So we have a system of locks when the render thread needs to access the gamestate, the gamestate isn’t allowed to change itself, and when the gamestate is changing itself, the render thread must wait until it can access the gamestate. It still needs to synchronize a lot with the main thread, as we can’t be checking an object that’s being changed. In CK3 rendering is a separate thread rather than done on the main thread.
And it tends to be easier to identify what could be parallelized than it was in CK2, resulting in more work being done in parallel than before.įurthermore, this works great with CK3’s new approach to rendering. Simplifying the rules means that fewer bugs are introduced, in particular OOSes. This allowed us to simplify the rules of what you can and cannot do massively: now during parallelism the only limitation is that we can’t change any visible information we must instead store the changes we want to do and then apply them a bit later in series.
For instance, we might update the scheme system at the same time as the opinion system. Now instead of processing several characters at the same time we instead process several different systems. We moved from object-level parallelism to system-level parallelism. So in CK3 we replaced this system entirely. There was also a significant overhead in having to process every character in the game with most checks just resulting in “we have no need to do this part of the update”. Occasionally it could even crash the game. Violating one of these rules would generally result in an OOS, breaking the multiplayer experience. The biggest one being the various rules on what the programmer can and cannot do in each update.
However, there were also some significant drawbacks. Similar setups were applied to other objects too, like titles, plots, etc. In practice it worked reasonably well CK2 is a heavily parallel game and has had significant speed gains from increased parallelization. These restrictions meant that these updates could be done in parallel each thread doing the same section for a different character. During another, it would be illegal for it to change any information it owns that is visible to other characters. For instance, during one part it would be illegal for one character to check any information that belongs to another character. The daily update for characters were split into a handful of segments with different rules for parallelization. The way we structured this in CK2 was largely based around the characters themselves. The rendering would then take over entirely until done with the frame.ĭuring gamestate updates it would thread a large number of different operations. In order to render frames so the users can see what’s going on, it would periodically stop updating the gamestate in order to make a frame instead. The main task of the main thread was to update the gamestate so the game progresses. The game as a whole was structured around the main thread. The two are heavily intertwined, so much so that you can’t really talk about one without talking about the other. The two systems that differ the most from CK2 for the sake of performance are threading and rendering. Our approach to a number of tech systems differ from CK2 for the sake of performance, and this has given us some great results. As such performance has been a priority throughout the development of CK3, and especially as it has neared release. The release version today feels like molasses compared to how the game performs after its long and venerated life.ĬK2 has been a standout amongst PDS’ games when it comes to performance, which means we have a lot we have to live up to. Over the course of CK2’s lifecycle we made numerous improvements to performance, and when Holy Fury released it was the best it has ever been. Let's start off by talking about performance. Today I’m going to talk about how we’ve worked with these two areas in CK3 to ensure a better game experience than CK2. Of particular relevance today is my work on performance and AI in CK2. You might know me from my work on CK2 and the Paradox Wikis. I’m Magne “Meneth” Skjæran, one of the programmers on Crusader Kings 3.