Page 2 of 4
Re: FSM - Finite State Machine
Posted: Sat Nov 19, 2011 7:46 pm
by 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
Re: FSM - Finite State Machine
Posted: Sat Nov 19, 2011 8:05 pm
by TechnoCat
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.
Re: FSM - Finite State Machine
Posted: Sun Nov 20, 2011 9:57 am
by coffee
TechnoCat wrote:
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")
Re: FSM - Finite State Machine
Posted: Sun Nov 20, 2011 5:44 pm
by TechnoCat
coffee wrote: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.
Re: FSM - Finite State Machine
Posted: Sun Nov 20, 2011 6:17 pm
by coffee
TechnoCat wrote:
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.
Re: FSM - Finite State Machine
Posted: Sun Nov 20, 2011 9:54 pm
by 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.
coffee wrote: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.
Re: FSM - Finite State Machine
Posted: Mon Nov 21, 2011 2:03 am
by coffee
Robin wrote:I don't think TechnoCat was offended, in fact I think he was encouraging you.
Subtleties in meaning are often lost over the internet.
coffee wrote: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.
Re: FSM - Finite State Machine
Posted: Sat Nov 26, 2011 7:18 am
by 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.
Re: FSM - Finite State Machine
Posted: Sat Nov 26, 2011 4:35 pm
by 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.
Re: FSM - Finite State Machine
Posted: Sat Nov 26, 2011 5:17 pm
by 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.