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.