Software Architecture and CPPGEN

After a long time I realized that the engine wasn’t very well architected. By this I mean that all the components were lumped together and were interfacing directly with each other more than they should. I decided to do a COMPLETE REWRITE of the entire engine (maybe using some snippets from here and there) using a better structure.

I have been working on the new design for about a month now and it is starting to come together. Here are some of the major changes to the engine:

• SDL is no longer part of the engine core. A new window management system will be used instead. This will allow the engine to be ported more easily to consoles and PC platforms without SDL support.
• The graphics API has been abstracted to a Renderer system. This uses an interface to allow more APIs than just OpenGL. This way DirectX, LibGCM and other APIs can be implemented. This also means that other engine components don’t need to deal with API-specific code.
• The game state system has been simplified. Now “states” are called “games” and should implement their own state management system.
• User input is now managed by an input manager interface.
• Different components are placed in their own sub-directories and namespaces.

CPPGEN

The current design lists more than 40 different classes, and the engine design is only about half complete at this point. Once the technical design documents have been drawn up and the structure is finalized, creating close to 100 class definitions will be tedious work.

To make this simpler, I hacked together a Python script to do it for me. All I have to do is write an XML file defining all the namespaces, directories and classes and cppgen will create everything for me. Right now it’s fairly simplistic and will generate class definitions of the form:

#ifndef NS1_NS2_CLASSNAME_H
#define NS1_NS2_CLASSNAME_H

namespace ns1 { namespace ns2 {

class ClassName
{
public:
    ClassName(void);
    ~ClassName(void);
};

}}

#endif

Where ns1 is the main namespace, ns2 is a sub namespace and ClassName is the class’s identifier.

It does not handle member properties, methods, inheritance or interfaces yet, but it could in the future. I would also like to extend it to generate getters/setters for properties and function definitions.

Right now the code is very messy and needs cleaning up before these features are implemented but it is in a usable state at this point.

Interested? Check it out on Github.

~ by Tom Savage on October 7, 2009.