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.

The Renderer so far...

In the prvoius weeks(weeks 1 to 4) we were tasked with implementing matrix and vector classes. In the upcoming week (week 5) we had to implement a camera class. What we had to was implement all the properties of the camera class which included the View and projection matrices for the class aswell as the screen matrix. These were required for rendering inorder to tranform our objects from world space into camera space and finally into screen space. If I didnt mention this earlier, we are using MD2 models for this project. Implementing these was fairly straight forward, having extensively read about this particular topic in a couple of computer graphics books.

Next task was to implement the rendering part of the the program there completing the rendering pipeline. To begin with I did have afew problems understanding the whole concept of a bitmap and pixels, colours and how all this was connected. I read several computer graphics books on the topic but I still could not find a book that explained well enough for me to understand. So I continued reading both in books and searching online for better explainations on the topic. I later came across an explaination in one of the books I had which prompted me to think of a bitmap interms of an array of data. This really made it much easir for me to understand what a bitmap was and how to use it. Having finally understood what I was meant to do I continued implementing the neccessary methods and properties required for rendering objects onto the screen.

To begin with we were going to using GDIplus API for drawing our objects. The other topic that really made my head spin was the topic on vertices. To begin with it was stated that these were just points in space, fair enough. But came the idea of shared vertices, indices that reside in the polygon which index vertices(this was the bit that really got me confused). Again I decided to do asmuch reading as I could on this topic until I found something that could explain it to me in a way that I could understand. I found loads of info about the topic and most which explained the topic very well for me, so it didnt really take long for me to get my head around this. Back to the program, we had to implement a rasteriser using GDIplus which would connect all the vertices for us using lines enabling us to come up with a wire frame image of our object. Having setup all the neccessar methods required for the rendering pipeline(this included building and setting up the camera from our camera class, loading the object using MD2 loader calls class). Note that the rasteriser was a class of its own which possed all the drawing methods for the renderer. Having done this finally I was able to load up a basic cube and display its wire frame image onto the screen. Below are some screen shots of renderer displaying wire frame images:

THE GAME SO FAR...

In this post I will pretty much show a few screen shots from the game. At this point in the game I have got most of all the core mechanics working. I now have both of my levels pretty much built(all that is lacking is just detail in the levels i.e. static and mobile NPC's). I can switch between the Dick(the human character) and Timmy(the dog character who happens to also be my AI partner aswell).

When playing as Timmy you are able to use his special ability which enables you to see waypoints/markers which show you were your suppose to go incase your stuck or lost, ofcourse I have this working aswell. The other thing that I managed to get working is the compass. This works more like a radar as oppossed to a real compass but in a famous five game it would not have made much sense to call it radar so calling it a compass made perfect sense. What it does is it identifies the location of items, some objectives and special NPC's that you neeed to interact with in the game. The thing is though it has limited range. At first I wanted it to show everything on the map without range limit but I then realised that this would make the game abit easy. The range limit was introduced to force the player to still look for items etc, as these would only appear on the compass if the player was within a certain range of the items or objective or NPC. Here are some of the screen shots which illustrate everything I have just talked about:

This is the first level of the game. Compass on the right with an Icon of a nearby NPC.


A shot of the beach.

Player AI partner Timmy the dog(also a playerble character).

Playing as Timmy the dog in "Dog view mode"


These screen shots are all from the first level which is the beach. I will have screen shots of my other level in the upcoming posts. These are just some of the core features in the game. In the upcoming post I will talk about the problems and difficulties I faced when implementing these features.

THE GAMES DESIGN

To begin with I have had to change my design alot for this game. For instance in my initial design I didnot plan to have an AI partner that is Timmy(the dog). But now I do. I chose todo this because this did make the game much more interesting interms of gameplay mechanics. My AI partner doesnot really have advanced AI behaviour as such.

The AI simply follows you around and I designed this way because the dog is also a playable character. For starters if the player switches to play as the dog, they are able to see items they could not previously see(This is when the player switches to dog senses mode when they switch to dog). Dog senses mode reveals which paths the player should take if they are lost or if its not very obvious as to were the should go to next. This is a helpful feature interms of player feedback and information. The other thing that makes playing as the dog different from playing as Dick (one of the four children which the player will play as) is that there are some areas which only Timmy the dog can access. For instance in one of my levels the castle dungeons, the player arrives at a locked gate which can only be opened from the otherside so the player has to use Timmy to get through a small space inorder to get to the otherside of the gate and open the gate for Dick (yes I know dogs cannot open locked doors or gates but this is a game and if it adds to the gameplay why not?) . The player can change between these two characters at will during the game by simply pressing the "RB" button on the XBOX360 controller (If I forgot to mention then well the game uses a 360 controller).

Making the decision to have this sort of gameplay mechanic really opened a world of ideas for the game design and required a drastic change in most of the games design as a whole, seeing as I didnot plan to implement this in my first design. Ofcourse implementing and balancing this mechanic to work in the game was quit challenging but thats a story for another post.

The other major change in my design was cutting down on levels. In my initial design document I planned to have four levels which included a tutorial level by the beach, a level on the shipwreck, a level in the castle dungeons and a level in which the player is escaping from the island. I also planned to have sections in which the player was required to sail to the island in a row boat. As implementation of the game started and I began to familiarise myself with the Unreal level editor I realised that designing and building levels takes alot of time. There was no way I was going to be able to build four levels and program the game at the sametime and finish intime. I decided to cutdown on some of the levels. In its current state the game now only contains two levels, the beach level which serves as a tutorial level and the castle dungeon level. I will talk about these level in more detail in my upcoming posts and I will also be posting screen shots of the game.