Basic Terrain Rendering and High Precision Network Timers

Long time since I have done an update and most of this is due to work overload at EverFire Studios as I work dilligently to produce code for our up and coming Bring Out Your Dead: Black Plague TCG. This brings me to my first topic: High Precision Network Timers.

To be honest, this is a field I am not entirely experienced in and had a trouble finding a place to start. The reason that we needed this in the game was to provide the clients accurate timestamps for their turns. The first part was simple - use a standardized time system and send that time to the client. But this brings one consideration to mind - latency. If any of you have ever played any game ever, you know what lag is, more so if the game was an online based such as Battlefield 4, League of Legends, or any MMO.

How did I go about this then? Well, I wasn't sure at first but that is why research exists.

After a few days of research I decided to create a model similar to the ideas of NTP stratum servers. Sounds quite wonky at first - which confused my lead as well. But I was not actually using NTP server, daemons, or anything of that nature. What I pulled from this was the implementation of a modified Marzullo algorithm. This algorithm calculates a best effort confidence level. And, instead of the client receiving multiple time stamps, calculating the values with least difference, and then apply that time, mine is reverse and singular.

What do I mean by this? My latency calculator goes as follows:

Game server thread sends message to event listeners that there is a time update.
The engine calculates the remaining time in a turn.
The server, on this event, sends the remaining time less the latency to the client.
The client receives this message and responds with a packet that sends the server response time as well as it's request time.
I have to take into consideration the time delay used for firing off the time update message.
After collecting X amount of samples the server calculates the new latency using values selected from the calculation of time intervals of client-server requests and client-server responses.
This is then the new latency.

Using this method, I reduce server CPU time by not calculating lag every pass, but maintain a tight interval of the lag. I also ensure that when the time packet the server sends, the client will have synced time with lag put into consideration.

Now to switch gears entirely, so don't think about time now. It is rendering time in regards to my engine. For my simple engine I, as a separate project, I am implementing a heightmap on terrain and mapped texturing. All very well basic methods (I am not a fancy voxel person just yet) to accomplish simple ends.

That blurb was more of an update than anything to prove I am still working on my game engine - albeit slowly now.As you can see from the beginning though, it is on its way to being something tangible!

DX10 Heightmap/Blendmap Terrain

So there you have it!

Tiny Update (XML Parsing)

In an old post I stated that I wanted to create a content creator script that would allow the generation of levels. I was going to implement it and got a lot of work on it done, but realized that I needed to go a different route. The reason I did this was portability and compatibility.

This lead me to store data as XML and load it into the engine as a per level basis. Then each level was pointed to in the overall world. This allows for level streaming- which was my original intent. It is also significantly faster than what I originally hoped to do.

To achieve this I implemented a wrapper for rapidxml (an xml API using the MIT or Boost liscense.) The purpose of the wrapper was to decouple it from the engine and hopefully build my own one day.

As far as updates, that is about it.

FPS Camera

From my last post I stated that I was going to implement an FPS camera into the game engine. This will be one of many cameras. The various cameras I wish to incorporate are a top down camera, which would be nearly similar to an FPS camera, a third person camera - which follows a user controlled object, and a cinematic camera - an FPS camera with no user input and on rails or static.

Well, today I finished my mouse look WASD controlled FPS camera. The math behind it was pretty simple and only took a couple dozen lines of code from combining my Movement class with my Camera class. Then I put all necessary input translations in regards to the up and right vectors of the camera and the movement of the position vector. Here is a sample of the code:

//sprinting //TODO: remove magic numbers if(keyDown(DIK_LSHIFT)) { mForwardVelocity = 2.0f; mStrafeVelocity = 1.25f; } else { mForwardVelocity = 1.0f; mStrafeVelocity = 0.75f; } //mouse look XMFLOAT2 newPitchHeading( getHeading() + mouseDX() * dt, getPitch() + mouseDY() * dt ); setHeading(newPitchHeading.x); //x rotation is equal to x coordinate mouse movements setRotation(XMFLOAT3( newPitchHeading.x, getRotation().y, getRotation().z )); if(newPitchHeading.y > MINPITCH && newPitchHeading.y < MAXPITCH) { setPitch(newPitchHeading.y); } //keyboard movement if(keyDown(DIK_W)) direction += forward; if(keyDown(DIK_S)) direction -= forward; if(keyDown(DIK_D)) direction += strafe; if(keyDown(DIK_A)) direction -= strafe; direction = XMVector3Normalize(direction); position += direction * mForwardVelocity * dt;

So essentially we take the mouse x coordinates and make that the heading value of the camera. This is essentially the look left and right with the mouse. The y coordinates of the mouse translate to looking up or down in the world. Conveniently, the camera class takes care of calculating the right and up vectors natively, so we omit it from the update method for the FPS player. We then apply the forward and strafe vectors (up and right) to the direction vector of the player and either increment or decrement depending on player input (W,A,S, or D). Finally, we normalize the direction vector and apply it to the position in relation to the forward velocity and delta time scalars.

Here is a video of the working camera:

Default Renderer Completed!

Today I completed my default shader for all static objects within my game world. By static I mean objects that are not animated such as a walk animation. My shader includes a diffuse texture, normal map, and a specular map. Those three textures are what I wished to accomplish at the minimum for my basic 3D models.

With my default shader complete I wish to incorporate a messaging system for all input so I can start creating a user movable camera. The reason I mention messaging systems is because of my current job at EverFire Studios. Recently we have decided to create a headless game engine for our current game in development. Naturally this meant a lot of research in design patterns. This also included patterns with messaging systems.

As to which messaging system to incorporate all input controllable objects... I do not know yet. I will have a detailed post about that at a later date, perhaps.

To recap, I have finished my default static model shader and will move forward with incorporating user input. Until next time, enjoy programming games!

Collision Detection and EverFire Studios!

Busy, busy, busy are my three excuses. It is still within the month and I will still try to update as much as possible in regards to my game engine, but man, I must go on a rant.

So, as mentioned before, I have started a job at EverFire Studios in Milwaukee, WI as a game play programmer. Currently, we are working on developing a new game and it has taken a lot of my attention. Perhaps when it goes alpha I will show some game play videos. On top of school and a second job, I have not had much time to work on my engine.

Well, at least I have something to show you. It is exciting and incredible...
It is two boxes detecting a collision with each other, and don't worry my spheres can do it too. With this I will implement a Rigid body physics system. But, honestly, I don't like programming physics - so I may go back to my renderer and implement a shader for diffuse, normal, and specular mapping as that is the bare minimum I want on my models in the engine.

Speaking of which, I need to think of a name... still!

So, since I wish to have this be somewhat intellegent, the idea behind simple AABB (Axis Aligned Bounding Box) and Sphere Collision is all of but a few simple statements. In order to get the code from this we just need to do the following:

Two spheres collide it the distance between their center points is less than their combined radii.
Two AABB collide when the absolute values of the x, y, and z coordinates of the length vector between the center points of each AABB is less than the cumulative values of the respective coordinate extents.

The sphere was easy, the AABB tests were a mouthfull, so here is the code in its simplest iteration:

bool Intersect(const AABBCollider& pVolume, const AABBCollider& other)
{
XMVECTOR volumeCenter = XMLoadFloat3(&pVolume.getCenter());
XMVECTOR otherCenter = XMLoadFloat3(&other.getCenter());

FXMVECTOR length = otherCenter - volumeCenter;

return fabs(XMVectorGetX(length)) <= (pVolume.getExtents().x + other.getExtents().x) &&
fabs(XMVectorGetY(length)) <= (pVolume.getExtents().y + other.getExtents().y) &&
fabs(XMVectorGetZ(length)) <= (pVolume.getExtents().z + other.getExtents().z);
}

And yes, for right now I am using xnamath for my math library; perhaps that will change too.

Until next time, enjoy game programming!

A Whole New World

Alas, I must admit defeat...

No, I must not,

Aye, I must...

That has been my thought process for the past month as new issues kept arising in my current game engine using the component-entity model. And alas, after realizing I was over-engineering, I admitted defeat.

But I had a secret weapon, and that was re-engineering my existing code to reflect a traditional OOP design architecture.

I know, not as intuitive, but I must digress, I need something to SHOW other than just a cube. And so far it has been successful. What I mean by this is that I have complete integrating a Shader class that is derived from and create any shader. I have a render-able Prop with colliders. And now I am fine tuning the collision system to implement Rigidbody Physics.

Within the month I will have a demo video showing as I still have to work on my projects with EverFire Studios, Inc.

Wish me luck and I promise I will have something to show you and a thorough technical post in regards to it.

And as always, enjoy game programming!

Rendering Architecture Established

For a while I have spent time on getting my DirectX 10 rendering system architecture established, and I am successful in that end of my engine. However, in doing this implementation, I have realized a few setbacks for my system. One such, that I will be swiftly reengineering, is the loss of data as my Entities fall out of scope (this is because I only use pointers after their initialization to do the rest of the work). What also happens is that iterating through each component registered does not match components correctly with 'brother' components (components of the same entity). This causes wrong calculations and issues within the system that are completely unacceptable.

Now, the re-engineering I plan on doing is creating hash values for each Entity within the system, use an Entity Manager, and correctly mapping components to their respective Entities. This will also make debugging entities simpler as that has been and issue.

Now, for the picture proof of my renderer actually working:

Long Time... No Post

It has been well over a month since I have posted on this blog. Most of it is due to a lack of time to put into my Game Engine... which still remains nameless. However, many exciting things have happened to me this past month, one of which is an announcement that I will be a Gameplay for Forever Interactive/ EverFire Studios - a game company located in Milwaukee, WI. So, that is where a lot of my programming efforts have gone to, not to fail to mention school work and a job!

Excuses... Excuses...

Now, for the real post - the progress on my game engine. So far I have been unable to render files parsed in from waveform .obj. Now, my first issue was a simple 'off by' error in a for iteration to fill in the indices of an object. However, that is not all. I have applied textures, but they are not rendering... I believe it is due to the model being created in a Right Handed coordinate system, so I will investigate that.

One issue that also happened was a lot of my D3D10 variables and interfaces were being passed as NULL from components. This was fixed by passing the pointer to a component, rather than pointers to variables inside of a component... grr, C++.

Either way, I promise to have at least a screen shot of something interesting next post.

Component Scripting and 3D Rendering

It has been a while since I have posted an update in regards to my Game Engine Design. Well, for the most part, my Component-Entity Design and manager are completed and compile without errors. The nice thing is that it also shuts down without any memory leaks as well.

So, in the long haul, it looks like creating entities will be a breeze after I incorporate a file parser for a standard text file that will create entities. How will this work? Well, I plan on creating a class that will handle the importing and parsing of the file, send that data mined from the file and send it to the World (a class that contains all the entities, managers, and processors). From there the World will create Entities with the given components that the file dictated.

An example of what I want to do is as follows:

(In .txt file)
new Entity "PhysicalObject"
{
    has <Movement>
    {
        Position(1.0, 1.0, 1.0);
        Rotation(0.0, 0.0, 0.0);
     }
     has <Physics>
     {
         Acceleration(0.0, 0.0, 0.0);
         Mass(25);
      }
}

So, to explain this, I would have a buffer of the file contents loaded into the program and then have each symbol interpreted based on what I declare data relevant to the creation of Entities. For instance, in the above example new Entity would declare the intention to create an entity with the given name in quotation marks. From here, all data in the brackets lists the components it has. That is what the keyword 'has' is for. When the parser finds the 'has' keyword, it will search the brackets ('<' and '>') for a relevant identifier of an identity. It will then convert this to a bit field that identifies entity components for registration with the entity manager. The, inside of the brackets after the declaration of the component, is the definition of the components properties. If one was to look at <Movement> they would see that in the brackets is defined Position() and Rotation() with values separated by commas. This determines the initial position and rotation of the entity in question.

This is just some of what I wish to do with a custom text importer for the creation of entities in my world. What I hope to achieve with this is rapid development of games or simulations without the need to recompile every time I want to add a new type of entity.

Now that I have explained what I wish to do going forward, I have to talk about what has to get done first. In order for me to actually see if my methods are working and this program works, I need to get something rendered to the screen. Now, since this is primarily a game engine, I need to incorporate 3D models, 2D textures, Rendering to a texture for effects, and shadow mapping. This would be the core of my rendering engine.

So far, I have finished a file parser for static .OBJ files for 3D objects. The only hitch is that it only imports the models geometry, normal, and UVs. The texture would have to be imported separately and then applied. Speaking of which, my texture importer is also done.

The only things left on my TODO list for the 3D rendering engine is as follows:

Class and interface for .FX files.
Class and interface for Shadowmaps.
Interface for 2D textures of models.
Class and Interface for Render to Texture for effects.

From there I will have all of those interfaces accessible through the DXManager that I have already completed. I plan on completing this within the next two weeks, so feel free to check in within that time period for some updates!

Engine Design: Components, Managers, and Entities

I have spent quite some time on my engine trying to figure out a name. But what I have spent more time on is the infrastructure of the engine.

The component based design I have been going for has been coming together very well.

The layout of the design follows this pattern: Base Component class with necessary virtual functions such as type identifiers and a default constructor that requires any new component derived from the base Component to identify itself. There is a list of Component Types contained within a namespace and globally accessible. This list contains identifier names associated to a bit within a 32-bit field - each one must be different. This allows for only 32 types of components.

In conjunction with the Components is a component manager that holds vectors of all the different types of components. Now, one thing to note that there are n vectors in the Component Manager, where n represents the number of components. This is preferred to avoid searching one giant vector of components in order to collect components of a certain type. The Component Manager is responsible for storing all components in the game and giving them out to processes that require the component data.

Containing components is the Entity class. It is small, containing merely a vector of dynamically allocated Components and a name. When it is created, the components that it has are defined in the constructor and allocated into the Component vector. Then they components are registered to the component manager.

So far that is all that I have accomplished so far but it was a lot of fun implementing such a system into my game engine architecture. Soon, I hope to have video to show the design and methods behind the engine.

Engine Design: The Name Game

Alright, so in an earlier post I stated that I was going to start building a 3D game engine from scratch in C++ using DirectX 10. I also said that I was going to name it "Kraken". That beast has already been born as a game engine (http://kearwood.com/projects/kraken) which uses the same name. So that is out.
Now I need to wrack my brain for ideas on names. Always one for symbolism - I am trying to come up with a meaningful name for my engine. The engine is designed using these simple concepts:

The game objects will be entities which contain components.
The engine will use a simple messaging system to pass data between components.

These concepts will form the core of my engines philosophy of design and how it will be engineered.

But first... a name.

Week 7: Final Post

Alas, 16 long weeks have come and gone - and with it, the experience of a life time.

Indeed - this project has been a roller coaster of emotions, stress, and accomplishment.

After looking at the engine, assets, design, and game itself, I have a lot of thoughts going through my head. One is what a great learning experience it has been in regards to team-work, game design, and engine architecture.

First off, I would like to say kudos to my team for all of the effort they put into the game. It was a challenging project and was worth all the work that was put into it. Working on a code-base and a game with a team as this level has been a first for me and taught me a lot of lessons - especially about source control and how it is a requirement these days it seems. Many of the other teams can agree with me on that one.

Secondly, the game taught me about game design - from the conception of the game to the actual creation of it. Things change and issues cause delays. These seemed to be the two biggest setbacks for the design of the game. Content couldn't meet timelines, some content would just be too buggy, etc.

Finally, if I am to leave this project with any type of lesson - it is about the creation of software architecture. Particularly for games. I will be blunt - I would never use this engine again. If I had a time machine, I would go back and completely rebuild it in terms of design. The low level systems worked excellently - DirectX wrappers, file parsers, FMOD wrapper, camera wrapper - without a hitch. It was the game flow, states, and communication that caused the issues. First off, let me explain this in a technical way. The engine was designed heavily on the idea of OOP and so had lots of inheritance - mostly in relation to 'is-a'. This wasn't bad until I realized that rather than wide inheritance (which would be preferred) I had too deep of inheritance. This can be seen in the following manner.

Example of bad inheritance:

class Monster : public SpriteObject
class SpriteObject : public GameObject
class GameObject

Why is this wrong? First off, I broke a few rules by not following the best practice of virtual destructors, mostly because I did not know when to use them, and it is an unforgivable sin. Secondly,
I had SpriteObject a child of GameObject so that any class that was a child of SpriteObject could have a system for rendering a sprite and have data for movement, scale, and rotation. This was the wrong way to go about it.

What I should have done:

class Monster : public SpriteObject : public GameObject

This would have given Monster everything it needs with less issue. Also, it would have made adding, removing, altering, and creating game objects much simpler.

That was just one bad design flaw in the ChainEngine. The other one that is really two is complete failure to create a messaging system and a proper game flow. First, the messaging system. The need for a global message handler that took in data and processed it would have been a lot of help. Two things this would have done was avoid coupling and support class independence. Also, the messaging system would have been a supporter of proper game flow. The flow of a good engine would look similar to this:

if(!CheckWinConditions())
{
    GetInput();
    ProcessCharacterController();
    ProcessAI();
    CheckCollisions();
    HandleCollisions();
    UpdateCamera();
    Update();
    Render();
}
else
    OnWinCondition();

Then the message handler system could take data sent to it from each method and process it to be sent to the appropriate other methods for handling when needed. What our game engine did look like was something like this:

if(level0)
{
     character->Update() //this also contains all input from user
     weapon->Update(character) //used characters position passed my value
     hookshot->Update(character, weapon) //even more classes being passed by value
     level0->Update(character, weapon, hookshot) // unfortunately, this is also where most of the collision detection went about and also updated right here as well based on collisions, this was a huge design flaw.
     camera->Update(character)
     background->Update(camera)
...
}
if(level1)
{
    ""
}

Anyways, as you can see, this resulting in writing a lot of the same code for each level, as well as each monster, character, object, etc, included in it. It also caused a lot of coupling, a lot of passes by values which in turn resulted in a lot of function calls. This design broke our physics engine when it came to implement the hookshot.

All in all, I wouldn't say that it was a total piece of garbage engine, but it needed a lot of work. This is why I am glad we tackled creating our own engine, so that we could learn proper design of a game architecture and learn from our mistakes. After all it is programming, which means: Practice, Practice, Practice...

Indeed, I was sad to have the class end as I enjoy game programming and wish I could do more in a group. But, I came out of the class wiser in the ways of team work, game design, and engine architecture. Because of that, I can say that this project was a huge success.

Also, we have a website at http://rctaddict.adryheat.net/DeVry/GSP362/index.html , so check out the trailer!

Also, keep an eye on my Blog as I will be continuing it in a new section. This new portion of my blog will follow me as I design and code a 3D game engine using what I have learned in this class. The new engine will be called 'Kraken' and the posts will be found under that as well.

   

Week 6: Final Development

Well, a new week has rolled in and a lot remains undone. The group is entering the final stages of production and there is not much left to do on my end. Some new changes that I created was an animation state machine for our playable character. Now the character has three states:

1)Idle
2)Jumping
3)Walking

There was a non-working fourth implemented but time has run out and it was not included. This state was climbing. The code kept conflicting with the actual animations and the Render updater so it had to be removed.

What does the animation state machine do?
Essentially it keeps track of what the player is doing, standing, walking, or jumping. Based on those actions the system renders the proper sprite or animation to translate to the player what the character is doing.

On top of that I included animations for the character taking damage from an enemy. As we have to enemies I cannot test it without cheat codes; however, I am confident it works as all it does is draw a damage sprite over the character if his health is reduced in any way.

All in all, it was a fun project and the coding taught me a lot about game engine architecture. All I have left is collecting art assets - Sounds and Textures.

Week 4: Playtest

This past week we submitted our game for play testing by other people. It really helps to get a fresh pair of eyes on your own project when it comes to a game. When working on a project for a while it is easy to see it through rose colored glasses. This helps put the project back into perspective as to what needs to be worked on.

From the reviews of other players there are a few consistent errors that need immediate attention. These two issues are collision while using the hook-shot and not dying when falling off the platforms. The latter is an easy fix where areas the first is going to have to involve revamping the physics engine again.

From there we must also implement all other game play features such as sprites, sounds, music, enemies, and three complete levels.

Week 3 Wrap-Up

Week 3 has had a lot of challenges placed before our team. These challenges were including a finished level with a start location, end location that goes to level two, an item, and an enemy, as well as some fixes to the physics code.

The fixes to the Physics engine were my main responsibility so far and it has been quite the nightmare. Our original engine involves a lot of (regretful) code that was hacked in last minute for the Alpha demo due to falling behind on our Physics engine. Integrating that with an OOP based engine that lacks a messaging system or DOD (Data Oriented Design) lead to a nightmarish coupling. I am paying for my sins tenfold now as any change in one area of the codebase involves jumping around. By the Beta version I hope to have this all fixed as it looks bleak right now.

Apart from nightmares we have the seven layers of hell. This is a friendly stroll down memory lane... (pun intended with utmost enthusiasm.) The game is suffering from a tiny 640 and 28 byte memory leak... that is 20 bytes larger than last week. Stepping through the code - no missed new/delete pairs could be found - yet. Without an appropriate logging system (or any what-so-ever) it is even more difficult to find the issues that are causing memory leaks. Another issue that decided to come out of Wonderland and into reality with the advent of my parallax backgrounds is a Heap corruption at the closing of every run of the game. I have no idea where to start on that one. So far that means I have two major memory issues that need addressing and I am at full throttle researching for an appropriate (free) memory profiler. So far Very Sleepy and the AMD memory profiler have looked okay but not promising as of yet. Perhaps a trial of IBM's or Intel's memory profilers would be a good choice.

To stop the bad news buffet - I do have a plateful of good news dessert. I have successfully implemented a primitive level editor in the guise of a text file. It suspiciously looks like binary - well, why wouldn't it. 0 means no tile (off) and 1 means tile (on). Each byte of ASCII code in a text file represents (or is ignored if it does not) a game object for a level. The .txt file is parsed into the game using a simple function call and getlined() to a temporary string that then is added to a final string that contains the entire level. From there, each ASCII symbol in the string is processed and creates the appropriate game object at the correct location. At this point it just does rows and columns of tiles but will soon implement all GameObjects and its children as well as start and finish locations of each level.

Here is an example of the geometry of level one:
1000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000#
1000000000100000000111111111111111000000000110000000000000000000000000000000000000000000000000000000#
1000000000000000000000000000000000000000000110000000001111111111100000000000000000000000000000100000#
1000000000000000000000000000000000000000001110000000001000010000100000000000000000000000000000100000#
1000000000100000000000000000000000000000000110000000001000010000100000000000000000000000000000100000#
1000000000100000000000000000000000000000000110000000001000010000100000000000000000000000000000100000#
1111111111100000011110000000000000000000000000000000001000010000100000000000000000000000000000100000#
1000000000100001111110000000000111000000011111100000000000000000000000000000000000000000000000100000#
1000000000100000000011000000100000000000000110000000000000000000000100000001000000010000000000100000#
1000000000100000000000000000000000000000000110000000000000000001000100010001000100010001000000100000#
1000000000100000000000000010000000000000000110000000000000000001000100010001000100010001000000100000#
1000000000100000000000000000000000000000000110000000000000000001111111111111111111111111000100100000#
1000000000100000000000000000000000000000000110000000000000100000000000000000000000010000000100100000#
1000000000100000000000000000000000000000000110000000000000100000000000000000001000010000000100100000#
1000000000100000000000000000000000000000000110000000000000000000000000000000001000010000000100100000#
1000000000100000000000011000011111100000000110000000000000000000000000000000001000000000000000100000#
1000000000000000000000011000000000000000000110000000001100000000000011111111111111111111111101100000#
1000000000100000000000011000000000000000000110000000000000000000000000000000000000000000000000000000#
1000000000100000000001111000000000000000000000000000000000000010000000000000000000000000000000000000#
1111111111111110000000000000001111111111111111111100000000000000000000000000000000000000000010001111;

I hope I haven't scared you off with my woeful cries of memory loss as I do hope to see you next time. I also pray that when we do meet again I will be singing songs of praise as I triumph over computer memory management once and for all!

Week 2 of Part II

This week was busy as we had to code a lot of extra aesthetic features. One important feature I had to work on was a parallax background. The biggest issue was figuring out how to properly translate the background in accordance to the camera. This involved me making a function that found the change in camera position so that the background would not continuously update its position to weird coordinates off screen. Another feature that I implemented was the all important hook-shot. This game mechanic gives the player the ability to shoot an object and use it to pull the player to that location. The only thing left in that field are the sound effects and the chain.

Part II: Making an Actual Game

Part two of my Applied Project Development class has begun and we have a lot to do. The first part of our class was spending a semester getting an architecture up and running. This, we did successfully.

To recap, the game will be native to the Windows OS, written in C++, using the DirectX9.0c June 2010 API and FMOD API for the sound engine. The DirectX API, In game Camera, DirectInput, and FMOD were all successfully wrapped in our architecture and basic game object classes were created. On top of that a method for creating, interacting with, and rendering a world was implemented. We also implemented a HUD and a menu system for the game controlled by a game state manager.

What does this all mean?

It means there is a ton of more work to do. On top of the architecture we must not implement Game Specific Subsystems - obstacles, actors, triggers, etc. From there we will also be changing our architecture to include a font engine to render text to screen as well as a new rendering method for our backgrounds.

Most of the work after that will all be implementing gameplay features for the player. I was left to be in charge of the following:

Weapon System
HUD (improved mechanics)
Background
Font Engine

As well as some art assets

Ambient Music
Player Animations
Some Sound FX (Player, Weapon)

We have achieved a lot the past 8 weeks and now must achieve more for a beta in the next 8. Here is a look at what we have graphically so far:

Until next time, enjoy!

Day Before Presentation

Sweating palms...
Frantic typing...
Muttered curses...

Those are just three of the issues I am having right now with my nervous breakdown. Tomorrow we show out Alpha version of the Chain Engine for our game "Chain of Memories" (Working Title). There are a few split ends that need to be tied, and code to be forged into a working game level.

This is the end of our frantic production and tomorrow we will see if it has all paid off.

To be honest, my concern is blown out of proportion because I really shouldn't me nervous. However, as most programmers or developers, I have an urgent need to fine tune every little detail before presenting my child before critics. Not critics - per say - but they are grading me on our work and so I am nervous.

This is something school books can't teach you how to handle.

Honestly, our engine should do fine as well as our alpha version of our game, then we can get the go ahead to work on the Beta version. That will be more fun as it will mostly be design - even if I do want to revamp the graphics engine.

Our engine incorporates the following:

Graphics engine - DirectX 9.0c compatible
Sound engine - using FMOD API
Input handling - using Direct Input
Collision detection - using a custom build physics library

What we will need to incorporate later is an actually physics library ripe full of fun things like gravity and acceleration. Another addition would be to create a GUI for designing levels so that not everything is hardcoded - but rather created, saved to a file, then loaded into the main game driver. This will allow for rapid development.

Next post will be tomorrow, after the 'show and tell' of our game - complete with pictures.

Until next time.

Crunch Time

This week marks the inevitable crunch time for game development. So far we have been able to keep up with our assigned workloads and with this last week we still have that goal. So far we have full player input and control, a working HUD, a working health meter, a full game state manager, dynamically buildable levels, a weapon, an enemy, and some collision. With everything done on the graphical and input side, we are now focused on our collision and physics in the game. With one week, we have to fine tune that and do some polishing but I beleive we can do it.

It was tough creating a workable level from scratch using C++ and DirectX, however, a challenge is always welcome and I am glad that the team has taken it in full stride and created something everyone can soon enjoy.

Game Engine Update and Some Concerns

It seems that the development phase has swept by in the past few weeks and we already have a working engine in DirectX9.0. We have implemented a Game state manager, have declared multiple classes and created a few game objects including a grid of the level and an animated character. The engine is almost done, all we have to incorporate is physics, the weapon, and a monster. So far the biggest issue I had was implementing a HUD that stores objects in it.

At first I had decided to use a small array of void pointers; however, this lead to type casting issues. I decided against this. It seemed that the easiest description of an inventory is  a list of class objects. Now, how do I implement different objects into a list? At first I thought I could initialize it with a template parameter of the GameObject class and add children to that. Nope, this caused an issue that is caused slicing. Essentially, it cuts down the child class to its parent class and loses the other data. To fix this, I simply had to assign the template as a pointer to the parent class, and whenever I add a new object, I use the new declaration and that fixes the slicing issue.

I will keep up to date on our week 6 progress.

Week 4

Week 4 of the Development phase has come and is soon to pass. As of right now, most of the development work is done and we have been working on the core game engine to get an Alpha version up and running by week 8 or our class.

The On-Paper Development phase is done as we close with our Statements of work (this details what our jobs are for the project) and a Technical Design Document. According to the statement of work, I am in charge of the Graphics Engine, User Interface, and the construction of physical data (bounding boxes and spheres.) As one can see, all of my work involves programming. This means for the most part - my blogs will be more on the technical side of game creation than on the design side.

As far as technical work goes. I have a working DirectX Framework up and running with a base GameObject Class, a child of that class that supports sprites, Direct Input controls, as well as a sound engine class that wraps FMOD into the game to be used. There is also a small state manager that goes from the start menu to the first level. So far, it is looking good, the only thing I need to get my hands on are sprites to incorporate.

Week 2: Development Process

This week heralded the second week of our game development phase. So far in development we have a High Level Concept document and we are currently working on a Game Design Document. On the technical side of things we have begun a rough abstract of the classes needed to create our 2D platformer.

Part I:
As mentioned above we currently have a working High Level Concept document that outlines the basics of what our game is and what makes it so interesting. Essentially it is our pitch. The game, "Chain of Memories" (working title) is about an amnesiac genius. The player is the protagonist and must navigate through challenging obstacles using uniquely crafted items. One of the main items in the game is the chain arm that the character creates for himself. "Chain of Memories" will contain basic WASD movement controls as well as the use of the mouse for using various items.
Apart from that, the Game Design Document will define what we plan to implement as far as Game flow, User Interface, Story, Characters, Environment, and Game Mechanics are concerned. That will be discussed next week.

Part II:
Jumping ahead of the Game Design Document, and even the Technical Design Document - our group has described several classes that are required for the coding of "Chain of Memories" in C++ and the DirectX API.
The classes are as listed:
==================

+DXRenderer
--This class creates and defines all of the various required functions for rendering images to the screen.

+GameObject
--This class is the base class to be inherited by all 'physical' objects in the game, i.e. characters, blocks.

+Collider
--This class defines the collision boxes or spheres for GameObjects. It also contains code for detection collisions.

+ PhysicsLib & MathLib
--These classes are a little self explanatory. They define all of our Physics and Math variables as well as functions.

+GameStateManager
--The Game State Manager is a class (perhaps implemented as a Singleton) that controls the flow of the game between the menu, loads, saves, pauses, and levels.

+SoundManager
--This class will contain on wrapping the sound API we plan on using (FMOD) to implement sounds and music throughout the game. (Also may be implemented as a Singleton)

+DirectInput
--This class contains the code to implement DirectInput into our game application to handle user input for the controls of the character and the various menu items.

+WinMain
--This class contains the code to create, register, and handle the window in which our application will run.

+Camera
--This class is used to create a camera for setting the view in the game window.

Of course, these are not all of the classes that we plan on implementing into the game. There are still a few others, such as inherited classes, that need to be defined. However, that is a few weeks ahead.

As for now, that is all that is going on for this week and I will update again next week on the status of our work.

Very First Entry!

Today marks the beginning of a new blog!

The aim of this blog is as follows:

-Give insight into the creation of a game through an 8 week class at DeVry University.
-Give readers information about game design and programming processes.
-Most importantly, log the process of creating an Alpha version of a game in 8 weeks.

The posts of this blog will be done on a weekly basis and will primarily be broken down into two parts:

-Part One: Design. This will contain all the story, design processes, art, and non-technical aspects of the game that is to be created.

-Part Two: Technical. This will contain all of the programming and technical side of the creation of the game. This part of the blog will be relatively short for some time until we hit to about the 4 week mark of the blog.

Now that you have an understanding of what this blog is about, let us begin with the design aspect of the game that my group and I are preparing to create.

Part One: High Level Concept

As of right now our game exists only on paper and in our minds. We have just finished and polished off our high level concept for the game we plan on creating. The high level concept is a document that is a narrative description of what the game is about, basic features and game play, as well as what we are targeting. By targets I am referring to platform and audience. So far our draft explains a concept, game play, and our targets.

As of right now our concept is straight forward. The game is untitled as of right now as well as the protagonist - which is fitting since, according to the story plot, is amnesiac. Although typically found as an 'easy out' to explain why a hero starts at such a low skill level and without much experience - the amnesia storyline persists and lends itself as a vital part of the game play. The game will be a simple action adventure 2D platformer with a few twists and exciting features. After the group decided on that as our story and game play we decided on a target. Since we are familiar with DirectX, we decided to target just Windows based PCs as of right now.

Part Two: Technical Considerations

From what one can gather from the description of the high level concept - a few technical features are already unmasked. The game will take keyboard input for most interaction. Unlike most retro platformers though, the game will also take mouse input to use special devices that the player can possess. From here we have decided to use DirectInput, C++ programming, and the DirectX API. That will take care of most of the basic needs for the game.

Unfortunately, since the game is in its infancy and just at the design phase, there is not much else to say on the technical side of things.

Closing Notes

I hope that you have enjoyed the first post of this wonderful blog and it helps give you insight into what goes into developing and programming a game. Look forward to more content next week!