LÖVE

rokit boy wrote:I learnt how to use slither and I use it for every project I make from now on. I just find it hard to use that class system and making other projects with slither.

I don't think I understand you. How does your comment relate with Stateful?

Anyway to the topic.

I am making a platformer and I basically set a couple of booleans for collisions (AABB of course) and how would I go about checking the state every step and making him stay on the platform (I know the how to stay on the platform, I don't know about the states.)?

AND, what is the most efficent way of making a menu with this?

First of all, don't double-post. That's bad etiquette on this forum. Instead, edit your previous post if you need to.

rokit boy wrote:Anyway to the topic.

I am making a platformer and I basically set a couple of booleans for collisions (AABB of course) and how would I go about checking the state every step and making him stay on the platform (I know the how to stay on the platform, I don't know about the states.)?

The short answer is that it depends on how you are doing your platform tests. Why do you need more than one boolean? One should be enough: isInground - true or false.

Assuming that you only have one boolean, the simplest way of doing it involves two states: "OnAir" and "OnGround". Both of them would have, at the very least, one update() method, called on every game iteration (on every love.update).

When OnAir, update will check whether ground is near the player's feet. If it is, then the state should be changed to OnGround, and update should be called again. Otherwise, behave like on the air.

When OnGround, update will check wether ground is near the player's feet, too. If it is *not*, then the state should be changed to OnAir, and update should be called again. Otherwise, move like moving on the ground.

The "areFeetTouchingGround()" method would usually be the same in both cases, so it's worth considering putting it in some common place, not copy-pasting it.

Finally, if you do this properly, you can use the same states on enemies in addition to the player. Just create a "WalkingCreature" class, superclass of Player and Enemy.

rokit boy wrote:AND, what is the most efficent way of making a menu with this?

You can see an example on the first page of this thread.

Thanks!

If a State also implements 'update', 'draw', ... does this state overrides the

* Game:update
* Game:draw
* Game:keypressed
* ...

functions in 'game' class?

How I can fix this, that it's also called? An option is to put it directly into main.lua 'update', 'draw', ... but I really want to have this clean.

SiENcE wrote:If a State also implements 'update', 'draw', ... does this state overrides the

* Game:update
* Game:draw
* Game:keypressed
* ...

If the state is a State of Game, then yes, it overrides.

SiENcE wrote: How I can fix this, that it's also called? An option is to put it directly into main.lua 'update', 'draw', ... but I really want to have this clean.

"fix" might not be the right word there. You might be trying to make a solution work when a simpler solution is possible. But I can't know for sure with so little data. In general, the whole point of states is overriding methods in the "base" class. The fact that you want to use states and and the same time not override them suggest that you are doing something wrong, or that you have at least some misconception.

In any case, to make this particular scenario work, you could rename your Game:draw to something else (like Game:baseDraw) and call that function from your state:draw() method. But as I said, probably that's not the cleanest solution; you should add a state when you *want* to override methods.

thx kikito.

Let me explain. My game.lua should handle scaling, sound, global keypresses aso.

Therefore I need to call:

in Game:update(dt)
TEsound.cleanup()

and Game:draw()
TLfres.transform()

Your last suggestion by renaming the functions in Game and call them from main.lua works. It's not very nice as you said, but should work. I thought there is a way to call the basemethod.

Take your sample "stateful.demo.love". In Game:keypressed you assigned a key 'escape' to globally exit. But when you want to handle keyboard input in MainMenu too, you need to define MainMenu:keypressed. But this overrides Game:keypressed and you would not want to define the 'escape' key again in MainMenu:keypressed (and all other states).

You can also do the opposite:

In Game, create a function called baseDraw that calls TESound + whatever else you need, and then calls self:draw(). From main.lua, never use Game:draw() - use Game:baseDraw() instead.

Then, on the state, override draw() to do the specifics of each state.

This should be clean and will have less repetition. (Probably).

Good idea. Thx.

Do I still need to define the following in game.lua ?
Otherwise I get nil for self:update or self:draw when calling this in baseDraw, baseUpdate.