Running a little late this week as I had other stuff going on at the weekend, however over the last couple of days I have managed to put together a fair bit of (admittally hacky) code to give a general idea of how the underlying game engine will function. The main problem with this is that it’s quite a short sentance for quite a lotof work.
So maybe a little detail about how I it works then?
Well the whole thing is based around a single class called GameComponent. This is used as a base class for maybe 90 -95 % of the classes. The general principal of the class is that it contains a vector of other GameComponents whose update and render methods are automaticcally called by the parent classes update and render functions.
For instance the whole game will be in a class derived from GameComponent and will contain (amongst others) 2 instances of a player class, an instance of a level class and so on. These in turn will also be derived from GameComponent.
So a call to game->render() would automatically call renderMe() and renderChildren(). The first function “renderMe()” obvoiously carrys out all the specific actions for game ( which being an abstract idea probably won’t have specific render code), and the second will iterate through each contained component and call their render() functions which will in turn repeat the process.
Now I’m off to take the test code I’ve written and create an actual OOP framework based on it.
This will take some time, and hopefully by next week I will have a complete UML diagram of the engine framework.
About Keith Grant
