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.