Official State Machine

Starting on https://open.codecks.io/unity-open-project-1/decks/15/card/157-state-machine.

 

Hey Dustin, please do. Feel free to keep it simple on its first implementation, it will be easier for us to review but still allows us to build on it or tweak it later.

 

I'm cannibalizing from another personal project, so it might be a bit beefier than you're expecting.

It's will force an order on the application but also makes it clear where lots of pieces go -- New Game creation, Settings and Main Menus, Quit Game, etc. Hopefully that's worth the cost it imposes.

Feel free to ask questions, request changes, demand deletes on any parts you don't like.

 

Oh, and PR is at https://github.com/UnityTechnologies/open-project-1/pull/6

 

It looks hardcoded and overcomplicated. State machine should help at solving boilerplate code, not introduce it.
I think it would be better to write something smart from group up, starting with basic animations.

 

It definitely tries to cover much more than I expected, I was going for just a state machine for the character controller
Let me take a better look at the code, I'll get back to you.

 

Why not just using Bolt?

 

Because it will limit our capabilities.

 

In how far? I've used Bolt a lot and think I know the weak points very well. But I wouldn't say that one of them would limit you in any way. Therefor I'd be really interessted in why writting a fsm from scratch would be better than using an already battle-tested statemachine.

 

I'd like to use Bolt, but, I think we should aim at having a good structure made with code first, and then we can provide an "entrance" into the game logic that a game designer can "plug in" using Bolt. Basically expose functions that designers can use to build quests and whatnot.

I might be a bit of a stretch goal, but let's think about it for later.

 

Not sure if I got you right. So does that mean that you want to have both: a fsm written in code + later bolt?

Because in overall I agree with you. The logic should live in code. Bolt should just use them in order to create the final behavior. At least this is how used it.

So from my point of view it just wouldn't make sense to create an own fsm solution. Of course my point of view don't have to be right.

(Btw: I'm definitively not against seeing a fsm getting realized within code. I saw only a couple of variations so far and it would be really interessting to see with what the project would come up with. But due to productivty reasons I would recommend bolt ^^)

 

I just recently added in a state machine pattern into my own indie game to make it so much easier to keep track of enemy states and level states, so I'd be down for working on that card.

It was based on the simplicity that Jason Weimann discusses here in his video:

And I'm a developer so, you'd know where I stand on the whole Bolt discussion

 

Hey @Proryanator, this one seems overcomplicated as well and based on tons of delegates.
I've been already working on it today and took ScriptableObjects approach based on Pluggable AI by @MattMirrorfish



All the logic is written inside ScriptableStates (Action or Decision).
They contain shared data only.
StateMachine (MonoBehaviour) has dictionary for all the non-shared data.









With this approach it's all super easy and reusable, you can create new logic just from combining states in the inspector.
I think it would fit this project perfectly

 

@Neonage looks super interessting. But I think this is too simple. I would at least provide methods for entering/exiting a leaving a state. Think of if a state/transition wants to add listeners for events and remove them when exiting the state.

 

Yeah, I want to add more features like that, but need to make it as simple and intuitive as possible
Hope I'll finish the base tomorrow and will make pull request so you guys can try it out

 

@Proryanator I like Jason's approach me too and I am working on a fsm using that style with some simple modifications.

@Neonage sorry I don't get what is NpcData. Is it a collection of dependencies used by the states of the FSM?

 

It's a scriptable object that holds shared data about NPC.
All dependencies are handled by StateMachine internally

 

Could you post a snippet of code with an example of a shared data object?

 

Any scriptable object asset is a shared data

 

So actions and decisions are going to read/write on this data? Meaning that the same instance reference of NpcData is shared across multiple instances of actions and decisions?

 

Yep, and NpcState is unique per instance.

Mostly only read, as it's, well, shared

 

It's a very interesting approach, @Neonage. I also would love if the state machine was simple at first, then we can look into making it more complex and full-featured.

 

This the official thread for discussing the Character State Machine (roadmap card)

 

This looks like a quite nice extension of the original system, thanks for sharing!

Anyone curious about the original version that I created a few years ago can watch these videos:

I still stand behind this approach, some nicer editor scripting is what's missing in the original IMO. What's nice about this is it should make it easier for designers / non-programmers to manipulate and configure states. Not as fancy as a behavior tree but pretty viable for FSM based NPC AI.

 

Why don't use the Animator Controller and State Machine Behaviours scripts?
It's simple and powerful.

 

I've heard conflicting opinions about this implementation. Some people love it, some hate it. I guess it's the usual case of trying to bend a tool that was originally conceived for something else: it's great until it works, until it becomes a nightmare

But maybe for the small scope of this project it might be ok. I like the SO-powered implementation though

 

I was about to reference Jason Weimanns solution too.
But I really like the solution @Neonage suggested. It seems simple, scalable and should be easy for designers to use as it works with scriptable objects.

 

Ok! I'm not sure about public fields that can potentially be overwritten by multiple clients, but I want to see a completed implementation before judging!

 

Same here, however I do like @Neonage 's design allows for designers/non coders to create transitions and such, that's a pretty awesome ability.

My solution and probably yours was going to be purely code-based @kcastagnini I'll still work on it just to see if our implementations differs in any way.

What's the harm of having lots of implementations and deciding on the best one right? #openSourceUnityProjects

 

I love the thought of making the ability to add transitions an available feature for designers, this is wonderful!

Can't wait to see your PR I'll probably learn a lot from it!

 

I opened a PR of how I would implement the state machine, have a look! I'm good with what you guys think is best, and I'm still a fan of @Neonage 's plan/idea.

https://github.com/UnityTechnologies/open-project-1/pull/33

 

I have posted an open-source Unity project called Zen Toolset a while ago with an extremely minimalistic FSM. But I'm pretty sure you guys have a better implementation than mine, but I'm going to share it anyway. My implementation of FSM is based around the idea of component-oriented design, but I hope to implement more feature that allows non-programmers to modify the behaviour even more.

State Machine scripts: https://github.com/Nichii/ZenToolset/tree/master/Assets/ZenToolset/StateMachine/Scripts
Example: https://github.com/Nichii/ZenToolset/tree/master/Assets/ZenToolset/Examples/StateMachine

The project also contains a few other useful scripts that I've been using as well. Feel free to check it out and contribute as well.

 

Oh I never thought to create additional methods to be called in either Update or FixedUpdate, that's clever that makes me think you might make a 2 state machines that work the same way with my design but, I can see how yours would keep the logic separate, very nice!

Thanks for sharing!

 

Hi @Proryanator
I would like to work in open project_1.
Can i work on task Char. controller? in Codecks
Can i change mesh player(FBX), because player don't add animation ?

 

So my solution is purely code based, which does mean the ability to add new transitions between states as a non-coder is not really possible. It also creates a discussion about configurability of states and the character, as brought up by @ErikBehar in my PR.

I'm not sure if there are state specific variables right now but there may be at some point in the future for certain states. Perhaps the DamageState would have a timeout, and you can keep said timeout configured in the DamagedState itself, which would encourage using the SO approach.

So I see 2 possibilities for configurability; one where we keep adjustable values pertaining to the state in the state itself using SO's, and the other where the states simply act upon/read data from the object that it's states revolve around. Or something similar to how @Neonage is storing NPCData that is stored inside of states.

The only thing I'd be curious about with using SO's to store configurable variables about the character, is that if you have multiple characters or objects that end up using the same states, you'd need to create new SO instances to change their configuration. That's how you're doing it for your example right @Neonage? Which might just be a different way of configuring data than all in 1 MonoBehaviour.

Where going with the current implementation, you have states that act upon the Character, do not store any configuration data, and if you wanted to change lets say the gravityModifier or any other values, you just change it in the Character itself.

Thoughts?

 

Alright, added basic triggers, but i'm unsure about UX i've camed up with..

 

Not SO itself. In my example, I'm attaching IStateData struct per-instance based on shared data

 

gravityModifier is sharable, so it would be in SO.
We can easily store some unique data in behaviour so we can adjust it in inspector.
But if so, we'll need to make Overrides like in Volume component
Like, if we want to make one weak enemy in the corner of cage, we'll just override it's initial energy in inspector

 

Nice job! Could you please share your branch so that we can take a look at the code and participate somehow?

 

As soon as I finish implementing actual logic

 

Ok I don't know if this is how we are supposed to collaborate considering that we are not collaborating at all.
@cirocontinisio Isn't the open project supposed to be about working together?
Or is it about some random developer claiming a whole system and sharing the final code only at the end?

 

No-no-no, i meant that i haven't finished base and example, it will not work if i'll share it now)

 

Seems pretty good to me. A little unclear how to add multiple decisions to each transition or how to add "On true" feels like there is 1 -+ control missing ?

 

And now? I've tried to save as much space as possible while keeping it intuitive, what do you think?

 

Oh nice, it has a little popup, yeah that seems good to me.

 

@cirocontinisio Any thoughts on how collaboration should be handled in this project? Especially in a case like this, where this early design decision will have ripple impacts down the road.

Will this project lean towards an approach of "each developer makes a PR, best PR gets approved"? Or are we building it incrementally?

 

Should audio triggers be managed in the FSM? Would it be more robust to have a separate script watching for audio events?

 

You've got a good question here, it could probably be some combination of both really. I wouldn't be opposed to working with others in a discord chat and working off of the same branch perhaps in a forked repo.

But there might be cases where someone might either want to do it on their own at first, then get input/feedback incrementally as they go.

Either way the code that gets merged in will most likely be community approved/designed, as well as approved by the moderators

 

I'm working on it non-stop to establish the right foundation, so everyone can understand it without confusion and be in the right direction from the beginning

 

They are not managed by SM, they can be triggered from anywhere