Planet Ludum

Now, before we begin I'll be mostly talking theory, if you want you can download the entire source code as well as a sample program showing it works in a link I'll provide at the end of this page. This tutorial won't explain on how to implement the saving system I'm describing, but it will tell you a lot of theory to build your own based on Shells or use the code I wrote. If you don't find this tutorial that much helpful since you would like to know the implementation then look at the code in the linked file at the bottom of this post, not only it has everything setup so you can use my code in your project right away, but it has a very good readme file that explains everything from how it works to what every separate thing does, to how to integrate it with existing systems.

Part 1: the start


Part2: the Theory


What is a shell?
The theory behind shells is the following: you create a small object specialized for every entity you want to save in your game that holds which variables will be saved and loaded. It'll work as our intermediary between the entity to save and the buffer: [entity]<--->[shell]<--->[buffer]
The Ideal would be to be able to write something like this:


FooShell
{

SaveVars
• x[float]
  
• y[float]
  
• name[string]
  

}

...and then just call the shell's saveObject(object,buffer) and loadObject(object,Buffer). To achieve this we must create a system that:

• allows passing of a variable as a parameter
  
• allows passing the type of the variable
  

The difficulty lies that Shell and the entity we want to save are separate classes. By joining them into one we would lose the abstraction we have right now. So what do we do? We use a nasty little trick and instead of getting the variables themselves we get their offsets and sizes in bytes. What do I mean by that? Let's say we have an object with three float variables x,y,z and we want to save two of them, let's say y and z. This is how our object would look in memory:
  v-object start
[x][x][x][x][y][y][y][y][z][z][z][z]
where each [ ] represents a byte. to save y we need to get it's offset from the start of the object. for that we must handle some nasty pointer calculations. in theory you grab the address of y and then subtract from it the address of the object which is also the object start. In our case the offset of y would be 4 and it's size would be sizeof(float) which is also 4. Would you look at that! We already have a format for our variable storage entry in c++ it would look like this:

struct varEntry
{
 unsigned int size;
 unsigned int offset
};

our Shell class would look like the following

struct Shell
{
  virtual void fillEntityFromBuffer(baseClass* ent,char* buffer);
  virtual void fillBufferFromEntity(baseClass* ent,char* buffer);
  virtual unsigned int getMinBufferSize();
  static varEntry* variableList();
};

The member function variableList should return an array of statically allocated varEntry-s holding information about the offset and size of every variable to be saved/loaded for the specific entity that Shell was made for, to add simplicity that array should end with a special entry, you could chose an varEntry with size0 and offset 0 or size=0xffffffff and offset=0xffffffff (you can get this by casting a -1 to unsigned integer).
3. How the system works
In a Shell based saving system to save all the entities you'd do either one of these things: every instance of every class would need to have a member function that gives us the shell assigned to it. This works great for saving but problems appear when you are loading entities, and don't know which constructor to use.
My favorite mode of overcoming this problem would be to write a singleton factory class for every entity that could not only spawn the entity instance we want, but that could also give us a singleton shell object specific to that entity.

On the save system side you'd have one shell for every entity in game and one base shell corresponding to the one entity/class that is the common ancestor from which every other are descendant. An advantage of such system is that if combined with Macros you'll end up writing a little bit more code on the implementation but it'll save you literally thousands of lines of code throughout the project.
The workflow of this method is separated into two phases:
-Implementation
-Use The
Implementation phase is the most difficult and takes the longest to complete as you have to write a generic loading code for variables, however thanks to this initial stretch the Use phase, which is when you're actually assigning saving capabilities to every entity you want/need will take a lot less time and a lot less code.

So the things you'll need are:
• One common ancestor to all entities in game
  
• A Shell class, that's gonna be rewritten a lot (or not at all with macros), built for saving and loading the variables from a buffer.
  
• A variable storage entry with a specific format.
  

if done right with macros you'll end up with having something like this after every entity you want to save:

START_STORAGE_DESC(FooEnt,FooParentEnt,BaseEnt)
  STORE_VAR(x,TYPE_FLOAT)
  STORE_VAR(y,TYPE_FLOAT)
  STORE_VAR(name,TYPE_CSTRING)
END_STORAGE_DESC()

So that would be all! I hope you liked this tutorial/article/whatever and found it useful, even if not, you can still download my code here:[Shell Based Entity Save System]