I know the title is a bit vague, but I'll try to explain myself.

I'm working on a game with Zelda-style top-down gameplay and would like a few opinions before i continue my work.

In a game like this, actors (player characters, monsters) will all have numerous actions they are able to perform, such as:
* Attack
* Walk
* Run
* Use an ability
* Pick something up
* Throw the currently held item
* Push a block
* Take damage
* Become frozen
* Being set on fire

Performing these actions will put the actor in a "state" (usually associated with an animation):
* Attacking
* Walking
* Running
* Using an ability
* Carrying something
* Pushing a block
* Being knocked back
* Being frozen
* Burning

What I'm searching for is a system/structure to handle what actions can be applied when, which states that can be "active" on an actor at the same time, what actions cancels another one out and so on.

Example:
Being knocked back when attacking should cancel the attack
Running while burning is allowed.
Being frozen while carrying something drops the carried item
Being put on fire when carrying something does NOT drop the carried item

As you probably can tell having if-else-clauses or switches will quickly become unmanagable. I'm not sure yet how many actions and states I will be needing but probably 10-20.

Does anyone know of a robust and elegant system that handles this?

Is running while carrying something and burning a special sprite or is it a composite of three sprites?

It seems that you have three types of states:
[M] One set for the motion: Attack, Walk, Run, Push, Stand, Knockedback
One set for the item: Carrying, Throwing, Using, EmptyHanded
&#79;ne set for the status: Normal, Freezing, Burning<br><br>You could use the above sub-division regardless if you use a special sprite for each possible combination. Within each type, the state is mutually exclusive. It doesn't seem that having if-statements would make it unmanageable.<br><br><br>You could also make each transition a function:<br><br>Example:<br><br><b>"Being knocked back when attacking should cancel the attack"</b><br><br>When the character is being knocked back, the game runs the function BeingKnockedBack(). It changes the motion to Knockedback. Since [M] is no longer Attack, it cancels the attack.<br><br><b>"Running while burning is allowed."</b><br><br>When the character is being set &#111;n fire, the game runs the function BeingSetOnFire(). It sets to Burning. (Since it does not modify [M], whatever motion the character has remains.)<br><br><b>"Being frozen while carrying something drops the carried item"</b><br><br>When the character is being freezed, the game runs BeingFreezed(). It sets to Freezing, and calls SetEmptyHanded() to set <span style=font-weight:bold;> to EmptyHanded. When SetEmptyHanded() is called, it drops whatever item that the character is carrying. This logic will also make a freezing character unable to use or throw an item. <br><br>When the character tries to pick up an item, the game runs PickingUpItem(). If is not Freezing, pick up the item. <br><br><b>"Being put &#111;n fire when carrying something does NOT drop the carried item"</b><br><br>When the character is being set &#111;n fire, the game runs BeingSetOnFire(). It sets to Burning (no modification, it is the same function as before).<br><br><br><br>

Quote:

Original post by Wai Is running while carrying something and burning a special sprite or is it a composite of three sprites?

It'll probably be a composite of two sprites, where burning/freezing are separate. That's not really decided yet.

Quote:

Original post by Wai You could also make each transition a function: Examples...

This was my initial thought, and the more i think of it the more convinced i get that this actually is the best solution... However simplistic it may seem...
I would however appreciate more suggestions. How do game programmers normally solve these kind of things?

Your question seems to be almost entirely about programming, not game design.

Anyway, don't worry about graphics while setting up game logic. Keep them separate.

One way to enforce the mutual exclusivity of some states is by having a stack of states on each actor, and having the state constructors examine the state stack for incompatible states and remove them. Other interactions between states can be accomplished the same way.

Quote:

Original post by MrMadMan How do game programmers normally solve these kind of things?

What you are discussing is a state machine. While hand coding them is a perfectly valid approach, if you want something robust and maintainable, you might want to take a look at one of the state machine compilers, such as Ragel.

Just a guess, are you using Game Editor?

Quote:

Original post by Stroppy Katamari Your question seems to be almost entirely about programming, not game design.

Sorry about that. I'm not 100% on the distiction.

Quote:

Original post by Stroppy Katamari Anyway, don't worry about graphics while setting up game logic. Keep them separate.

I am :)

Quote:

Original post by Stroppy Katamari One way to enforce the mutual exclusivity of some states is by having a stack of states on each actor, and having the state constructors examine the state stack for incompatible states and remove them. Other interactions between states can be accomplished the same way.

That's probably what I'm going to go for. But why a stack instead of a set?

Quote:

Original post by swiftcoder What you are discussing is a state machine.

Thanks for the info. It's probably a bit excessive for me though.

Quote:

Original post by klefebz Just a guess, are you using Game Editor?

I'd rather call that an assumption than a guess ;)
And no. I'm using Java 1.6. How is that relevant to the discussion?

Quote:

Original post by MrMadMan Quote: Original post by Stroppy Katamari Your question seems to be almost entirely about programming, not game design. Sorry about that. I'm not 100% on the distiction.

Your examples contained a rule "actor getting knocked back has its attack canceled". If we were debating on whether or not the game should contain that rule, whether or not it fits together with some other rule, or whether the rule needs to be modified, we'd be talking game design. This thread is concerned with how to enforce such rules in code, which is a question of programming.

Quote:

Quote: Original post by Stroppy Katamari One way to enforce the mutual exclusivity of some states is by having a stack of states on each actor, and having the state constructors examine the state stack for incompatible states and remove them. Other interactions between states can be accomplished the same way. That's probably what I'm going to go for. But why a stack instead of a set?

My bad. I used the word informally in the sense of "a bunch of". The collection of states might theoretically be a set but that doesn't mean the data structure needs to be. Use whatever is simplest in the language you're working in. It's just minor detail.

Okay. Thanks for the clarification!

I don't really feel I'm set to go yet. But at least I've gotten a better understanding of it.