

Or in short, “custom engine” does not automatically mean “half-baked alternative to Unity”. MonoGame) or platform abstraction library (e.g. Some games have fairly custom needs and aren’t a good match for existing engines (like No Man’s Sky or Minecraft) 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. 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. 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. You might also have a valuable mental toolkit that is squandered when using an existing engine.

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. You don’t need a sophisticated custom level editor, you can just use something off the shelf like Tiled. “Make games, not engines” is fine advice in general but you can make an engine for your specific game without making that engine look like Unity. 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”.
