#Animator State Machine for Game Mode Flow?
burnt hearth
Gahh, if I knew it would only post the first image and blow it up to massive proportions, I would have posted the animator picture first.
Animator State Machine for Game Mode Flow?
whole pewter
Hi!
"... I'm having trouble figuring out best practices for getting my FSM GameObject exposed..."
You could definity make it a Singleton that's accessible by everything else, that's probably the easiest approach.
"... pass around the Animator Controller ..."
That one could be a public property inside the Singleton
"... able to store the FSM in a namespace or static script ..."
A namespace is probably not what you want for this, their main purpose is purely organizational.
You could definitely have a static class where the FSM is a public property, although you'd need to Register/Unregister the FSM to the class somewhere.
"Is there a better way..."
That's very subjective, but in my opinion, it may be more straight-forward to just write a FSM from scratch that doesn't use/need the Animator Controller
burnt hearth
"Is there a better way..."
That's very subjective, but in my opinion, it may be...
That's my backup plan. The fact that the Animator already has a robust UI is what I'm hoping to leverage. I could easily write a DFA if I really wanted to, but I'm hoping to leverage this existing stuff.
whole pewter
Another solution for communication between the FSM and other parts of your project would be to have some kind of static MiddleMen that exposes some events as well as the possibility to raise them,
as a simple example:
static class FSMRequests
{
Action OnRequestFSMStateChange;
void RequestFSMStateChange()
{
// ...
}
}
That way, you don't need to reference the FSM directly in other spots of your project, and the Requests class could even check if the FSM exists or not
The FSM itself would subscribe to the relevant events
That may not be the best approach, I'm not a professional, but that kind of pattern helped me in some previous projects,
downside is that you'll have more code
burnt hearth
The way I currently handle transitions is through the Animator Controller itself, using Animator Triggers.
So it might get clunkier if I'm not directly exposing the Animator
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public static class FSM {
}
'FSM' is missing the class attribute 'ExtensionOfNativeClass'!
Trying to attach the FSM script to the FSM object doesn't seem to work. How would I go about making a static singleton that has a reference to the FSM?
Would I need the OnLoad of the FSM to facilitate connecting it manually?
burnt hearth
Currently solving this with a bit of a bootstrap and it seems to work.
whole pewter
public class FSM : MonoBehaviour
{
public static FSM Instance { get; private set; }
private void Awake()
{
Instance = this;
DontDestroyOnLoad(gameObject);
}
}
That would be the easiest way to make the FSM a Singleton
burnt hearth
Ooooh! I like it. I'd refer to it by FSM.FSM then, right?
whole pewter
FSM.Instance
Because Instance is the name of the static property and it lives inside the Type FSM
burnt hearth
Err, yeah. My mistake
whole pewter
But you could name "Instance" however you like
You could then have some public properties in it to expose the Animator, for example
public Animator Animator => _Animator;
[SerializeField] private Animator _Animator;
FSM.Instance.Animator.SetTrigger(...);
But it's possibly preferred to rather do something like
FSM.Instance.ChangeState(...);