It's fully deterministic, multiplayer works by only sending user input around (at a reduced tick rate) and the unit movements get calculated locally from that.
That's interesting. I wonder why the other poster say the replay functionality would turn into nonsense at some point.
Now if the game is deterministic and multiplayer works by only sending user inputs around, why the save / continue feature wasn't implemented that way?
In any case I love to read about how these games worked!
Your only interpreter for the data is the entire game engine. By design it's going to use most of the power of the target hardware, so cannot run faster. Ie, 30 minute load time if you had played 30 min.
- a huge part is going to go to rendering, which you don't need to do if you only care about the end state
- in many games, the simulation runs at a much lower frame rate than the game, so perhaps you see the game animated at a silky smooth 60 fps but internally the sim runs at a fraction. 10 and 5 fps for the sim are common.
- some sim architectures may allow you to run the sim at a variable frame rate and still generate deterministic results. So (ideally) you tell the sim to run a single step of 30 mins and you get the end result. In practice of course variable steps will be limited to much less, but Supercell mentioned reducing their server sim cpu costs by 80-90% with this kind of trick.
All added up with reasonable guesses for a well optimized case: 30 mins of sim run at 1 sim tick per second of game time, where sim ticks take say 2ms, could take 3.6 seconds to sim, not 30 minutes.