Well this is it, the documents are all finished, the presentation went well and terms almost over. I feel that as a team we have worked well together for the whole term, and we have all made significant contributions to the project. I can’t wait for next term to begin so we can really move on with the actual implementation of the engine. The last couple of weeks were really spent finalising the design and plan stage of the engine and the game, and in putting together the presentation we gave, my main part for this was to create a short video of a tech. demo that showed some of the features we have been working on so to finish up I will let you take a look. This will be all until after Christmas and New Year so I hope you all have a good one.
Alpha Team 11.1
Alpha Team 10.1
Where did 9.1 go? My schedule got confused with the re-timetabling last week and it completely slipped my mind. But on to what I’ve been up to.
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.
Alpha team 8.1 (A little late)
Now we’re onto the good bit, coding. So far this week I have created place holders for the majority of the base classes required to implement the online demo, and have implemented the collision detection system. I have also started work on the movement and positional modules. Code may be the most enjoyable part of the project it is unfortunately one of the most boring parts to talk about. Especially when it doesn’t have any viewable output yet. Hopefully by the weekend I will be able to post some preliminary screen-shots, so until then I’m afraid there’s not much else to say.
Alpha Team 7.1
Another busy week as we all worked towards putting the finishing touches to the tech. document. An important but rather dull job when it comes to writing a blog. What I did find however is how important a tech document is in clarifying the actual details of a project in my mind. For me it really brigs a sense of reality, not to mention urgency, when you see a detailed class diagram, especially when you see how much is actually required to be implemented. I still feel that we will be more than capable of completing the first build of the engine within the time allotted to us, and as Neil and myself have been tasked with writing the first build we will probably be having a good long discussion on this today.
Team Alpha 6.1
Another week nearly finished and a productive week it has been.
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.
Team Alpha 5.1
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.
Team Alpha 4.1
Another week is nearly over and I feel that we are still progressing well as a team. Having talked to the others they all seem to be proceeding well with their areas of research and I feel that I’m doing pretty well as well. I’ve now finished a first version of a 3d graphics/maths tool-kit that gives us access to matrices, matrix stacks, frames and view frustums. It also has a 4d vector class in it that was provided by Kieran. It also includes a maths class that has definitions for commonly used constants like Pi, and 2Pi and also has methods for converting between degrees and radians.
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.
Team Alpha 3.1
We are coming to the end of the third week now and things are going well, we have all completed our preliminary research and now have a better idea of what we can and can’t include in the engine.
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.
Team Alpha 2.1
We are well into the second week of development, and things are going well.
I have been tasked with researching some specific AI topics involving flocking and group movement, and also with looking at some outline ideas for the underlying framework of the engine. The first priority however is the AI research.
To this end I have looked out some old projects of my own where I first looked at implementing a simplified version of the ideas discussed by Craig Reynolds at SIGGRAPH in 1987, (copy of the paper here).
While this does simulate simple group cohesion, we will want to alter the algorithms I developed so that groups will also include goal seeking behaviours, and will move with more purpose. We will also have to include some algorithms that allow the player to manually command selected groups of individuals into one unified group and move as one.
Team Alpha 1.1
Well it’s back to group work again, and this time we’ve got two trimesters to create a 3D game/game-engine. Having two terms will give us the chance to really take our time in the early stages and ensure that our actual software design phase works. We have already agreed that unlike previous projects we aren’t going to rush in and start hacking away at code rather we are going to design our solution before we start to implement it. Our team consists of:
Me( Keith Grant)
It’s still early days (we only started this module yesterday) but we have already made a number of important decisions. We have agreed that Kieran should be project manager, Neil’s going to work on the graphics, Anthony will work on the the UI and I will work on the basic engine design.
We have also decided that instead of what we suspect the majority of students have done over the years, we are going to design an engine aimed at making Real-Time Strategy(RTS) games. We all agreed that this would provide us with a new set of challenges that we hadn’t really faced before, and would allow us to do some interesting work with AI.
The first thing we have to do though is create a 5 page project plan for submission next Friday. There is still some confusion over what exactly has to be provided within this plan, but as far as I can tell it is to be a basic outline of our goals over the next few months. It should include a rough guide to the major deadlines and milestones within the project. I think it will also include information on which third-party library’s we want to use along with a good justification for each one. Obviously we are supposed to be programmers and so we should be creating as much of the code as we can, but certain third-party library’s such as the BASS audio library (or similar) will be almost essential as it would be a whole project in itself to create our own versions from scratch.
On the whole I am looking forward to the project, and we have a good team. Every member is motivated and hard working and I feel that by the end of the academic year we will have produced something we can really be proud off.