dinghino / xstate-game-state Goto Github PK

Issue is that while axis do more or less one thing and can be easily configured with options and such, actions can do basically anything, especially in a web environment where you can do actions both in a canvas, on the state machines themselves or even on the DOM.

Right now - while in the demo configuration there's 2 actions binded, break and fire - only the break action is working through some typescript hacking whatnot directly inside the processInput machine action. This is obviously a no-go since it enforces you to name the "slow down" action break and it only does what it's in there.

Ideas

Assigned upon interpretation

One idea would be to set up a named action like processActions inside the ControlsMachine (createControlsMachine), called before or after the inputs, but not implementing it, and passing an extra argument to the main factory that extracts that type (following xstate types) to enforce developers to a type safe method to pass there.

Problem with this though is that you may not have access to target of the effects for the actions where you interpret the machine, so that would work for simpler actions.

Just handled

Simpler options is that we map the action inputs (from the ControlsMachine) to the state machine (with velocity and actions) and inside the components we react to those where they are needed. it may become complicated to keep track of everything but it may be a quick and dirty solution for everything that does not require internal context changes