Al's Game Programming Blog

One of the goals of my C++ metaprogramming system is that it should be possible to generate a schema for game data directly from an annotated C++ program. This schema is important because it decouples the game engine from the tools that are used to process the game's data.

There seem to be three options here. The first option is the one I am currently investigating and also the motivation for my C# to C++ translator: generate the schema from the code. The second is to generate the code from the schema. The third is to write both the schema and the code by hand.

The last option is undesirable. It violates the Don't Repeat Yourself principle. The schema and the program express the same thing and one of the two is redundant.

The second option, generate the code from the schema, has some appeal, primarily simplicity of implementation. It has one problem I can't see a solution to though. A schema is data-centric whereas an OO program hides data within classes that expose a more abstract public interface. The schema language could of course be extended to include OO constructs for information hiding but then it would become coupled to the structure of the program, which is undesirable.

So lets say I generate C++ classes from a data-centric schema. The generated C++ classes will inevitably be data-centric too. They might just be structs with public data members. Or one might generate accessor function pairs for the data members. But that is just C++ gorp to make a C style struct look like a OO class.

Then, being a good OO programmer, I would have to write more classes that exposed a better OO abstraction. These classes might be initialized directly from the automatically generated classes. Here is an example:

// Hand written schema
[schema]
  [dynamite]
    [field name="fuseTime" type="int" default="20"/]
  [/dynamite]
[/schema]
 
// Automatically generated from the schema
struct SDynamite
{
  int fuseTime;
};
 
// Hand written OO abstraction for dynamite
class CDynamite
{
public:
 
  CDynamite(const SDynamite &d): fuseTime(d.fuseTime) {}
 
  // Abstract interface to dynamite
  void StartCountDown();
  void Update(float dt);
 
private:
 int fuseTime;
};

Of course it would be possible to embed the SDynamite as a private data member of CDynamite. But then CDynamite is tightly coupled to the schema format. It does not allow the internals of CDynamite to change without changing the schema. Notice the redundancy in the constructor. It is essentially converting between the schema format and the internal representation of CDynamite.

So generating the code from the schema does not appear to eliminate the redundancy. It just moves it around. The fundamental problem is the schema does not contain all the information necessary to generate an OO abstraction to itself. Whereas, through metadata annotations or naming conventions, OO code has sufficient information to generate a data-centric schema without redundancy.

// Hand written annotated dynamite class
CDL class Dynamite
{
public:
 
  PROPERTY
  ATTR(Serialized)
  ATTR(Default=20)
    int GetFuseTime() const;
    void SetFuseTime(int);
 
  // Abstract interface to dynamite
  void StartCountDown();
  void Update(float dt);
 
  // ...
};
 
// Automatically generated schema
[schema]
  [dynamite]
    [field name="FuseTime" type="int" default="20"/]
  [/dynamite]
[/schema]

Both examples express how to convert between the schema format and an object. In the second example, the schema format is inferred from the conversion. In the first example, both the schema format and the conversion must be separately expressed. There must be redundancy in the first example.

In the case where the OO class has the same or similar structure to the schema (probably a high proportion of cases), this redundancy can also be eliminated.

CDL class Dynamite
{
public:
 
  // Abstract interface to dynamite
  void StartCountDown();
  void Update(float dt);
 
private:
 
  PROPERTY
  ATTR(Serialized)
  ATTR(Default=20)
    int fuseTime;
};

This is similar to embedding an SDynamite data member in CDynamite but with one key difference. Embedding SDynamite is all or nothing. It is not possible to say I only want the fuse time from SDynamite but these other schema fields will be represented differently.

I see a potential problem with generating a schema from code as well. Which language? If I am using multiple languages, say a scripting language and C# or C++, which do I generate the schema from? If I want to be able to implement game components in both languages, I probably want both. So I need to allow my preprocessor to accept metadata from multiple sources. For that reason, I will start calling it a metacompiler.