Final History Post

While the last history post was largely about what other people have completed (which is important, since I'm managing this project I need to be keeping up with their progress all the time), I have neglected to mention much of what I have been doing myself on this project - which is what this post will be about :P

I have spent a good deal of time this semester working on learning how the Havok engine works. It is an awesome, awesome engine, I like how well its organised. Moving on to Havok means I can do away with PhysX, and the nxOgre wrapper, which had very little documentation at the time I was trying to learn it.

Not to mention we can now put in the awesome Havok logo on our credits screen :P


The Havok SDK is broken up into many subsections. Animation, Physics (Dynamics), Collision, Destruction, AI, etc. Since we're using the free version of Havok (I can't afford some insane amount of pricing to get the full version) we only get Animation, and the Physics / Collision dynamics sections of the engine, as well as no access to source code. But really, that's all we need :) Heck, we're not even using the animation portion of it (though if we had selected Havok earlier, I may have had tim to learn how Havok's animation blending works).

Anyway, Havok is quite extendable, you can inherit from most of their classes and create your own versions of the functions required. In fact, some of the functions in Havok require this (collision listeners, heightfields, etc) to work properly, mainly due to the nature of the function.

So far, I have encapsulated the following tasks into separate classes for use with Steel Arms:

1. Initialising and Destroying the Havok Engine
2. Creating a "Havok World", which holds the physics information
3. Creating the terrain - in a heightfield format
4. Creating a rigid body from convex hull information - from a .HKX file
5. The Havok Character controller, to allow for inputs from somewhere other than natural physics
6. Collision Listeners, so that we can intervene when a collision occurs and take some actions

Explanations of exactly of what this means follows:

1. Any engine needs certain information to initialise itself, and needs to be removed from memory when we are done using it. Havok is no different in this regard. I have encapsulated this using static methods, so we don't need to waste any memory creating an object of my custom class, simply use it to create a Havok engine with its memory managers. Didn't take very long at all to do.
2. Havok needs to have boundaries for where its simulations are running. The Havok world is where this is sorted. In a Havok world, global data is set, such as world size (since we don't want it simulating an endless world, that would kill us in terms of computation complexity), gravity etc etc. When we create an object, it gets put into a Havok World for simulation. We can have multiple Havok Worlds if we wish. Anyway, my world class allows us to create a world (multiple if we instantiate my class multiple times), update it in regard to time passed, and to destroy it when we are done with it (destroy the WORLD MUAHAHA).
3. The terrain is an important part of any game - since you need to walk on the ground and all. In physics terms, it is simply for collision purposes. So the player walks along the ground, and sticks to it as a result of gravity. There are many ways to create terrain - it can simply be modelled and put into Havok as a regular rigid body, or we can take the heightfield route. A heightfield reads the heights of data off a heightmap (or any other way I wish to input the data if I like, but for our purposes it reads from an OGRE heightmap), and uses this to create the shape of the terrain. It is much more efficient than just creating a massive mesh for the ground!
4. Rigid bodies are the heart of physics simulation. Most physical objects are simulated in terms of rigid bodies, since they are more efficient. .HKX is the havok file type for physics data. With the class I have created, I can export a .HKX from Maya (using Havok's plugin set), import the shape data into our game, and then create a rigid body with it. This allows for us to quite easily get the approximate shapes of all the models for our game, be it a building, a rock, a mech, whatever needs to be collided with.
5. Character control is important... since if we don't control the character, we don't really have a game. Havok's character controller absolutely threw me a few curveballs, and I still don't have it absolutely perfect, but at this stage it is serviceable for our purposes. I plan on making it better ASAP.
6. Collision Listening is very important. A physics engine simply runs its simulation, and makes objects react as they would in physics. This is of course, all well and good. But in certain cases, we need to do more than just figure out what happens to physicsl objects when they collide. If a mech kicks a rock, we want the rock to bounce away. The physics engine handles that on its own. However, if a bullet hits the mech, we want the mech to lose integrity (aka health). The physics engine alone cannot do that. This is where a collision listener comes in handy - it alerts us that a collision has occurred, and what has collided. With that information, we can do whatever we want - such as reduce a mech's integrity, destroy the bullet so that it doesn't effectively drill a hole in the mech's HP bar, etc. The collision listener allows us to put in the gameplay sections of collision resolution as required.

Quite technical, isn't it? :P

In addition to all of this, as mentioned in an earlier post, I wrote a basic Particle system since Ryder had difficulties, and an AI system since Rob had difficulties. In addition to this, I integrated my physics classes into Amir's preliminary engine for testing and demonstration, and have been keeping tabs on everyone else's work, trying to keep us all on track.

Moving forward, I'm sure the project will be completed on time - mainly due to the sheer stubbornness of our group absolutely refusing to fail. Its another story entirely on how good it will be by then :P