browser icon
You are using an insecure version of your web browser. Please update your browser!
Using an outdated browser makes your computer unsafe. For a safer, faster, more enjoyable user experience, please update your browser today or try a newer browser.

200 commits and counting

Posted by on October 18, 2010

Today I commited the 200th change to the RemBolo source code.  This also marks some milestones reached:

  • Proof-of-concept for the game object model by implementing various stone types, figures and “immaterial” objects like rubber bands.
  • Rooms (levels) can be loaded / saved from XML files
  • Created a basic GUI for selecting level files

The GUI thing wasn’t that difficult at all.  The CEGUI library was easy to compile and integrate with the Ogre graphics library. It was fairly easy to grasp the basics from the documentation. Just as it should be.

The serialization (loading / saving of game objects) was another topic. If you g**gle for “C++ serialization”, you get an overwhelming number of “suggestions”. The idea is to let all objects handle their (de)serialization by themselfs instead of having central “load” and “safe” functions that need to know the details of all objects.  This is the way to go if you want an easily extensible code base. I already had a basic idea how to implement this stuff myself but I thought I would give one of these “serialization” libraries a try. Since RemBolo already uses boost excessively, it was only natural to try out boost.Serialization. I liked many things about it:

  • Easy to add serialization to an object. Just one additional method and a few macro calls needed.
  • Clean source. Serialization method can handle both serialization and deserialization with the same source without the need of conditions.
  • Automatically handles serialization of built-in and standard types like vector, set, map.

What I disliked:

  • Too much “macro magic” behind the scenes. Library source code is difficult to understand. This is propably true for any generic serialization library.
  • The XML archive output is too verbose (e. g. using element text instead of attributes to store single values). Since one of my goals is to have a level format that can easily be editied by hand, this was a no-go.

I could have written my own archive plugin for boost.Serialization to get a cleaner output or try out another serialization library. But I decided it was not worth it. In the same time I could completely write my own serialization code and also learn from the experience. So I developed a simple serialization model based on inheritance. It uses the factory pattern for deserialization, boost.PropertyTree as the archive format. The code is propably not as clean as with boost.Serialization but easy to understand and customize.

Enough tech babble, some screenshots:

Leave a Reply

Your email address will not be published. Required fields are marked *