Game State

Unity Engine
1

I’ve created a state machine to start my project. My perfectionist tendencies lead me to go over things just to make sure they’re done properly. So when looking at tutorials and being lost because the internet looks like big mess of everything and partial projects, I tend to doubt myself.

My plan is to start off with the basics and work my way toward the center of my mechanics. I’m not going to be doin anything revolutionary, just the basic foundation for a simple game. Take the word “simple” with a grain of salt, because of coarse it’s going to take time, effort, blood, sweat and tears to finish a quality product.

The start of this plan is to create a basic state machine to keep track of the players input. When adding more content to the game, more states will be added and transitions will be easier for me to follow this way. My goal was to use the update loop as a way to listen to the player, but also ignore them depending on the state.

My first hurdle was creating a script and having the scene not show my any debug logs. A note to anyone who has a similar problem, make sure when you hit play, go to the top of the console tap and to the right and make sure the exclamation bubble is on to see the debug logs. Then make sure to press the game scene with your mouse to make sure, that the game scene is actually highlighted.

I got frustrated because nothing seemed to work. Then decided to create a simple hello kitty script, just to find out that my scripts weren’t the problem. It was that damn button and the scene not being selected. The hello kitty script didn’t seem to work, until I found a single post online that talked about the exclamation button.

Finally, I checked my other scripts and they worked fine. It was just that button.

So here’s my state machine. It seems to work, but I’m not an experienced programmer. Is there any advice anyone could give to improve upon or am I worrying for nothing. This should persist through scenes and depending on the players input, should trigger an event of some kind, which should change the state.

public class GameState : MonoBehaviour
{
    void Awake()
    {
        DontDestroyOnLoad(gameObject);
    }

    private static BaseState CurrentState;

    void Start()
    {
        CurrentState = new TestState();
        CurrentState.Enter();
    }

    void Update()
    {
    
        CurrentState.Execute();
    }

    public static void ChangeState(BaseState NewState)
    {
        CurrentState.Exit();
        CurrentState = NewState;
        CurrentState.Enter();
    }

}

Here’s a sample state, listening for the user to do something.

public interface  BaseState
{
    public void Enter();

    public void Execute();

    public void Exit();

}

public class TestState : BaseState
{

    private bool StateActive = false;

    public void Enter()
    {
        Debug.Log("Setting Up : State One.");
        StateActive = true;
    }

    public void Execute()
    {
        if (StateActive == true)
        {
            if (Input.GetKeyDown(KeyCode.A))
            {
                Debug.Log("Test State One!");
            }
            if (Input.GetKeyDown(KeyCode.Space))
            {
                StateActive = false;
                GameState.ChangeState(new TestStateTwo());
            }
        }      
    }

    public void Exit()
    {
        Debug.Log("Cleaning Up : State One.");
    }

}

I’ve picked apart dozens of tutorials and came up with this. Am I missing anything important?

2

FSM finite state machines:

This is my position on finite state machines (FSMs):

https://discussions.unity.com/t/834040/6

I’m kind of more of a “get it working first” guy.

Your mileage may vary.

3

It’s mostly for joystick commands. Or lack of commands…

Splash Screen
Main Menu
Start Game
Character Controller
Inventory Menu
Battle Menu (Turn Based JRPG)

And others…

Dialog State
Story/Cinematic State
Open Chest State
Climb Ladder State
Open Door State
Load Scene State

Putting all that into one file… Seems unorganized.

4

It seems fine, but you might want to wrap it in a StateMachine class so you can reuse it, and think about how you are changing/transitioning from state-to-state.

Right now you have embedded one single state machine, and you are allowing the jumping from any state to any other state.

It could look more like this:

public class GameState : MonoBehaviour
{
    public StateMachine FSM = new StateMachine();

    void Start() => FSM.ChangeState(new TestState());

    void Update() => FSM.Update();
}

Later, you might also want to look into the idea that functions can be stored as variables, and store your states in a dictionary with data about what state they can transition to.

5

That was the goal. It’s a single machine and persists through scenes. Doesn’t destroy on load.

Example Transitions:

Splash Screen > Main Menu > New Game > Story Mode > World Map

World Map > Player Menu
World Map > Battle Mode
World Map > Story Mode

Battle Mode > Player Death > Splash Screen
Battle Mode > Win Battle > World Map
Battle Mode > Win Battle > Story Mode

Player Menu Example:
When you open, close, and use the Player Menu.

The “CurrentState.Enter” would activate open menu animation.
The “CurrentState.Execute” would allow you to use joystick controls.
The “CurrentState.Exit” would activate closing menu animation.

Not sure the reason for making a dictionary to overcomplicate things.
It’s a single player game. So each state should be self explanatory.

The state will declare where it wants to go, depending on the condition.

6

Started to use the new input system. I’ve altered the state machine to compensate.

This is the current manager. I took out the update function.

public class GameManager : MonoBehaviour
{
    public void Awake()
    {
        DontDestroyOnLoad(gameObject);
    }

    private static BaseState CurrentState;  

    private void Start()
    {      
        CurrentState = new MainMenu();
        CurrentState.Enter();
    }

    public static void ChangeState(BaseState NewState)
    {
        CurrentState.Exit();
        CurrentState = NewState;
        CurrentState.Enter();
    }

}

Here is the sample state.

public class MainMenu : BaseState
{

    private PlayerActionInput PlayerInput = new PlayerActionInput();

    public void Enter()
    {
        PlayerInput.Gamepad.ButtonSouth.performed += TestStateTwo;
        PlayerInput.Gamepad.ButtonEast.performed += ChangeState;

        PlayerInput.Enable();
    }

    public void Exit()
    {
        PlayerInput.Disable();

        PlayerInput.Gamepad.ButtonSouth.performed -= TestStateTwo;
        PlayerInput.Gamepad.ButtonEast.performed -= ChangeState;
    }

    public void TestStateTwo(InputAction.CallbackContext Context)
    {
        Debug.Log("Test State Two!");
    }

    public void ChangeState(InputAction.CallbackContext Context)
    {
        GameManager.ChangeState(new PlayerMenu());
        Debug.Log("Changing State!");
    }

}

This just subscribes and unsubscribes the functions to the gamepad. This should allow me to change state from the player to the inventory, then to dialog and story events and such. I’ve been watching videos and trying to wrap my head around things, mostly on how to switch between events, menus and the player.

Are there any memory issues with this? Every time I look at "new PlayerActionInput(); or “new PlayerMenu();” I’m not sure what this does to performance. I’m not creating piles of garbage by using the new word every time the state changes am I?

7

Currently checking out dictionaries using enums for the index and the code still looks small and easy to read. Thanks for the suggestion. Was trying to wrap my head around being able to keep some data, while being able to transition between states. But not make a monolith of unreadable stuff.

public class StateManager : MonoBehaviour
{

    private static Dictionary<GameState, BaseState> CurrentState = new Dictionary<GameState, BaseState>();
    private static GameState CurrentIndex = GameState.Start;

    private void Awake()
    {
        DontDestroyOnLoad(gameObject);
    }

    private void Start()
    {
        CurrentState.Add(GameState.Start, new TestState());
        CurrentState.Add(GameState.Player, new PlayerMenu());
        CurrentState.Add(GameState.Menu, new TestState());
        CurrentState.Add(GameState.Combat, new TestState());
        CurrentState.Add(GameState.Store, new TestState());
        CurrentState.Add(GameState.Trigger, new TestState());
        CurrentState.Add(GameState.Cutscene, new TestState());

        CurrentState[CurrentIndex].Enter();
    }

    private void Update()
    {
        CurrentState[CurrentIndex].Execute();
    }

    public static void ChangeState(GameState NewState)
    {
        CurrentState[CurrentIndex].Exit();
        CurrentIndex = NewState;
        CurrentState[CurrentIndex].Enter();
    }

}

public enum GameState
{
    Start,
    Player,
    Menu,
    Combat,
    Store,
    Trigger,
    Cutscene
}
8

Does anyone else have problems with perfectionism when planning their code? Like spending too much time on the names you want to use for scripts or looking at the code and debating on how organized it looks? Sometimes I get stuck in an analysis paralysis loop.