I've had a fair bit of work to do in the last couple of weeks on Alta, mostly around the RenderManager2D class. Its essentially a scene manager that keeps track of all of the sprites to be drawn, each of which is assigned to a 'layer' to make depth sorting easier.
The interface for the RenderManager2D is based around a heavily overloaded function called AddToScene(), which is fairly flexible about what parameters it can take. I've also tried to integrate the layering system into the gameState system, by creating
int backgroundLayer, mainLayer, foregroundLayer, textLayer;
in AEGameState (base class for all game states).
I then altered the game state manager to change the value of these variables based on where the state is in the gameState stack. This has made it easier to know what layer to add sprites to, but its not particularly flexible, and will probably end up being cumbersome in the long term.
I've also set up a SVN repository on Assembla for Alta. The reason being I'm considering branching the engine at some point in the near future so that I can rewrite a lot of the base gameState management code.
I'm considering a new hierarchy along these lines:
Scene: equivalent to my gameState, essentially a discrete section of the game, e.g. a menu screen, titlescreen, level of the game etc. The management of the scene will essentially be the same as the current management of game states, with some tweaking to make it a bit less clunky.
GameObject: This will represent an element of the scene, and will be arranged into a tree structure, so that GameObjects can own other game objects, e.g. a menu might own a submenu, or a player object might own a weapon object. Changes to the parent object will filter down to the child objects, so if the player is destroyed in an explosion and removed from the scene, the players weapon will also be removed from the scene, for example.
Components: Each game object will be able to have a collection of components. These will be the bits of the object that actually change its state and react to stimuli. For example, a gameObject could have a physicsBody component which would allow the gameObject to be manipulated by the physics simulation. It could also have a mover component which checks the game's InputManager to see if a button has been pressed, and responds by moving the object in a certain way.
The idea of all of this is to allow as much flexibility for the developer as possible, whilst enforcing a strict OO design to the game. However, I would need to create some sort of prefab or archetype, which would allow the designer to create multiple instances of the same object with tweaked properties, or else it could be very tiresome creating every tree and bush on a piece of terrain!
I also picked up a cheap copy of Game Coding Complete this week.
Whilst its a C++ book it deals a lot with engine structure. The author advocates a model which separates out the Game logic (essentially the simulation of the game world, a lot of which would be game specific), from the 'Game view' i.e. the inputs and outputs of the game logic, so user input, graphics, audio, network code, AI (I'll get onto this in a second) etc. and then has two communicate via 'commands' with 'listeners' that then act on those commands.
The point behind this is to create a clear dividing line between the game logic and the rest of the engine, rather than make direct API calls. However, it sounds awfully like events and delegates to me, which can seriously cripple the xbox 360 when using C#. I'll have to look further into how the authors suggests implementing this structure, but I'm not sure its one I'll be able to adopt with Alta.
Right that's enough for now.
Hopefully next weekend I'll be able to upload some footage of PacMan running, along with the game from James Silva's book.
No comments:
Post a Comment