Over the past few months, I've been slowly populating my framework with nicely re-usable game objects: doors and switches, lifts and guns, items and characters. At first, it was going along really nicely. I had a few different game prototype building on top of the framework, and they were all nicely sharing these objects even though some were 3d and some were 2d, one starred a cow, and one had a spaceship. But as time went on, things started to get more complicated. The games had subtle differences in how they needed to use these things - the cow game (being a bit RPG-ish when it's done) wanted a serious inventory with equipable objects. But the space shooter wanted a lightweight gun swapping inventory. The Gun in the cow game was an item you equipped, but the guns in the space ship game needed to be part of a ShipComponent heirarchy.
Very quickly, I found myself spending more and more time trying to reconcile all the differences into a set of super-object that could be configured to be all things to all people. After all, these were objects in the framework darn it - so they better be re-usable!
So my "ah-ha!" moment came in two parts:
The first realisation was that I needed to formally separate game objects from scene objects. Previously, game objects were just another type of generic Behaviour object you could attach to a part of the scene - just like animation, a particle emitter, or a joystick controller. The problem with this is that you (i.e. the game, the scripts, the AI) couldn't unambiguously determine what something in the 3d world represents in the game world. Now, there's a new base class purely for game objects - allowing any game code to go up to a 3d object and know that it's a Door, or an Item, or a ShipComponent, or an Asteroid, or an EvilSorceror ... or any other game object your game wants to use.
The second realisation is that trying to commonise these things is a waste of time. Even if 3 games all have inventories, they're always going to need different gameplay rules, different slots, they'll need to know about different categories of items, they'll need to know how to map themselves onto different character models, etc. And the same is true for Guns, Items, and most everything else too. If I find myself re-using a set of objects across games in the future, I'll wrap them up into a re-usable game object library - but for now, a little code duplication is a glorious thing.
With these two changes under my belt, it's like a huge weight has been lifted off my shoulders! I honestly didn't realise how much this has been holding me back. Instead of agonising over every little addition to game logic (worrying about whether it's general enough, and how other types of games might want to use it and what options they should have, where it should fit into the class heirarchy, etc), I'm now totally free to just experiment with things - as each game project is in its own little sandbox, and the worst it can do is create a little mess of the small number of game objects it defines, while the framework code stays nice and clean.
Unfortunately, none of that translates particularly well into screenshots. But given I don't like to post without one, here's a cool ship prototype a friend of mine put together in Maya using the modular particle system I talked about last time: