SyntaxHighlighter
Thursday, 1 July 2010
Code, delete, re-code
One issue with the idea of game driven development is the fact that I find myself spending hours over an issue that has a quick fix FOR THIS GAME but not for other games, and hence is useless for the engine.
I came across an example last night whilst debugging my latest build of Tetris. At the core of my engine is a game state manager. This works by having a stack of 'in use' states, and controlling whether or not those states in use are visible and enabled.
Those states that aren't on the stack are removed from the game's component list and are added to it when they join the stack.
This all worked fine until I created game components that were owned by my game states. If the owner state was removed from the stack, the owned components remained active. Problem.
Now, its a simple enough matter to fix. I don't really need all the objects that are currently 'owned' game components to actually inherit from the GameComponent class, I can just call their update and draw methods from within the owner's update and draw methods.
However that's not a very satisfactory solution, especially in a more complex game where the playing state might have many sub-components.
I have two options that I can see. The first is to add a components list to the base game state and add the components to that, which then adds them to the Game class's component list when the owner state is pushed onto the stack, and removes them again when they're popped or removed from the stack.
The other is to re-evaluate my whole approach to game management, as the game state system isn't as flexible as others I've seen, such as unity's Scene - game object - component hierarchy, or UDK's system where everything is a 'level'.
The second would be more work to implement but might save me from complex work arounds in the future, but the first is simpler to implement now and may turn out just fine...
Labels:
None
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment