This is definitely a topic we'll cover in the follow-up video. Transition pairs were actually one of the first things I added to insignia's state system and then never used because of the tree structure I'll be showing next.

Thank you!

That's right! I'll be showing a more advanced example next video doing exactly that.

I would encourage you to be project oriented in your learning. If the project you're making needs specific math, you'll encounter it while trying to solve the associated challenges. Otherwise you'll just be learning for learning's sake (nothing wrong with that, either!)

When I tested it before filming, I was able to add frames to a tag in Asperite after the initial import and had no issues seeing the Unity animations update accordingly. This is the first time trying it in earnest, since I've got my own systems that I've been using for a long time. It surprised me with how simple it is for basic animations like this, so I might use it in future game jams. Of course, there are limitations that don't make it very extensible. Eventually you typically need to build your own thing, but that's what these tutorials are for :)

@@AdamCYounis Thanks for the answer

They are components primarily to allow for instance data to be set in the inspector, at the game object level. A static class would not allow for this, and scriptable objects are designed as data objects, not really intended for runtime logic.

@@AdamCYounis I mainly meant to hold the data for what the state does and have a script that swaps between the states and takes the data from a different source than having say 200 sub game objects holding 200 scripts under the player in the hierarchy which seems less performant to me. So A manager script that references the Data for each state. Since states aren't changing the data on the fly then why would it need to be modified at runtime?

isComplete belongs to the State class, and I set it false in an Initialise() function from 31:55

Thank you

24:38 - The update function of the "state machine" class (PlayerMovement for the sake of this tutorial) calls state.Do(), as well as SelectState() which handles Enter() and Exit().

@@AdamCYounis I have no idea what state Do, enter or exit actually do. I understand them conceptually; do, enter, exit something. I just really struggle with how they run logically; how they run line by line. The state object is, i believe, just a framework you can use over and over, and code within it can be trailered for things common across states etc. I just struggle how they are interpreted by Unity and order of code execution. This probably sounds complete jibbirish but I'm not used to creating objects in programming, and how to use them. im more of a functional programmer, and used to keeping things on one page.

@@cyberblitzTBH I'm not super familiar with Unity or with Adam's exact system, but maybe that'll help me explain this stuff to you in a more agnostic programming perspective. Basically, every frame, Unity calls Update() on all the active game objects Objects with a state machine will now call state.Do() and SelectState(), because that's what they were told to do in their Update() function. state.Do() is just a function, the same as functions in the paradigm you already know. It's going to do something. Maybe it tells the enemy AI to approach the player, as an example. Maybe it spits out "Hello, World." It doesn't matter. It is just running the specific lines of code written under "state.Do()" for the state that was assigned to this game object. SelectState() changes which State the game object is in, according to its current situation. This is just simple IF statements. If you're in the air, you're in the aerial state. If you're attacking, you're in an attack state, etc. It figures out which state the object should be in, and puts it in that state. Then, in future Update()'s (that are happening all the time as the game is running), the behavior will change according to the new state. On the line level, it's just something like this: Update() -> the line of codes under "Update()" run, calling the "state.Do()" function state.Do() -> the lines of code under state.Do() run, they come from the specific "state" we assigned to our character earlier. Update()-> now that state.Do() finished, Update() continues to its next line of code, which is calling SelectState() SelectState() -> the lines of code under "SelectState()" run.

Because my state machine data structures are hierarchical, they are literally trees.

@@AdamCYounis I think it's a valid point. You showed a tree structure at the beginning which was confusing, because state machine you shown later, in this particular video, is not hierarchical. It's state A to State B to State C to State A, basically.

"switch" implies that you have to pick one or the other. My long term game is a Unity game and can't be ported to another engine. For smaller games I produce for jams, Godot is an engine I've begun to use, but it's far from a replacement for Unity at this stage.