Fuzzy Logic and AI for Racing Games

During my masters degree in games programming at the University of Hull, I was looking into integrating a technique known as fuzzy logic into racing game AI.   The goal was to determine how well my fuzzy logic AI behaved when compared to AI that did not utilize fuzzy logic.  Therefore I had to implement a conventional (non fuzzy logic) racing AI driver  as well as a fuzzy logic AI driver. For the rendering and physics I utilized middle ware. For all the rendering, I used an open source rendering engine known as Irrlicht 3D rendering engine. For physics simulation i.e. vehicle dynamics, I used Havok physics engine.  All the programming was done in C++.

PC and PS3 Sledding game.

As part of my masters degree in games programming at the University of Hull, we were split into groups of six and asked to produce a sled racing for both the PC and Playstation 3. This was both exciting and daunting for me since the only other devices I had ever programmed for besides the PC were mobile phone and the PSP. In terms of game design, decided to go for a checkpoint style racing game in which the player has to follow an arrow indicating where the next checkpoint is, and they must hit that way point in order to progress. Instead of making two different versions of the game for each platform, we decided to implement a cross platform engine in which the one game can be built on. Therefore we would only be making one game in one go to run on both platforms. The rendering API for the engine was OpenGL on both platforms, bullet was used for physics (both platforms), fmod (for PC only) was used for sound and CG by nvidia was used for shaders (both platforms). Interms of what I personally did for the project, I was mostly responsible for the playstation3 part of the engine. I wrote the PS3 version of the renderer and I was also responsible for making sure that the game and all the third party libraries built and ran on the PS3. I was also responsible for intergrating bullet to our engine and implementing some of the physics for the game. I was also responsible for intergrating CG with our engine and writing some of the shaders for the game.

OpenGL Seasonal Snow globe

This was my first application using OpenGL, since previously I had only ever used direct X. This was part of my masters degree in games programming at the University of Hull. All the lighting was done using shaders, per pixel ligthing and normal mapping(for the ground, water and house). The specs were to implement a snow globe, with a house, a pond, grass and a tree. It has/feature 3 seasons, firstly spring which has the tree growing, and then leaves grow on the tree. After the leaves have grown, we have autumn, in which the leaves change colour to yellow and fall and then the tree catches fire and burns away. After that we have winter, in which the snow falls down to the ground and smoke comes out of the chimney. After winter the cycle goes back to spring. Each time, the tree will grow differently. This was achieved by simply using a binary tree for the branches and trunk. The tree is also reflected in the water.

Traffic AI in C++

This an implementation of ambient AI traffic vehicles. This implementation is based on an article written by Joe Azdima on Gamasutra titled "AI Madness: Using AI to Bring Open-City Racing to Life". The following is the link to the article: http://www.gamasutra.com/view/feature/3106/ai_madness_using_ai_to_bring_.php?page=4 .

In this article the author describes how they developed certain types of AI for open world racing games such as Midtown madness 2 and Midnight Club (Azdima, J., 2001). The author discusses three different types of agents or AI which they developed for this game namely ambient traffic AI, opponent racer AI and pedestrians. However for this project I was mainly interested in attempting to reconstruct the ambient traffic AI. The entire project is made built in C++. For vehicle implementation I used Newton Game Dynamics phyiscs engine available at : http://newtondynamics.com/forum/downloads.php . For rendering I used an open source C++ rendering engine by the name of Irrlicht available at http://irrlicht.sourceforge.net/downloads.html . Both engines are much like the project itself C++ engines. The project makes extensive use of finite state machines. Basically all AI vehicles have states and they can only be in one state at any given time, depending on the kind of road they are in. For instance if the vehicle is driving along a straight road and there is no other vehicle close enough infront of it then that vehicle will be in a "Drive State" in which the vehivle will drive normally, how ever if the vehicle detects another vehicle infront of it will slow down(if it was travelling at a greater speed than the vehicle infront of it) and it will match the speed of the vehicle ahead going into a "Follow State". Other states included are states to handle traffic lights and stop signs. Something else that I implemented is steering behaviours(For more on this topic please read: http://www.red3d.com/cwr/steer/gdc99/). Basically within each state the vehicle can exihibit a variety of steering behaviours used to enable the AI vehicle to navigate the world. Essentialy the vehicle can have any number of behaviours enabled in its current state. The key behaviour which was implemented is the "Seek" behaviour. In this project waypoints are placed in each road and the vehicle "Seeks" out these points in order to determine where to go.

DIRECTX9 3D ENGINE

SUMMARY:
This is a directx9 framework I had o build as one ofmy assignments. The demo that you can see above shows some of the features implemented into the framework. The framework features/includes a fully functional (and abstract) scenegraph, complete with an abstract scene node class. I also have a fully functional state machine complete with a state class. All the objects in a game made using this framework would be scene nodes, for instance in the demo the vehicle is infact a scene node obviously a very specialised scene node. In the demo you can switch between different states via the use of the state machine. The demo has two levels you can switch between with the press of a button. These are implemented as states and can be switched back and forth by cycling through the state machine. Just to be clear there is only one instance of the scenegraph that exists in the application. I could have had it as a singleton but instead decided to have each state include a pointer to the scenegraph. The scenegraph takes care of the updating and rendering of the scene nodes in the current state. When the state is switched to a different state the scenegraph is emptied of all the current scene nodes and scene nodes from the new state are loaded into the scenegraph. I would also like to point out that the camera is also a scene node and it contains its own state machine. This makes it easier to switch between different camera views/states instead of having different camera node. Camera states simply change the behaviour of the camera thus enabling different camera views etc.

For user input the framework supports keyboard, mouse and a joy pad specifically a xbox360 controller. For the demo in particular the xbox360 controller is what is mainly used. To turn the vehicle the D-Pad is used, to accelerate the vehicle the Right Trigger button is used and to Brake/reverse the left trigger is used. Ofcourse as stated earlier keyboard input is also possible.

THE DEMO:
The demo as you can see is terrain based and as stated earlier is meant to show some of the features implemented in my framework. It features a particle system in the form of dust generated by the vehicle as it moves through the terrain. It also features collision between the terrain and the vehicle object. As you can see from the video the vehicle orients itself according to the height at its particular position in the terrain. The terrain itself is randomly generated. I used the midpoint displacement algorithm to generate the terrain but for the flat track or road I simply stenciled that part of the terrain. What I did was to load up a black and white texture. The texture has to be the same size as the terrain in order to have one to one mapping. If the part of the texture mapped onto the terrain was white then the height at that point would be the specified height which in my case was zero, and otherwise if the colour was black the heights would reamin as they were. Ofcourse this was only done after the terrain had already been generated.

I could have used hardware lighting for the terrain but I prefered to use slop lighting algorithm simply because it is much better performance wise to use this lighting technique as oppossed to hardware lighting. As I stated before, you can switch between two levels or terrains in the demo by either pressing the LB button on the controller or the RB button. Each of these terrains have different textures and parameters which define how the terrain is generated for instance how rough the terrain should be etc. Since the is random generation, each time you switch to the next terrain or you switch back to the previous terrain, the terrain itself will not be the same as it was before. Essentialy it will be regenerated randomly each time you switch.

CHALLENGES:
There were indeed quit a few challenges faced when implementing this. Firstly this was the first time I had used directX so there was abit of a learning curve when it came to figuring out how it worked and which functions did what etc. One other huge challenge was learning about scenegraphs and scene nodes, state machines etc. These were quit new concepts to me so it took quit a bit of time to again figure things out and try to understand how these structures functioned and how to ultimatly implement them in the framework.

FUTURE DEVELOPMENT:
I will ofcourse keep developing this framework/engine until I finally make some sort of game from it. In future I would love to first of all clean up the engine abit more, refactor the code quit abit and remove some of the things that arent needed anymore. Having done this I would also like to some sort of collision detection between game objects. Something I would also like to add is a resource manager, which would make it easier for me to load and manage models, sound files, textures etc without much difficulty. Something else I would like to add is a sound engine most likely built ontop of f-mod or direct sound. There are plenty of ways inwhich I would like to extend my engine many which have not been mentioned for instance shader support.

MY WORK(DEMOS)

COMPLETED DEMOS

UNREAL TOURNAMENT 2004 TOTAL CONVERSION: FAMOUS FIVE ON TREASURE ISLAND
walk through video of the complete demo:


SUMMARY:
This is an unreal tournament 2004 total conversion based on the book Famous Five On Treasure Island. This is an action adventure game and so far the demo features two levels. The first level is designed to be a tutorial level which is intended to help players familiarise themselves with the controls and gameplay. In the game the player is able to switch between playing as a dog and playing as human character. Speaking of controls, the game uses an Xbox360/Windows controller and a summary of the controls are: the left thumb stick is used for moving forward and back, the right thumb stick is used for turning and looking around(orientation), Y button is the action button used for opening doors, talking to people and moving objects. The A button is used for jumping, the X button is used for viewing controls and hints whilst playing the game, the B button is used for crouching whilst playing as the human character, RB button is used to switch between the dog and the human player at any point in during the game. The D-pad button Up is used to switch the flash light/Torch on and Off. D-pad Left is used for ordering AI dog(thats if player is playing as human character) to Stop/Follow. D-pad Down is used to order AI dog to jump. The second level is based on the last chapter of the book were the player must follow the bad guys without getting caught and lock the in the treasure room. For more on the development process and design information please read the blog posts labelled as "Unreal Total Conversion: Famous Five Game".

3D SOFTWARE RENDERE:DEMO SCENE
Video of the demo scene demo:


SUMMARY:
This was a class project. The idea was for us to build a 3D software renderer from scratch in C++. This involved building our own matrix and vector classes, our won camera class aswell as our own custom rasterizer class. The models used are MD2 models thus we also had to use the MD2 loader file. The other part of the project was to comeup with an individual demoscene using our software renderer. The specifications were that it had to be original, creative and entertaining aswell showoff all the features implemented in our renderer. My demo as seen in the video features wireframe drawing, flat shading aswell as gouraud shading. It also features directional lighting, ambient lighting and point lighting. The objects in the demo are tranformed(scaled, rotated and translated) by the music's frequencies. For this I used a sound software API known as FMOD. For more on the development process of this demo please read the blog posts labeled as "3D Software Render".

EARLIER WORK
XNA:Enigma

Enigma, is a prototype game I developed in my first year using Microsoft XNA platform. As seen in the video its a scrolling top down shooter with a twist. The twist being that its a co-op game. The game uses Xbox360/Windows controllers and so far features two levels. In the first level both players are on one aircraft. Player one controls the aircraft interms of movement and orientation using the both the left thumbstick and the right thumbstick, aswell as activates shields using the B button. Player two on the other hand fires the two cannons. The left thumbstick is used to rotate one cannon and the right thumbstick is used to rotate the other cannon. The left and right triggers are used to fire each of the cannons. So this part of the game does need quit a bit of coordination.

The second part of the game is split screen inwhich both players must progress through waves of enemies and mini bosses. If one player dies then its game over. In this mode the controls for both players are identical with the A button being used for firing cannons, the B button being used for activating shields and the Left thumbstick being used for moving the craft. The only difference is in how each of the aircraft look, the type of cannons each one posses and their shield types. This difference was only used to give each player their on distinct personality but otherwise they both deal and recieve equal damage.

COMPLELTE

My 3D Software rendere Demo scene Video:

Looking back now that the demo scene is complete, writing a software renderer was quit exciting and very interesting. Coming up with a demo scene was even alot more chalenging seeing as creativity was required. Having pulled it off i am rather pleased with the results. Ofcourse it wasnt all smooth and like in every other project there were bumps along the way. Firstly the math involved was quit overwhelming at times, interms of getting my head around it. But this wasnt the biggest of my problems. What I found difficult initially was the fact that we were using C++ for this project and having never used C++ before for such a complex project, learning how to do certain things was quit a challenge. We had to use linear interpolation quit alot for this project. Understanding the concept of how this worked wasnt that much of a problem it was implementing it in C++ which I found to be quit challenging. Ofcourse after sometime I began to grasp the language, and obviously having only used it for several months I am still learning and I have a long way to go interms of mastering it but I now feel that I am competent enough to use it to the best of my abilities.

During the project I did have one huge problem which took me 2 weeks to solve. In a nested loop I typed in the wrong variable which made the entire program behave in a very strange manner. All my models appeared to have missing ploygons thus not all the polygons were being proccessed. This was very difficult to spot and as a result I wasnt able to proceessed with the project until this problem was solved. eventually(after 2 weeks) the problem was solved but alot of time had been wasted and as a result i did not implement some of the things I was hoping to have in my demo such as texturing. The other problem was that I was left with very little time to come up with an actual demo scene. But in the end everything worked out, not according to my original plan due to the issues stated but it all came together. Its has been an interesting process and I enjoyed every moment of it, even the frustrations. I learned alot of amazing things during this process. In future however i would think about the demo scene as early as possible, seeing as this time around I underestimated how it might take interms of coming up with a creative idea. As a result I left the planning for last and this proved to be more difficult than I initially thought it would be. For future development I will implement texturing, as I was not able to do so.