Plu wrote:We only need to store the point where the behaviour changes from "falling" to "moving" (ie; the impact point with the ground, or the point where it walked off the platform)
Ok, I understand. So in the forward simulation there are time-episodes that are reversible and there are moments, when information about the past is lost (behaviour change from falling to moving). So we need to keep track of these moments. Then it is generally possible to reconstruct any previous state of the system (given the current state and the pile of "lost information").
I have to admit that here I am discussing something that I haven't tried myself, but I still doubt that this approach is very practical. Have you tried implementing such a system?
I made a small calculation to see how fast the memory is filled, if you record a game: A double has 64bit = 8 byte. If we have 50 Objects on screen and each objects contains 10 numbers to characterize it's state and if we record 60 frames per second for 10 seconds, then we end up with
8*50*10*60*10 = 2,400,000 byte = 2.4 Mb. That isn't as bad as I expected. But still, yes you can get into a range that will not fit into your memory. So if I wanted to record a game in order to player it backwards, I would have to be careful to select the essential data and only store these. Otherwise it could grow too fast. So maybe an event-based approach is better, than a state-based approach. And this is already what you suggested.
Thanks for discussion. It made me thinking and I learned something.
Starcraft 2's replay system is capable of tracking the events of hundreds of units over sometimes an hour or ore of game time in a replay file which is often less than 100kb. While I'm sure they put some effort into making the replay files as small as possible, it's not unrealistic to expect to save every state change for every object in a small game for a short period of time in under 1mb.
I don't know TOO much about how SC2's replays work, but I know the basic idea. Every time a player does an action such as building a unit, ordering it to move to a location, etc. it saves the frame that the event happened on, and the event. The way it handles ordering a collection of units is that every time you select or deselect a unit, that is also recorded as an action in the replay, so when you record the "attack here" action, you don't also need to save which units are being ordered, because you must have already recorded the player selecting them.
Here's an example screenshot showing the list of actions from the beginning of a game using the SC2Gears replay analyzer tool:
Not in an action game, but I have done something similar for a browser based game that required the ability to store events to walk through time in order to calculate gamestate. And yeah, it's complicated stuff. If the OP says "max 5 seconds backwards" I would probably skip that solution and do the more straight forward "save every frame in the the last 5 seconds in a table" approach as you probably won't max out your memory fast enough to worry about it.
Yeah often simple answers are better than complex yet powerful ones... I just wanted to point out that it's very doable (and show a bit of how it works) to create a system that can remember extended periods of time with potentially hundreds or thousands of objects and various actions, and still store it in an absurdly small amount of space.
retrotails wrote:this NEEDS vsync, otherwise RAM use could get out of hand.
Small thingy: don't rely on vsync. Some systems don't provide it, even if you ask for it, and then the RAM usage would get out of hand anyway. Instead, keep a time variable, add dt to it, and only store a frame once the total time passed 1/60 s or 1/30 s. Then subtract that number from the time variable.
retrotails wrote:this NEEDS vsync, otherwise RAM use could get out of hand.
Small thingy: don't rely on vsync. Some systems don't provide it, even if you ask for it, and then the RAM usage would get out of hand anyway. Instead, keep a time variable, add dt to it, and only store a frame once the total time passed 1/60 s or 1/30 s. Then subtract that number from the time variable.
I know I should have, but it was just a warning for those running my demo. Also I like frame limits anyway, mostly because I like to always get perfect results.
Bobbias wrote:Starcraft 2's replay system is capable of tracking the events of hundreds of units over sometimes an hour or ore of game time in a replay file which is often less than 100kb. While I'm sure they put some effort into making the replay files as small as possible, it's not unrealistic to expect to save every state change for every object in a small game for a short period of time in under 1mb.
I was thinking about games with a replay function as well. I played super meat boy recently and it records the game in each level for multiple tries. But this is a forward replay. Sure, when the game is deterministic then it is enough to record the players input to replay the game forward. For a backward replay you'd either have to store additional information (see goomba example above) or you need to run a forward simulation each frame.
