rec.autos.simulators

Did any one of you already implent replays in your car sim?
Currently I'm asking myself which variables to save in a replay file
to keep it small and fast but of course near to the original.

I thought of saving the game inputs and every 1/10 sec or so the
positions & velocities of the cars. What do you think about a replay
implentation?

Ciao!
Roppi

if your sim is completely deterministic (ie the same input will always
produce the same simulation) then saving out the user inputs is definitely
the best way since the data is quite small. However ensuring that your sim
is deterministic can be quite difficult, (random number generators need the
same seed, all simulation data needs to be tied to the simulation rate
rather than the render speed, you'll need a fixed simulation rate rather
than variable).

In my sim I save out the inputs and random number seed, mainly as a debug
tool but I will also extend it to replays some day. I always get an exact
replay, but this is only beacuse I had this approach in mind from the
beginning. If you try to fit this into your sim retrospectively, this can be
a complete b*****d (I know from experience). If it doesn't play back
exactly, it's very difficult to debug when the replayed version first
diverges from the original version.

Another approach is similar to one we used on a football sim I worked on a
couple of years ago. We saved out all "interesting" data (ie player
positions position, player animation states, ball position) every frame, and
that was used for the replay. The problem is that the data can get quite
large (we only had sufficient memory for the previous 10 secs of the game).

Of the 2 approaches, I prefer the first, since it can also be used as a
debug tool and can also be extended to a networked multiplayer game (since
the system is deterministic, the same inputs on the different machines will
produce the same game state - you only need to pass around user inputs). But
like I said, it can be difficult to implement at first.

Mike

Quite right. Sort of MPEG.
I only store states though (at 10Hz), but it gets big pretty soon.
That does enable me to do reverse playing, and superslomo's. (although
probably such an MPEG-type replay may be able to as well)

GT3 uses only player inputs for example. GPL does states only I think
(big replays).

The pro of saving game inputs is that it's the same code base as what
you would like for network communication.

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/

But this doesn't (in my system anyway) allow you to rewind, does
it? I hate replay systems that don't allow you to rewind, what's
the point of having a replay if you can't watch that spectacular
wipeout (or passing move, if you're into that kind of thing <g>)
over and over from different camera angles? I haven't figured out
a solution to this yet, though I've been busy on other things.
My initial idea was to save a complete state once every n seconds,
and that way I could just run forward from the closest state,
rather than from the beginning of the recording. Size/speed
tradeoff.

Jason
379

Indeed. And be careful when trying to NOT save intermediate states.
Different FPU's can (and thus WILL) give different results; so saving
a replay on one machine and playing it back on another may***up
(on a Nurburgring-sized lap or race).

Right. A big flaw in GT3 (just as the lack of damage is).

I think this idea should work. I'm still trying to work out how to
reverse things like smoke and spark particles though, without saving
too much (state) data. Perhaps in that case, doing it like you
described is the *only* sensible (and relatively simple, read
codeable) thing.
But even then, the particle states (and things like laptimes etc) must
be saved as well. But once every couple of replay frames shouldn't be
that bad. Anyway, memory becomes bigger and bigger, so it will be less
and less of an issue (except on consoles for the time being; that's
why GT3 selected storing only the inputs probably).

Ruud van Gaal
Free car sim  : http://www.racesimcentral.net/
Pencil art    : http://www.racesimcentral.net/

Hee hee, yes, trying to retrofit a "control-stream" replay onto a game that
used a compressed-state-stream replay is a real pain  We had to do that when
we wrote Nascar Heat for the PS2, because a state-based replay is completely
impractical for a console system, unless you only need 5 seconds of
replay...  it's a good demonstration of chaotic principles, as an error in
the tenth decimal place will quickly propogate and the player car ends up
against a wall with the tires spinning and the wheel waggling purposefully
back and forth. When we wrote Heat for the Xbox, we were able to use a
state-based replay using the hard-disk, which is nice because than you can
shuttle back and forth and all that nice stuff.

Well, I think the replay will only be satisfiying with a compromise of
state/input-information.
I think I'll run my physics code in replays as usual as in the game,
with collisions etc. and will correct the states and send inputs with
4Hz or so. I I suppose that with a running physics system the result
shall be quite realistic.
But another prob arises with temporary objects like sparks while
collisions, I don't know how to handle things like that.
(spawning/deleting)
Maybe it works anyway with physics like I said because collisions are
tested and that's why sparks should be spawned as usual.

Well, think I've got to test this first to have an opinion :)

Ciao!
Roppi