Final Week

The last week has been aboluely ridiculous for this project. Many technical difficulties arose, and many hour of sleep were lost.

Since last Friday, Michael, Ryder, Amir and myself have been working practically nonstop on the game, frantically attempting to meet the deadline of Thursday 3pm - this afternoon.

Michael has spent the time touching up Amir's model for use in the game, since Tran absolutely failed to get us a remotely usable mech in time for the game. In addition, he has also been designing (and hand scripting) the level, and coming up with some extra environmental assets.

Ryder has been working on the particles. At this point, the particle system crashes the game, which I a bug we think we will have sorted before submission time. He is working very hard as I write this trying to make the Particle Universe plugin work properly with our engine.

Amir ha been working endlessly on many, many systems within the game. He had to rewrite the vehicle system YET AGAIN due to Tran's failure to get us what we needed, and in addition been writing building systems, lighting ystems, and a scripting engine. The man is a machine :)

I have been making the physics work. Collisions, sticking to the ground, and bullet collisions. The Havok engine ended up not working correctly with our engine, due to difficulties with the collision listeners, so I have written a basic form of collision detection utilising OGRE's native ray casting system. At this stage, it someetimes freezes, and crashes, but I am confident that it will be ready for presentation.

Major difficulties have come from elsewhere however. Rob spent a single night with us, got very little done, and went home. He has failed to deliver us his level editor in time (which forces us to hand script it), and as a result leaves is only contribution to the game itself the sound system - and that didn't even work until I fixed it. (Note, "his" AI system was actually written by me - he couldn't get that working either).

Tran has failed to deliver us anything usable. He contacted me last night telling me the buildings were nearly finished. That is the day before submision, for a major project! By then we had all the buildings we were going to use. Even if he delivers us the best assets in the world today, we cannot use them. In addition to this we still cannot use his mech (which throws out other people's work too), so the total amount of work we have gotten from his that we can actually use i absolutely zero.

Brenden has been very sick, and he had delivered us all the assets we asked for in time. Quite well done. However, these asets were weapons for the main character mech. We cannot use the mech since Tran failed to deliver it to us in a useable state. As a result, we cannot use Brenden's weaponry in the game, because there are no characters with hands capable of holding a SMG, or a pistol, or a rocket launcher. This is not Brenden's fault, a he actually completed his task on time, and responded quite quickly to feedback and criticism, and updated his work as required.

Rakitha finished his cutcene weeks ago, and was done with the project at that time. However, we cannot use it, for conistency's sake, since we have lost our main character!

The main character we are using at the moment was modelled by Amir, animated and textured by Michael, and coded for by Amir.

At this point, I have just been informed that my collision detection broke again, so I', off to fix that. Hopefully, the game will work in time for submission.

~Natoli

Integrationisation!

Hey all, just a quick update so you know I'm still alive :P

Spent the last week or so touching up some of the systems I've gotten from people. The particle system is now ready to go, and so is the audio system. Of course, I'll be integrating these after the physics is ready to go.

I've spent the last 2 days or so integrating physics. It hasn't been too difficult to do, the main issues have been sloppy code on my part - resulting in memory leaks in my wrapper classes. I've been steadily removing these as I integrate portions of the physics, however, and am making some good progress.

Andrew T has practically finished his mech animations, however there were some miscommunications in general about what was required. I was under the impression that we needed all of the animations in a single timeline, and as such communicated this to Andrew, who did so. Recently I found out that there is a way to export it off separate timelines, so now, as well as feeling like an idiot, I also have a massive animation timeline for our mech. It will still work though :P

There are bigger problems with the animation - for some reason the skeleton won't export properly with the mech itself, which makes animation a little difficult. Discussions with Russel, Michael and Amir revealed a potential reason for the problem - the left leg wasn't connected to the mesh properly. While it makes sense that rebinding this would solve the problem, according to Amir (who I asked to test the solution), it didn't work. Amir has gotten some animations working via simply exporting vertex movements, but this will complicate other parts of the animation (such as attaching weapons to the bones. You can't attach a weapon to bones that don't actually exist...).

At this stage, I'm integrating the physics into a simple test version of the program - a flat plane, and a different mech that Amir modelled, Michael textured and gave a basic walk cycle to. It works quite well so far, except that the mech becomes airborne after walking in a straight line. I am troubleshooting this issue at the moment - I believe it may be some of the speed and acceleration values I've input. I'm also requesting help for this issue on the Havok forums :P

At this stage, I think we'll have something "playable" by end of next week, at the latest. Which is a godsend, since the engine is designed for scalability. Once we have our most basic form up and running (two mechs running and shooting at each other), we can add in the extras quite quickly. The pieces are beginning to snap together :)

9 / 11 / 2009 - Code!

Just a brief post today:

Spent some time updating my Havok Physics classes to allow us to add userdata to them. Havok's userdata is essentiall an integer value, which we can use for whatever we want.

We are using the userdata so that we know what type of object the collision entity belongs to, and the index of its position in its storage vector. Using some entertaining maths and these values, we can access the objects that have collided, and as such intervene to do things like reduce integrity of a mech if it has been hit by a bullet or missile, etc.

In addition to this, I looked over Rob's Audio class code. It worked quite well, though it had two subtle bugs to iron out (upon unloading it would crash). I fixed those, and then created a manager class to hold all of the sounds in a central location in memory, and access the sounds as required.

Amir and I looked at Andrew T's updated mech model (with partial animation) today. There are still some parts of the mech that are completely untextured... in OGRE these sections are rendered in PURE WHITE. In other words, it will make the mech look horrible, so I'm going to need to speak to him and get that fixed.

My next task is to start integrating my updated physics into Amir's updated vehicle and graphics engine. From there we begin programming weaponry, and some actual gameplay. Fun times ahead...

Other Vehicles and Buildings!

This post is less techy, showing off some of the assets that are coming up (and explaining a little more about the game itself). The screenshots are courtesy of Michael Page - our Vehicle and Buildings artist.

In an earlier post, you saw the Pod-Vee and the Pulse Runner. We have two more vehicles (excluding mecha) in our game.

Hover Tank

The hover tank is exactly what it sounds like - a tank that hovers. It's main weapon is a laser (the reason being that if it was a cannon... well, anyone whos seen Sergeant Bilko knows what happens when a hover tank fires a shell :P). It is the enemies' medium attack vehicle.

Hell-E-Copter

The Hell-E-Copter is a flying vehicle, with a flamethrower for its main weapon. Why a flamethrower? Because fire is awesome!

There are no guarantees that the Hell-E-Copter will even make it into the game, since we need extra AI behaviours to deal with flying vehicles. However, the model is done and ready to go if we get it working.

We also have some buildings ready to go. Without revealing too much, here is one of them.


A propaganda tower. Yes, that is me in the photo :P

Of course, Michael isn't the only one who's been working on graphical assets. Unfortunately, I don't have any renders of the player mech, though what I can do is show a screen cap from the intro cutscene:


As for the cutscene itself, you'll just have to wait until the game is completed :P

At this point a level design is still being set in concrete, level builder is being written by Rob, while engine is still being completed by Amir and myself.



Steel Arms is coming. Are you prepared?

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

History - continued

I've decided to try and shorten the history a bit, since its a huge amount to read, and to be honest, spending a few hours writing it is a few hours I should be spending programming the game :P

For the next few weeks, we encountered some interesting problems with our code AND our graphics.

#1: Code: Ryder's issue with the Particle Universe plugin was worse than expected. Once I finally took a look at Ryder's code, it was utterly unusable (it was not even remotely Object Oriented, and it didn't even make sense).

As a result I spent an hour with him on a Friday afternoon designing a class that we could use, and simply asking him to fill it out in C++ with the Particle Universe code. The following Monday, when I caught back up with him, he'd created another behemoth that was unusable - and worse, it wouldn't even compile. I worked alongside him for a couple of hours that evening trying to figure out what was going on, until I finally realised that the plugin he had didn't come with any lib files!

So we looked at the Particle Universe project itself, and it wouldn't compile properly. In the end, I decided to write my own Particle class to use OGRE's in-built particle engine, and let Ryder try to sort out the lib stuff through the Particle Universe support. At the very least, we would have a working particle system as a fallback - it may not be pretty, but it would do the job.
later that night, I spent 2 hours and got a basic Particle class working, that we can use in our game.

#2: Code: Rob sent me some AI code. Unfortunately, when I opened it it was almost entirely blank - simply a skeleton for code. Completely useless to us. When I asked Rob what was up with that, he tyold me that he must have given me the wrong file, or lost data or something. I asked for a backup, to which he told me he'd have to me the next day.

1 day, became 2. Which became 4.

2 weeks later, I finally got an AI system from Rob. Said AI system didn't compile, nor did it comply with the code standards Amir and I had worked on earlier in the project.
In the end, I spent a weekend writing a basic AI system myself. Along with the base class which we can override to create new behaviours at will, I created a basic behaviour. The AI I created wanders around randomly until it gets within a certain distance of the player. If it gets within this distance threshold, it then charges the player, chasing him/her indefinitely.
So we now have an AI system that works, and a tired and annoyed project manager :P

#3: Graphics:
Amir took a look at the preliminary animation set we had from Andrew T. The animations themselves were quite good... but the model was... interesting to say the least.
The model itself looked pretty good - however there was an issue with its joints.

In short - the joints weren't joined. I had asked for the model to be hierarchised so that we could export pieces separately - meaning that I needed to be able to select the pieces of the model in Maya so I can export them to OGRE's format, and potentially allow for disconnection of limbs in-game. Sure, the model was selectable separately, but the model was also more a case of something like 12 models in a single scene, simply placed in theior proper places. Not connected.

The net result? When put into Ogre we get massive gaps in the shoulders, legs, ankles (assuming you could say a mech HAD ankles) etc. When I called Andrew to ask what was going on with this, he told me that that was the model he had received from Rakitha.

To be completely honest, I didn't care who had messed up, or why. The end result was that we had an unusable model. Even worse - Andrew was unable to make it to the college that day to resolve the issue. In the end, Michael, Amir and Russel devised a workaround, which Michael promptly created and sent to Andrew to implement.

However, it isn't all doom and gloom with this project...

Rakitha finished his cutscene before leaving us to deal with his internship. It looks pretty sweet. He is planning on some small tweaks to sound synching and such, but as it is its still awesome.

Michael finished his vehicles (which are looking good) and has begun on buildings. A few of the buildings are also ready, and they all look pretty sweet too.

Andrew T has gotten half of our main mech's animations ready to go (albeit it took a few tries for him to get it in the format I'd asked for, even though I told him what we needed fairly early on). By the end of next week they should be all ready to put into the engine.

Amir has been coding like an absolute maniac. Now all of our vehicles are scriptable, same with the level file itself, and possibly buildings too. The vehicles all allow for AI or player control, and we have an input system which allows a player to customise the keys if they so desire (though we haven't created the interface for the control changing just yet).

Brenden has just returned from his internship, and while he has been quite ill, he will be beginning on the terrain during the upcoming week.

Speaking of internships, Concentric went bankrupt (or something similar). Long story short is that Amir and I are now free to work solely on this project. A mixed blessing really. While I appreciate the extra time we can spend on the project (and quite frankly, absolutely NEED to spend on this thing), we now don't have nearly as much experience heading out of the college in the end. Not to mention I'm supposed to figure out what to write for the assessments since they still need to be completed :P

Week 1 - History Post

Since I've fallen way behind on this, we have a series of history posts detailing what has been done this semester.

At the beginning of the semester, I began my internship at Concentric (3 days a week), which, while short-lived, was interesting. Why am I mentioning this on the game blog? Because it severely cut down the time I had to work on the project! In addition to this, Amir also had 3 days a week at Concentric, which meant we could only actually meet each other on Wednesdays, and also cut down on the time he could spend on the project.

In addition to have 2 programmers lost to internships, Brenden had a full time internship for the first 6 weeks, and Rakitha a full time internship for the second 6 weeks. We were effectively running at half capacity for the first chunk of the semester.

So it is perhaps no surprise that very little was completed during the first week of this semester. Brenden was settling in to interning (but still got plenty of work done on weapons models), Amir and I were coordinating our code, and getting a start on our respective parts of the project (Amir focusing on the Vehicle system, and the rendering, while myself researching how to use Havok, and encapsulating it for our use).

Andrew T made some textures for the low-poly versions of our mechs - however they didn't look all that amazing. As a result, I got him to discuss with Rakitha how to sort that out, both artistically and technically. I know very little about 3D modelling myself (if anyone has seen the abomination of a 3D test of Lucy from Elfen Lied that is on Youtube, that was me), so all I can do is delegate any issues about that to the people who *do* know what they're doing in that regard.

Michael completedf two vehicles over the holidays! I was amazed, he still needed to reduce the poly counts quite severely, but we had something to show for our presentation (other than random code snippets).

The Pod-Vee

The Pod-Vee is effectively a humvee with a missile pod attached (hence its name). It is the enemies' light attack vehicle. While not too dangerous on its own, they will likely be swarming the player, and should be quite a handful when this occurs.

The Pulse Runner

The Pulse Runner is a slightly heavier vehicle. The cannon on its back fires an EMP weapon, designed to reduce the effectiveness of electronics - specifically your mech. Getting hit with a pulse from this will slow the mech down, and reduce the effectiveness of weaponry.

Rakitha had produced an animatic for his cutscene, which was looking entertaining.

Ryder had procured a plugin for our particle system, and was having some difficulties getting it to work, however the effects it produce were above and beyond anything Ogre's native particle engine had shown me thus far. The main difficulties with the plugin were yet to have been revealed to me however...

Rob had redesigned his AI system, yet again. The reason for this was that the old one was too complex, and he was struggling to get it working.

Amir had written a basic Vehicle system, and encapsulated Ogre enough to be usable to us.

During that week, I had gotten a very basic test program up and running, using Havok and Ogre together. It was simply two cubes colliding with each other, but its the first step to getting an actual physics system for Steel Arms.