TORCS Adaptive Real-Time Tracks

Since my last post I've managed to get a prototype of the track generation system up and running. It currently generates and loads an entirely new model file for each segment that is added to the track, running through TORCS' existing track generation functions. These functions have all been exported to a static library, and the client has access to these functions to enable what you see in the video below.

As can be seen, this is not the most efficient method for track generation at run-time within TORCS. It does however prove that it is possible without drastic changes to the existing framework. Possible optimizations would be to only generate a single track segment's AC3D file, and somehow merge this with the existing file. However, it is not yet clear where the computationally expensive part of this process is. It may be that removing and re-attaching the node containing the track from the scene graph is expensive, or it may be the track generation itself. This needs to be further explored before deciding on how it could be optimized.

ScareJam!

Artist: Brooke Hayes (Blog, Twitter)

Back in October, I competed alongside an artist in the ScareJam at the University of Lincoln. This was an interesting experience as it's the first time I've done any rapid development, particularly focussed on programming, alone. I decided to use XNA and C#, as I have a lot of experience with this framework and can develop quite rapidly within it. The ScareJam was focussed on creating scary games, and the additional game mechanics were "Loss" and "Important Sounds". We came up with "Lost and Sound", a title with a subtle nod towards the game mechanics! Lost and Sound is a game in which you must go into an abandoned hospital in search of your lost daughter, as she's been kidnapped by the ghost that haunts it! Most of the game mechanics are intended for the player to discover alone, and the game is intended to be somewhat of a mystery. I will let you explore the rest for yourself! To play the game you'll need a wired Xbox 360 gamepad, and the XNA 4.0 redistributables which can be found here.

Download Lost&Sound.

TORCS Adaptive

For my final year project at the University of Lincoln, I am currently modifying TORCS (The Open Source Racing Car Simulator) to generate tracks at runtime. It is then intended that these tracks will adapt to the skill of the player, depending on several performance measures. The project is currently in it's very early stages, but some simple run-time track generation has been implemented alongside some telemetric functionality, though these values are not yet used in any kind of performance measure. The following videos show some of the current features.

This video shows telemetry printing data to the console at runtime about the current car. The car here is one of the 'robots' that come with TORCS, which are compiled AI drivers written in C++.

This video shows a single track segment that has been generated completely at runtime. TORCS stores all of it's 3D models, including tracks, in AC3D files. Here, a segment has been generated at runtime and an AC3D file generated for it all during the runtime of the application. The next step is to find a way to update the existing AC3D file with new segment data each time a new segment is added.

The project's Github page can be found here, and more information can be found on it's wiki.

Component-Based Game Engines

I've been doing some reading recently into 'Component Based Game Engines', and wanted to share a few of my findings and thoughts about it, in the hopes it might interest someone. Component Based development has existed for years in the software development sector, so it only seems natural to attempt to apply this same theory to game engines. Before you read on, I'd like to point out that this is in no way going to be a tutorial or contain any implementation of Component Based Architecture, it simply serves to outline the theory behind it. I'd also like to mention that there is no RIGHT way of implementing Component Based Architecture - different approaches can be taken by different engines, depending on personal preferences and the requirements of the engine.

Imagine we're building an engine for a very generic 3D FPS. Usually, the first thing we would do is examine what 'objects' we have in our game, and create classes for them. We would also consider any shared behavior or data that certain objects need to have. For example, we have an 'Enemy' and a 'Player', which are both entities within our physical space. They'll need a position, maybe they each carry a weapon, and they each need health points. We'd then consider some objects further down our inheritance tree, for example different types of enemies would need different behaviors so we would probably be deriving enemies from our enemy class. This is the kind of game architecture that we are all used to. The following class diagram is one we should be comfortable with, it's a simple representation of part of the object hierarchy for a 3D FPS.

Familiar enough, yes? The Player inherits different behavior by overriding the virtual Update function in the ModelEntity, as does the PowerUp. The PowerUp then has two derived classes that add additional behavior on to that. This is a well established paradigm for structuring a game engine, as in our update loop we can treat all classes derived from ModelEntity uniformly in a single data structure, and make use of polymorphism and dynamic-dispatch to handle the different behaviors of each entity.

So, what actually is Component Based Architecture? Component Based architecture is different to our usual object hierarchy in that it focuses on making compositions of 'components' to form a game object, as opposed to the game object getting it's functionality through inheritance. When applying component based architecture to game engines, I find it is easier to refer to these components as 'Behaviours'. Each of these different Behaviours have their own Update() and Draw() functions that pretty much allow them to 'do their thing', and data members that are specific to that job. For example, the component 'ModelRenderable' may contain a Model and it's Draw() function may simply render that model. It may also have a velocity, or direction, or bounding box, the functionality of which is handled by it's Update() function. We can then group these behaviours together in composite classes in order to create what we consider to be a 'Game Object'. A player, for example, may contain a 'ModelRenderable' behaviour, a 'Health' behaviour that keeps track of their health, and any other functionality needed for that specific game. We can then refer to these 'Game Objects' polymorphically, just as before in our object hierarchy approach, in a 'Game World' object, that contains a collection of Game Objects. It's Update() and Draw() functions simply call the Game Object's Update() and Draw(), which in turn can carry out all of it's different behaviours. The following class diagram is a very light-weight outline of how Component Based Architecture could be implemented for games.

So the next question is - why use Component Based Architecture? We're all comfortable with object hierarchies, they're well established so that we can all understand one another's code. Well as to the answer to that - I'm not entirely sure as of yet. There are some cases in which code in object hierarchies can become very bloated, where base classes can implement code that is not used by some of it's derived classes. This makes sense however - as if a class uses most of it's base class' functionality, why re-write it just because it doesn't use some of the other base class functionality? It would add a lot of unnecessary code. But a component based engine would avoid this issue - as objects only implement the functionality or behaviour that you know they require. I've added some links to other resources and reading that might help you further understand Component-Based Architecture.

• Shows some of the problems that occur in object hierarchies, and also shows some different ways of implementing Component-Based Architecture: http://www.raywenderlich.com/24878/introduction-to-component-based-architecture-in-games
• This post by Gareth Jenkins of 36peas uses a similar architecture to one I outlined above: http://www.36peas.com/blog/2011/9/15/lightweight-component-architectures-and-object-composition-i.html 

Kinect Full Body Collision Model

Just a quick post on something I thought I'd share, for anyone out there who's developing games for Kinect using XNA. This is a fairly simple implementation full-body collision in 2D for Kinect, using Separated axis Theory to detect collisions. A particularly in-depth and intuitive paper about Separated Axis Theory by Johnny Huynh can be found here:
http://www.jkh.me/files/tutorials/Separating%20Axis%20Theorem%20for%20Oriented%20Bounding%20Boxes.pdf  (Accessed 01/04/2013)

This paper also explains some ways to optimize the computations used within SAT and how to use it  in three-dimensional space, so is well worth a read.

To summarize, SAT can be thought of as shining a 'light' on to any two convex shapes. These shapes produce shadows along their different axes, and if all of the axes of both shapes have intersecting shadows, then we can infer that the objects are colliding with one another. If you're not familiar with Vector Projection, you may want to go and have a read-up, since that's the main mathematical principle used in SAT. My collision model simply maps the different joints, and creates object-oriented bounding-boxes for each limb, rotating the box by the angle found between the center-point between two joints and the up vector. The implementation also stores information about the velocity of a given limb, by calculating how much and in which direction the center-point of the limb has moved between each frame. This feature is designed to help with collision response, and could be used to implement some simple 2D physics, for example. The collision detection algorithm uses a Collision Tree, a collision rectangle is drawn around the entire body, and if an entity collides with this, it can then be tested against each individual limb. This improves efficiency, as the program is not having to check for collisions against each limb every single frame for objects that are no where near the player's body.

Full source code and and an executable of the sample program can be found below. If anyone uses this in their project, I do not ask to be credited. But feel free to drop me a line so I can see what you're doing with it!

Downloads:
Source Code (VS2010)
Sample Program

Theme Park Scene Complete

I have just returned to University after the christmas break, and I am now finishing up last semester's projects. The theme park scene is now complete, and a full demo video has been created, and can be viewed below.

I am happy with how the scene has come together, although there are a lot of more advanced graphics programming concepts I now wish to explore much further. The most prominent of which is tessellation of surfaces in order to achieve better lighting effects. However, from here I wish to move away from the now deprecated fixed function pipeline and begin to explore more modern OpenGL, now that I have a grasp of some basic 3D programming techniques.