jamesyfc / susmachine Goto Github PK

There is a chance this isn't actually that useful, we'll see.

var fsm = new StateMachine<States>{
	AnyState = {
		// ...
	},
	[States.State1] = {
		// ...
	}
}

maybe an update func param in the transition function

due to the fact that these state machines are independent of MonoBehaviour, users may unwittingly expect SUSMachine update functions to only be active when the creator script is active and enabled.

E.G. we could have an option (in the constructor perhaps, seeing as we already have the game object param there?) to input a monobehaviour and check on update its enabled status to mirror update functions on/off in the StateMachineManager

Mainly to run the tests.

If I've read the docs right, we can do something like this...

private StateMachine<States, Events> stateMachine;

private void Awake()
{
	stateMachine = new() {
		// ...
	}
}

on stateMachine.Initialize(), add a runner mode enum that allows the user to choose where life cycle & update methods are called?

• StateMachineRunner (default)
• Manual
• Automatic? (adds a monobehaviour? or requires another parameter that spells out which monobehaviour to check before giving it update callbacks?)

When Unity supports newer language features like covariant returns, I will be able to simplify the codebase and improve quite a few aspects of this library. Though that will likely bump up the supported Unity version as well. We'll leave the previous version in another branch.

After this, I will look into new features and improvements such as...

• Supporting UniTask/task based delegates on some functions
  • (it is currently possible to provide async methods, the state machine will just run them and forget about them)
• Make passing event args nicer.
• Look into nested state machines
• FSM-wide state
• various other API improvements
  and more...

No promises that everything will be feasible but I will certainly be looking into them when it's time.

turn on a IsEnumerating bool or something and cache these new ones if trying to add during enumeration, then add them in after current enumeration is done

If you create a state machine with update functions in any of its states, then destroy that component, you'd probably expect that state machine to go away.

However, if I recall the details correctly, the manager will still hold onto it as the gameobject destruction component from Initialize(x, y) won't trigger if the gameobject is still alive.

makes it easy to reset & reusable

add Enable/Disable functions to AutoCloser (and rename it) that tell the state machine manager to stop or resume calling the relevant update functions

double check that the TimeInState counting functionality still works correctly (should it count or not while the gameObject is disabled?)

this might have to be togglable behaviour or something. sometimes there is value in being able to turn off the game object but still allowing these life cycle functions to run. Purists would hate it, but it does make certain scenarios more convenient.

if togglable, we'll use a modified version of AutoCloser instead, or a separate component that contains the new magic methods

If I'm reading the microsoft docs correctly...

This will make the fsm a little safer by not allowing modifications to be made after initialization, as public setters are required to use object initialization syntax

First decent idea might be blocked by this

Maybe something like record structs in C# 9, but is there a way to have copy on write optimizations without the user having to do anything special?

probably a nullable States?
is it possibily to return null by default when you declare a function with no returns?

Something like this?

enum States {State1, State2};
enum Events {Event1, Event2};

fsm = new StateMachine<States, Events>
{
	[States.State1] = {
		// new
		OnEvents = {
			[Events.Event1] = _ => Debug.Log("event1 triggered for State1")
		}
		
		AutoTransitions = {
			// new overload for Add() super simple form
			{States.State2, Events.Event1}

			// new overload for Add() simple form
			{_ => true, States.State2, Events.Event1}

			// new overload for Add() complex form
			{_ => someCondition ? States.State2 : (States?)null, Events.Event1}

Somewhere down the line...

fsm.TriggerEvent(Events.Event1)
// debug "event1 triggered for state1"
// enters state2

so we can write _ => rather than (_, _, _) => or even (_, __, ___) => when no discards

Across the projects I've been using this library in, delegate instantiation costs haven't been an issue.

Still, this is a possible improvement.

e.g.

https://devblogs.microsoft.com/dotnet/understanding-the-cost-of-csharp-delegates/#workarounds
https://devblogs.microsoft.com/dotnet/understanding-the-cost-of-csharp-delegates/#comment-10168