supervision of my first game(pong)

[hokuto]

Brot's excuse is that he's German (even though he's the only German I've know with so much bile to spread). Anyway...

There are several approaches to gamestates. But first let's define what we're talking about. When you're in the menu screen, you want to handle the menu; when you are in the game screen, you want to handle the game, etc. We then say that the game is in the menu screen, or in the game screen. Since the word "screen" is used for more things, a unique word that has been used for that purpose is "gamestate", so in this case there would be the "menu gamestate" and the "game gamestate".

I've seen some people call that "scenes", but a scene library is typically a different thing that implements a kind of graph, so it's not a very good word either.

The bottom line of gamestates is that they need to receive the Löve callbacks in order to handle them for their purpose: the menu needs to handle events in a way that makes the menu work, and same thing for the game. And of course there are several ways to implement them.

I've seen some people do it like this:

Code: Select all

local state = "menu"

function love.update(dt)
  if state == "menu" then
    menu:update(dt) -- call the update for menu
  elseif state == "game" then
    game:update(dt) -- call the update for game
  end
end
...

I consider that hard to maintain and inelegant, though, because every event needs to know about all states it supports, preventing modularization. A simpler and (IMO) better solution is to have the state be a variable that holds an object, and that object may or may not have the event:

Code: Select all

local state = menu

function love.update(dt)
  if state.update then -- check if the current state has an update method
    state:update(dt) -- call it if so
  end
end
...

That's the way I prefer to implement them. I also have a function to switch states; that function has the additional feature that it calls a method deactivate() in the gamestate you're leaving and a method activate() in the gamestate you're entering (again, if they exist), which allows initialization of the state, stopping sound when the state is finished, etc.

That's also pretty much what RNavega was trying to explain, except that I added the check that the method exists, because not all gamestates need all methods, and my convention for naming the enter/exit events is different.

Thanks for the advice, I am going to focus on studying the lua book to have an adequate knowledge of the language.

I should have listened to you from the beginning when you told me to ignore this guy but I like to give people a chance and I was wrong.

[hokuto]

Rude

I was trying to help in best faith.
But i have once again proven why i choose to put OOP users on ignore.

You are the only rude person in this forum. You only know how to criticize and make people dizzy and you don't teach anything.

And you have once again written something useless, which is useless neither to learn nor to contribute something to the community, the only thing you know how to do is write text to fill in an empty space.

You have not taught anything, neither in code nor in text. The only thing you have shown is a useless code and worse than the spaghetti code of the era of dinosaurs, that shows that you know almost nothing about programming, just know how to annoy. For my part I am not going to answer you anymore and I am not wasting any more time with an individual like you, until ever.

[Bigfoot71]

Wow, they harvest salt here. You shouldn't say that kind of thing. He showed you some great principles that may not be directly applicable using his code as is, but are explicit enough to be reproduced in real situations as long as you understand them. If you didn't understand where he was trying to take you, you can ask. He's pretty rough around the edges, but what he said is not without interest. Peace and löve <3