This project has moved and is read-only. For the latest updates, please go here.

Serialization in FP3

Topics: Developer Forum
Jun 8, 2010 at 9:00 PM


Is there any plan to add generic serialization to the engine? This is required for games on the phone where the entire state of the physics system needs to be persisted at a moment's notice.

I'd like to use the new DataContractSerializer stuff since it's pretty straightforward, but to do this myself, I'd need to modify every object in the engine to support the necessary [DataMember] attributes.

I was just wondering if that was something on the radar?



Jun 10, 2010 at 1:13 AM


I understand the desire to be able to serialize the entire engine, but honestly I think it is just to much trouble. The way I do it is to create a Physics Object Interface and a Physics Simulator Interface and make those serializable. It also makes your code very portable. I did this for three 3D physics engines and I was able to switch between engines without changing any code. Anyway if you do manage to get the engine to serialize I'd love to add your code to the engine.


Jun 11, 2010 at 6:44 AM
Actually I happen to need extremely fast and 100% accurate serialisation for a game I'm working on.. but it's not yet stable. I'll consider merging it once it works reliably. So, answer: maybe, someday, in the future. If you need this now, best to do it yourself.
Jun 11, 2010 at 3:37 PM

Using the interfaces can ensure 100% accurate serialization. If I get enough interest I will write up a small demo showing how this can be done.

Jun 12, 2010 at 1:40 AM

Is it possible to write a serializer that uses all public methods/properties of the classes? I would imagine not, since some internal state needs to be preserved as well, right? If not, then each engine object (i.e. Body, Fixture, Contact) would need to be modified to be serializable (and there are a LOT of them :)

Jun 12, 2010 at 1:45 PM


If you need perfect serialization, i.e. contacts and internal states, you will have to modify every object in the engine. I can't see why anyone would need this however. I have a simple serialization setup using interfaces and all I save is position, linear velocity, angular velocity, and any relevant flags and I don't have any problems with saving and loading levels. There is some very minor movement of stacked objects, but nothing more then when initially creating them.

Jun 12, 2010 at 7:12 PM

The reason I think I need more than just positions and velocities is because this is for phone development where you might be right in the middle of the action when the app is told to save and terminate. So it would not be just for loading levels from the start where I agree that complete serialization is not necessary. I can imagine that in cases where you need to serialize mid-collision or something along those lines, "partial" serialization probably wouldn't suffice. I could be wrong, but that's my feeling anyway.

Jun 13, 2010 at 2:38 PM

Now I see. I'm not sure how you would even go about serializing contacts without serializing the whole World. If I was you I might setup a simple test where you create a group of shapes, think pyramid or vertical stack, and at any point pause the engine, save all the positions and velocities, remove all the objects from the world, then create new objects using the saved positions and velocities. This would give you a good testbed to determine what needs to be saved before tearing into the engine. If just the positions and velocities worked well or well enough, that might be all you need.


Jul 19, 2010 at 8:56 PM
Edited Jul 19, 2010 at 9:00 PM

This is an old post, but I thought I'd bring up a point: If you have your World step calculated in your UI thread (not the best idea), it is my understanding that the WP7 OS will not halt you in mid-frame to give you the save state event, but instead wait for a safe point to do so (your draw/update call finishes, etc..).

However, if you calculate the physics step in a separate thread, it might. So what you do is keep a reference to your physics thread handy so you can join with it (or cancel it, depending on your setup) when you receive the save state event. At that point you can probably use partial serialization (as described by Matt) of the world (positions, velocities, etc..) and get acceptable results since you won't be in the middle of a world step.

This assumes contact joints and other dynamically generated bits of the World are generated every time-step and not retained for multiple time-steps (except for memory pooling purposes). Would this be a correct assumption?

Nov 23, 2010 at 12:41 PM
mattbettcher wrote:

If I get enough interest I will write up a small demo showing how this can be done.

 I'd be very interested to see a demo of how you'd recommend doing serialisation.

I'm still usiing farseer 2.1 (my whole engine and level editor would need rewritten in order to move to 3.1, which I'd prefer to avoid for now) and I can see in principle that I need to work through each object and store its position etc, but I dont know quite what all attributes I'd need to save.

Its for a WP7 project, where the phone can close down my app whenever it fancies and I want to restore the game so that from the user perspective it looks like it was just paused.


Nov 25, 2010 at 9:26 PM

I would be interested, maybe it could even be combined with the port recently posted here: