Even tough the subject has been on my mind ever since I learned abut them about 5 years ago I haven't got around to actually make or even thinking of use one for my games. Why? we'll several reasons, but the most powerful of all, every single implementation I could either find or come up with on my own was clunky, confusing to write, even more confusing to understand and worst of all confusing to read when used; so in short by using FSM my code would get even more difficult to understand than without them! That's why I ran away from them on game development until now.
This past few days I've been working on a simple game with some boys and girls that should be done in a few days called: Ephimeral Body
 |
| "Ephemeral Body" Title Screen |
So mechanically this game is nothing special, it's a simple platformer, way simpler that THE original platformer AKA Super Mario Bros. So we started working on it, the movement was done in a few minutes and then: we wasted hours trying to make the animations work properly! The characters would keep on walking on the air, or wouldn't play their attack animation at all even tough the event was registered or so many other animation problems that we didn't notice until our character stopped being a red square on the screen.
 |
| Something like this |
Sure this might be all avoided with experience and maybe we were just pressured by the deadline to actually think things trough, but this is a very common issue that I've encountered many times in my life, even way back when I was just learning to code and naively tough I would make a Super Smash Bros. clone in a few weeks, only that time around it took me days to figure it out. And I'm sure I'm not the only one, some of my students wanting to make platform games fall into the same pit, and many of the indie games I've encountered even fairly polished ones tend to have this problem too.
So I tough to myself this can't be right. I began thinking about that finite state machine again, that simple yet beautiful mechanism that allows software designers to lay out the states of a system in a human comprensible way. It looks something like this usually:
Or more interestingly like this (more of that in next blog entries):
It's a diagram so useful for game design that I every time there's a game to be done that's one of the first things that begin to wander my mind with questions like How many objects would I need? What states would they have? What's their behavior? How do they affect each other? All of which can be easily solved with a what system design calls a state diagram.
And so I began working on simple extension that would allow me to tinker with state machines in a simple comprensible way, and after a few hours of work I finally was able to re-implement the work we had done and that ugly movement from above turned into a more fluid transitioning like this:
 |
| Much better |
The most important aspect of this however is that this new re-implementation took me only a few minutes to code with only a few lines of code. That is of course after several iterations of the state machine's inner workings, all of which I will explain in this series of entries.
But for now that's it this. In the next entries I will explain what I was looking for in a state machine, how I implemented several versions of the state machine, all their advantages, disadvantages and the final version I decided to stick with and why. Next entry more specifically I will be discussing the use of a switch based state machine. So, until next time!
No comments:
Post a Comment