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!