The bug mentioned in the last blog entry and a couple new ones found are now squashed. Also the walking animation has been set up to play as it should, now I only need to detect when the player is walking backwards and play the corresponding animation instead of the normal walking animation. I also have an idea to improve the hit detection for melee attacks, and I'm actually quite excited about it. We'll see how it turns out.

Back on the track

Since the last blog entry problems with the animations seems to have disappeared. Several individual animations are already in use, the next bigger problem when it comes to animating will probably be walking and blending. Blending animations actually worries me quite a lot, we will soon see how it turns out.


Good thing is that now we are finally over the stall that the problems with animation caused and the project is again proceeding at acceptable pace. I also worked out a solution for the separate state management for each portion of the split screen. Just yesterday we found a rather mysterious bug from the system while playtesting and I might have to think it over again if I can't find the cause of it and fix it.

The first setbacks

This is what I've been waiting for all this time. Things finally started to not go so smoothly.

Last couple weeks have been a struggle. We've tried to animate our characters, but things resist our efforts as they best can. Everything is all fine and dandy as far as we keep the 3D models unanimated and just let them slide across the game world. When an animation starts playing, things go wrong and the model turns into distorted, undistinguishable mess.

At first nobody seemed to have any idea what's wrong and how to fix it. I've not played animations on 3D models before and don't have the experience or knowledge to outright point out where to start debugging, so on my part fixing the issue has been largely poking around blindly and hoping to hit something. Our animators and modelers have apparently not worked with this file format before and that seems to have resulted in that they also are fumbling in the dark. It has largely been me who has had to import and export the models from one file format to another, and it really is not a good thing considering that I just barely have any idea how to use the software to do the job.

After a week we finally got help from an outside sorce, a teacher who has not been involved directly with us before. I explained the problem and he spent a while with his laptop examining the situation and the models. I don't know what he found out bu he talked with the local artists for a while and after that the animations I've been handed to by the artists have worked better. We still don't have perfectly working animations, but now the distortions are much lesser and one can make out what the model is actually supposed to represent. We still need to work out the minor distortions that appear on the animated models.

Another thing that worries me is that now all the necessary animations are in a single take all clumbed together. Basically there is just one long animation sequence, where the character first does the walking animation, then after that attacks, then jumps etc. etc. I need to come up with a system that plays only specific frames from that one long animation to separate walking animation from attack animation and such. This is problematic, because initially I had the impression that different animations could be separated into different takes that would then be easy to call from the code. The file format indeed supports this, but it seems that the tools we are using here do not take advantage of this and force us to use only one take that contains all the animations. I did not allocate time for doing the separation of the animations by hand in the schedule, so this is going to set us back even more in addition to the extra time we've spent getting the animations to play at all in the first place.

I also discovered another flaw in my initial plans: the state management system I'm using is designed for having only one globl state active and responding to input at any given time. This means that currently all four players have to be in the same state all the time, one player can't have a menu open while three other players duke it out on the battlefield. This leads to a situation where one player can't join the game on the fly and get in through a character selection menu while the others are playing. Currently I see three options open here: change the initial plans and make a game where the players start the game in a synchronised manner so that they all get out of the character selection menu and start the game at the same time; or come up with a workaround and make slight (and possibly messy) adjustments to the state management system to allow the desired behaviour; or rewrite the whole state management system. I do have some ideas for a workaround, I just need to make sure whatever I end up using won't get on my way later on and end up setting the schedule back more than a rewrite of the state management system would.

Now the characters have melee attacks and hitpoints, so they can run around rampaging and destroying each other. There is also a win condition in place, the player who first reaches a certain amount of kills wins the game and a new round can begin. Ranged and special attacks are well under way and should be implemented soon too.

Ooooh, shiny!

Since the last update the support for a varying number of players has been increased. Now there is a "Press start button" screen in the beginning of the game, and the menus only take input from the controller that presses start on that screen. This way it doesn't matter which controller you grab from the floor, it can be attached to any port be it number 1 or number 4, any controller can use the menus. Also the gameplay screen starts with only one player now, controlled by the same controller that made it through the menus, other players can join the game on the fly by taking a controller and pressing start button. The camera controls were also fine tuned to work better and some problems with rotating the camera were fixed.

Currently we only have 3 controllers to test the game with, we need to ask for one more so we can make sure the game actually works with 4 players.

From matrices to a quaternion

The camera controls turned out to be quite tricky actually. I spent a lot of time trying to make it work by storing yaw and pitch angles separately and calculating rotation matrices out of those. This caused all kinds of problems and funky behaviour. Finally I settled down with using a single quaternion that is used to store all rotations around all three axises. We won't probably need roll (rotation around z-axis) though, so we are currently using only yaw and pitch (rotations around y- and x-axises respectively). Now the game has the possibility for less than 4 players based on the number of attached controllers, whereas previously the screen was always split in four parts no matter what.

Breaking through barriers and buffers

I just noticed I've been writing in English recently even when the first entries are in Finnish. My thoughts just flow more naturally this way. Funny. Anyways, sorting all objects in the scene so that things further away are rendered first solved the issue with rendering. Then I realized that the problem is actually caused by the fps counter that is rendered on top of the final scene; rendering that string apparently likes to screw around with render states and turns off the z-buffer even when I do turn it on in the beginning of the game. This can be solved by simply enabling z-buffer in the beginning of each frame instead of just once in the beginning of the game. Now we are also rendering the arena the characters are standing on as a simple flat plane along with a skybox. Currently I'm trying to make the camera to be able to rotate around the player character around it's horizontal axis too, at the moment the camera can only be rotated around the y-axis.

What's on the menu?

Now we actually have a partially functioning menu in the beginning of the game instead of just a screen displaying some text. I say partially because at the moment no matter what option you select from the menu you will always end up in the same place: the gameplay screen. Also now you can rotate the camera around the player character and look at it from different directions. There is something funny going on with rendering the scene though. Sometimes things that are further away are rendered on top of things that are closer to the camera. I have some ideas in my mind for that, I'll start working on the issue next.

In addition to having the screen split in four parts, now the objects on the screen can be controlled with X-Box 360 controllers and each of the four cameras follows one object assigned to it. The objects of course are placeholders for player characters. So far one cannot rotate the objects or the cameras, only move the objects on a flat plane. We also have a primitive game state management system in place, meaning we can change between different game states such as opening splash screen, menus, victory screen and the gameplay screen. Currently the game starts with a simple screen with some text on it and moves to the gameplay state when a player presses start button on any controller.

Split screenin tesmausta.

Aikataulutusta

Aikataulua tehdessäni mieleen hiipii ajatus että projekti saattaa jopa tulla valmiiksi ajoissa. Jos saan tämän aikataulun pitämään niin viimeistelyyn ja hiomiseen jäisi vielä ihan kivasti aikaa projektin lopussa. Tosielämässä tietysti venytään ja paukutaan kun asiat osoittautuvat arvioitua vaikeammiksi ja enemmän aikaa vieviksi kuin osasin odottaa, puhumattakaan elintärkeistä ominaisuuksista joita vain ei muistanut listata ja aikatauluttaa. Odotan jo innolla viimeisten viikkojen yöllisiä koodaussessioita ja vähiä yöunia.