State replay?

[jakov]

I am trying to create a network game server based on Chipmunk. I have read the classic "Fix your Timestep" article by Glenn Fiedler, and everything I can find on networked games.

I understand, that for networked games to play well, the server needs to have the ability to back a few timesteps, to replay events as new input comes from players.

Obviously, for that to work, I need to save Chipmunk world state from time to time. (At least 10 times per seconds.)

Is there some way to do that? This weekend I trawled the forums and found something about how state of objects can be read out, except for "impulses". (Whatever that is.)

Any ideas?

[slembcke]

Oof. So binary serialization is one of those features that is definitely on my list of things to do, but I don't really know when I'll be able to get to it.

The issue is that while you can save the position/velocity/etc of every object in the game, Chipmunk caches a bunch of information that helps it speed up the calculations and make the physics more accurate for the next frame. Without it, the simulation won't turn out exactly the same way. It also stores information on colliding objects so that it can call the begin/separate callbacks correctly and give you a contact graph.

So if you rewound the simulation by simply restoring positions and velocities, you wouldn't get quite the same simulation ever again. If you needed strict determinism that would be bad, but a networked game isn't going to be so sensitive. You aren't re-running tens of seconds of intricate piles of objects where the differences would show up. You are only rewinding by a fraction of a second. So the cached solutions would be pretty close, and the difference would be tiny fractions of a pixel I expect. Certainly far less error than latency itself introduces. The real problem is the begin/end callbacks and contact graph. If you need them, then there is no easy solution.

[jakov]

Ok, thanks for quick answer!

" The real problem is the begin/end callbacks and contact graph."

I don't know if I need them. Do I?

I just want my objects to bounce off each other, basically, and report hits. BTW, chipmunk is awesome for what it does. Very simple to use.

[slembcke]

Well, the begin/separate callbacks let you know when you first start colliding with an object and when they stop colliding. The begin callback tends to be the most useful as it triggers only when things collide for the first time instead of repeatedly every frame like the pre/postSolve ones.

[jakov]

Well, the begin/separate callbacks let you know when you first start colliding with an object and when they stop colliding.

*I have read some more posts and documentation*

Hm, you mean if I need to play back these too? I guess not... if I reset positions and speed vectors, some collisions are bound to happen again, and then I will get a callback again, right? (If they hit.)

Anyway, I will start implementing a state reset with only speed and position vectors, to see if it works "good enough" to cover maybe 200-300 ms of latency or whatever it ends up being in the end.

[slembcke]

If two objects start colliding, a begin callback will be called. If you then rewind their positions back before the collision and step again, you'll get a separate callback. The objects hadn't yet collided at that point in time though. The space only knew the objects had collided the last cpSpaceStep() was called which is now in the future.. sort of.

Similarly if two objects have been in contact (the begin callback has already been called) and you rewind one frame before they start colliding, the begin callback won't be called.

I'm sure there are a couple of other similar situations that would happen as well.

[jakov]

Are all states in chipmunk allocated with cpmalloc? Or are there static or other storage?

[slembcke]

There is no cpmalloc anymore, just cpcalloc and cprealloc. All of Chipmunk's memory is allocated through those two functions. The only exception would be if you allocated your own memory and passed that to a Chipmunk init function.

As for static variables, I think there are only 2 that are modified at runtime:

• cpShapeIDCounter in cpShape.c - This one is actually really important now that I think about it. It's incremented for every shape you create as a hashing identifier. This is important so you can get deterministic iteration of hash tables even after resetting a scene. You'll want to persist this value along with the space state. It's more complicated if you run multiple spaces simultaneously... Hrm. I really should make that a space property somehow. Pretty sure this is the last bit of global shared state that is really important.
• colfuncs in cpCollision.c - This will change if you call cpEnableSegmentToSegmentCollisions(). This is a global setting, so you don't really want to change it in the middle of a simulation anyway.

I can't think of any others other than the static string buffer used by cpvstr().

[jakov]

Thank you, not sure I would have found those on my own!