State Machine not working

Unity Engine
1

Okay so this is my last hope I am working on a project and trying to get a street light to go to red yellow and green. I also would like to make it blink yellow and nothing is working I have all he code in there correctly with no errors and nothing works at all. Not even the get key down code. I uploaded the file I just need help and need some answer or corrections by Monday. I am not looking for a free ride here, I am looking for someone to help me out and tutor me at the same time to help me understand it better.

2773494–200518–TrafficLight.docx (13.4 KB)
2773494–200519–TrafficLightStateMachine.docx (14.5 KB)

2

Post your code in code tags:

It’s tedious to have to dl your code and read through it, most likely unformatted.

1 Like
3

Yep, post your code in code tags. And really, no reason to do a survey when asking for help. That might even turn people away from helping.

2 Likes
4

Okay one bug that probably won’t fix things but it could cause problems. Your Update function should look like this:

void Update()
    {
        timeKeeper += Time.deltaTime;
    }

and GetTimer should be:

 public float GetTimer()
    {
       return timeKeeper;
    }

This is because say an update happens, your code does correctly update timeKeeper. However, lets between 1 update and a 2nd update… 20 different objects call GetTimer. In your code each one will increment timekeeper and return it, and they will all have differnt values of the time. When they should all be getting the same time. Increment timekeeper one time in update… then have GetTimer just return that value.

Traffic Light State Machine seems mostly to be correct. I’d make the changes I showed above change your Update to just
fsm[curState].Invoke(); to see if it now correctly changes the light colors. If that works add in
StateBlinkYellow(); // you’ll never need a GetTimer call in this update

1 Like
5

Well thanks guys for responding and helping me out here, I’m new to this forum and didn’t know how to do the code tags, I appreciate the link. Now the only problem is my blinking is not working. Takatok I did what you said and one of the lines was a warning. Then the Code didn’t work at all and the colors did not change. I went back to the original and it worked.

private Dictionary<LightStates, Action> fsm = new Dictionary<LightStates, Action>();
    private TrafficLight target;
    private LightStates curState = LightStates.RED;
    private GameObject greenLight, yellowLight, redLight;
    private bool blinkYellow = false;
    private Renderer lightRenderer;
    private float timeKeeper;

    enum LightStates
    {
        RED,
        YELLOW,
        GREEN,
        BLINKYELLOW,
    }
    void Start()
    {
        target = gameObject.GetComponent<TrafficLight>();

        fsm.Add(LightStates.RED, new Action(StateRed));
        fsm.Add(LightStates.YELLOW, new Action(StateYellow));
        fsm.Add(LightStates.GREEN, new Action(StateGreen));
        fsm.Add(LightStates.BLINKYELLOW, new Action(StateBlinkYellow));

it was saying line ten and 25 of my code and gave a warning but didn’t work.

6 
 private LightStates curState = LightStates.RED; Line 10

target = gameObject.GetComponent<TrafficLight>(); Line 25
7

No comma for the last entry in an enum.

8

I would like to propose a methodology for implementing an FSM using enum and switch.

The two essential pieces of information about a Finite State Machine are its states and its transition conditions. Because these define an FSM at a conceptual level (e.g using pen and paper).

Let’s say your traffic light starts as red, then after 2 seconds it turns green for 2 seconds, and finally yellow for 1 second before turning red again. (I’ve omitted the blinking yellow for simplicity; the idea is the same for any FSM). Then a graph representation of this FSM is:

Now, the problem is to implement this FSM. Anyhow you implement an FSM, you need to keep track of the states and their transitions. This is essential. If your implementation does not clearly make this graph somehow apparent, it won’t be clear what your FSM does, so it could mislead the person reading your code (which could be yourself in future), which increases the risk of introducing bugs. That is, it has an impact on the maintainability of the code.

The usual way to implement an FSM is by using an enum and switch. Each enum maps to a function implementing the respective state and the transition conditions are define in each case block. (I often see the transitions directly defined in the state functions. I think that’s a mistake, since it makes the transition conditions less obvious because mixed with the low level implementation of a state.)

using UnityEngine;

public class TrafficLightFSM : MonoBehaviour
{

    enum State
    {
        Red,
        Yellow,
        Green
    }

    State currentState = State.Red;
    float t = 0.0f;

    void Update ()
    {
        switch( currentState )
        {
            case State.Red:
                State_Red();

                if( t > 2.0f )
                {
                    t = 0.0f;
                    currentState = State.Green;
                }
                break;

            case State.Green:
                State_Green();

                if ( t > 2.0f )
                {
                    t = 0.0f;
                    currentState = State.Yellow;
                }

                break;
            case State.Yellow:
                State_Yellow();

                if ( t > 1.0f )
                {
                    t = 0.0f;
                    currentState = State.Red;
                }
                break;
        }
    }

    void State_Red()
    {
        t += Time.deltaTime;
        GetComponent<Renderer>().material.color = Color.red;
    }

    void State_Yellow()
    {
        t += Time.deltaTime;
        GetComponent<Renderer>().material.color = Color.yellow;
    }

    void State_Green()
    {
        t += Time.deltaTime;
        GetComponent<Renderer>().material.color = Color.green;
    }

}

Notice how the switch structure is almost a direct translation from the graph representation to code. You can easily rebuild the graph representation just by reading it.

2774327--200587--trafficlight_fsm_graph.png

9

Once you get the bliinking worked out. I would also suggest another level of … complication :slight_smile: I would separate out inititialization code from update code. You should have two functions, InitializeRed and UpdateRed. When you switch states, you call InitializeRed… Then in the Update function, after switching on your currentState you call UpdateRed. There is no need to consantly be setting Red’s Color to red, and yellow/green to grey. Which your current implementation does. With a small state program like this, it isn’t a big deal… but if you start expanding it and dealing with more code it could lead to performance issues, and possibly bugs from having what is effectively Initializers called non stop.