Victoria 3 News

Hello and welcome to this week's Victoria 3 dev diary. This time we will be talking a bit about performance and how the game works under the hood. It will get somewhat detailed along the way and if you are mostly interested in what has improved in 1.2 then you can find that towards the end.

For those of you who don’t know me, my name is Emil and I’ve been at Paradox since 2018. I joined the Victoria 3 team as Tech Lead back in 2020 having previously been working in the same role on other projects.


It’s hard to talk about performance without first having some understanding of what we mean by it. For many games it is mostly about how high fps you can get without having to turn the graphics settings down too far. But with simulation heavy games like the ones we make at PDS another aspect comes into play. Namely tick speed. This metric is not as consistently named across the games industry as fps is, but you might be familiar with the names Ticks Per Second or Updates Per Second from some other games. Here I will instead be using the inverse metric, or how long a tick takes on average to complete in either seconds or milliseconds. Some graphs will be from debug builds and some from release builds, so numbers might not always be directly comparable.

What exactly a tick means in terms of in game time varies a bit. In CK3 and EU4 a tick is a single day, while on HOI4 it's just one hour. For Victoria 3 a tick is six hours, or a quarter of a day. Not all ticks are equal though. Some work might not need to happen as often as others, so we divide the ticks into categories. On Victoria 3 we have yearly, monthly, weekly, daily, and (regular) ticks.

If you thought 1.1 was slow you should have seen the game a year before release…


Victoria 3 is very simulation driven and as such there is a lot of work that needs to happen in the tick. To keep the code organized we have our tick broken down into what we call tick tasks. A tick task is a distinct set of operations to perform on the gamestate along with information on how often it should happen and what other tick tasks it depends on before it is allowed to run.

An overview of some of the tick tasks in the game. Available with the console command TickTask.Graph.

Many of the tick tasks are small things just updating one or a few values. On the other hand some of them are quite massive. Depending on how often they run and what game objects they operate on their impact on the game speed will vary. One of the most expensive things in the game is the employment update, followed by the pop need cache update and the modifier update.

Top ten most expensive tick tasks in our nightly tests as of Feb 15. Numbers in seconds averaged from multiple runs using a debug build.

As you can see from the graph above many of our most expensive tick tasks are run on a weekly basis. This combined with the fact that a weekly tick also includes all daily and tickly tick tasks means it usually ends up taking quite long. So let’s dive a bit deeper into what’s going on during a weekly tick. To do this we can use a profiler. One of the profilers we use here at PDS is Optick which is an open source profiler targeted mainly at game development.

Optick capture of a weekly tick around 1890 in a release build.

There’s a lot going on in the screenshot above so let’s break it down a bit. On the left you see the name of the threads we are looking at. First you have the Network/Session thread which is the main thread for the game logic. It’s responsible for running the simulation and acting on player commands. Then we have the primary task threads. The number will vary from machine to machine as the engine will create a different number of task threads depending on how many cores your cpu has. Here I have artificially limited it to eight to make things more readable. Task threads are responsible for doing work that can be parallelized. Then we have the Main Thread. This is the initial thread created by the operating system when the game starts and it is responsible for handling the interface and graphics updates. Then we have the Render Thread which does the actual rendering, and finally we have the secondary task threads. These are similar to the primary ones, but are generally responsible for non game logic things like helping out with the graphics update or with saving the game.

All the colored boxes with text in them are different parts of the code that we’ve deemed interesting enough to have it show up in the profiler. If we want an even more in depth we could instead use a different profiler like Superluminal or VTune which would allow us to look directly at function level or even assembly.

The pink bars indicate a thread is waiting for something. For the task threads this usually means they are waiting for more work, while for the session thread it usually means it is blocked from modifying the game state because the interface or graphics updates need to read from it.

When looking at tick speed we are mostly interested in the session thread and the primary task threads. I’ve expanded the session thread here so we can see what is going on in the weekly tick. There are some things that stand out here.

First we have the commonly occurring red CScopedGameStateRelease blocks. These are when we need to take a break from updating to let the interface and graphics read the data it needs in order to keep rendering at as close to 60 fps as possible. This can’t happen anywhere though, it’s limited to in between tick tasks or between certain steps inside the tick tasks. This is in order to guarantee data consistency so the interface doesn’t fetch data when say just half the country budget has been updated.

The next thing that stands out is again the UpdateEmployment tick task just as seen in the graph above. Here we get a bit more information though. Just at a glance we can see it’s split into (at least) two parts. One parallel and one serial. Ideally we want all work to be done in parallel because that allows us to better utilize modern cpus. Unfortunately not all of the things going on during employment can be done in parallel because it needs to do global operations like creating and destroying pop objects and executing script. So we’ve broken out as much as possible into a parallel pre-step to reduce the serial part as much as possible. There is actually a third step in between here that can’t be seen because it’s too quick, but in order to avoid issues with parallel execution order causing out of syncs between game clients in multiplayer games we have a sorting step in between.

Closer look at the UpdateEmployment tick task.


One concept that’s common throughout PDS games is modifiers and Victoria 3 is no exception. Quite the opposite. Compared to CK3 our modifier setup is about an order of magnitude more complex. In order to manage this we use a system similar to Stellaris which we call modifier nodes. In essence it’s a dependency management system that allows us to flag modifiers as dirty and only recalculate it and the other modifiers that depend on it. This is quite beneficial as recalculating a modifier is somewhat expensive.

However, this system used to be very single threaded which meant a large part of our tick was still spent updating modifiers. If you look at the graph at the top of this dev diary you can see that performance improved quite rapidly during early 2022. One of the main contributors to this was the parallelization of the modifier node calculations. Since we know which nodes depend on which we can make sure to divide the nodes into batches where each batch only depends on previous batches.

Closer look at the RecalculateModifierNodes tick task.


A lot of the work going on in a tick needs to be done for every country in the world. But with the massive difference in scale between a small country like Luxembourg and a large one like Russia some operations are going to sometimes take more than a hundred times as long for one country compared to another. When you do things serially this doesn’t really matter because all the work needs to happen and it doesn’t really matter which one you do first. But when we start parallelizing things we can run into an issue where too many of the larger countries end up on the same thread. This means that after all the threads are done with their work we still have to wait for this last thread to finish. In order to get around this we came up with a system where tick tasks can specify a heuristic cost for each part of the update. This then allows us to identify parts that stand out by checking the standard deviation of the expected computation time and schedule them separately.

One place where this makes a large difference is the country budget update. Not having say China, Russia, and Great Britain all update on the same thread significantly reduces the time needed for the budget update.

(And this is also why the game runs slower during your world conquest playthroughs!)

Closer look at the WeeklyCountryBudgetUpdateParallel tick task. Note the Expensive vs Affordable jobs.


I’m going to guess that this is the part most of you are interested in. There have been many improvements both large and small.

If you’ve paid attention to the open beta so far you might have noticed some interface changes relating to the construction queue. With how many people play the game the queue can end up quite large. Unfortunately the old interface here was using a widget type that needs to compute the size of all its elements to properly layout them. Including the elements not visible on screen.

New construction queue interface.

To compound this issue even further the queued constructions had a lot of dependencies on each other in order to compute things like time until completion and similar. This too has been addressed and should be available in today’s beta build.

Side by side comparison of old vs new construction queue.

One big improvement to tick speed is a consequence of changes we’ve done to our graphics update. Later in the game updating the map could sometimes end up taking a lot of time which then in turn led to the game logic having to wait a lot for the graphics update. There’s been both engine improvements and changes to our game side code here to reduce the time needed for the graphics update. Some things here include improving the threading of the map name update, optimizing the air entity update, and reducing the work needed to find out where buildings should show up in the city graphics.

Graphics update before/after optimization.

As we talked about above, the employment update has a significant impact on performance. This is very strongly correlated with the number of pops in the game. As in the number of objects, not the total population. Especially in late game you could end up with large amounts of tiny pops which would make the employment update extremely slow. To alleviate this design has tweaked how aggressively the game merges small pops which should improve late game performance. For modders this can be changed with the POP_MERGE_MAX_WORKFORCE and POP_MERGE_MIN_NUM_POPS_SAME_PROFESSION defines.

Another improvement we’ve done for 1.2 is replacing how we do memory allocation in Clausewitz. While we’ve always had dedicated allocators for special cases (pool allocators, game object “databases”, etc) there were still a lot of allocations ending up with the default allocator which just deferred to the operating system. And especially on Windows this can be slow. To solve this we now make use of a library called mimalloc. It’s a very performant memory allocator library and basically a drop in replacement for the functionality provided by the operating system. It’s already being used by other large engines such as Unreal Engine. While not as significant as the two things above, it did make the game run around 4% faster when measured over a year about two thirds into the timeline. And since it’s an engine improvement you can likely see it in CK3 as well some time in the future.

In addition to these larger changes there’s also been many small improvements that together add up to a lot. All in all the game should be noticeably faster in 1.2 compared to 1.1 as you can see in the graph below. Unfortunately the 1.1 overnight tests weren’t as stable as 1.2 so for the sake of clarity I cut the graph off at 1871, but in general the performance improvements in 1.2 are even more noticeable in the late game.

Year by year comparison of tick times between 1.1 and 1.2 with 1.2 being much faster. Numbers are yearly averages from multiple nightly tests over several weeks using debug builds.

That’s all from me for this week. Next week Nik will present the various improvements done to warfare mechanics in 1.2, including the new Strategic Objectives feature.

Hello everyone!

We have opened up an open beta for Victoria 3 Update 1.2, which after careful consideration by the entire team has been named “Hot Cinnamon Spice”!
We’ve been working on this update for a while now and we hope that it will provide a significant improvement to your experience with Victoria 3. Before we unleash it fully we’d like for you all to give it a go and provide us with feedback so that it can be the best it can be. The final release date of the full update will be revealed later.

How to opt-in to the Open Beta:
First of all we'd like to recommend everyone to start a fresh game and not use existing 1.1 save files. To opt-in you right click Victoria 3 in Steam, go to properties, click on the tab that says BETAS and in the dropdown list there you should be able to select the “1.2-beta”. Let the game update and you should be ready to go. If you wish to opt-out from the beta you repeat the above process but pick “none” in the dropdown list.

Step by Step Guide
1. Right click Victoria 3 in your Steam library
2. Go to Properties
3. Click "BETAS" on the menu to the left
4. Pick 1.2-beta in the dropdown list
5. Allow for your game to update
6. Start Victoria 3 as you normally would

How to report bugs and give feedback:
Our primary channel for communications will be the Victoria 3 Discord Server in the OPEN BETA section where you can post feedback and report bugs!
You can also file bug reports in the bug report forum (make sure you specify the bug is found in the 1.2 Beta build).
PLEASE NOTE THAT WE WILL NOT BE COLLECTING BUG REPORTS ON STEAM - ONLY ON DISCORD AND OUR OFFICIAL FORUM

Updates to the build:
We’ll be updating the open beta build on a regular basis and any updates will be communicated on Discord. Please note that updates may render your save file incompatible.

THREAD ABOUT KNOWN ISSUES CAN BE FOUND HERE!

Hello and welcome to another Victoria 3 Dev Diary about Update 1.2! By now the Open Beta is of course in full swing, and everything in this post will either already be available to try out or be part of one of the upcoming updates to the Open Beta in the following weeks. However, we still want to take the time to properly outline the changes we’re making to the game in 1.2 for those who either don’t want to opt into the Open Beta or are just interested in more detail and context. Today’s Dev Diary will be focusing on changes on the Diplomatic side of the game, both in terms of new functionality and AI.

The first improvement we’re going to go over today is Colonial Claims, which is a change to Colonization that is intended to prevent some of the more ahistorical nonsense we have going on in colonization at the moment, such as countries rushing for Hokkaido before Japan can get it or the United States setting up shop in Tierra del Fuego. Quite simply, what it means is that some countries now start with claims on states owned by Decentralized Nations, and any country which *doesn’t* have a claim on that state is blocked from colonizing it so long as the claiming state maintains an Interest there.

As an example, the Hudson Bay Company starts with a claim on Alberta in 1.2, while the United States of America does not, which means that the USA cannot start just colonizing into Canada without first forcing the HBC to revoke their claim through the use of a ‘Revoke Claim’ war goal. Similarly, Chile and Argentina have overlapping claims on some parts of Patagonia and thus are able to race each other for it, but won’t have it sniped away from them by a Belgium with grandiose Latin American ambitions.

While we’re on the topic of colonization, I should also mention that something else we’ve changed to improve how it plays 1.2 is how the Native Uprising diplomatic play works. In 1.1.2, a colonizer that defeats a Native Uprising would annex the entire native Decentralized Nation, which led to some weird pacing and balance issues. This has been changed to instead give the colonizer a special ‘Colonial Rights’ diplomatic pact with the defeated natives, which lasts for the duration of the truce. During this period, colonization speed is doubled and no further uprisings can occur from that particular Decentralized Nation.

It is no longer possible to simply snipe Hokkaido away from the Japanese Shogunate, as they start with a claim on the Ainu-controlled parts of the island

Next up is a change to Diplomatic Plays that allows countries to expand their Primary Demands in a play. An issue that has been repeatedly identified by players since release is that once they grow strong enough, the AI has a tendency to back down against them in plays, ceding one war goal at a time and setting in place a five-year truce before the next demand can be made. While this does fit with the design principle that there should be a reason to want to back down, the end result could end up unduly frustrating and wasn’t just an issue for the player, either, as the AI of the USA struggled to reach the West Coast when it could only take one state off Mexico at a time.

To address this in a way that directly tackles the problem while still ensuring that it still isn’t simply best to always take your chances with a war, we’ve changed the concept of Primary Demand (ie the first war goal added, which gets enforced when backing down) to Primary Demands, which will all be enforced when the enemy backs down, and Secondary Demands, which will only be relevant if the play escalates to war. Just as it works right now, the first war goal added on each side is always a Primary Demand, but there are now ways to add more Primary Demands beyond the first.

Firstly, any war goal targeting the main opponent (or any of their subjects) that is added by Swaying another country to your side will now automatically be a Primary Demand. In other words, if you’re launching a play against France and they’re being supported by Spain, any country you sway to your side with a war goal targeting France will have that war goal added as a Primary Demand, while war goals targeting Spain are Secondary Demands. The AI understands this and will place higher value on Primary Demands, since they are much more likely to actually receive what’s promised by the war goal in the end.

Secondly, any war goals you yourself add can be made into Primary Demands if they target the main opponent (or any of their subjects). However, doing so is considered less ‘justified’ than adding Primary war goals through swaying, and so will cost an amount of maneuvers and generate an amount of infamy proportional to the cost of adding the war goal in the first place. This means that while adding more Primary Demands for yourself ensures that you receive them if you end up making them back down, it isn’t free, and is done at the expense of adding additional war goals or swaying more countries to your side. The AI is also going to receive some tweaks here to make them less likely to back down if you keep piling on Primary Demands, as at a certain point the unreasonableness of the demands just becomes too much to take without making a fight of it.

The cost of expanding your Primary Demands is entirely relative to the cost of the wargoal, so in the case of taking the small and depopulated state of Utah, it’s quite low

On the topic of AI, we move on to the final topic for today’s dev diary: Peace AI and War Exhaustion mechanics. Both of these have received a bunch of improvements in 1.2, though most of these improvements have not yet made it into the Open Beta. War Exhaustion, of course, is the rate at which a country’s War Support drops towards -100, at which point they are forced to capitulate. In the 1.1.2 version of the game, the main driver of War Exhaustion is occupation of territory, particularly wargoals and the capital, leading to the much-maligned ‘just naval invade Berlin’ meta.

In 1.2, you still get War Exhaustion from occupation, but the amount gained from occupied wargoals/capital is less, and War Exhaustion from occupation of other territory now scales non-linearly, with severity increasing rapidly as the country approaches full occupation: a fully enemy-controlled Modena will still capitulate quickly, while a Russia that has lost control of a few states in the Caucasus is barely going to be affected. Instead, the primary driver of War Exhaustion is now casualties and battles lost. War Exhaustion from Casualties now scale against the total available manpower for the country instead of its Population, so a country with an army of 10,000 is going to be much more affected by 5000 casualties than a country with an army of 100,000, even if the two countries have the same overall population. For available manpower, all regular battalions are counted (whether mobilized or not), but conscripts are only counted once they’re actually called in - so calling up more conscripts can be a way to directly affect your War Exhaustion rate.

Furthermore, War Exhaustion from Casualties now scales against the % of battles (proportional to battle size, so a battle of 100 battalions vs 100 battalions counts more than one of 5 vs 1) that your side of the war has lost. What this means is that a country which keeps winning battles can absorb far more losses than one which keeps losing them, and allows for battlefield victory to play much more directly into achieving overall victory in the war.

Even though the amount of casualties relative to army size are fairly similar owing to the massive Qing army, the British are losing war support at a much slower rate due to their string of battlefield victories


The AI for making peace has also received some upgrades. In addition to now just being better at constructing equitable peace deals through a rewrite of the core logic behind AI-made peace deals, the AI has also been made to consider more angles when deciding whether or not a peace deal is acceptable. Firstly, a new factor has been added called ‘achievable wargoal’, where the AI looks at whether a war goal is likely to be gained by the side that holds it through the capitulation of the target if a peace deal is not signed. Such wargoals, if held by the AI, will make them far more reluctant to sign peace unless those wargoals are part of the peace, while they are simultaneously more likely to accept the enemy pressing wargoals against them that they’d just lose anyway if the war continued. Secondly, the AI now looks at more additional factors for peace (such as the relative military strength of the two sides) and other factors have been tweaked, for example the size of AI Gold Reserves now has less importance than it used to.

Even though the Qing are offering considerable concessions, the British AI will refuse this peace deal because they believe they can get everything they want anyway once Qing is forced to capitulate

That’s it for today! This is of course not an exhaustive list of everything that’s been improved diplomacy-wise in 1.2, and there are a number of improvements still planned for future Open Beta updates, particularly on making the diplomatic AI behave in a more plausible way and be better at sticking by important allies, but details on that will have to wait for another day. Next week, we continue talking about the 1.2 Update as our tech lead Emil will tell you all about the improvements we’ve made to Performance. See you then!

Hello, my name is Henrik, and I am one of the UX Designers on Victoria 3. For 1.2 I have been fully focused on improving the user experience of the game. Before we go into the details of what has been worked on for this update, I want to give a special thanks to the community, all the modders, and anyone who posted feedback here on the forum, Discord, Reddit, Youtube, or any of our other communication channels. Your feedback, ideas, and discussions have all been instrumental in helping the team prioritize our time and efforts for this update.


One of the first things we started with immediately after 1.1.2 was improving the usability of the Trade Routes panel. In addition to the current view of grouping Trade Routes by Goods, you can now get a sortable list of all Trade Routes in the Market, or get a view where they are grouped by Country. All of these lists can also be filtered to exclude any Routes not owned by you. The Country grouping is especially useful when setting up Embargos or Trade Agreements.






Our new Message Settings window lets you decide how you want a specific Notification to be displayed, and if you want the game to automatically pause when it gets triggered. In future updates, we are planning on expanding this to cover more functionality, like the Current Situation panel, Alerts etc.



Parallel to adding Message Settings, we also made a pass on making sure that the Notifications we post to the player are informative and have a reasonable default setting for how to present them. Among the tweaks we have done are:

• Make the “Interest Activated/Deactivated” Notification into a “You can now conduct Diplomacy with X” Notification that only triggers if the activated/deactivated Interest is the first/last one that overlaps with any of your Interests
  
• Moving the Price Report to the Market Panel (turned off by default, can be turned on in the Message Settings panel)
  
• Splitting up Trade Routes Notifications into significant and less significant versions (Significant is turned on by default, less significant is not)
  
• Only show “Mobilization” and “Declare Neutrality” Notifications if you are committed to the Diplomatic Play in question
  
• Only show resource related Notifications if they happen in your Market (previously Strategic Regions in which you have an Interest in)
  

All of these changes should, according to our benchmarks, reduce the number of Notifications by roughly 50% for most Countries. In addition to this, we have also tweaked the animations for the Notification feed, so the overall user experience of the entire system should be much improved.


Our shortcut system has been replaced by a new system that can leverage rebindable keys. When adding this new system also made a pass and added a few more shortcuts, as well as hooked in a few existing ones in more places.




Another fully reworked panel is the Population overview, which now gives you more information about who your Pops are, how many they are, how much money they make, what they spend it on, and how much that goes to increasing/decreasing their Standard of Living (the last one not included in the screenshot, but visible without scrolling when the Taxes and Needs sections are collapsed).



In addition to creating this new panel, we have exposed more information in the Pop Lists used throughout the game, and improved a few of the Pop Need tooltips. They should now surface more of the relevant information higher up in the information hierarchy. We also exposed the top five Goods a Pop spends money on in this list, inspired by the Visible Pop Needs mod by Apprehensive-Tank213




Martin has already discussed some of the changes regarding Construction in DD #71, and in addition to these changes we have improved the user experience of the gameplay loop by providing better contextual information in several places. For example, we have added Infrastructure, Available Labor, and Qualifications to the Map List that is shown when expanding Buildings. In the screenshot below you can also see that we have restructured the layout of the Map Interaction panel to make it possible to navigate directly to another panel, which in the case of the Construction Interaction is the Building details panel for the specific Building. This layout also allows for more reasonable tooltip positioning, making it easier to navigate into a nested tooltip without accidentally opening another tooltip when moving the cursor towards the tooltip you wanted to dig into the details of.



The most recent improvement that made it into the game is the Reset Production Methods Map Interaction, a PDT project by our Lead Designer Mikael and myself. It should make it much more efficient to streamline the production in your Country, which is especially useful if you have just acquired a few new States. This is currently somewhat of a work in progress, and we are hoping to expand this to work on Buildings and Building Types in the future.



One of the most popular mods for the game is currently Visual Methods by FUN, a mod that we liked so much that we decided to make our own, slightly tweaked, version of.



The Investment Pool is now being more prominently displayed in the Buildings panel.



The tooltips for Market Access have also been improved to give more detail as to why a State is not fully connected to the National Market.




We have improved the presentation of why your Pops turn Radical or Loyal, who they are and which Interest Groups they belong to. Information regarding this has been exposed in several tooltips and panels, like the Interest Group panel.






Your current Convoy balance has been added to the Top Bar, making it much easier to keep track of and access when needed. This item will be hidden for landlocked Countries and unlocked as soon as you gain access to a coastline.




We have added three new Map Modes (Literacy, Population and Infamy), and given the transition between two Map Modes a configurable fade in/out to make it smoother. One of the first mods I personally subscribed to at release was Practical Heatmaps by Ronin Szaky, and an ever-so-slightly tweaked version made its way into the base game in 1.2.




For Diplomacy, we have improved how we show AI Acceptance and signal more clearly if offering or using an Obligation would convince them to accept.



We have also exposed all types of Diplomatic Plays on the Country details panel, not only the ones you can currently start, making it easier to figure out what is blocking you from starting a particular Play.




When it comes to the Military system, the focus for the UX improvements in 1.2 has revolved around making it clearer how the Battle systems work. We approached this by exposing more data related to Battles, as well as, improving some of the tooltips presenting breakdowns of the calculations involved. Some effort has also been made to decrease the amount of visual noise from multiple Front Markers.



Work in Progress tooltip for the breakdown of the initial number of troops each General was able to bring to the Battle.



We have also surfaced the information regarding which HQ a Commander considers their Home HQ and made some improvements to the information presented in the Naval Invasion user flow.






The Outliner has gotten some polish, with pinnable Goods and non-Military Characters being the biggest additions. Interest Groups are now showing their Approval value, and States show their Available Labor and Qualifications.








The Tech Tree Improvements discussed in DD #70 also made it for 1.2.


In addition to all of these changes listed above, we have also made over 100 smaller UX tweaks and bug fixes, which you will either have to wait for the full patch notes to explore, or experience for yourself during the Open Beta. Once again, thanks for all the feedback, it really helps us make the game as great as it deserves to be!

Next week, Martin will be showing us diplomacy improvements coming in 1.2!