There are a variety of common versioning systems and choosing one indicates a lot about the way you plan on managing and releasing your product:

• 3-digit semantic (major.minor.patch -> 0.1.0): Anything above 1.0.0 denotes release, and anything below denotes pre-release. Early access for Steam requires your project to be released within 1 year, therefore you need to be 1.0.0 by that time.

• 4-digit semantic (major.minor.patch.build -> 0.1.0.42): Similar to the 3-digit semantic, but you also include the build number. The build number could be anything, but I have seen this be the number of days since development started, each version compilation, or some other internal identifier.

• Calendric (YY.MM/YYYY.minor.patch -> 23.01/2023.1.0): This is great for projects in constant development or SaaS projects. It lets your client know how recently an update was put out but also has the downside of highlighting dead projects.

• Percentage (0.42 -> 42%): This is rare, but famously used by Dwarf Fortress until launching on Steam. This requires you to know your project's scope in full, so you know how far along you are. Zach and Tarn Adams write a story about the world of Dwarf Fortress, identify work items in the story, apply a percentage to the story and when completing the work items adjust the release percentage.

I love the idea of writing stories and generating work items from the text. I think this is a great way of defining scope through narrative, and it is similar to epics/user stories used in agile project management; the dominant project management methodology in the software industry. I don't however think using percentage versioning is a good idea for most people.

Even though versioning is often used to communicate the state of a project with users, it is a great way to help with motivation. It gives developers an easy way to set milestones which can be achieved and celebrated. Motivation is often lost because projects seem unachievable, and it is because developers fail to put in motivational strategies.

For Pillars of State, I plan on combining stories with the 3-digit semantic versioning. 1.0.0 would still be considered a release, however, stories would define the minor version steps (e.g. x.1.x -> x.2.0). This has the added benefit of controlling scope and targeting user suggestions, as users can read the story and suggest elements that might not have been converted into work items already. Scope creep is a major issue in most projects, but can be a killer in complex projects with user interaction.

I imagine anyone who is still reading by this point is a project manager who wishes all developers would value project management more, but the key point to take away is simple.

Empathise with your future self by utilising little methods to help with motivation and success.

In the next blog, I will be writing a story for Pillars of State, reviewing it for work items and looking at project management tools. In the meantime, if you have any comments or suggestions, I would love to hear them.

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.

Introduction

Pillars of State is a game I'm making which combines colony-sim with grand strategy and therefore risks not motivating players with a story or aim to keep them playing. Games like this need to rely on alternative strategies such as Apophenia or engineering experiences. Both of these strategies have been discussed in detail by Tarn Adams (Dwarf Fortress) and Tynan Sylvester (Rimworld & Designing Games) to make colony-sim games fun. Apophenia is the tendency to perceive a connection between unrelated or random things and is heavily utilised in Dwarf Fortress and Rimworld to let the player's brain do the heavy lifting of story generation and emergent behaviour. In simple terms, to achieve Apophenia you need to engineer experiences by generating a variety of events, making information accessible to the players so they can latch onto it, and having this cocktail be enticing enough for the players to drink from.

I find the best way to design a game is by studying games that inspire you and your idea. Identify what they do to achieve their aims and adjust as you see fit. Ultimately, there is no perfect implementation, our job is to find the least-worst design.

Reviewing

Dwarf Fortress is the inspiration for many famous games including Minecraft, Factorio, Project Zomboid, Rimworld, and many more. I have played a lot of Dwarf Fortress over the years, starting with ASCII on the classic edition, before moving into the Steam version. My best experience with the game happened because 3 dwarf children climbed a ladder into an apple tree I had assigned to be harvested, the ladder was moved to the next tree and the children were stuck in the tree. I wasn't aware any of this happened until I had a frightened dwarf run to my tavern to drown his sorrows in ale after seeing a dead child fall from a tree next to him. Before I could save the 2 remaining children, 2 more dwarfs came running into the tavern to also drown their sorrows.

None of this was planned or scripted, it was emergent behaviour caused by layering simple systems on top of each other until complexity arose. My brain, however, perceived this as 3 children trying to surprise an apple picker because they were bored. They had fallen asleep when the ladder was moved and thought someone would notice them. My dwarves were so busy with all the work I had assigned them that the parents had failed to keep an eye on the children and their deaths were caused by me driving my dwarves too hard. This was a powerful gaming experience for me, and the game didn't provide me with a story, only the events in which my brain filled in the blanks.

Rimworld is similar to Dwarf Fortress but puts the focus on the colonists and turns the social dial up to 11. Whereas a fortress in Dwarf Fortress typically starts with 8 agents and scales to 200, Rimworld typically starts with 3 and often only scales to 15-20, though it can go higher. Rimworld has this habit of making you care for colonists through their impact on the colony and ability to solve the problems you need them to. I once had a colonist who seemed to solve every problem I ever had, yet they watched as the person they loved got married to another colonist they hated. I was so attached to this colonist that when they got infected from a bullet wound during a raid, I sent out most of the other colonists on a mission that rewarded me with antibiotics. The group was not prepared for the mission and they were ambushed and killed before they got home, leaving my favourite colonist to die and 1 colonist remaining to manage the fort.

Whilst this wasn't planned, Rimworld uses different AI storytellers to adjust the game based on your decisions. Each time I solved a problem, the AI increased the chances of escalation to add to the experience. This escalation led me to become attached to the colonist that helped me the most, furthered by their emotional rejection and then the random chance of being shot during a raid. To me, this was a similar experience to the weed mission in Far Cry 3 or Ghost's death in CoD MW II. This rollercoaster of emotions was achieved through emergent behaviour, AI-engineered experiences, and Apophenia.

Finally, I have been playing a bunch of Songs of Syx, the epic city-state simulator. I have really enjoyed the take on colony-sim/city-builder that Songs of Syx has taken, turning the agent scale way up to 50,000+ and adding large-scale Total War-like battles. Whereas Rimworld focuses on the colonist, Songs of Syx focuses on the state. We lose out on the unique stories that occurred in Dwarf Fortress and Rimworld but gain a feeling of grandeur and world impact that those games struggle with.

Analysis

I want Pillars of State to combine the agent scale of Songs of Syx with the depth of Rimworld. This is an easy claim to make, but far harder to back up. With each design decision in a simulation game, we are not only adding development work but also removing compute power from our cap. All decisions must be worth the performance impact.

Because of my background in Ancient History and Archaeology, I have spent years studying the relationship between the individual and the state, and low-ranking individuals are rarely covered in history, which is a shame. There is no possibility of providing agents with a Rimworld-like depth and then generating 50,000 of them. This could be optimised by creating lots of simple agents and then adding fewer but more complex agents throughout the social hierarchy. There would be a disparity between agents and there is a good chance this could be jarring or hard to communicate with the player. On the other hand, this gives a personal narrative to the state's decisions and lets the player see how their choices impact agents throughout the social hierarchy.

Having both a state-level and agent-level simulation gives us 2 areas for engineering experiences and Apophenia. Rimworld and Dwarf Fortress have succeeded with Apophenia because they are so focussed on the agents, and we as players can best associate at a personal level. I believe this means state-level Apophenia is still possible, but there must be smaller tangents between events if it is strong enough to motivate the player. Engineering experiences are a bit easier with the state-level simulation as existing grand strategies like Crusader Kings III, Hearts of Iron IV and Europa Universalis IV all push the player to make compelling decisions that excite or frustrate them.

Conclusion

Pillars of State needs to combine both state-level play and agent-level play if people are going to enjoy it. By creating simple agents for simulating most state-level decisions, players can focus on more complex agents who act as an analogue for their actions. The state-level play requires compelling events which impact all aspects of society and integrate with the complex agents, reinforcing the Apophenia within the player.

Development should iterate features and simulations as follows: add state-level decisions (e.g. process grapes into wine); add a new task of processing grapes to simple agents (e.g. workshop or building to process grapes); add new events related to celebrations and alcohol (e.g. character was stabbed in drunken argument and lost an eye); add new state event related to festivals and trade (e.g. wine is traded with a nearby state); add new social impacts of state on agents (e.g. losing an eye is a punishment in the nearby state, they perceive the character as a criminal and refuse to buy his wine).

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

After chatting with my two best friends who had studied Electronic Engineering and Computer Science, we decided that we should build our perfect game and use this as a way to learn/improve our coding. After 3 years of learning and building, switching from Unity to Unreal Engine 4, we realised that this project was beyond our skill. We had managed to get a very basic game working with multiplayer, but it had several major issues: it wasn't fun; the scope was too large; and when we tried to implement saving, we realised we were going blind to each new section. A little bit of research highlighted we had fallen into the typical trap, we should have been building small games before we ever attempted a major project.

Don't start with a dream or major project for the first few games. You need experience across the whole lifecycle of a project.

By 2017, I had gone back to uni and done an MSc in Archaeology, specialising in computational archaeology and predictive modelling. With 3 years of learning to code and an MSc, I got my first role as a full-time developer. During this time I built a handful of little projects but didn't release any of them, however, spending so much time coding meant that I was learning a lot at work and home. Now in 2023, I have gathered enough experience to try my hand at a large project again.

Pillars of State (working title) is a colony-sim with grand strategy combined, set in a procedurally generated ancient world. Think Ancient Greeks, Romans, Ancient Egyptians and more, meets Dwarf Fortress, Rimworld and Songs of Syx.

Generate a world populated with different cultures, city-states/poleis, geography, climate, and historical events. Select a city-state/polis as a "mother city", land to colonise, and supplies for your colonists. Once in the game, the main loop consists of 3 parts: Survive; Thrive; Expand.

Surviving is the first part. Build housing to shelter your people, farms and fishing zones to provide them with food, manufacturing for processing wood and mud bricks. Once your people can fend for themselves, it is time to make them thrive. Improve the manufacturing to collect and process better resources like marble/sandstone/limestone, build temples/education/tavernas, and provide luxury goods like olives/grapes/wines/food varieties. Once your people are happy, it's time to expand and become a powerhouse through trade, war or both. You can then settle more colonies or expand your settlement into neighbouring areas. Maybe it is even time for war against another state.

I will go into more detail in future posts, but if you have any comments or suggestions, I would love to hear them.