Hi, I''m currently writing 2D football game, much like the much loved ''Sensible Soccer''. The question i have is, how would you go about coding replays so that you can watch, say, the last 5 seconds of play, or record highlights so that you can see them at the end of the match? I had a couple of ideas, but i''m not sure how feasible they are. One would be just to store the position, animation state, etc on each frame of the match. However, i see two problems with this. One, seeing as my game is currently running at ~700 FPS with all the players, the ref, and the correctly draw pitch, on screen, for 5 seconds of play this would mean 3500 copies of the state for each player. This seems rather a lot. Secondly, replays would run at different speeds on different machines depending on the FPS. Another idea i had would be to record actions that the players perform, such as run left, run forward, shoot. However, how would you go about timing them correctly? Thanks Gavin =========================== The price of intelligence is stupidity

Actually, you may want to separate inputs to your characters (soccer players, refs) from the character implementations themselves (which, incidentally, facilitates switching from computer control to AI...) Then the outputs from character AI (which are the inputs to the characters in forms of simple signals: RUN_N, SHOOT_A, TACKLE_B, etc) can be buffered before being fed into the characters. If you decide the most recent game segment is worth saving, dump the buffer to a file, otherwise "into the bit bucket they go."

This way you could save the entire game by dump()''ing the buffer every x minutes, at an out-of-bounds, or immediately after a replay. And for the replay you''d simply feed the dump()''ed data back into the game and presto!

---
Those who can do nothing criticize; those who can, critique.

that way is similar to one of the ideas i had.

however, the problem of timing still remains.

take one player as an example.

i could issue a walk forward command then 5 secs later issue a walk left command.

if i just saved the commands and replayed them, he would walk forward, then immediately walk left. therefore some way of determining exactly when to perform each command would be neccessary.

this may be done by having a separate buffer for each player, and along with the command, have a record of how long after the previous command the present one was issued.

but are thereany other better ways of doing it. Lots of games have this feature nowadays so it can''t be that hard to implement, but is it always done the same way?

===========================
The price of intelligence is stupidity

Either put a FPS cap on during the game, or during the recording of the replays. How are you animating your players? If you''re not interpolating, is 700FPS worth it? Do your players change their animated posture every 700FPS?

Ok, my solution would be to store the info at something reasonable like 60FPS. If you want it faster or slower during playback, interpolate between frames. (ie, if player is at x=30 during frame 1 and x=40 at frame 2, and you''re at frame 1.3, he should be at x=33.

If you want to just record events, record the times as well, and don''t do the next event until the proper time has passed.

How about this? Seed any random number generators with a constant, and then just store the player''s input for the last 5 seconds into an array. To replay, just run the stored player input back through the logic using the same seed as the original play. The game logic would respond identically, and Viola! A replay..

Apex

Apex: that''s basically what Gav suggested at first, but the problem of frame rate is a big one. Ie. on his machine, it runs at 700fps. Therefore, he will get 700 input commands each second (the player usually holds down at leat one of the arrow keys each second). Play that back on a computer that averages 350 fps and you will get a replay that''s twice as slow. So either only record 60 frames per second, or cap the framerate.

I would opt for the former (because what if your framerate is less than the cap limit? a super fast replay on someone elses machine)

It''s ok for your sprites to be drawn 700 times a second, but why poll the keyboard and update your logic that fast? You didn''t specify what platform/compiler etc you were so I can''t tell you how to do it but all you really have to do is getinput/updatelogic about 60 times a second, your game can still blit itself silly 700 times a second, but most of the time it''ll be blitting sprites that haven''t changed state. If you left it the way it was then someone with a painfully slow computer would not only get a jerky framerate but half the commands they input wont even be noticed by your game.

In response to outRider, i''m using DirectX which means it should would on most of the different flavours of Windows that are around.

In reply to Thrump, i''m not intentionally running at 700FPS, that''s just what it happens to be and i figure that there is no point in capping it as my movement code is frame rate independant.

Also, if a user has a fast machine, should i not give them the benefit by polling the input device as much as possible? Admittedly, it may not make much of a difference,but why bother adding extra code when it isn''t really neccessary?

From the disscusion, i think the best approach would be to record all the positions approximately every 1/60 of a second and reply them back at that rate. Hopefully this won''t cause a problem when played back on different machines.



===========================
The price of intelligence is stupidity