Sorry, the title is kind of misleading.. I'm already using hump.gamestates and it's working nicely so far. But I want to progam hmm states inside a gamestate. For example, let's say I wish to show 3 images as a kind of a comic telling a story before the playable character appears.
-- 'somegamestate' room (gamestate)
local somegamestate = Gamestate.new()
-- Love stuff
function somegamestate:enter()
-- Load assets
end -- somegamestate:new()
function somegamestate:draw()
intro:draw() -- comic showing a story
-- remove everything from intro:draw()
-- before drawing this..
start:draw()
end -- somegamestate:draw()
-- Additional stuff
function intro()
-- Show a story like a comic
love.graphics.circle('fill', W/2, H/2, 50)
end
function start()
-- game starts here
-- show character, map, enemies.. everythin
end
return somegamestate
At the most basic level it'd be a couple of ifs with a switch variable, and a trigger within each mini state that allows you to switch states by changing the variable.
There are many possible solutions. One other solution is to make the "sub-states" be full-fledged states, e.g. game, game2, game3, game4. There are also state libraries that handle the states as a stack, so you can suspend the current state while another one is executing, and resume it when that one finishes. You could perhaps make use of hump.timer's timer.script() function instead, but you need to understand its limitations in order to decide whether it fits your needs. Those are some that come to mind.
Handling them manually as suggested by lachlaan is probably the simplest solution, though.
@lachlaan, yup when you said switch I got and idea hope it works @pgimeno, I thought about full-fledged states too but dunno. Maybe I'll try to do something manually with switches.. if that doesn't work then 'sub-states' it is.
I wanted to add that the problem you're describing is a use case for some of the 'state machine' design patterns. Robert Nystrom's 'Game Programming Patterns' book has a chapter describing them.
Basically, conditionals and switch statements will solve a lot of problems, but turn into an absolute nightmare given a certain level of complexity. The 'state pattern' recommends taking all that logic and putting into classes representing each state and have some sort of 'state manager'.
Your use case, taken to an extreme where state logic has a lot of 'substates' might necessitate some sort of 'hierarchical state machine'. This website has some good examples/diagrams of what use cases are good for that.
Probably bringing these up is in the context of this simple question is a little overkill, but it's good to have some idea that these patterns exist earlier rather than later.
