If statement and Goto

[Bowlman]

Im new with Love2d, and I have just tried it out for few days. I have some coding experiences from the past. More of the basic kind Id say. I feel like Love2d is pretty cool and could be something long run for me. I just need to get hang of things. So. Now I try to get the idea about Gotos and Ifs. Gotos are just way to jump from here to there. Thats how Im use to think about some of the logic. Like when the game is over and you need to goto start and start all over. Zeroing variables, reload the level etc. But thats not how it works here I guess? I got the goto to work, but only inside functions. So how should I think about it? I have tried to look all kind of tutorials I could find. But some times they are not very clear =(.

Other thing people seems to say that you suppost to avoid "if" statements. Like if state = 1 then do all these things, then when its 2 then you do this other things. There seems to be some state of stateful thing I think I suppost to use, but I just dont get it. I try to make small game and learn basics. I want to learn all the good habbits from the start. Or more like how to think code. How to think alot of small things tied together. Also I feel like there is not very good and clear tutorials about Love2d. There are some, but from those, I find that only few are okey-ish. And they seems to just go really basics. Id love to hear tips from good tutorials and guides. I think Love2d is great and I like it so far. I just want to learn some more and see what I can do about it. Thanks.

[pgimeno]

'goto' is certainly not a good method for accomplishing what you're trying to do, and not just because it's limited to functions, but because Löve is not designed to work that way. 'if' statements are generally OK. If you mean them as a way of choosing what screen to send events to, they are not the ideal solution, but if they are the best you can think of, go with them until you're more comfortable with the language and can use alternatives.

The rough idea of Löve is: it's running a continuous loop, one iteration per frame. Rather than forcing things to happen, like "go to the end of game section", you wait for things to happen, like, "set the end of game flag and wait for it to be detected by the code that deals with it, maybe in the next iteration (frame)". Game logic usually goes in the love.update event, which always happens right before love.draw. Drawing code goes in love.draw. You may need to process more events.

[darkfrei]

Like when the game is over and you need to goto start and start all over. Zeroing variables, reload the level etc. But thats not how it works here I guess?

Code: Select all

if game_over then restart_game () end

Where you reset all values.

(Deleted bad code)

[grump]

You can actually run the love.load() again.

Code: Select all

if game_over then 
  love.load ()
  return -- exit from love.update to start it from the begin.
end

Sure you can do that. But setting aside all the global state that may break in subtle (or hopefully not so subtle) ways, your game's main loop now goes draw -> update instead of update -> draw.

A simple but ugly way to reset your game is to restart it from scratch:

Code: Select all

return love.event.quit('restart')

Unless you know what you're doing and have written your code in a way that allows a controlled reset to its initial state, this is the easiest and safest way to reset. It's also the ugliest and slowest way to do it.

[Bowlman]

Its not about restart the whole program. Maybe you want to just restart the level. And not jump all the way to the main menu. Variables could be always zeroed out. Now Im thinking flags, but I think Im heading in wrong direction here. Now I have tons of flags and state variables on my practice project. Its really confusing and ugly. Its working, its logical, but I think there must be more clear way.

I understand what pgimeno said. At least I think so. Now I just need to make it from theory to reality. I have made some progress to learn all the commands too. One by one. I mean ofc I have still long way to go, even with the basics, but I think I had a start at least. Interesting stuff.

[RNavega]

How much have you read on software programming patterns? Specifically the state pattern, it's very cool: https://gameprogrammingpatterns.com/state.html

As I understand it, you're encapsulating logic into separate objects, and at one given moment only one of those objects is controlling the game (both in update and in drawing).
So a menu screen is one game state, a level is another game state etc. Each state has the code to switch to other states, that's how you can go from the menu screen to the first level.

To implement states you need to decide on a common interface, a format that you decided to use for all state objects. Say, all state objects should have a 'load' attribute that points to a function that both loads assets (art, audio) that the state will need, and replaces the current update function and the drawing function with the ones from the state so it can take over handling the game.

With Lua this is done easily since you can store a function in a variable, and execute that function without knowing what it is, something like...

Code: Select all

currentState.load()

So if you want to restart a level, make this (re)loading as a separate state, like "loadLevel1State", and transition to that state. Inside the update code of that state you can reset all variables you want, load assets (if not already loaded) and transition to the next state, "playLevel1State" that runs the level.
So this "loadLevel1State" just runs for a single frame since it does simple things, and switches to the play level state right then without any user action needed.

It's in the "playLevel1State" that things happen and the game runs. Within the "playLevel1State" update function you need to run the game and react to user input, like if the player hits escape, transition back to the menu state (or rather, the menu 'loading' state that loads its assets if needed and resets variables, and then transitions to the menu playing state).

[pgimeno]

You can actually run the love.load() again.

Code: Select all

if game_over then 
  love.load ()
  return -- exit from love.update to start it from the begin.
end

That's a horrible hack, and awful advice to give to a newbie. Events should never be directly called by user code; a framework's philosophy is "don't call us, we'll call you". It is actually unlikely to need to initialize everything from scratch in most situations (e.g. you don't need to reload every image). And if you run into the unlikely case where you really need to do that, you can move the initialization code to a function, and call it as appropriate, like this:

Code: Select all

local function init()
  -- do your initialization here
end

function love.load()
  init()
end

...

if game_over then
  init()
  return
end

This case can more easily be accomplished with a start_game() function, that only initializes everything that needs to be at the starting positions. E.g. it moves the player to the start position, sets the score to zero, resets all enemies, sets the level to the first level, that kind of stuff. It doesn't need to reload all images and sounds, for example.

[Xii]

That's a horrible hack, and awful advice to give to a newbie. Events should never be directly called by user code;

What? Why? The wiki does not support your assertion; love.load() has no warnings about calling it from user code. It's not a hack, it's a simple function that you define, and you can call it normally like any other Lua function. The framework will call it once, but there's no problem calling it yourself again.

[pgimeno]

Of course it's practically possible and nothing stops you from doing it, but still a hack, because it's not how it was designed to be used. It's not a good way to structure a program, to depend on love.load being callable at any time by user code, being that it's designed to be called once at program start, i.e. mostly for the loading of resources. Using something for a purpose that it was not designed for, is inelegant, i.e. it is pretty much the definition of a hack.

I know of one language, LSL, that doesn't support calling events from user code; event names are keywords, not usable as identifiers. This kind of hack wouldn't be usable in LSL.

Furthermore, giving that advice to a novice, implying that doing it would make the code restart, is highly misguiding.

[Xii]

it's not how it was designed to be used.

Citation needed.