Achieving game engine determinism with threading

Question

I would like to achieve determinism in my game engine, in order to be able to save and replay input sequences and to make networking easier.

My engine currently uses a variable timestep: every frame I calculate the time it took to update/draw the last one and pass it to my entities' update method. This makes 1000FPS games seem as fast ad 30FPS games, but introduces undeterministic behavior.

A solution could be fixing the game to 60FPS, but it would make input more delayed and wouldn't get the benefits of higher framerates.

So I've tried using a thread (which constantly calls update(1) then sleeps for 16ms) and draw as fast as possible in the game loop. It kind of works, but it crashes often and my games become unplayable.

Is there a way to implement threading in my game loop to achieve determinism without having to rewrite all games that depend on the engine?

score 5 · Accepted Answer · answered Mar 15 '13 at 07:22

You should separate game frames from graphical frames. The graphical frames should only display the graphics, nothing else. For the replay it won't matter how many graphical frames your computer was able to execute, be it 30 per second or 1000 per second, the replaying computer will likely replay it with a different graphical frame rate.

But you should indeed fix the gameframes. E.g. to 100 gameframes per second. In the gameframe the game logic is executed: stuff that is relevant for your game (and the replay).

Your gameloop should execute graphical frames whenever there is no game frame necessary, so if you fix your game to 100 gameframes per second that's 0.01 seconds per gameframe. If your computer only needed 0.001 to execute that logic in the gameframe, the other 0.009 seconds are left for repeating graphical frames.

This is a small but incomplete and not 100% accurate example:

uint16_t const GAME_FRAMERATE = 100;
uint16_t const SKIP_TICKS = 1000 / GAME_FRAMERATE;

uint16_t next_game_tick;

Timer sinceLoopStarted = Timer(); // Millisecond timer starting at 0
unsigned long next_game_tick = sinceLoopStarted.getMilliseconds();

while (gameIsRunning)
{
    //! Game Frames
    while (sinceLoopStarted.getMilliseconds() > next_game_tick)
    {
        executeGamelogic();

        next_game_tick += SKIP_TICKS;
    }

    //! Graphical Frames
    render();
}

The following link contains very good and complete information about creating an accurate gameloop:

http://www.koonsolo.com/news/dewitters-gameloop/

score 4 · Answer 2 · answered Mar 15 '13 at 07:21

To be deterministic across a network, you need a single point of truth, commonly called "the server". There is a saying in the game community that goes "the client is in the hands of the enemy". That's true. You cannot trust anything that is calculated on the client for a fair game.

If for example your game gets easier if for some reasons your thread only updates 59 times a second instead of 60, people will find out. Maybe at the start they won't even be malicious. They just had their machines under full load at the time and your process didn't get to 60 times a second.

Once you have a server (maybe even in-process as a thread in single player) that does not care for graphics or update cycles and runs at it's own speed, it's deterministic enough to at least get the same results for all players. It might still not be 100% deterministic based on the fact that the computer is not real time. Even if you tell it to update every $frequence, it might not, due to other processes on the computer taking too much load.

The server and clients need to communicate, so the server needs to send a copy of it's state (for performance maybe a delta from the last copy) to each client. The client can draw this copy at the best speed available.

If your game is crashing with the thread, maybe it's an option to actually put "the server" out of process and communicate via network, this way you will find out pretty fast, which variables would have needed locks because if you just move them to another project, your client will no longer compile.

As a side note: once you have deterministic behavior, you don't need to regularly update the game state, that's the point! You do this only for initial conditions, then regularly send player inputs and receive other players inputs, which happens to nicely scale with our assymetric connections. But the best is the dramatic decrease in the amount of datas exchanged! This has been done already, often in RTS game (Total Annihilation, Starcraft, Supreme Commander...). Determinism is also a great way to implement replay, and of course, replays of multiplayer sessions. — Alex, Jan 31 '16 at 18:55
The real drawback is that with modern hardware, you must have good hacking skillz to achieve determinism (floating-point calculations still have crossplatform issues). — Alex, Jan 31 '16 at 18:59

JSQuareD · Answer 3 · 2013-03-15T07:15:15.170

2

Separate game logic and graphics into different threads . The game logic thread should run at a constant speed (say, it updates 60 times per second, or even higher if your logic isn't too complicated, to achieve smoother game play ). Then, your graphics thread should always draw the latest info provided by the logic thread as fast as possible to achieve high framerates.

In order to prevent partial data from being drawn, you should probably use some sort of double buffering, where the logic thread writes to one buffer, and the graphics thread reads from the other. Then switch the buffers every time the logic thread has done one update.

This should make sure you're always using the computer's graphics hardware to its fullest. Of course, this does mean you're putting constraints on the minimum cpu speed.

edited Mar 15 '13 at 07:15

answered Mar 15 '13 at 07:05

JSQuareD

4,641
2
18
27

This is what I am trying to do - however I cannot understand why it crashes. Is it because drawing uses the position of an entity (which is updated by the thread) and it is accessed during update? – Vittorio Romeo Mar 15 '13 at 09:03
@Vee Most likely, yes. The double buffering I suggested might not even suffice. A triple buffer should, though. Use three buffers, A, B, and C. The logic thread should always write to A, the graphics thread should always read from C. When the logic thread finishes an update, swap buffer A and B, when the graphic thread is ready to draw a new frame, swap buffer B and C. Obviously you should use pointers for fast swapping, and to prevent a partial swap. – JSQuareD Mar 15 '13 at 10:23
there's something I still fail to understand, though - what should buffers contain? Copies of the entire game state? – Vittorio Romeo Mar 15 '13 at 11:01
@Vee Everything that's required to draw a frame. So yes, probably the entire game state. Just a little tip to make sure it graphically looks pleasing, also store the age of a buffer (number of logic updates since game start), and don't let the graphics thread switch to an older buffer (this will help when your graphics thread runs faster than your logic thread). – JSQuareD Mar 15 '13 at 11:10

score 0 · Answer 4 · answered Mar 15 '13 at 07:05

I don't know if this will help but, if I remember correctly, Doom stored your input sequences and used them to generate the AI behaviour and some other things. A demo lump in Doom would be a series of numbers representing not the state of the game, but your input. From that input the game would be able to reconstruct what happened and, thus, achieve some kind of determinism ... Though I remember it going out of sync sometimes.

Achieving game engine determinism with threading

4 Answers4