How to trigger State changes from non State classes?

[MrVizious]

Hi!
I have spend a couple days working with your State Machine, and I have to congratulate you on your code!

However, I have been unable to find a clean solution to one issue I have: I want to trigger and listen to State changes from non State classes.

I have this List of Commands, and each command knows which state to trigger. Since the method Execute of the State class is async and awaitable, it should be easy to simply iterate the list waiting for each State to finish before sending in the next one.

Right now, since changing a State is not possible unless from a Transition.GoTo or similar at the end of an Execute() from a State class, my solution involves a custom method at the end of the Execute to check what the next state should be. This currently involves Reflection and unwanted code from my end, and the biggest thing: States should not be in charge of choosing the next State with this approach.

The command list should be the one triggering the Execute methods, having the responsibility and allowing for better testing, and for that, having a reference to the StateMachine should suffice.

I don't know if there is an angle I haven't seen or if this is something that clashes with the way you plan to code your State Machine, but I wanted to reach out and see your point of view.

Thanks in advance for your response and, again, congratulations on your work!

[bazyleu]

Hi! Thanks for the interesting question and for your kind words about UniState.
Could you share a small code snippet that shows how you’re currently working around the limitation (your command list + the reflection bit)? I’ll take a look, I will have some recommendations, and give you a few insights into upcoming features that might help.

[MrVizious]

Thanks for replying! Let me expand on the question.

I uploaded the relevant files here. To boil it down and possibly save you time, I'll tell you that my current solution involves a Queue of PlayerCommands, each of which has the type of the PlayerState and the Payload to send. When a state ends, it immediately goes into a state that looks into the Queue and checks if there is a next Command to execute, and if there is, uses reflection to create a Transition.GoTo with the information.

This works rather well, but requires reflection since I can't use the Transition.GoTo from a Command. Also, having a decision making state seems like a code smell to me, since it is doing the job of a command executer but things like cancelling the current state would have to be made from a different script, dispersing the functionality of such command executer.

That's basically it. Right now I have a very robust PlayerController thanks to this structure, but it stills bugs me not finding a better way to do so hahaha

Thanks for taking time to answer!

[bazyleu]

Thanks for the extra details and the sample code - always great to see how UniState gets used in different ways. I like your current approach; below are two ideas that might clean it up a bit.

---

1. Small base class for ResolveNextState()

If every “command state” ends with the same peek-queue / resolve next logic, you can push that into a common base so individual states only care about their own behaviour:

public abstract class CommandStateBase : PlayerState
{
    protected abstract UniTask ExecuteLogic(CancellationToken ct);

    public sealed override async UniTask<StateTransitionInfo> Execute(CancellationToken ct)
    {
        await ExecuteLogic(ct);
        return ResolveNextState(); 
    }
}

---

2. Reflection replacement

Instead of storing Type (+ payload) on the command, you could store the transition itself.
A minimal interface could be:

public interface IPlayerCommand
{
    StateTransitionInfo Transition { get; }
}

Creating the StateTransitionInfo can be done via StateTransitionFactory (IStateTransitionFactory) class ships in UniState package:

public abstract class PlayerCommand<TState, TPayload> : IPlayerCommand
    where TState : PlayerState<TPayload>
{
    private readonly IStateTransitionFactory _factory;

    public StateTransitionInfo Transition =>
        _factory.CreateStateTransition<TState, TPayload>(_payload);
}

Before injecting IStateTransitionFactory, it should be registered. Here is an example for VContainer:

builder.Register<IStateTransitionFactory>(
    r => new StateTransitionFactory(r.ToTypeResolver()),
    Lifetime.Scoped);

Now your queue simply dequeues a command and returns its Transition - no reflection is needed.

---

Hope this helps! Let me know how it feels in your codebase, or if anything’s unclear. Always happy to help. 🚀

[MrVizious]

Thank you so much for your input!

I certainly could make a base class that has the ExecuteLogic() and ResolveNextState() already in place, I will do so.

I didn't know about the IStateTransitionFactory, I will certainly use it now to avoid reflection.

I will try these improvements and further my implementation, thanks a lot!