Team high five - interim report

Weekly development

Week 1: Let there be light

The first week of development was spent setting up our XNA game engine and getting to know the content pipeline. For that reason, we imported two pre-existing models with animations into our application and then tried to achieve the same for a model created on our own in Blender. The result is the small guy called "Rolf" who even has a very crude walking animation.

We also started work on graphical effects such as shadow mapping and particle effects. We implemented them ourselves using the HLSL shading language to put as much of the computational effort as possible on the GPU. While the flare thing in the background is a first test for an animated fire, the bright pillar in the middle of the screenshot is what will later become Frosty's ice beam.

Week 2: Adam takes a walk...

We spent our second week of development integrating more techniques to be used later into our game engine. Our main character, Adam, makes his first appearance and is already able to switch between idle, walking and running animations. We now also fully implemented the Phong shading model and there is a light flying in a circle above the scene. Loading heightmaps from grayscale images provides us with the first concept of a "level" we can load and on which we can move our character around. The shaded staircasing on the ground indicates problems we encountered with the heightmap resolution loaded from images, which will be fixed later. The "false" in the Window title indicates that the game is running at less than 60 FPS, which was caused by a performance bottleneck to be fixed in the next versions.

Week 3: Interaction!

After one more week of development, Adam's abilities can now be fully controlled by an Xbox Gamepad and his animations are synchronized with the movement. He is able to shoot fireballs, walk around, stand idle, make jumps into the air, and die. In this version, the evil opponent Frosty makes his first appearance by just standing around and glazing in an evil manner at the poor Adams. The fireballs shot by Adam can actually hit both the ground and Frosty and damage him, reducing his hitpoints shown in the top left of the screen. There was also first work done on the water animation of what will later become the frozen pool level. First GUI elements can also be seen on the screen, although they are not yet seperated from the game level and simply drawn on top of it.

Week 4: Gameplay!

The last week of development before this report was spent mainly making the game playable. Starting from a large grown collection of classes and techniques developed over the last weeks, the task was now to combine them into an actual game. A lot of work went into Frosty's ice beam creating an ice path in the freezing water below it and into Frosty's shield deflecting melee hits. There now is a dynamic camera following the players over the playing field and trying to keep them all visible. Players now respawn after being killed and the Adams also have hitboxes, meaning that there can be friendly fire! Frosty has a simple AI which randomly shoots frost beams on one of the two players.

All of this takes place on the freshly created frozen pool level which also features ice blocks placed in and around the playing field. We now also have a game menu that allows you to restart the map and exit the game.

The view from the modelling team

We were all a bit scared of the modelling and animation part. None of us had any prior exposure to this field, and yet we knew that our game idea heavily relies on reasonable models and their movements and actions. We chose Blender as our primary modelling tool and this turned out to be a great choice. There are a lot of tutorials on the web, from the fundamentals like getting to know the GUI or box modelling to more advanced topics like rigging using inverse kinematics.

Soon we modelled our first test model (we called it Rolf) to see how well Blender works when it comes to compatibility with XNA. Luckily, using the SkinnedModel sample from the XNA webpage, we were able to import our rigged and animated test model and make it walk.

Then the real work began. After spending hours and hours to model and rig our final characters we had to invest even more time in animating both the boss and the main player character. The key point was to make the movement look natural, like you would expect those creatures to move. After several iterations of improvement, we decided that it looks good for now.

The next part was texturing the models. We used the UV-mapping approach, which turned out to be a rather tedious work. However, after combining the textures with bump mapping, we were really satisfied with the results.

Now it was finally our turn to contribute more to the actual code. The task was to find a good way to incorporate animation blending (smoothly blending between two animations for a nice transition), animation overlay (change some part of the model during a different animation, e.g. shooting whilst running) and bone tracking (track a bone's position to attach an object to it, e.g. a fireball to the hand). The AnimationPlayer class provided in the SkinnedModel sample mentioned above turned out to be very minimalistic, and so we tried to expand it to match our needs. This of course meant digging deeper towards the actual fbx files and how the bones etc. are stored. The absence of documentation and the precompiled libraries did not make matters any easier. However, in the end we succeded and found a clean and efficient solution to all three problems.

Some time was spent on developing a foundation for GUI elements like a health bar or the pause screen; a simple way to play sounds is already in place, too. As these tasks do not have a high priority, work is going slowly and we are only adding features as needed.

The rest of the time was dedicated to player logic (input handling, state transition, use and timing of animations etc), which is still one of the parts we are working on at the moment, while improving the models and their animations is a forever ongoing task.

Progress Assessment

According to our development plan, we finished the low target and are now working on the desired target. Certain small low target points are missing (e.g. printout instead of health bar), but on the other hand, we are ahead of schedule in other areas, like lighting or character modelling / animation. The first encounter is almost playable, and since we have almost all of the game engine ready, adding new levels will certainly take less time than adding the first one.

The next big step will be the incorporation of sound, AI for the first boss, polishing the first level. When the latter is playable and fun, we will move on the the next level. One thing at a time...

Attachments