- state-machines-du (107 Tokens): each state has its own draw and
- state-machines-st (111 Tokens): each state has setup and teardown
methods which are run only when the state is entered and exited
Creating a state machine
To create a new state machine use the 'new' method:
sm = state_machine:new()
After creating the machine itself you need to add states. A state
consists of four things:
- A unique name or identifier: Most likely a string but can be
anything as long as it's unique.
- A transition function: This function is called once per cycle
and should return the identifier of the state the machine
should switch to.
- An update (or setup) function: The update function is called
once per cycle and should update variables, etc. associated
with the state. For state-machine-st.lua, this is instead a
setup function which is only run once each time the machine
enters this state.
- A draw (or teardown) function: The draw function is called
once per cycle and should draw everything relevant to the
state. For state-machine-st.lua, this is instead a teardown
function which is only run once each time the machine exits
Add a state to the machine using the 'add_state' method:
sm:add_state( -- identifier 'a state', -- transition function function() if btnp(5) then return 'some other state' else return 'a state' end end, -- update function function() if timer then timer += 1 else timer = 0 end end, -- draw function function() print(timer) end )
Using the state machine
Once you've created a state machine and added some states using it
is simple: Set the initial state then call the update and draw
function _init() sm:set_state('a state') end function _update() sm:update() end function _draw() cls() sm:draw() end
The update method calls the current state's transition function
and changes the current state if necessary and then calls the
current state's update function. The draw method calls the current
state's draw function.
The setup/teardown version is basically the same except there is
no draw method and the update method does a bit more work, so all
you need is this:
function _init() sm:set_state('state 1') end function _update() sm:update() -- whatever other update stuff you need to do. end function _draw() cls() -- whatever draw stuff you need to do. end
The update method in this version also calls the transition
function. If a state change is necessary, then the current state's
teardown function is called, then the current state is changed,
and finally the new state's setup function is called.
A very basic state machine with two states. Press X/V to switch from state 1 to state 2, Z/C to switch from state 2 to state 1.
A simple platformer demo with 5 states: intro, tut_movement, tut_jump, play, and gameover.
I don't want to put your work down, but I must confess, I really can't see the Benefit of using a State-Machine especially on PICO-8. It looks "Over Engineered" in my Opinion.
Why not just using Global Variables like UPD and DRAW, and changes these Values on-the-fly? Like:
(Of course, on other Languages and Dev-Environments without such harsh Restrictions like PICO8, or with more Devs working on the same Project, it's a whole different story...)
@Astorek86 No worries, criticism is always welcome. Nothing wrong with having an opinion and I'll freely admit that over-engineering is a problem I'm prone to!
Mostly I was just playing around, made a thing and thought I'd post it in case anyone found it useful. Totally okay if nobody does. Heck, I might not find it useful a week from now. I have a habit of writing stuff like this and then completely forgetting it exists.
I think it's mostly just preference and habit more than anything. I was originally doing essentially what you suggest but having a whole bunch of similarly named functions just kinda...makes me twitch? I mean there's nothing wrong with it objectively speaking it just doesn't make my brain happy. I got around that by stuffing all the functions into a couple tables and then just indexing into them. But at that point you're most of the way to where I am with these implementations anyway and it's just a couple methods to handle the indexing and index switching automatically.
I do like the transition function being its own thing. I feel like it makes adding/removing/modifying states or changing which states transition to which other states easier. Having state changes mucked up into the update functions isn't a big deal for simple cases like the above demos but for something more complicated, removing an entire state (for instance) may or may not be an easy refactor while making sure not to break everything else going on in update. With the separate transition function, just change that and leave update alone and you're done. Easy! But, again, you don't actually need a state machine object to do that.
[Please log in to post a comment]