Player state machine design

[nfagerlund]

(and/or similar kinds of entity state machines)

• The first thing that occurred to me was to just have a bunch of independent systems that exit early unless the state enum component is in the right slot.
  • That definitely clutters the system schedule, but it has the advantage of being simple and safe... I think. At least it means each state can go query all the stuff it needs without worrying about the signatures of other state functions at all. There might be a problem with making sure you only ever run one state per frame -- today I think if you insert the new state as a component with Commands, that gets deferred until the stage boundary, but I think that's changing with Stageless, sooooooo
• Then there's this situation from the discord — person's doing an exclusive system that does a match and branches off into one inner system for current state.
  • I somewhat like that, and Alice said it was a reasonable design. It's got a bunch of the same advantages as the previous, but some extra complexity for figuring out how to run the systems properly.
• ???

[nfagerlund]

Something occurred to me earlier -- I could just do the same idea as with inputs for handling the state transitions robustly. The current state can modify the state component to indicate it's due for a transition, and then I can have one system in PostUpdate that processes that so the next tick will use the new state.

(the comment about inputs is: I moved input processing to a PreUpdate system and everything else just reads the resource instead of polling inputs.)

[nfagerlund]

Currently where I've got it is that there's a "transition out" system per state, because I couldn't come up with an ergonomic way to make a unified one given the type requirements. (Tried doing some shit where I pre-construct a Command, box it, and put it in a vec, but that was a non-starter for some reason once it came down to getting it out and doing anything with it.

I reworked the movement to be like,

• However many state-specific movement planning systems
• Universal planned movement execution system

That's working ok for now, I think. State machine design stuff will just continue to percolate. The next thing I ran into was the question of how to deal with drawing shadows and fake-height Y offsets for objects in the air! (For the bonk state.)

[nfagerlund]

Ok, ready to do the bonk state, and on letting it percolate, I'm not at all happy with my state transitions logic here.

I'm starting to think I should be using events instead! Will investigate.

[nfagerlund]

• https://bevy-cheatbook.github.io/programming/events.html#events
• bevy api docs: Events and friends

Ok, so

Each event can be consumed by multiple systems, in parallel, with consumption tracked by the EventReader on a per-system basis.

• system ordering is pretty important, but you get a one-frame grace period before an event expires.
  • naturally, you've got problems if you're doing a fixed update rate on an event-consuming system. I think you can do manual event clearing for that if need be, but it's a pain. Maybe better to have fixed-update systems able to emit events, but only reliable systems consume them? Hmm.
• Event objects are your own structs or enums, and you have to register them with the app builder.
• EventWriter::send(), EventWriter::send_default, EventReader::iter()

As for how to integrate that into a flow of state transitions, hmmm.

[nfagerlund]

Right now the transitions I have going on are:

• free -> roll
  • pressed action
• roll -> free
  • spent roll distance
• roll -> bonk
  • collided
• bonk -> free
  • spent bonk distance

(and then more in the original project)

Hmm, makes me wonder if collision should be an event too, rather than a prop on Movement.

[nfagerlund]

Uh, this situation has mutated outlandishly since last I wrote here. Events ended up being somewhat unstable for state transitions.

[nfagerlund]

And I ended up using timers instead, for the most part. 🤔

[nfagerlund]

OK, so I was previously using one sparse component per state, because it allowed me to check the current player state in the system query. (The type system can't manipulate enum values, only types.)

But the resulting system code was actually much more complicated and brittle than it would have been otherwise (careful gardening of command sync points, need to manually ensure mutually exclusive states exclude each other, etc.), and it was much easier to get a handle on what was happening after I switched the state to be a single enum (with an optional queued-up "next" instance) inside a PlayerStateMachine component.

I think I've now hit the point where I've learned plenty of stuff and I won't learn more by designing without a use case. So let's close this ticket and figure out how to make something playable next.