Devlog #009

Hello Capitalists!

It's time for another devlog, this time I got news about the trains, the new land ownership system and more!

Since the last post, trains have undergone another round of optimizations.

I've implemented a hierarchical pathfinder for trains and trucks, which was a pretty massive improvement for the game across the board. I also had some time to write a debug visualization for this pathfinder to see what exactly it is doing:

Instead of the "naive" A* grid pathfinder that has to visit every tile, this pathfinder only visits intersections where straight paths cross.
The visualization shows the final path as connected nodes in red. Visited nodes are shown in light blue and connect to the node they were visited from in light green.

Compared to the old pathfinder this is quite a lot less lookups:

As can be seen here, the new pathfinder avoids many node visits and I've also benchmarked this so I can post some numbers about this - I benchmarked 2 scenarios:

• "Simple" network: 3 horizontal trunks, 3 diagonal rungs per trunk pair
• "Complex" network: 8 horizontal trunks, 6 diagonal rungs per trunk pair

For both algorithms I benchmarked 1000 (uncached) pathfinder calls:

• The old algorithm scores ~55 ms on the simple network and ~939 ms on the complex setup
• The new algorithm however scores ~15 ms on the simple network and ~66 ms on the complex setup

This makes for an improvement of ~3.5x for the simple case.
Simple cases however are not what the average player so far did with trains 😃

The complex setup is ~14x faster than the old pathfinder.

I really like how this turned out and the next step on this front will be parallelizing the pathfinder so multiple queries can run at the same time. I did a first step in that direction by revamping my engine's job system, but for now I'm done and satisfied with the new vehicle pathfinder.

I've also been working on the new land ownership system I wrote about in the last blog post, and it's fully implemented now and it kinda works but it doesn't yet feel complete. I have however decided to keep it as is for now and flesh it out in later development stages.

The problem with it is that it feels a bit like an arbitrary, unnecessary restriction.
I made sure that the rest of the world generator properly "behaves" with this new mechanic, so for example resource nodes are not spawned too close to the border.

But still, it feels a bit off at the moment. I think however it will work, if combined with mechanics such as politics, work force access and other meta-level decisions that push the game more towards high-level strategic thinking.

I'll see where this leads me, not sure yet how this one will play out 🙃

Another rather big feature that I kept pushing back and back on the backlog was terraforming. As it turned out, implementing it was pretty straightforward.

The controls and concept behind it are pretty simple, drag to select the area you want to change, then drag up / down when in "raise / lower" mode or see the preview in "flatten" mode equalizing the height level. Then click again and it's applied:

This feature opened up another next feature to implement that I wanted to implement for a very long time now: Rivers!

So let's talk about them next.

Now this one was a hard nut to crack, I did not think that it's this complex to create organic-looking rivers and optimize the generation code to be fast enough for procedural generation. First things first, here's a screenshot:

First I had to define where rivers start and where they end? There's currently 2 types of rivers:

• Start at a lake, end in the sea ("Lake rivers")
• Start on a random edge-map tile, end on a random edge-map tile ("Through rivers", as in "passing through" the world)

Now the world generator first  checks how much of these 2 river classes should there be, then checks how many it can actually build and uses the "passing through" rivers as replacement when it determines it cannot spawn a proper lake river.

I'm pretty happy with the end-result, they do not contribute much to the gameplay (yet? Not sure if they ever will), but they sure make the world look much nicer.

I've also already put a task on the backlog to implement a  flowfield based river renderer, so rivers will actually animate like flowing water. This will look super cool I think, but unfortunately don't have the time for it now 😶‍🌫️

Now this is a pretty controversial topic that gave me many headaches and hard decisions to make.

So far I've only used GenAI to draft concept art to then have proper art created and I don't think I will change this decision in regards to "production" assets.

However, I've always rejected using GenAI for writing production code in Capitalist Empire and Sparrow Engine. Over the past six months I've been experimenting with different LLM-assisted workflows - from small side projects to limited experiments in the Capitalist Empire codebase - to figure out where they genuinely help and where they don't. At this point I've settled on a handful of things that I consider genuinely useful:

• Code reviews: Probably the absolutely best use case for LLMs. The number of bugs it catches even on code of experienced developers is genuinely impressive. I use manually-authored, pre-written "pattern" files as instructions for the agents that list bugs that are easy to happen with my engine and specifically for Capitalist Empire, this dramatically increased the finding rate compared to "find bugs"-style prompts.
  
  
• Devtools: Probably my favorite use case. They're isolated from the game code, so they're low-risk, and they save me a lot of time while debugging.
  
  
• Throw-away work: Temporary work that I already know will be replaced later. Since it's well isolated, it's very low-risk. The current tutorials covering the basics for testers are LLM-created and fine-tuned by me for example. I do know they will never make it in the final game (because I want it to have a proper campaign), their code is highly isolated and they constantly change at the moment.
  
  
• Plan-Implement-Review: I first write a design specification. Then I work with an LLM agent to create an implementation plan, have implementer subagents carry it out, let other subagents do the codereview and fixes - and finally review all code myself. This can be used pretty well on isolated tasks, but on large feature implementations this still requires a lot of manual "de-sloppification".
  
  
• "Programmer art": I also recently let an LLM create some "programmer art" style 3D models to use until I have the funds to hire a freelance artist or (the better case) the time to git gud in 3D modeling and create them myself. This art, however, will not make it into the finished product.

The biggest risk I've found is that it's easy to stop fully understanding your own codebase. That's why I only accept LLM-generated code that I've thoroughly reviewed and completely understand.

I do understand that this is a highly controversial topic and that GenAI usage has a very bad reputation among gamers, but I do think LLMs are a great tool, especially for smaller developers, to speed up development of our projects. For Capitalist Empire I'd say LLM usage overall gives me approximately a 25% efficiency boost when working on the project. It's not what the marketing claims and will never replace software developers (at least I don't see that in the foreseeable future), but it's a nice tool that - I think - is there to stay.

So this was a pretty hard topic for me but I think it's the right decision to be transparent about my LLM usage, what I think about it and also give other developers some ideas on where to start using it effectively themselves.

I am actually right now pretty close to starting a new testing round. The only missing piece to it is fine-tuning, bugfixing, balancing and my own internal testing.

Unfortuantely it's pretty busy at work at the moment, so I'm not sure when I can get it ready for testing.
If you want to participate in testing, join the Noble Bird Games Discord server and send me a DM.

After the testing phase, I think the next things I will tackle are these:

• Research: A tech-tree, but I don't know yet how exactly it will work. One thing I do know though is that I'm pretty bored about the standard linear tech trees that every game has nowadays. I will think on this the coming weeks.
• Market simulation: Also not yet fully sure how I will proceed - maybe cities selling bonds, futures markets or a global stock market. Stay tuned!
• City building: Probably one of the oldest algorithms in Capitalist Empire. It's time to replace it now for good. Cities look horrible, they should build recognizable patterns and in general I want them to look way better.

So that's it for this devlog.

Thanks for reading, see you next time!