So I’m doing this, Spaceport Manager is going to be made. The only question at the moment is which game engine or framework (if any) to choose. I went over this with a friend who knows actual game developers, and this post roughly reflects the state of our conversation, plus the conclusion I eventually arrived at.
What I Want to Build
Spaceport Manager will be a base-building game where players build space ports and keep them running. As such, it will probably draw some inspiration from Dwarf Fortress, Prison Architect, Sim City, Rimworld, and others. It’s most likely going to feature a 3D top-down or isometric/angled view, although I’m still considering a 2D world as well. In any case, the game’s main view will be a map displaying some dynamically generated planetary environment and then a lot of buildings on top of it. There will be lots of people and machines milling about. Spaceport Manager is expected to make somewhat heavy use of advanced UI elements such as windows, list and tree views, and possibly 2D visualization widgets.
Any game framework or engine must at the very minimum fulfill the following critera:
- run with minimal effort on current Windows, Linux and OS X installs
- be friendly to dynamic content
- allow for a reasonable programmer-centric workflow (as opposed to designer-centric)
- enable extensive customization and UI work
I considered 4 choices for this project:
Choice A: Unity 5
A lot of games are getting made with the Unity engine. From what I can tell, Unity enjoys exceptional support from the indie game community, and it’s the default engine for Ludum Dare. Its 3D engine is certainly impressive, giving developers easy access to an almost AAA-level graphics implementation. Programming happens in an ancient dialect of C#, which is not the worst thing in the world, and apparently performance is decent.
On the con side, you can never “own” Unity, you need to rent it for 75 bucks per month plus some revenue sharing. While that cost is relatively low, the thought of renting a content creation tool and losing access to it when I stop paying bugs me. When using Unity, you are expected to buy things from its asset store, which I am not necessarily opposed to. However, my expected use of both the engine’s central 3D editor as well as the asset store is very limited given my game’s nature. If I choose Unity, I will spend most of my time writing C# code that puts objects on the screen, and this gives rise to the feeling that the engine is probably not designed with that specific use case in mind.
If I use Unity, my game will probably run fast on all platforms, and it will look great. However, I will probably spend a lot of time both learning how to use the engine and re-inventing the wheel because my game would probably be an off-label use case for Unity.
Choice B: Unreal 4
The Unreal 4 engine is a top-of-the-line choice, it’s what a real game dev studio would use. The graphics capabilities are simply amazing, and it too runs on every conceivable platform.
Like Unity, Unreal 4 centrally features its own 3D editor, an amazing tool I’m not going to use. Programming-wise access to the Unreal engine is facilitated through C++ or language FFIs.
The pros and cons are in fact absolutely similar to Unity. The central concern remains that my expected workflow will be very different from the use case these engines are optimized for.
Choice C: from scratch
To be honest, this is instinctively my most favorite option: build the game in C++ with OpenGL and SDL bindings, and maybe a script interpreter like Lua. However, since the clock is actually running on this project and I want to get a reasonable prototype out of the door quickly, I’m shelving this option for some future endeavor.
Choice D: Chromium Weirdness!
This one is a bit out there: I could just use the Chromium browser as a platform. It has decently fast WebGL and general hardware acceleration support, and it can be combined with web workers and the node.js runtime to write actual desktop apps. But why would someone do this?
On the con side, web technologies are certainly not fast by any stretch. I recently made a dungeon-crawler prototype in WebGL only to discover it was unplayable on my friend’s laptop even though the graphics were straight-up nineties level. If I used this, I would be relatively free as a developer in any sense, but the cost would be that the game could only run on recent hardware, and the graphics quality would be …underwhelming. Mobile and console versions of my game would be out of the question.
Like almost everything in life, this project starts of with a choice driven by weighing tradeoffs against each other. Whatever I do, I am faced with the possibility of discovering insurmountable problems at a later stage, at which point I would have to trash everything and start over. This risk seems especially prominent with the Chromium option, but I can see similar issues cropping up with Unity down the line. Even considering the Unreal engine, some nagging doubts about the cost of wheel-reinvention and off-label use remain.
Knowing the risks, I choose the Chromium option, for several reasons. Most importantly, my familiarity with the platform will ensure a reasonable speed of development from the get-go. If I accept the comparatively bad visual quality of the end product, the only potential showstopper will be crushing performance issues. The number of unknowns is probably small. From my current perspective, there is more potential for unwelcome surprises hiding inside Unity and Unreal.
How Could You?
I’m not sure it can work out, but I’ll certainly try. I’ll revisit this decision if something serious comes up. If this fails, I’ll blog about it, hopefully this will be useful to someone having to make a similar decision.