It’s my opinion, probably because I’ve written lots of database-driven apps, that all software can be reduced to a simple set of data structures, relations between the data structures, and the operations on those data structures.
Take, for example, this blog. There is a database table with the posts in, and then some PHP to turn that into readable HTML. Without the database, the site is worthless. The PHP, while important exists solely to display the data.
The same probably works for games too. Game objects have attributes, it makes sense to store game objects in collections for ease of management – put all the baddies in a collection, put all the bullets in a collection, collision test the baddies collection against the player, but don’t collision test the player against their own bullets. Level data contains attributes that are modified for each level. These also need storing in some sort of collection. Enemy AI is merely a type of attribute for each enemy type, and even the actual AI code should just modify known states for each sprite – ‘find player’ ‘move to player’ ‘shoot at player’ and so on.
Don’t forget the game’s menu system and title screens. They’re just more data – “Display splash.png for 3 seconds, or until mouse pressed” “Display main menu until option chosen”.
So, because it’s easier than trying to debug homebrew Nintendo DS code without a debugger, I’m in the process of making a game environment that accepts an XML control file to set the game up. It won’t be predesigned for any particular style of game, but it will be designed for 2D sprite-based games.
It’s my aim that by writing an XML control file, some enemy AI in a scripting language and drawing the artwork my environment can then render the game. The ultimate aim is to have a reusable game rendering environment that lets me create games of a certain style in a less error-prone way.
I have a sample XML file created already, and am now using the excellent TinyXML to parse this and turn it into a set of C++ classes. After that I will reuse the sprite management stuff from my DS coding and expose basic sprite functions – “move_x”, “move_y”, “explode” etc to see if I can make a simple game of some sort.
I’m re-using a lot of code that I’ve used before. I had a basic sprite and screen management system on my DS, which has been ported to Allegro/C++ and some of the code I did in Processing has been used too. I think I’ll stick with Allegro now, it not only has excellent documentation, but it also works and is complete and so simple to use.
Robustly parsing XML is possibly more tedious than writing SQL though.
