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.

Matrices and vectors

Having learned about matrices and vector or rather revised about the we began to implement their properties and behaviour in c++. Our tasks for the next few weeks was to essentially write both marix and vector classes for our application. These were to include all the fundemental features exhibited by both matrices and vectors. For instance vectors should include methods for dot product, and methods for cross product(vector multiplication) and much more. As for matrices, well they should include methods for transformation matrices, methods for rotation matrices and many other methods.

Most of this would be used in the following week in which we were required to comeup with a camera class which would be used to view our scene when the final renderer was built. Not only that but these special vector and matrix classes would also be used to tranform our objects in our scene during the rendering phase.

Intro To 3D Graphics: Our goal

WEEK1

In week 1 we had an overview of what we want to have as an outcome at the end of the module. Things discussed were coordinate systems. This is basically how our virtual world can be represented in our computer. We discussed how we can use the cartesian coordinate system. cartesian space can have 2 planes, the x and y planes for 2 dimensions or in the third dimension we introduce another plane the z axis. With the z axis however you have to decide on whether you wish to use the left hand system(this is when the positive z axis is into the plane) or the right handed system(this is when the positive z axis is out of the plane).

So you have to make sure you select a system to use and remain consistent with that system. We also discussed about data sampling for 3d geometry and about how these points to be plotted are stored in the geometry.

GDT:Five On Treasure Island Brief

GAME DEVELOPMENT TECHNIQUES

BRIEF:
For the GDT module we have to do a total conversion of unreal 2004. The game we are making has to be based on one of the famous five books by Enid Blyton. I am basing my game on Five on Treasure Island. Now this is the first book in the series. This book tells the story of how the five meet for the first time. It is also about their forst adventure together.

In this book the four children and Timmy the dog get to visit a shipwreck, castle on Kirrin Island aswell as the castle dungeons in search of treasure in the form of Gold.

I chose this because it does have great potential as a game. The children visit diverse environments as I stated previously which is great because his automatically gives me great templets interms of level design. For instance I could have a level in which they are on the beach and then they could go on the shipwreck and later on go onto the island. This makes it easier for me to have diversity in my levels making sure that the player doesnot get bored with seeing the same kind of environments over and over again. A brief overview of my design document and how I intend to implement my designs will be available on my next post.

INTEL X86 MICROPROCESSOR FOR THE XBOX

The intel x86 microprocessor is a register machine that uses a CISC( Complex Instruction Set computer) instruction set. Which basically means the intel x86 chip in the xbox stores and executes complex instructions which perform multiple tasks such as arithmetic operations sequentially(www.siyobik.info, 2009).

Example machine code:

mov eax, 1
mov ebx, 10
xor ecx, ecx
our_loop:
add ecx, eax
inc eax
comp eax, ebx
jile our_loop

Most of theselines represent an instruction that gets executed by the processor.

The code in C++:

int calculate_sum(int limit)
{
int sum = 0;

for(int i = 1; i <= limit; i++)
{
sum += i;
return sum;
}
}

The instruction pointer (this is what contains the address of the current instruction being executed) is stored in a 32bit register(www.siyobik.info, 2009).

More info on the x86 chip at: LINK

One homebrew disassembler for the x86 chip is known as OllyDbg developed by Oleh Yushun. Its a 32bit assembler level analysing debugger for mcrosoft windows which emphasises on binary code analysis. More info and free download available at: LINK