The demo has been progressing well, working with Neil I got a model loader and asset management system up and running so now all assets are loaded one time only, so that’s a good start.  But more importantly we now have the ability to actually display output to a window.

To do this I implemented a (very) basic camera class that allows the player to move the camera forward, backward left and right.  I also added some quick and simple code for moving a unit about using the WASD keys, although once we have terrain implemented we will click a position as the units destination and the unit will make its own way there.  We are also now able to choose a specific unit using the mouse and and clicking the desired unit.  This has been achieved using color picking.  To do this I created a simple function that assigned each unit a unique ID as it is created and then this ID is passed into the shader along with the standard display info.  The shader then has two outputs one is the standard screen info that is sent to the display and the other is a buffer that holds a version of the view which shows each model as a flat color based on its unique ID.  A quick call to glReadPixels using the mouse co-ordinates as a parameter allows us to read the color value at the cursers location which can then be compared to each units ID to select the correct  unit.

On Sunday, Kieran and I finally managed to decide on a concrete structure for the AI and as I write this I am just taking a quick break from finishing the class diagram for it.  I also managed to finish the class diagram for the engine itself, and so we can now start on implementing it.  Before that however I’ll have to sit down with the guys and as a team we will have to decide on the file specification for our custom file types, this will then enable us to implement the load from file functions for the various components and entities in the engine.  Ultimately what we hope to have is a situation where you use the tools Anthony is working on,  to create a series of linked files which will then be used by the engine to create the finished game.  The user of the engine should be able to create a unique game without writing a single line of code.  Obviously if the user does alter or add to the engines base code they will be able to add new features but the design we have should allow for a wide range of different RTS games to be created without resorting to altering the code base.

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.

In addition to finishing the graphics tools, I have also started outlining the algorithms for our path-finding,  I’m sure it will be no surprise to anyone with even the smallest interest in AI that we will be going with an A* algorithm, however we will be running the algorithm over a navigation mesh rather a way-point map.  This is slightly more complicated to implement, but gives a more realistic movement to AI controlled characters.

A navigation mesh breaks the play area down into a number of convex polygons, some implementations only allow triangles, some allow n-sided polygons, personally I feel that triangles will be easier to utilize A* with but n-sided polygons may be easier to create automatically (we hope to have auto-generation of the nav-mesh, although that may well be a second term project).  The search algorithm then finds the quickest route between the start point and destination point, each polygon is given a cost value that is often based on average distance between the centre and the edges, or average distance between the centre of each edge.  The actual path however will be worked out using an algorithm that will calculate line of site and so smooth the path of the unit.

I’m currently working on a couple of diagrams to clarify the exact process in my head, and will post them up here when I get a chance in the meantime however there is a simple explanation here.

We also have a new team member this week and while it is always hard to integrate into an established group, I’m sure that he’ll get on fine and make a good contribution to the project.

Again I have spent most of the week deep in books on AI trying to gain a better understanding of path-finding and hierarchies.  Luckily I am also taking part in the on-line AI course being run from Stanford University and in the very first week they gave one of the clearest explanations of A* I have come across.

But although AI will be a big part of the game we also need to to be able to create a 3D world within which the game can take place.  As we are now using SDL for windowing and have been advised to stay clear of GLTools ( a library supplied with the OpenGL superBible that greatly simplifies the use of the new core profile), we also have to work on a number of classes to provide us with simple access to things like matrix stacks, view frustums and projection matrices.

We decided that if we are going to implement our own matrix stack, we would be as well creating our own matrix class, and if we are going to be creating our own matrix class we’de be as well to create a vector class and so we may as well create our own maths library.

This will  give us a couple of advantages, mainly that if we write it, then we know how it works and what it can and can’t do. This will also make it easier to add further functionality to it as well.   It does also however cause a couple of problems, the main one of which is making sure it actually works the way we think it does.  For me personally this caused some confusion when it came to issues like are the matrices column or row major, (This was especially important as we wanted it to be directly compatible with the GLSL equivalents and GLSL matrices are row major), and just because I think the ones I’ve created are row major does that mean they actually are.

Hopefully though we will have all this sorted out by the end of the week and we will have a full ( or at least full enough to be going on with) version of all the classes we need.