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.

LOOKING BACK

Video of complete game:

Now that the demo is complete, looking back the development process wasnt completely smooth. To begin with I had a lot of problems trying to understand how unreal script worked. It took about three weeks to get my head around it seeing at this point this was the biggest code base I have had to work with thus far. This was a quit a challenge in itself. One major issue which I now realise set me back several times and might have even cost me quit abit of time was the fact that through out most of the development process I kept changing quit alot of things in my design document. Most of these changes were a result of realising that I might not be able to include everthing that I had originally planned to have in the given time frame. Some things had to be removed and as a result other things had to be included aswell. For instance originally I planned to have atleast five levels in the game. But I ended only including two of the five levels I originally plannned to have. In my original design I planned to enable the player to be able to switch between all five of the characters. Each of these characters would have distinct abilities, which would force the player to have to each one at certsin points in the game. But in the end I only ended up just having one AI partner(Timmy the dog) and the player could switch between the human character(Dick) and the dog on the fly. However the catch is There certain places the dog can go and only the human character is able to open doors and and interact(talk) with other NPC's in the game.

The other reason as to why I frequently deviated from my original every so often was due to the fact that once I managed to get my head around unreal script and unreal editor I realised that I could implement quit of things that would make my game look that much better quit easily. most these things were not in my original design, for instance in my final handin I included the ability for the player to issue orders to the AI partner without having to take control of him i.e. ordering the AI partner to stop, jump.

Although I did make quit alot of changes to my design I am very pleased with the changes that I made because in the end they made the game that much better than it would have been. Ofcourse the trade off was that I did lose quit abit of time make these cahnges every so often, time which I could have probably used in polishing up the game but most of these changes were to a certain degree neccessary. In future however as lesson learned from developing this game, it would be wise to carefully plan my design and stick to this design asmuch as possible. All in all I am very happy with how the game turned out, it turned out better than I expected and I enjoyed every moment of developing this game. For future development I would most certainly like to include the levels that were originally not included.