ECS: Entity Parsing, Hacky Factory Method Approach

Okay so I started looking into re-implementing the entity parsing code and there was so much I didn't like about it the way it was currently done. Clearly in my previous implementation I just wanted to get something up and running as soon as possible, no surprise there. I basically had a class that had a massive switch statement based on the component name and then unpacked the xml and called the constructor. This time round however I wanted to make it as easy as possible for a user of the engine to create new components and start using them, which was the whole reason for the ECS re-factor.

First Approach

The first and main idea I found was based on an article written back in 1998 by Jim Beveridge called: self registering classes in C++. Essentially this approach used static initialisation to add an instance of a proxy object for each component to a vector which could then be used to create instances of the component itself. 

At this moment in time it is actually the way I have it working but at the time of writing this I am thinking about trying out a different method.

This approach does work at the moment and the main advantage of it is that all that needs to be done is that after the definition of the new component you just have to create a global version of the proxy templated with the new component and away you go, you can create instances of your new component based on it's name.

There are a lot of reasons I'm sceptical about this:

• Wow does this seem incredibly hacky!!
• From what I've read in forum posts across the internet static initialisation can cause incredibly hard to track bugs.
• Static initialisation can act differently depending on compiler, meaning this code may not work correctly when compiled on linux( something I'm wanting to do in the near future )
• There will be tons of globals all over the place
• A component will always be available if it's being compiled, unless you remember to remove the global proxy declaration.

So like I said I have literally just thought about trying a different way and here it is: 

Second Approach

Essentially it will work in a very similar way, there will be the concept of a "Component Store" as noted in the webpage I have linked. This will still hold a vector of proxy objects for creating components. Instead of doing all the hacky static initialisation stuff and having global declarations of things I will just fill the vector at runtime. Right at the initialisation of the engine, before any parsing can be done the Component store will run a function to populate it's vector. This itself has a few drawbacks:

• The Component Store will need to have a huge function adding proxy objects for all the components in the entire game.
• The Component Store will have to #include every component in the entire game. 
• This will cause a slow down at program start up whilst this vector is populated.
• Every time a component is added to the game, the user will have to remember to add it to the list.

Okay that seems like quite a lot of potential drawbacks but If I was to go down the route of the first approach and then come to try and get it to build on Linux or OSX to find it doesn't work then that would require a lot more work. I actually understand how the code works in this second approach as well which is much more valuable than it seems. 

Conclusion

So I have a lot more work ahead of me, I am hoping that this next part converting to the new simpler approach won't take that long. I am really glad I did this blog post before fleshing out the components using the Static Initialisation method as it would have meant even more wasted time. 

Setting myself a deadline of next Tuesday to have the new approach implemented for Components and to have done a blog post about it.

Thanks :)