0
\$\begingroup\$

I'd like to implement the player in my game as an FSM as described in this guide to programming patterns in games.

What is the best way to accomplish this? Should I implement each state as a monobehaviour with a state interface that can be enabled/disabled when the state transitions? Or would it better to the states as plain classes (with their own Update method) where the main player monobehaviour calls StateName.Update() from its own Update method (.e.g. void Update() { currentState.Update() })

\$\endgroup\$
1
  • \$\begingroup\$ Do what you like, there's nothing such as best solution in game programming \$\endgroup\$
    – Bálint
    Jan 26, 2017 at 6:52

1 Answer 1

1
\$\begingroup\$

I personally like to create a private enum with different states, with a private States variable that holds my actual state. Then in the Update function I create a switch-case to test in which state I am right now, and I call the relative function. Then inside the called function I assign the new value to the actual state. This is an easy to mantain solution, in my opinion.

{
    private enum States { state_0, state_1, state_2 };
    private States state_now;

    void Start () {
        state_now = States.state_0;
    }

    void Update () {
        switch (state_now) {
            case States.state_0 : state_0(); break;
            case States.state_1 : state_1(); break;
            case States.state_2 : state_2(); break;
            default : break;
        }

    void state_0() {

        // Business logic
        state_now = States.state_1;
    }

    // Others function, one for each state
}

I wrote this snippet without Unity on my PC to give you an idea, it's not intended to be a complete example.

\$\endgroup\$
2
  • \$\begingroup\$ In my experience, when adding methods such as onEnter, onExit, state specific methods and state specific data, the code literally explodes, and keeping everything in the same file makes it very hard to follow... Perhaps for a simple character, the way you suggest is a good start, but one has to keep in mind that refactoring could be needed at some point..! \$\endgroup\$
    – Vaillancourt
    Jan 26, 2017 at 11:22
  • 1
    \$\begingroup\$ Indeed, I agree with you. As I stated in the answer, this is not meant to be a complete example, just a basic idea. This depends on the specific requirements of OP: if he adds some additional Information for the specific scenario, there is for sure a better suitable method. \$\endgroup\$
    – Andrea
    Jan 26, 2017 at 11:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .