LÖVE

Hi!

I'm wanting to replace the very basic gamestate system I've been using so far with stateful.lua. Because it looks really good, NIH is bad, why should I program my game when others can do it for me, etc.

Currently when the player dies I switch to my game over state, passing the player's score as a parameter. This calls the "entered_state" callback of the game over state with the score as a parameter so that it knows what score to display on screen. I see that HUMP gamestate allows me to do this too, but I couldn't see whether it was possible with stateful.lua. Is it? Is there an alternative way of achieving the same result?

Thanks.

Hi there!

Passing parameters to the callback methods (enteredState, exitedState, etc) is not possible. But there are several ways to accomplish what you want (setting a score in the "play" state and showing it on the "gameOver" state).

• You can use a member variable on any object that "lives" in both states - if you have a Score object, you can keep it alive until the main menu is shown, for example. You can also use the game object itself. It's totally ok to add member attributes to it on certain states and use it on others. Just do game.highScore = 1000 . And then get that score doing game.highScore (or self.highScore if you are inside the game object). This is the option I recommend.
• You can set up a global variable. I think the other option is better.

Let me know if you need more help.

Thanks for the reply. That works perfectly.

So if member variables are shared between all states, I just need to be careful that unrelated variables specific for different states don't share the same name? (I'd get away with it when the states owning these variables will never be in the stack at the same time, but it's probably better not to risk that and just choose different names.)

15jamie20 wrote:Thanks for the reply. That works perfectly.

So if member variables are shared between all states, I just need to be careful that unrelated variables specific for different states don't share the same name?

Correct.

What I usually do is using the enterState and exitState methods to initialize/destroy the member variables that are specific for that state. But if I need too many of those, I prefer moving the state to its own file and creating as many "members" as I need as local variables in that new file.

For an example of the first case, see Battle Cry's MainMenu state: the self.menu member variable is created on enter, and destroyed on exit. But I could have destroyed it in another state as well.

For an example of the second case, see Battle Cry's Play state. The local variables map and player are used as "members" of the state, although they are never "attached" to the Game object.

Regards, and good luck!