stateful.lua

[kikito]

(Good stuff)

That doesn't implement all stateful, but it's more than enough for Game state management, I think. Well done!

I don't really get how my game structure (update,load,draw) fits into the game.lua. Those are just functions.

Well, the idea is that you initially create a (possibly global) variable called game inside love.load:

Code: Select all

require 'middleclass'
Stateful = require 'Stateful'
require 'game'

function love.load()
  game = Game:new()
  game:gotoState("MainMenu")
end

Then the rest of the usual functions can just "depend" on game - like this:

Code: Select all

function love.draw()
  game:draw()
end

functino love.update(dt)
  game:update(dt)
end

Then, game "controls" what to do and what to draw. Inside the MainMenu state, there will probably be something like this:

Code: Select all

function MainMenu:startButtonPressed()
  self:gotoState('Play')
end

That line will automatically call Game.states.MainMenu:exitedState() and Game.states.Play:enteredState(), and set the new state to "Play". Then Play can define its own update, & draw etc.

Notice also that the way I pictured here is not the only possible one. You might, for example, need to add more "updates" inside love.update. Or maybe you might not want to use the game inside love.draw. Or maybe you will also want to use it inside love.keypress. It all depends on how you want to structure your game.

[Jack5500]

Thanks for the explaination. You, sir, are the god of all explaining. One question is left for me tho: Does the Menu:enteredState() equal the love.load(), just for this state?

[kikito]

Thanks for the explaination. You, sir, are the god of all explaining.

Thanks

One question is left for me tho: Does the Menu:enteredState() equal the love.load(), just for this state?

It's very similar, yes. The difference is that love.load is called only once, when the game starts. <statename>:enteredState() is called automatically every time that state is entered, which can be more than once (every time you displayed the menu, or started a game, for example).

[Ellohir]

I see huge amounts of benefits from using middleclass and this library. I also see huge amounts of refactoring in my future xD

[Jack5500]

I used yesterday completly implementing stateful and it's absolutly awesome. It made my lua coding more clear and structurized. But I have another question:

I'm having a setup for the level AND the player in the same "play" state right now. But I'd like to make the setup for the level external in another state. That would require the play state (player, bg, etc) to run and within this state another state like level01. Is that possible and if it is, how would I do that?

Thanks for your amazing work again

[c00ld00d]

Hello, I'm very new to LOVE2D and I have absolutely no idea how to start in making th main menu. I already made the base of my game, it's a platformer and has 5 levels. I have your middleclass.lua and stateful.lua, and made a game.lua according to a wiki. But I still have no idea how to create a button or change the background in the menu. Any help? I can show you all the code if you can help.

Thanks in advance!

[kikito]

Hi there!

Middleclass and/or stateful don't really provide a way to create buttons - they are "logical" stuff, not "graphical".

Menus and buttons appear simple to do, but they can be very complex to do if you want all the bells and whistles - for example a fade-in/fade-out color when the mouse hovers in/out the buttons, how the spacing works, etc.

There are some libs out there to simplify this. I'll try to prepare a simple example in some hours.

[MarekkPie]

I recommend Gwee. It's simple, comes with a nice tutorial, and has documentation with the download.

[kikito]

Hi there,

Finally I didn't use any external libs; creating a very basic lib for menus only was easy enough so I created my own.

You may find the .love file attached in the OP.

The file that draws and manages the menus is lib/menu.lua . You can see examples of how to use it in gamestates/main_menu.lua and gamestates/options_menu.lua .

I've also included several states on several files, to illustrate how the states can be organized. Brief explanation:

• The loading state doesn't do anything! It just shows a countdown, but doesn't load files at all. I just put it there to remind that a loading state is sometimes useful.
• Notice how each game state implements draw, keypress, mousepress, etc independendly, although there are values by default to each of those methods in game.lua .
• I believe I didn't need to use game:update() in any of the states, but it's so important that I have left it there in the demo.
• OptionsMenu is a substate of MainMenu. As a consequence, I can reuse some of the functions of MainMenu without having to write them (for example, the draw() method is inherited).
• Notice that the NotImplemented state is inserted with pushState instead of with gotoState. This way I can "go back" to the previous state by simply using self:popState(), without having to "remember" the previous state.

Quiz: the demo as a bug on the NotImplemented state. Can anyone guess it?

I noticed a couple of (very minor) bugs on stateful.lua while doing this demo. I fixed them for the demo, but I haven't updated them on the github repo yet. Will do it either today or tomorrow.

[TechnoCat]

I noticed a couple of (very minor) bugs on stateful.lua while doing this demo. I fixed them for the demo, but I haven't updated them on the github repo yet. Will do it either today or tomorrow.