Chipmunk physics + replay system « cocos2d for iPhone

cocos2d for iPhone » Programming » physics

Chipmunk physics + replay system

(37 posts) (8 voices)

Started 6 months ago by wybielacz
Latest reply from caferlop

Tags:

12 Next »

wybielacz
Member

Hi,

I'm trying to implement a replay system in my current wip game which will allow to the user to view his/hers best run on each level. I'm using chipmunk for the physics with a fixed time step.
I figured out that I have to save the position of the player at each frame and then when I want to play a replay just load and set the position of the player at each frame in the update method.
The problem starts here since the above method works but not always. Sometimes it happens that the player movement on the replay is slight different then it should be. The time between start and goal is sometimes different then it should be and sometimes even the player doesn't touch the goal point which doesn't end the replay. I even tried to save the velocity of the player instead the position but still the result are the same.

So my question is how to properly save and load replays of a scene using a physics engine? Should I save velocity or position or maybe something different? Is an NSMutableArray a good container to store each frame? I want to have the replay always the same as the player played. It would nice if someone with experience would help me or point me in the right direction.

Posted 6 months ago #
vashpan
Member

You really have fixed time step everywhere ? If you saving position - it should work fine in terms of precision, but I think it could be choppy.

I think the best is to save input state instead of positions - I don't know what kind of game you say, but it is easiest way if you have quite "static" input, like virtual buttons ( I'm doing this in Commander Pixman, and replays seems to be rock-solid, with various FPS even )

Then you can simply "play" game. Of course you need to have proper fixed-time-step. And I don't know how it will work with physics engine ( it should work well, if all settings are fixed and exactly the same ), in Pixman I have my own custom code.

Posted 6 months ago #
wybielacz
Member

Yeah, I am using a perfectly fixed time step.
Some details about my current approach. I'm still using the physics engine even at the replay in order to handle collision detection. That means my replay is handled in such a way that everything is like in the normal game play mode just with the difference that the player body position is set with the update method instead from input. Maybe that's why my solution doesn't work perfectly? Would it be better to just turn off physics completely and move the player sprite instead of the body for the replays?

Posted 6 months ago #
slembcke
Administrator

Playing back physics identically is much much more complicated than that unfortunately. You really need to store everything. I order to keep the performance good, physics tend to cache a lot of information and the cache affects how the simulation runs. Really in order to do it perfectly you need to be able to serialize the space including all that cached data, which I don't think any physics engine actually supports. Beyond that, saving the position and velocity is as close as you will get.

If you want 100% perfect replays, you really have to record the position every frame and exclusively use that without re-running the physics at all.

Posted 6 months ago #
wybielacz
Member

Thanks @slembcke
I thought that maybe running the replay with physics enabled could be the problem. I will rewrite my replay system to set the sprite position with disabled physics.

Posted 6 months ago #
zaaroth
Member

@slembcke is right. I have just finished implementing the replay functionality in my game and it was a headache. Even though I used box2d the fundamentals are the same: it stores/caches lots of stuff and in my case I had to replicate pretty much everything perfectly (order in which things are created, forces and so forth) in order to have a perfect replay.

You should consider if it is worth spending 50-60 hours to make it work.

Posted 6 months ago #
wybielacz
Member

I think the worst problem with a replay system is when you have a lot of collision detection in your game since then you have to keep saving at which time a collision happened. That is actually my case. So for simply save a lot of work I decided to stick with the physics engine and let it still deal with the collisions even during a replay and then just update the position of the player in the update method.

At first I had trouble achieving it and no matter if I saved velocity or position the results were not accurate. But just a few minutes ago I got a breakthrough and it seems to work accurate enough :)
There is still a small error margin like +-0.1 seconds depending on the duration of the replay and I guess this is because the FPS is not always super const at 60 but jumping slightly within this value.
I guess the solution for this would be to keep track at what time a frame was displayed and then during the replay check if the saved time for the current frame is the same as the current time and if not then just adjust it with the difference. Is this a good solution or is there a better way?

I think more problems would be if for example the user received a notification during replay viewing which will cause a slight lag and huge FPS drop so it is even more important to adjust the frames and time.

Posted 6 months ago #
vashpan
Member

If you have fixed time step, then why you bother with 'fixing' time during replay? ;) If your time-step is fixed - then you should have constant frame time every 'step' method in your game ( of course it won't be const in 'update' method of your scene/layer, this is where we need to 'fix' time step ), without any dependencies about notifications and slight FPS changes...

I don't get it :) But in terms of physics replays - I believe @slembcke ;) And I can confirm - replays in Commander Pixman, has been quite painful, and they influence many other things in game that I won't expect.

Posted 6 months ago #
wybielacz
Member

fixed time step means that the physics are running always the same no matter how much FPS you have. And since I am setting the position of the body every frame then it doesn't matter if the time step of the physics is fixed. When there is a slight lag caused by FPS drop then the next frame will be displayed to late which means I have to adjust it in the next frame for example by skipping one frame. That's how I understand the situation :)
Without using chipmunk I guess my situation would be different but since I want to go the easy way I will stick with the physics. The results are pretty accurate and promising right now, I just need to fix the small error margin and handle FPS drops.

Posted 6 months ago #
Birkemose
Moderator

Hmm ... That is a intriguing problem.

First, the timing of a recording would have to be adjusted for drops in framerate, to simulate a smooth recording.
Next, during a playback, the recording would likewise have to be adjusted for drops in framerate.

Why not avoid all that, and NOT use fixed time steps?

Posted 6 months ago #
zaaroth
Member

@Birkemose: To ensure the same simulation he would have to store each dt used to step (seems reasonable, @slembcke will know for sure).

Posted 6 months ago #
Birkemose
Moderator
I dont think storing dt is enough. You would have to store time for sure, but you would have to calculate a time.
Because the simulation runs slower at low fps, you would have to provide a calculated dt which was smaller than the actual dt.

I think the formula would be something like
```
stored_dt = fixed_dt * ( fixed_dt / actual_dt );
```
Same thing when playing back ( if playback has to be in sync with the real world, like ex a ghost playback )
```
playback_dt = stored_dt * ( fixed_dt / actual_dt );
```
You would then have to interpolate positions from the calculated playback_dt

I think ... ;)
Posted 6 months ago #
zaaroth
Member

Yeah, but the main issue is that the simulation will change. When you use a different dt you cant ensure the internal state of the physics library will be the same.

If the internal state changes slightly all positions/rotations will change as well. Depending on how your game runs it may have a different final result. For instance, shapes that collided slightly might not collide depending on the dt changes. Of course, if you manually turn on continuous collision detection you may avoid the collision issue, but overall positions/rotation will change.

There may be an easier way to solve this, but I didnt find it when I ventured on the subject :S

Posted 6 months ago #
slembcke
Administrator

I know there are some people that are happy with the results of using variable timesteps for various reasons, but I would never recommend them for anything other than physics for purely graphical effect purposes. Instead I would definitely recommend decoupling your update and drawing loops. Always run your game logic code at a fixed rate, and render as often as you can push to the screen. It solves a lot of problems, and is a great article on how to do it: http://gafferongames.com/game-physics/fix-your-timestep/

I guess the need to playback code that is triggered from collision events without running the physics throws a bit of a wrench into things. If you are always replaying the simulation from the very beginning, then it's possible without a lot of extra work. As long as you initialize the physics in the exact same way and modify the physics in the same order on the same frames, you should be able to get an exact replication of the simulation by only recording the user input. The only catch is that you need to call cpResetShapeIdCounter() (http://chipmunk-physics.net/release/ChipmunkLatest-Docs/#cpShape-Misc) and be careful with any random numbers you use.

However, it won't work between different CPUs/OSes/compilers/versions, etc. Even changing compiler flags mean that some floating point operations will possibly get reordered and cause slightly different rounding errors. A round off error of 0.000000000000000001 pixels might not seem like a big deal, but after hundreds of frames and hundreds of objects interacting, that could end up being a whole pixel. That 1 pixel change might be all you need to bump into something you weren't supposed to and greatly change the outcome.

Anyway. I guess if I was doing it I would always run the replay to start from the beginning and just play back the user input. It's pretty easy to make a game record just the input, easy to make it play it back, and uses a trivial amount of memory. If I wanted the replays to work between CPUs/OSes/compilers/versions I would make the game record the position of everything in the game as well as things like events triggered from collisions so that they could be played back to spawn explosions, remove objects, etc. It's more work to do this, but I really don't think you have any other choice. Even if you do this you have to be very careful that later changes to the game (changing the amount of damage a monster does) don't break the replays, or also record all of that information too. I would seriously avoid doing this, it seems like it would be a waste of time.

Posted 6 months ago #
iforce2d
Member

I have done the 'replay input' method by feeding recorded touch inputs to the game and it works ok as long as the caveats Scott mentions are followed properly - make sure everything starts from the exact same state, use the same random seed and generator for anything that needs to be replayed, use fixed time step size, etc. In my current game I am doing pretty much the opposite, saving the positions of every body every frame. This is because the world contains only a small amount of data and I want to have a replay that can be rewound or set to any point in time easily.

The unfortunate thing for the recording input method is that the simulator and the device will run the same input differently so you can't share replay files between them. As well as the rounding issue, trig functions give different results too.

So basically uhh... what he said :)

Posted 6 months ago #
wybielacz
Member

Thanks for the tips.
Basically my idea is to allow playback of the replay only once for the user. After the playback is finished the user can restart the scene to make another playback which will ensure that every playback will be always set up from the beginning as it should be.
Due to the not always stable FPS and slight FPS drops there is a small error margin and like @slembcke said when I got a really close collision during recording then it sometimes happening that the collision doesn't get solved on the playback.
My current approach for this is to save the position of all moving objects in the scene during each frame. But it seems for me like a lot of data to save. I'm using NSCoding with a custom replay class now and when I make a NSMutableArray and insert into it an NSArray every frame with the position data of each body then there is a slight lag during saving. How is the best and fastest way to save a lot of data into a file ?

Posted 6 months ago #
Birkemose
Moderator

@zaaroth
I was actually thinking of a 100% recording, where you record positions, and where the playback don't rely on physics.
After all, that IS the nature of a recording.
As slembcke ( our god into physics ) wrote, it is almost impossible to reproduce physics 100.0%
BTW, keen to see your carpenter in playback mode :)

New to me is, that non-fixed time steps is such a no-go. I will keep that in mind.

The blob-demo ( http://www.cocos2d-iphone.org/forum/topic/18039 ) I made a while back, actually includes a generic recorder. It works with non-fixed time steps ( slaps self ), but other than that, if is capable of recording and playing back any physics object. It is made simply by overriding the chipmunk body, and adding a position and rotation saving feature.
On top of that, I would add a separate event logger ( add object, kill object, etc ), and not mix that with the position recording.

Edit:
The recording system is actually fixed timing, but NO correction for FPS ( double-slaps self )

Posted 6 months ago #
Birkemose
Moderator

@wybielacz
Compared to loading a 1024*1024*32 image, it is less data than you think.
Apart from that, in a playback system where you don't have to rely on physics, you don't need the precision of ex doubles. A 16 bit signed value will do for any position, rotation, scale or whatever you want to record.
If you on top of that, creates "a clever" recording system, that only records changes, 1MB of memory can record quite a bit.

Posted 6 months ago #
wybielacz
Member

Right, now I am storing the players position in an NSArray of strings (NSStringFromCGPoint) for each frame and also the frame duration for each frame in an NSArray with NSNumbers.
So let's say I record a scene with duration of 10 seconds with 60fps. That means there was a total of 600 frames displayed so the position NSArray and frame duration NSArray have 600 objects each which gives a total of 1200 objects. And now when I save those objects to a file using NSCoding there is a slight lag (around 0.5s) which I want to avoid. Is it because of such a large objects count or maybe is my code not perfect?
I'm kind of scared what comes next since I still need to save a couple more NSArrays with positions of player enemies.
Each custom class is added to an NSDictionary which then I save. So basically all replays are in 1 single file and when I add one new replay then all the previous replays are re-saved again if I understand it correctly. Maybe that's the reason for the slight lag which would grow the more replays would be saved.
Maybe it would be better to save each replay in one single file? But then let's with 100 levels i would have 100 replays files saved in the documents directory. So what would be the best option to store those replays?

Posted 6 months ago #
zaaroth
Member

You should be careful with NSStringFromCGPoint. If you rely on precision you might bump into something odd I found out while making my own replay work.

Sometimes the least significant digits were kinda wrong. I have changed all my stuff to move away from NSStringFromCGPoint to a custom encoding. Depending on how your game work that might change the simulation a lot.

Posted 6 months ago #
zaaroth
Member

The ideal is to save the events that change your simulation. If you compose the simulation with the same forces, shapes and so forth in the very same order the simulation shall be equal. If the least significant thing is slightly different the simulation wont be the same. This stand true for box2d and should for chipmunk since it should not use randomization anywhere.

If you find yourself in a situation you cant replicate things perfectly than you should consider multithreading to store stuff. Push the positions to a different thread and the lags should reduce. A good thing of multithreading is that a thread that performs IO will leave the CPU mostly free to other threads that run stuff. The main drawback is memory depending on the simulation. If you generate positions far more faster than you can store you are likely to run out of memory and be killed by the iOS scheduler.

Posted 6 months ago #
Birkemose
Moderator

We are talking TWO different things here:
1) Make a recording which uses the physics engine to reproduce what happened
2) Make a recording which saves all data - like position, rotation - on each frame, and plays them back with NO physics involved.

Like slembcke said above. While 1) of course is possible, it is also prone to errors. An update in OS, a new device, or the slightest change to code, could break it. The pixel example he gives, explains it well.
I would NOT pursue that approach.

I would use 2)
I would use a structure based recorder, ie NO NSArrays or likewise. Because I dont need accurate data in such a playback system ( a rotation in 1 degree steps would probably be enough, and rotation could because of that be stored in a 16 bit var ). Likewise a screen position with 1 pixel accuracy would probably be enough, so again a 16 bit var would do the job.
So to save position and rotation, you would need a 6 byte structure.
I would only record changes, so stationary objects would only require one entry.
I would then use interpolation between entries, and unless you have very fast complex movements, 15 entries pr. second will be more than enough. I wrote a playback util for a PC combat simulator ( Janes FA18 ) a couple of years ago, and they saved only 2 times a second. The rest was calculated using spline curves and all kinds of fancy math.
So.
6 bytes times 15 entries a second, results in 90 bytes / second / object. Lets say you have 100 moving objects ( that is quite a few I think ), and you would eat up 9KB of memory each second.
A 1024*1024*4 image takes up 4MB, or 100 objects recorded for +7 minutes.

Posted 6 months ago #
iforce2d
Member

@wybielacz Saving floats into strings? You probably shoulda mentioned that to start with. It's unlikely that you will get the exact same value when you convert back to float again. This kind of data should be saved as its binary representation. This would also take care of your worries about data size. btw what's to stop you writing to a file while recording... that would use much less memory and would not cause the delay when saving it all at once.

Posted 6 months ago #
wybielacz
Member

@iforce2d
Hmmm, I thought that maybe saving the position using NSStringFromCGPoint is not really perfect but at the same separating the CGPoint into to two floats and saving them separately in different NSArrays would even more slow the saving down.
I guess writing to a file while recording would be a good solution but honestly I have no idea how to do this on iOS. I have been only using NSCoding for saving all my data previously and till now it worked perfectly...

Anyway I guess I could solve the problems with the playback now and I am pretty satisfied with the results that I get. The playback time is exactly the same as it was recorded without any error margins. But the current problem which I have is how to properly save all the data without and lags or game fezzes. I can imagine that if I have to store replay data for let's say 60 levels with my current approach then it will take like 5 seconds to save it each time...

Posted 6 months ago #
Birkemose
Moderator

@wybielacz ( can I call you W? )
Separating a CGPoint really doesn't take any time. Accessing the data members directly will always be the fastest approach.
Next, you really wouldn't want to save them in separate arrays. Organize them into structs, and save those.

Writing to disk isn't as slow on an iDevice, as it is on an iMac, because the disk is solid state, so it would certainly be an options. I dont have much experience with the iOS disk system, but under normal circumstances, writing to continuously open disk streams is a scary thing, and makes multithread programming look like kindergarden.

Posted 6 months ago #
wybielacz
Member

@Birkemose sure you can :)
Structs would be definitely a good idea to save the position, but I don't really have any experience in saving structs. I guess i would have to use NSData to save them right ?

I followed @zaaroth advice and used a background thread to save the replay data and the lag is completely gone now :) At first I thought it would take me ages to setup the multithreading but actually it took me just a couple of minutes to setup everything and see those great results :)

Thanks a lot guys for the help and great tips :) Since yesterday when I started this thread I made a huge step forward and everything is already almost working as expected :)

So the last thing what is left to optimize everything as much as possible and get rid for example off the NSStringFromCGPoint. Since I do not know any other possibility how to save a CGPoint expect the NSStringFromCGPoint way, it would be nice if somebody could point me how to do it another another way or how to save a struct.
And I still don't know how my current system will behave when I have 100 saved replays but it seems promising.

Posted 6 months ago #
Birkemose
Moderator

@W ( phew )
I noticed several times, that iOS programmers not having a C/C++ background, aren't used to using structs.
My guess would have been, that background threading would be a PITA, but it of course always has to do with what backgrounds we have. If it works for you, then that is how you should be doing it.
I am certainly looking forward to checking out zaaroth's implementation.

Posted 6 months ago #
slembcke
Administrator

Well, if you want to tightly pack binary data into an NSData, that's actually pretty easy. There was a question about that in another thread: http://www.cocos2d-iphone.org/forum/topic/22811#post-126923 It's a lot easier than converting back and forth between strings and stuffing them into NSArrays.

Posted 6 months ago #

wybielacz
Member

@slembcke
I tried the NSData method but it doesn't seem to work. Maybe I am just doing something wrong.
What's the difference between the code you posted in the mentioned thread:

CGPoint p = CGPointMake(10.0, 20.0);
[data appendBytes:&p length:sizeof(CGPoint)];

CGPoint p = *(CGPoint *)data;

and my code:

-(void) update:(ccTime) delta{
//save
[playerPositionArray addObject:[NSMutableData dataWithBytes:&pos length:sizeof(CGPoint)]];

//load
player->body->p = *(CGPoint *)[playerPositionArray objectAtIndex:frame];
}

I guess there is no difference but still after loading the data that way then it is completely messed up and not as I saved it.
Would it make any difference to skip the NSMutableArray completley and just do it that way:

-(void) update:(ccTime) delta{
//save
[playerPositionData appendBytes:&player->body->p length:sizeof(CGPoint)];

//load
player->body->p = *(CGPoint *)playerPositionData;
playerPositionData += sizeof(CGPoint );
}

Posted 6 months ago #

slembcke
Administrator
I'm making a single NSData object that is packing a bunch of binary data into it. You are making a single NSData object per CGPoint and putting that into an NSArray. If you want to do that, you might as well use an NSValue: http://www.cocos2d-iphone.org/forum/topic/22803#post-126246

Also, when loading the data back, "data" is a void * pointer, not an NSData object. I guess I should have used a different variable name than "data". I'm moving the pointer forward for each value read back out.
```
// The 'data' pointer in the load block is a void * pointer from the NSData, not the NSData pointer itself.
const void *data = [[NSData dataWithContentsOfFile:@"/tmp/data_thingy"] bytes];
```
Posted 6 months ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.