State Machine

Starting on Codecks.

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 Initial addition of adding a Finite State Manager. by Dustin00 · Pull Request #6 · UnityTechnologies/open-project-1 · GitHub

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?

1 Like

Because it will limit our capabilities.

1 Like

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.

2 Likes

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 :eyes:

2 Likes

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 @mirrorfish

6371256--709209--upload_2020-10-1_22-50-51.png

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.

6371256--709215--upload_2020-10-1_22-59-31.png

6371256--709236--upload_2020-10-1_23-7-49.png

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 :slight_smile:

4 Likes

@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 :slight_smile:
Hope I’ll finish the base tomorrow and will make pull request so you guys can try it out

2 Likes

@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?

1 Like

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 :slight_smile:
6371775--709308--upload_2020-10-2_1-0-48.png

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?