Custom Game Engines: A Small Study
Unity, Unreal, Godot, Game Maker etc are all so popular these days it’s easy to lose sight of how you can make a game with a “custom engine”.<p>“Make games, not engines” is fine advice in general but you can make an engine for <i>your specific game</i> without making that engine look like Unity. You don’t need a sophisticated custom level editor, you can just use something off the shelf like Tiled. You don’t need an extension language (like C# or Lua), you can just do the whole engine + game in one project, with one language.<p>You might also have a valuable mental toolkit that is squandered when using an existing engine. I can’t count all the times I’ve said, “I know how to implement that, but not in Unity.” My mental model of how objects are drawn to the screen consists entirely of buffers and shader program invocations. There are also plenty of games that just don’t benefit from some of the core features of engines, like physics, and need to roll their own anyway.<p>Some games have fairly custom needs and aren’t a good match for existing engines (like <i>No Man’s Sky</i> or <i>Minecraft</i>) and some games (especially 2D games) have very simple needs and an engine doesn’t provide as much of an edge over something like a framework (e.g. MonoGame) or platform abstraction library (e.g. SDL).<p>Or in short, “custom engine” does not automatically mean “half-baked alternative to Unity”. Just how it’s totally fine to make your next web app backend without using a high-level framework, and it’s totally fine to make your next frontend without React. If anything, it’s easier than ever to make a frontend without React, just like it’s easier than ever to make a game without Unity.