Devlog #007

Posted by Kenneth Ellersdorfer

Hello Capitalists!

It's time for a new update about the state of capitalist empire. Let's dive right in!

Playtesting

Since the last devlog, there haven't been many new features added. This is mainly due to my focus on playtesting the game for a new round of testing, along with being somewhat tied up with other work commitments 🥲.

My primary focus has been on playtesting, balancing, and incorporating small quality-of-life improvements. As of writing this devlog, I've made approximately 65 changes based on my playtesting. The process was fairly straightforward: I played through the game from start to "finish" (tier 3 residents), taking note of anything that felt frustrating or unclear, then addressed the issues before repeating the process. I've done this several times now and feel the game is in a good enough state to be tested internally by other players.

During testing, I also discovered some mechanics that simply don’t work and will need to be entirely replaced. Additionally, I've hit a roadblock with Dear ImGui. Unfortunately, it's proving difficult to further enhance the UI for optimal usability without a significant amount of work. (Just to clarify, this isn't a fault of Dear ImGui, which is not designed for end-user or player-facing interfaces.)

In the previous post, I outlined plans for a new user interface, and I've already begun development on this new system. However, it's still in the very early stages, so there isn't much to show at this time.

Trains

Now, let's talk about the first gameplay mechanic that just doesn't work: Trains.

This is a bit frustrating because I spent a significant amount of time implementing the current train system, which is essentially a simplified version of how trains work in games like Factorio and OpenTTD. The process of setting up and debugging the network grid separation was particularly... let's say "challenging".

However, despite the effort, the system just doesn't work well with the overall game. It’s overly complex, punishing if mistakes are made, and it doesn't align with my vision of creating a game that is easy to learn but hard to master. So, it needs to be replaced. The big question is: with what?

The new system should be intuitive, easy to use, and hard to master, without being too punishing, and it needs to scale easily. While I don’t have a concrete solution just yet, I’ve been considering a system where trains automatically try to avoid collisions but don’t impose heavy penalties when they do happen. For example, if two trains collide, they could slow down significantly for the duration of the collision. The result of a poor rail network would then be increased latency, which in turn would decrease bandwidth.

This is the direction I’m leaning towards, but I haven't fully planned it out yet. Rest assured, I'll keep everyone updated on the progress 😃.

City building

The next feature that needs a complete rework is city building.

This is one of the oldest features in the game, which I originally implemented over three years ago, and since then, I haven't made any significant updates to it. It's no surprise that it’s finally time to address it. There are several bugs causing strange behavior:

For example, in this screenshot, the building system fails to recognize that the store has been placed by the player, and it continues expanding the city as if the store doesn’t exist. There are also a number of random bugs that seem to occur sporadically, resulting in cities being built in strange ways or buildings trying to overlap with one another. While these issues might be fixable, there are also some conceptual problems with the system:

  • It only supports 1x1 buildings, and that's it. There's no straightforward way to address this limitation.
  • It only supports building in a very specific pattern, with no flexibility for anything else.

Given these issues, the best course of action is to develop a completely new solution that resolves all of these problems.
By the way, I didn’t want to withhold this screenshot from you—it shows a fully developed tier 3 residents city where the system worked pretty much as intended:

The Setting

I’ve also started giving more thought to the game’s setting and what I want the final product to feel like in a more concrete sense.

While it’s clear that the game revolves around capitalism, I’ve begun considering the time period it should cover and how deep I want to explore the "good" vs "bad" capitalist conflict. My plan is to start the game in the early Industrial Revolution, also known as the "Steam Age." From there, the game will progress, moving forward in time as I continue developing it for as long as I develop it. 🙃

On a related note, this fits nicely with a design concept I’ve been playing around with in my mind for a while - making research work in a way similar to Age of Empires. The idea is that players could research technologies, and once they reach a certain milestone, the game would advance into a new era, such as from the "Steam Age" to the "Oil Age." While this is still just an idea in my head, it’s something I’ve been thinking about for a long time, and it’s starting to look more and more intriguing.

As for the "good vs bad" aspect, it could be really interesting to incorporate elements like politics, corruption, company policies (like a 4-day workweek), or even a "personality" system for the workers. This would allow for a more defined path toward being either an evil or a good capitalist. The specifics of how this will be designed aren’t finalized yet, but I think it’ll be an interesting element. Plus, it feels like uncharted territory - there are very few games that have explored this approach, which makes it even more exciting for me to experiment with!

Optimization

I’ve started optimizing Capitalist for the next testing round to ensure that larger save files, up to tier 3 residents, can run smoothly even on older machines. I’ve only done a few passes with JetBrains dotTrace, addressing the most significant performance bottlenecks. Here’s a screenshot of an "endgame" save running easily at 16x game speed on my development machine:

The fact that the game already runs so smoothly is honestly incredible to me, especially considering my background with Unity and its outdated Mono runtime. .NET brings C# on a whole new level. Microsoft and everyone involved in its development have done an absolutely amazing job bringing C# closer and closer to C++ in terms of performance. It now feels very similar to writing C++ code in this regard, which is just fantastic.

That said, I still plan to optimize the game before any public release to ensure it runs as efficiently as possible. I've already compiled a small list of conceptual reworks for this purpose, most notably:

  • Vehicle simulation must be parallelized
  • The logistics solver needs a complete rewrite (and parallelization)
  • Pathfinding graph optimization (ignore "straight" nodes and only create a node where there’s more than one entry and one exit)
  • Many more systems that should in theory be able to run in parallel but currently don't

Overall, my goal is to redesign many of the systems to be parallelizable and highly optimized so that they scale well on machines with multiple cores, especially when dealing with large worlds. I’m confident this is achievable, though it’s going to be a massive challenge - one I’m actually really excited for 😄.

That's it for this devlog.

Thanks for reading!