Anatomy of a Game: Changing the Gamestate

  • We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Thanks for the explanation.

If I'm understanding this correctly if I ransom a character back to another ruler in multiplayer, then a command to change the game state would only fire when the other ruler accepts my ransom demand. And if the other rulers is AI then this all happens on my computer (until the command is sent out), while if the other ruler is a player they'd be sent a notification to respond to.

Did I get that correct?
 
  • 1Like
Reactions:
Thanks for the explanation.

If I'm understanding this correctly if I ransom a character back to another ruler in multiplayer, then a command to change the game state would only fire when the other ruler accepts my ransom demand. And if the other rulers is AI then this all happens on my computer (until the command is sent out), while if the other ruler is a player they'd be sent a notification to respond to.

Did I get that correct?
You sending the interaction is one command.
The other ruler accepting is another if they're a player. If they're an AI, acceptance is handled without a second command.
 
  • 4
Reactions:
When I read "command system" I had the faint hope that you would finally fix the issue, that denies us to activate and deactivate debug_mode during a running game. (as in console commands) Like in the old PDS games.

But no, we still need mods for that. *sigh*
Logged in just to upvote this. It really is disappointing to a player who is used to quickly toggling debug on and off in various PDX games. It wouldn't matter for achievement hunters but it really is strange how CK3 (such a roleplay focused game) doesn't allow us to freely tweak some things as we play like many of the other games, and forces users to fall back onto mods to do basic things :(
I am amazed at how the game was released without a console (that's able to be conveniently used without having to completely close the game). Is this a nit-pick? I don't know. It's something I use very often so I may be biased.
 
  • 2Like
  • 2
Reactions:
Thanks for the post! This is super insightful. Any chance you can tell something about how the map is displayed visually in-game? Though I'd understand, if that is something Paradox would rather keep to itself!
 
  • 1Like
Reactions:
I really appreciate the transparency and it certainly helped me understanding the challenges in managing a massive game state like CK3 and why OOS occurs even as a non-programmer (though with strong technical affinity).
 
On the topic of desyncs: my friend and I are experiencing desyncs maybe every 50 years or so in our two-player game. We’ve been trusting that using the multiplayer beta is enough to make sure you get adequate information about the problems we encounter. Is this a safe assumption?
 
Desyncs have plagued paradox games of the past, like in hoi4 (also happens far too often in similar in games like Civ). Nice to see that it's much less of a problem in CK3, and cool that you're explaining how it happens. Multiplayer adds a new dimension to the games
 
Having thought about this, I've got three technical questions:
  1. In multiplayer, how do you deal with different computers having different amounts of computing power? On an older, slower machine those evaluation calculations are going to take longer and have fewer threads to spread the work across. So how do the games sync up the update step to a heartbeat so that everyone stays on the same date?
  2. As far as updating the game state, did you consider and reject a design where the change sets are check-pointed and then committed using transactional memory? Or is the update step so quick that it just isn't relevant for performance?
  3. Since so much time is spent on doing the update calculations, do you compile the game scripts into byte-code or some other internal data structure in order to keep the interpreter from becoming a bottle neck?
 
  • 1
Reactions:
Given I have a particular game state
And I launch two game instances with the same state
When I execute a particular set of player-commands on each game instance
And next evaluation happens
Will the generated AI commands on one instance differ from those on the other?

In a single player game, I know the game is never the same even if I perform the same set of actions.
I assume there is some randomness involved to spice the game up.
But if a "randomness key" could serve as an additional startup/day input, and all random evaluations are run against that key, one can get the same result.
Or so I think : )
Yeah, this part was left out, or if it wasn't I didn't fully understand it.

The "easiest" implementation would be to just have one PC (the host's machine) do all the AI decisions, then pass that data to all the other players. Otherwise I don't have a clue how you could ever keep the gamestate sane, even if you tried to make the majority of the processing deterministic; eventually you'd have the same AI entity (character, army, or whatever) on two machines making a different decision at the same time.
 
This is probably not for general audience but the article is very informative and enlightening. I highly appreciate it.

"day" can be easily translated into "turn" making the engine perfect for turn-based character-centered simulation. I look forward to more of these tech blogs.
 
On the topic of desyncs: my friend and I are experiencing desyncs maybe every 50 years or so in our two-player game. We’ve been trusting that using the multiplayer beta is enough to make sure you get adequate information about the problems we encounter. Is this a safe assumption?
Make sure to go and leave a bug report with your out of sync's information and dump to!

Having thought about this, I've got three technical questions:
  1. In multiplayer, how do you deal with different computers having different amounts of computing power? On an older, slower machine those evaluation calculations are going to take longer and have fewer threads to spread the work across. So how do the games sync up the update step to a heartbeat so that everyone stays on the same date?
  2. As far as updating the game state, did you consider and reject a design where the change sets are check-pointed and then committed using transactional memory? Or is the update step so quick that it just isn't relevant for performance?
  3. Since so much time is spent on doing the update calculations, do you compile the game scripts into byte-code or some other internal data structure in order to keep the interpreter from becoming a bottle neck?
  1. If someone lags behind too much we slow down the speed selected for the whole session or even pause to let them catch up, with our min spec and not entirely useless internet you should be able to run at a decent speed in an MP session with that.
  2. The effects of most commands is not the bottleneck of our simulation, its much more the general daily tick of the simulation instead of any specific command actions.
  3. They are read in once into internal data structures at load time and then we just go over them for evaluation and execution never needing to go back to the file system or interpreting the scripting language.

Yeah, this part was left out, or if it wasn't I didn't fully understand it.

The "easiest" implementation would be to just have one PC (the host's machine) do all the AI decisions, then pass that data to all the other players. Otherwise I don't have a clue how you could ever keep the gamestate sane, even if you tried to make the majority of the processing deterministic; eventually you'd have the same AI entity (character, army, or whatever) on two machines making a different decision at the same time.
Exactly this, which is why they use the commands. Only the host machine actually posts the AI commands to the session which then update the rest of the clients with the AI's actions.

This is probably not for general audience but the article is very informative and enlightening. I highly appreciate it.

"day" can be easily translated into "turn" making the engine perfect for turn-based character-centered simulation. I look forward to more of these tech blogs.
I mean there is not a huge amount of difference between real time with pause and turn based anyway in that regard, both end up in the scenario where there is a hypothetical infinite amount of time between the updates so have some tick based system. Real time with pause just does it as ticks at an interval whereas turn based is tick on demand only.
There is plenty of gameplay considerations of course, and you'd want to work your updates differently, but the very core is not massively worlds apart.
 
  • 3
  • 1Like
Reactions:
  • 4
  • 2Love
Reactions:
When Paradox had no free community manager, so they put a coder to entertain people. :D
Well our community team aren’t writing our regular dev diaries or summer teasers either ;) They have the much less fun job of listening to my dumb ideas and collecting feedback and managing the socials and planning

Though thankfully Troy was very receptive and excited when I pitched this idea to him, both cause he’s nice and doesn’t want to kill my hopes and dreams and cause it’s a new type of content for us we can explore different areas of the game and our roles to those who are interested! :D
 
  • 7Like
  • 1Haha
  • 1
Reactions: