Conditionals best practice

[kLy]

Hey there

We're making a pretty big game and an issue I often come across is which approach to take when getting to a logic point that requires many branches. This is most common in what would logically be a "switch" statement, eg. checking if an item you're trying to use with an object is x, y, or z. Now the 2 approaches I'm faced with are:

1. Have a single state with all the logical checks within that state. This then sends out X number of events depending on which criteria gets met.

2. Have X number of states, each having the event "Yes" and "No" and chain the states together to check against all matches.

The number X here can be 10+, so things can get messy pretty quickly in one of two ways.

If I go with 2. I only need to create 2 events "Yes", and "No", which is very nice, however the FSM tree itself quickly becomes a big sprawling mess as X goes up and as the number of these checks increase.

Going with 1. results in a very neat and tidy FSM. The downside though is that there needs to be a *lot* of very custom and unique events that only get used once eg. the event "CombineRubberDuckyWithFishingRod". This creates 2 problems:
a) there's a big manual overhead naming, creating and hooking up all these events
b) worse still, the Event Browser and Custom Events list will start getting really huge, really quickly. Those 2 lists will quickly become useless as the huge number of unique events start cluttering it up.

I'm guessing 2. is still the most elegant solution, but (b) above starts becoming quite problematic. Ideally I guess there should be some kind of "scope" to events, so that you can create certain events that will only ever show up in the local FSM. This way the Event Browser and Custom Event list can still remain useful. I also don't know if there's any performance penalty to having a huge number of unique events?

Thanks!

[jeanfabre]

Hi,

 I use both, and it's very much related to the actual effect you want to achieve in terms of logic.

 1: is your general no brainer case
 2: is when you want to support mpre complex behavior. I use this when I want to define a process that I need to follow and double check regularly. Example:

let's say we have an industrial robot that needs to perform a specific task, like picking up a part and put it on a belt or something. The process of picking up, and delivering can be made into one fsm that will dispatch more precise commands to the robot arms, . and so in this case, each movement if one state, and you cascade down the process:

 is the robot in position: YES, NO

 no, would check if the robot can more, and if yes, move it to the pick up spot, then back to this state likely.

Is the part available; YES, NO

etc etc

so approach number 2 is like switch statements on steroid where you can implement really powerful logical processes, it's a lot more then just a switch statement

now, sometimes for clarity, you simply want to spread things a bit, and that's fine too, I often have one state per Case, even tho they could be all checked on one states, simply because I want clarity, I can then name states to reflect the case, something more difficult with one state.


Bye,

 Jean

[kLy]

Yeah I am talking more about the no-brainer case ie. a simple switch statement

In that case 1. would suffice but in using it you would still need to create lots of events, one for each case.

[jeanfabre]

Hi,

 I don't think that you can avoid the creation of specific events in conditionnal statements, even with a custom action, cause to transit from a state to another, you have to have an event.

I encourage you to create these specific events everytime cause they help the understanding of the fsm at a glance, I always name my events very precisly and carefully, and I don't do "EVENT 1" "EVENT 2" and stuff like that, that's terrible if you come back 6 months later on your game, you will be totally at lost as to what it actually means.

bye,

 Jean