If the game was a more typical 3D action-adventure or FPS/TPS shooter, then using one of the two engines might have been much better for development time. But this is a complex 2D sandbox simulator with procedural generation and a custom physics engine, so I'm not sure how Unity or Unreal might aid in developing this game in any way.
I’ll pick Unity to talk about here, because I have the most experience with Unity.
I’ve gone in more depth discussing Unity “off the beaten path” before and I think people really overestimate how much you are constrained by the way Unity works. This applies both to seasoned Unity developers and to people who only take a quick look at Unity.
I claim,
- You can use your own physics engine with Unity,
- You can model entities however you want with Unity, even not modeling them as GameObject instances containing MonoBehaviour components,
- It is completely reasonable to develop an actual, real game this way, under realistic staff / expertise / schedule / budget constraints. (In fact, it is known that certain successful commercial games do this.)
Just to focus on a more specific example—let’s say you need your own physics engine. What’s an easy way to do that? Create your physics engine, and have it control the positions of Unity GameObject instances. This way you can easily set up test scenes in the Unity editor and see the results by hitting “play”.
Unity gives you this fantastic GUI for setting up these test scenes and a renderer you can use to visualize your physics engine behavior.
This is really not “abusing” the Unity engine in any way. The engine provides physics simulation, but it does not force you to use it.
Likewise—I’ve written games in Unity that do a lot of procedural generation, and I’ve written games without an off-the-shelf engine that do procedural generation. There are a lot of things that make it easier in Unity, and I’m not spending as much time fussing about with builds, or dealing with input, or figuring out how to port my game to other systems. Unity provides an API for me to create a mesh at run-time. During procedural generation, I generate the meshes for generated chunks of terrain, and the data structures look very similar to the way I would have written the data structures in my own engine.
Since you seem to have much more experience in developing games, I'll take most of your word here.
Though from my four years of experience in Unity (albeit at a non-professional level), I was always fighting with the engine when trying to build new things. Trying to build complex UI code using Unity's built-in system was a mess, the serialization system always had weird errors and didn't really work well with version control, adding custom rendering to the rendering engine was full of hacks, and the documentation was quite poor for the more obscure/hidden aspects of the engine up to the point that I was thinking "I can just write these in C++/OpenGL, why do I have to go through all of this crap?". Nowadays I do gamedev at a lesser capacity (and doing more general graphics programming in C++ instead), and since several years ago I haven't really looked too deeply into the engine. I think doing all of these in Unity isn't impossible, just that I'm expecting a lot of friction while doing it.
There always seems to be some really good indie developers who are stretching Unity to its limits though (such as Manifold Garden). I always wondered how much they were fighting with the engine to make some specific features.
Yes, I think about Manifold Garden a lot when talking about limitations in the Unity engine.
There definitely are limitations in the render pipeline, and I’ve spent time frustrated because I know how to do something in OpenGL but can’t figure out how to do it in Unity. But the rendering pipeline in Unity has become far more flexible in recent years, and you can make your own custom rendering pipeline. Look up "custom SRP" videos on YouTube if you want to see what that’s like. Here’s one such video: https://www.youtube.com/watch?v=91zUwJwkXNQ
I do remember serialization + version control problems long ago, but these days, serialization uses a text format by default and if you are sufficiently adventurous you can solve merge conflicts in your serialized data. Better to avoid merge conflicts in the first place, though.
