Character animation logic is a surprisingly complicated programming problem. Every single condition for making a character animate the correct way, in the correct context, needs to be explicitly defined by the programmer. Without a clear methodology, this kind of code quickly spirals out of control, and becomes a major pain during the game development process.
Today, I will walk through how I implemented Character Animation Logic in Bullet Time Ninja.
The code included with this article comes from an earlier build of Bullet Time Ninja, when I was still using the red ninja.
I chose to share this code instead of a recent build because the code is a lot more readable.
Today, I will walk you through some common pitfalls I see game programmers make when designing their game level architectures. By the end of this post, you will know how to write an architecture that can support hundreds of game levels.
Inheritance
Inheritance is a cool feature of Object-Oriented programming languages, but too often programmers treat it as a one-size-fits all solution for every architecture problem they encounter.
Where an Inheritance Solution Fails, Hard
Flixel uses Objects called FlxStates to segment different sections of the game into seperate ActionScript class files that the programmer writes. One state runs at a time, and switching states destroys the old FlxState before switching to the new FlxState. This system is great for writing things like menu screens, where each screen sits in a different ActionScript class file.
// file TitleScreen.as
public class TitleScreen extends FlxState
{
// ...
}
// file CreditsScreen.as
public class CreditsScreen extends FlxState
{
// ...
}
However, you would never want game levels to extend FlxStates.
Hey folks.
I've been working on Bullet Time Ninja for a few months now. I think I'm going to use this blog to discuss some of the cool things that I have learned while working on the game.
