Question

I am migrating a tile based 2D game to C++, because I am really not a fan of Java (some features are nice, but I just can’t get used to it). I am using TMX tiled maps. This question is concerning how to translate the object definitions into actual game entities. In Java, I used reflection to allocate an object of the specified type (given that it derived from the basic game entity).

This worked fine, but this feature is not available in C++ (I understand why, and I’m not complaining. I find reflection messy, and I was hesitant to use it in Java, haha). I was just wondering what the best way was to translate this data. My idea was a base class from which all entities could derive from (this seems pretty standard), then have the loader allocate the derived types based on the ‘type’ value from the TMX map. I have thought of two ways to do this.

1. A giant switch-case block. Lengthy and disgusting. I’m doubtful that anyone would suggest this (but it is the obvious).
2. Use a std::map, which would map arbitrary type names to a function to allocate said classes corresponding to said type names.
3. Lastly, I had thought of making entities of one base class, and using scripting for different entity types. The scripts themselves would register their entity type with the system, although the game would need to load said entity type scripts upon loading (this could be done via one main entity type declaration script, which would bring the number of edits per entity down to 2: entity creation, and entity registration).

while option two looks pretty good, I don’t like having to change 3 pieces of code for each type (defining the entity class, defining an allocate function, and adding the function to the std::map). Option 3 sounds great except for two things in my mind: I’m afraid of the speed of purely script driven entities. Also, I know that adding scripting to my engine is going to be a big project in itself (adding all the helper functions for interfacing with the library will be interesting).

Does anyone know of a better solution? Maybe not better, but just cleaner. With less code edits per entity type.

Answer 1

You can reduce the number of code changes in solution 2, if you use a self registration to a factory. The drawback is that the entities know this factory (self registration) and this factory has to be a global (e.g. a singleton) instance. If tis is no problem to you, this pattern can be very nice. Each new type requires only compilation an linking of one new file.

You can implement self registration like this:

// foo.cpp
namespace 
{ 
  bool dummy = FactoryInstance().Register("FooKey", FooCreator); 
}

Abstract Factory, Template Style, by Jim Hyslop and Herb Sutter