Dev Diary 187 - Performance & Optimization

I’m Joel, and I’m the Technical Lead on the Crusader Kings III team. I’m at the start of my second decade working with Crusader Kings in various roles, having originally started out as a designer for CK2.

Before we get into the details of how we’ve worked to achieve better simulation speeds, I’ll hand it over to Daan for a quick summary of our results.

Straight-to-the-Point Summary

So you want some quick info and conclusions up front? Let me try and summarize it for you!

With All Under Heaven included, the game is about 30% to 40% bigger, in the sense of the amount of playable land, and playable living characters. We focused on reducing simulation tick duration to keep the experience as close to CK3 as it is now.

Our numbers, measured on both low-spec and high-spec machines, indicate that we have reached tick speeds comparable to the current live version. Comparable means we are slightly slower in the early game, but on-par or slightly faster in the mid to late game, running at speed 5 over 150 to 250 years, starting in 1066.

The following graph shows tick duration over 150 years compared to the current release (higher means longer tick duration, therefore slower):

[Rough Tick Duration Graph - Red: All Under Heaven, Yellow: Current Version]

We also implemented GUI, 3D graphics, and memory-usage improvements, though they were a lower priority than simulation speed.

Caveat: Results will vary by the world you create and the world the simulation creates around you! There is no single number or graph that covers all games, hardware, and play styles, but we have aimed to deliver a playable, stable, fast experience with All Under Heaven.

That’s the short version. If you want more details, more graphs, and more insights, then please read on!

Definitions

Now let’s get back to the regular schedule and start digging into the details

First, we need to define what we mean when we say speed or performance. Normally, when we talk about performance, we refer to two categories: rendering and simulation. When developing DLCs for Grand Strategy Games, we create more systems and objects to simulate over time. Graphical complexity will also increase with more development, but during DLC development it rarely causes new bottlenecks for us.

However, increased simulation demands put more load on the CPU for calculations and data transformations due to new features and systems to keep track of. This makes the CPU our most common bottleneck when it comes to optimizing for simulation tick speed. So our most common task when it comes to optimizing the code for our games is to look at where our CPU-cycles are spent and where we can be more efficient, in order to keep down the average time-per-tick for a playthrough.

This makes the time-per-tick measurement the most important metric for us to track throughout development, and the one we will be talking about the most in this Dev Diary.

Measuring Performance

So how do you get accurate measurements for tick speed when working with a complex simulation? There are many variables in play that will affect the final outcome. Examples of variables that affect results include: graphical settings, hardware, test length, early- or late-game state, background tasks, and random variation.

All of these variables matter in analyzing how the game performs, but we also want to stress that most of our performance improvements are going to have a similar effect across the board of different hardware. For that reason, the most valuable test is early-game tick performance on fixed hardware with