Hi,

I've been thinking about a possible method of multithreading my game engine, which would involve copying the state of all dynamic objects at the end of the timestep and saving them to a buffer of some kind. Any non-essential subsystem (rendering, audio) could work on old states and take as much time as they like while physics and gamelogic would be simulated on the current state. This would also neatly support demo recording, enabling scrubbing forwards and backwards through time (vs only recording inputs, which would only support moving forwards, though I guess a clever system could record only the initial state and inputs while recording, and then reconstruct everything in between upon saving). While resources would be shared between all states, I'm worried that the memory usage of this system might be prohibitive (however, my plan so far is to only target next-gen and pc hardware, so I have a lot of memory to work with); not to mention the cost of actually performing the copy. Has anyone worked on a system like this? Were there any significant problems with it? Thanks.

The title you've posted doesn't match up with what you're asking. Please tell the moderator to change to: "Multi-threading the game engine".

[edit]

Before I got more negative votes, my intention was saying that most of the topic titles we see here relates "saving the game" with questions about saving game-states into files, what is the best file format, how to load from file streams, etc. (since here we don't have a section called Multithreading, and the topic was created in Game Programming, which the OP is correct because is the one relates most with). I'm not saying "get out of this section" . At least a parenthesis after the title such

would help to get more specific topics, etc.

[edit]

The title you've posted doesn't match up with what you're asking. Please tell the moderator to change to: "Multi-threading the game engine".

Only one of the benefits of this system is easier multithreading for non-essential subsystems. My question was about whether this kind of system is feasible to begin with; not whether it's an ideal method of multithreading.

The title you've posted doesn't match up with what you're asking. Please tell the moderator to change to: "Multi-threading the game engine".

Only one of the benefits of this system is easier multithreading for non-essential subsystems. My question was about whether this kind of system is feasible to begin with; not whether it's an ideal method of multithreading.

Are there any articles or advice I could read about a good example on how to store the data for a snapshot of a game state? Because I saw this being mentioned briefly in the Fix Your Timestep article, with the pseudocode having a "state" variable and a means to integrate it. I suppose then there needs to be a function that can interpolate/tween two states and return that result, so that is what I want to know how to do.

You should create another topic.

Mathematically, the state of the system is the initial values of the initial value problem. You use a ODE solver (Euler, Runge-Kutta, MM, etc.) to solve for values in the interval t + dt, continuously. These are numerical methods.

In its article, the state is the whole state of the 6 DoF of the rigid body. See here.

Immutable state is your friend but adds complexity and requires the structure to be constructed from the ground up for immutability.

Immutable structures work by when you "update" them you are just rebuilding the objects that have changed. The memory cost for each new state is just what has changed and any linkages that have to be rebuilt the rest are reused. This way you can buffer all or the last n, whatever your needs.

Without immutability you have to clone each state fully otherwise the old snapshots will mutate over time.

There are performance costs involved. Immutable collections are slower than their mutable counterparts. Also if you have an object with 20 properties and you change one you have to create a new object and then reuse all the properties that are unchanged along with the new value,

That level of immutability also does not really sit well with OO, you are better of in the functional sphere, immutability is a core concept of the style.

There is hit on GC with object churn due to the object rebuilding.

Immutable structure do carry some benefits though.

• There are no requirements for thread management, no mutation means no locking.
• Easier load, save as the structure are simple, no real inheritance trees and everything is public. More like a sealed value struct.
• No strange mutations that are hard to track.
• No need to construct views of the data for other modules so they do not effect your engine internals.