FSM - Finite State Machine

[vrld]

... which is essentially what hump.gamestate does

Code: Select all

GS = require 'hump.gamestate'

local states = {}

states.intro = GS.new()
function states.intro:draw()
    love.graphics.print("INTRO!", 0,0)
end
function states.intro:keypressed(key)
    if key == " " then GS.switch(states.select) end
end

states.select = GS.new()
function states.select:draw()
    love.graphics.print("SELECT!", 0,0)
end

function love.load()
    GS.registerEvents()
    GS.switch(states.intro)
end

[TechnoCat]

... which is essentially what hump.gamestate does

Right, and I'm all for using a library to do gamestate. I personally use Kikito's stateful.
But I couldn't let Coffee's switch statement slide.

[coffee]

... which is essentially what hump.gamestate does

Right, and I'm all for using a library to do gamestate. I personally use Kikito's stateful.
But I couldn't let Coffee's switch statement slide.

I'm sure that for you medium or advanced coders use others people libraries is simpler and actually you all understand each line of code. But for me, a noobie coder when starting implementing kind others genial but kind of "esoteric" libraries that I totally don't understand are too much for my very poor coding skills. And that defeats the purpose of learning step-by-step and don't give big steps in the unknown right? I'm well aware that my switch isn't good code at all but at least was simple enough and understandable.

Robin's suggestion was actually useful and pointed me a good way for improve my code. I like too the cleverness of your suggestion TechnoCat but I feel actually the way you declare each state isn't my coding style to pursuit when doing later improvements (however it's better code than my switch of course). And well VRLD suggestion is now out of my league or as I said "ruins" learning things step-by-step. Thank you all for the suggestions, not a priority but I will later recombine them to make my "own" erm "library" (without "Switchnitis")

[TechnoCat]

I'm sure that for you medium or advanced coders use others people libraries is simpler and actually you all understand each line of code. But for me, a noobie coder when starting implementing kind others genial but kind of "esoteric" libraries that I totally don't understand are too much for my very poor coding skills. And that defeats the purpose of learning step-by-step and don't give big steps in the unknown right? I'm well aware that my switch isn't good code at all but at least was simple enough and understandable.

Robin's suggestion was actually useful and pointed me a good way for improve my code. I like too the cleverness of your suggestion TechnoCat but I feel actually the way you declare each state isn't my coding style to pursuit when doing later improvements (however it's better code than my switch of course). And well VRLD suggestion is now out of my league or as I said "ruins" learning things step-by-step. Thank you all for the suggestions, not a priority but I will later recombine them to make my "own" erm "library" (without "Switchnitis")

Right. By all means code how you want to code. Learn how you want to learn.

[coffee]

Right. By all means code how you want to code. Learn how you want to learn.

You seem like offended by my words. Don't be please, was not intented. When I said that I didn't "liked your style" is because instead of do something like you point for each state

Code: Select all

    introState = {
        draw = function() love.graphics.print("INTRO!!",0,0) end,
        update = function(dt) end,
        keypressed = function(key) if key == " " then current_state = "selectState" end end },

I feel that is more my "style" reach a solution like
states = { "Intro", "Play", "Help" and so on}
and then auto-redirect to drawIntro() and updateIntro(), drawPlay() and updatePlay() by somehow join "desirable method" + "name of state"(). I'm sure there should be a way to do it right? Don't worry I'm dumb but I will get there.

[Robin]

I don't think TechnoCat was offended, in fact I think he was encouraging you.

Subtleties in meaning are often lost over the internet.

and then auto-redirect to drawIntro() and updateIntro(), drawPlay() and updatePlay() by somehow join "desirable method" + "name of state"(). I'm sure there should be a way to do it right? Don't worry I'm dumb but I will get there.

Maybe you could have two tables: draw and update or something. Then you would have draw.intro(), update.play(), etc. It's largely a matter of taste.

[coffee]

I don't think TechnoCat was offended, in fact I think he was encouraging you.

Subtleties in meaning are often lost over the internet.

and then auto-redirect to drawIntro() and updateIntro(), drawPlay() and updatePlay() by somehow join "desirable method" + "name of state"(). I'm sure there should be a way to do it right? Don't worry I'm dumb but I will get there.

Maybe you could have two tables: draw and update or something. Then you would have draw.intro(), update.play(), etc. It's largely a matter of taste.

Yah, by his comment and tone I had the feeling that I was hurting TC but we already talked. We are cool I guess.

Yes, by your method there could be solved by the 2 distinct tables instead of use one. But when I saw your suggestion I got the feeling that you were too close to touch a minimalistic perfection "one table for all". I believe that with more study I will get there and explain where I wanted to reach, for what I checked today about string/saving manipulation there's still a lot I must learn to unleash Lua.

[tsturzl]

This is kind of what I do

Code: Select all

game={state="title"}
function game:setState(state)
   if state=="title" and title.isInit then
       self.state="title"
   else
       title:init()
   end
   if state=="play" and player.isInit then
      self.state="play"
   else
      player:init()
end
function game:update(dt)
   if self.state=="title" then
      title:update(dt)
   elseif self.state=="play" then
      player:update(dt)
   end
end
function game:draw()
   if self.state=="title" then
      title:draw()
   elseif self.state=="play" then
      player:draw()
   end
end
function love.update(dt)
   game:update(dt)
end
function love.draw(dt)
   game:draw
end

title and player are table's obviously, and your title screen can call game:setState() to change states to play the game. You can also easily modify game:setState() to destroy the previously initialized objects if you don't want the states to be persistent.

[Robin]

That method will grow unwieldy soon when you want to add new states. I suggest keeping all states in a single global table, then you get definitions as simple as:

Code: Select all

function game:update(dt)
   states[self.state]:update(dt)
end

Much less duplication of code.

[coffee]

well tsturzl, a bit massive even with only 2 states introduced. Actually you end doing the kind of if/elseif chain as I did. Till now Robin's code imho is the most compact and probably the best one.