Designing Pillars of State - Tech Stack

Game developers love arguing about 2 things: engines and programming languages. Which engine is better? Is it even possible to build a game without C++? Why would someone not use an engine in 2023?

As someone who has worked in software engineering and data science for the last 6 years and designed/built large-scale applications, you learn the most important phrase to answer any question.

It depends!

Everyone hates this answer, but the real issue at hand is: If you ask an ambiguous question, I have to give an ambiguous answer. There is another important concept that needs to be mentioned and it is highlighted in software/solution architecture.

The perfect solution doesn't exist. Stop trying to find perfect and instead flip the question. Find the least-worst solution.

I know this sounds odd, but thinking this way helps reduce decision paralysis and helps you stick to your decision when a better alternative is presented to you during development. We don't have to rebuild the same application because there is a better framework out now, it works and we don't need perfect. We don't need to change game engine mid-project because a similar game launched in that engine.

Engines, languages and frameworks are tools to help progress your project from idea to launch and beyond. You can build virtually any game in the big 3 engines: Unreal Engine, Unity, Godot. If you aren't sure which one to pick, make a very simple game in each one and see which one you prefer; this could be a very small platformer that you are never going to show to anyone and only takes 1 week tops. The question I ask myself when selecting an engine for a project is:

Is there any reason I can't use this engine for this project?

I have used a bunch of engines over the years for different projects and I had to run through this question for Pillars of State:

1. Godot: Supports C/C++/C#/GD Script out of the box. I created an agent test for A* pathfinding and could hit 2500 agents before dropping below 60fps. This was a good start, but I wanted more control and felt I would be fighting the engine in a few areas.

2. Unity: Supports C# out of the box. Rimworld was built in Unity and there are a large number of successful 2d games built in it. DOTS provides a form of entity component system (ECS) that helps with high performance at scale, but I have been frustrated with Unity in the past as features often lack documentation.

3. Unreal Engine 4/5: Supports Unreal C++/Blueprints out of the box. Probably the most impressive engine available and previous agent tests have shown it to handle large numbers of agents. In my experience though, UE4/5 is great for teams of 3+, but the engine has a lot that needs to be altered to work for Pillars of State.

4. Bevy: Written in Rust for Rust. I am a big fan of Bevy and it could be utilised for a project like this with the engine's current alpha state. The main problem is they advise against big projects during the alpha as the API will likely change every 3 months. This is an issue if you want to keep up to date with engine updates, and the state management needs some more work before I would be comfortable with it for Pillars of State.

5. C++/SDL2: Not an engine, but SDL handles the windowing, basic graphics and input. SDL2 supports OpenGL or Vulkan which means if rendering is the bottleneck, I can switch the renderer from SDL2 to either one for a performance gain. Whilst C++ is a lot more work than C#/GD Script/Blueprints and I prefer working in Rust, it can integrate with many other existing libraries or tools that I want to use.

Running through this question led me to choose C++/SDL2. I am not capable of amazing art or 3d models, so I will be sticking to Pixel Art like my other games. Games of similar complexity and depth have been written in C++/SDL2, and the lack of overhead from other engine features will reduce rewritting and wasted resources. Plenty of people will say "don't reinvent the wheel, use an engine" but the key differentiator for Pillars of State is that I don't need complex physics or rendering that engines provide, and I won't need to implement my own.

Because I am planning on creating lots of agents, I will be following data-oriented-design patterns and have implemented the EnTT package. This is an ECS used in many games and applications like Minecraft and Ragdoll for performance improvements. I will also be adding FMOD, a commonly utilised audio package for SFX and music in the game.

I am still making decisions in two areas: scripting and GUI. The conventional way is to support LUA for scripting as it easily integrates with C++ and is performant. I have been considering Python as it is a cross-domain language making it easier to integrate other packages into the game or for modders, but it does have some security concerns. For the GUI, I have no interest in rolling out my own and I am considering Dear imGui or Nuklear. I don't have experience implementing either of them, so I will need to run some tests to see which one I prefer.

Overall, the key takeaway is that engines and languages are tools to help you solve the problem at hand. Play around withh your options and select one that makes you happiest, keeps you motivated and supports you in solving the problem.

There will be more posts in the future about specifics, but if you have any comments or suggestions, I would love to hear them.