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\$
  • \$\begingroup\$ Do what you like, there's nothing such as best solution in game programming \$\endgroup\$ – Bálint Jan 26 '17 at 6:52
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.

| improve this answer | |
\$\endgroup\$
  • \$\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 '17 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 '17 at 11:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.