Tips on many Movement based states for a Player scene?

[Svaught598]

Hi! First off, I just wanted to say that I love this plugin for Godot! It's been incredibly easy to work with so far, and everything feels very intuitive.

I've just started getting into Godot, and having come from a more conventional software developer background, am having trouble wrapping my head around the "right" way to accomplish composition using state charts for states that require a decent amount of logic to be ran on process/enter/exit/etc.

In some examples that I've seen, it seems that the main way to interact with StateChart states is to have other nodes listen to signals being emitted by each state and processed in a main script. For a player scene, with lots of complex movement states, this method means that I either have to have 1000+ LOC in a single file, or create bespoke nodes/scripts for handling each one (e.g. a Running state would need a Running.gd script that handles the enter/exit/processing of that state. Or more generally, a PlayerMovement.gd script that contains all movement stuff).

I'm leaning towards creating scripts that just broadly organize the logic in the player scene, but with lots of cross-cutting concerns like parallel states that also affect movement, I was curious if there was a better way to accomplish this with StateCharts?

Apologies if this is a silly question, just looking for any tips if you have any!

[derkork]

Well without knowing more about the details it's really hard to give a decent recommendation that doesn't amount to "it depends" or descends into hand-waving. The platformer demo has about < 100 LOC for the whole player movement which has some extras like double-jump and coyote jump. This is an order of magnitude away from the 1000 you suggest. Could you give me some more insights about where all this complexity comes from? I feel I can give a much better recommendation when knowing the problem at hand rather than speaking in general terms.

[Svaught598]

Thanks for the super quick response!

I ended up spending the last week or so really digging into the demos to better understand the usage and now I have a player character script with < 200 LOC compared to an initial ~1200. These were my takeaways:

• I have basically two parallel compound state trees, and some transitions in one state tree really are "compound" transitions across parallel states. Most of the time the parallel states are non-interacting, but I have a few state transitions with side-effects. I was really thinking there must be an ideal way to model this, but I settled on just doing two send_events back-to-back after deciding I'm probably overthinking it.
• I had a number of states that had logic revolving around timers, and those shrunk dramatically when switching to timeout state transitions (no event & some delay seconds). I originally didn't do this because I wanted to export the timer durations in the script, but it seems to be working fine if I use the exported variables to set the transition delays in the _ready function.
• There were some issues with having states use a timeout transition along with other explicit transitions when I wanted to use the state_exited signal since the state exiting could mean different things. I had some weird workarounds in place, so those nodes were converted to compound states with a State that times out to a transient StateTimeout child (which then immediately transitions to what I original wanted to timeout transition to). So I basically just added an additional state that is only reachable by timeout to act as a sort of proxy giving me two state_exited signals that are a bit more granular.

So all in all, I think my problems were due to not modelling my state well enough in State Charts. But I'm interested to know if these solutions make sense or if there are alternatives that fit a little better?

Thanks again!

[derkork]

I'm happy that you were able to come to a nice solution. Your mentioned points seem sensible to me. As for the first point, you can actually have multiple transitions listen to the same event in different parallel sub-trees. This way you wouldn't need to send two events back-to-back, e.g.

• Parallel ROOT
  • Compound A
    • State A1
    • On "switch" to A2
    • State A2
    • On "switch" to A1
  • Compound B
  • State B1
    • On "switch" to B2
  • State B2
    • On "switch" to B1

If you now send the "switch" event both A and B will change their substate.

[derkork]

The last point could actually be addressed with events on transitions: https://github.com/derkork/godot-statecharts/issues/58 . If you get notified when a transition is taken you don't need to have this transient StateTimeout state because you get an information when the timeout transition is taken.

[Svaught598]

That would be awesome! I'm finding that I have a lot of transient states used specifically for signaling a transition and this would help a lot!