Best practices and things you'd like changed about Love2D

General discussion about LÖVE, Lua, game development, puns, and unicorns.
User avatar
milon
Party member
Posts: 472
Joined: Thu Jan 18, 2018 9:14 pm

Best practices and things you'd like changed about Love2D

Post by milon »

grump wrote: Wed May 26, 2021 5:07 pm ...
Keycodes being the first argument in keyboard events comes right after love.load on the list of things that should be burned at the stake.
This seems off-topic enough to warrant its own thread. I almost sent this as a private message, but then I thought I might not be the only one with this question.

I'm not looking exclusively for a response from grump (although I really do want to hear from him/her), so everyone feel free to chime in with any insights here.

The keycodes comment I understand - there are multiple keyboard layouts and assuming only 1 is highly problematic.

Please tell me more about your issue with love.load. I'm a self-taught novice, and don't have all the best-practice knowledge that others may take for granted. Also, are there other best-practice pieces of wisdom you'd like to share?
Any code samples/ideas by me should be considered Public Domain (no attribution needed) license unless otherwise stated.
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Best practices and things you'd like changed about Love2D

Post by grump »

milon wrote: Tue Jun 01, 2021 2:18 pm Please tell me more about your issue with love.load.
Sure.

love.load is a constant source of confusion for newbies, and encourages them to make bad decisions.

love.load has no real purpose. Everything you do in love.load you can do at the top level of main.lua instead.

love.load looks like you should use it for resource initialization. Which would be fine, if it wasn't for the temptation to make all your resources global out of convenience. Doing it right is more work and requires a deeper understanding of scope if you use love.load: You have to declare your locals in the parent scope before you initialize them in love.load, or they end up being global. You can just as well initialize them in the parent scope, ignore love.load, write less code that has fewer bugs, and still get the same results.

love.load is thought of as a magic "restart game" mechanism by some people: just call love.load and your game restarts. This can and will end badly, because calling love.load does not reset global state, and it's not meant to be called manually.

The only thing that love.load really does is give you a local copy of (or reference to, I don't remember) the command line arguments. But you can access those through the global arg just as well from anywhere you need them (which is also not the best design decision, and probably a remnant from the early days).

I'm not a huge fan of love.load.
User avatar
milon
Party member
Posts: 472
Joined: Thu Jan 18, 2018 9:14 pm

Re: Best practices and things you'd like changed about Love2D

Post by milon »

Thanks!!
Any code samples/ideas by me should be considered Public Domain (no attribution needed) license unless otherwise stated.
User avatar
ReFreezed
Party member
Posts: 612
Joined: Sun Oct 25, 2015 11:32 pm
Location: Sweden
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by ReFreezed »

grump wrote: Tue Jun 01, 2021 3:21 pm love.load has no real purpose. Everything you do in love.load you can do at the top level of main.lua instead.
Maybe what should actually happen is for LÖVE to remove main.lua since all you need is a conf.lua file. In this case it makes a lot of sense to have love.load as that would be the first place where you have access to all the loaded LÖVE modules, like love.graphics (unless you define love.run).
Tools: Hot Particles, LuaPreprocess, InputField, (more) Games: Momento Temporis
"If each mistake being made is a new one, then progress is being made."
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Best practices and things you'd like changed about Love2D

Post by grump »

ReFreezed wrote: Wed Jun 02, 2021 8:57 am as that would be the first place where you have access to all the loaded LÖVE modules
I wouldn't want the way main.lua works changed, but using love.load in conf.lua as a kind of post-initialization configuration point would indeed be a legitimate use case. Though it isn't usable as such, because it's called after main.lua loads.

The example on the wiki actually teaches you the worst and most unnecessary way to use love.load. Write more code to solve a problem that doesn't exist, to get worse results, smh.
Last edited by grump on Wed Jun 02, 2021 10:05 am, edited 1 time in total.
User avatar
4vZEROv
Party member
Posts: 126
Joined: Wed Jan 02, 2019 8:44 pm

Re: Best practices and things you'd like changed about Love2D

Post by 4vZEROv »

I had a bit of the same thoughts about love.update, love.draw and all the love callbacks.
As a beginner you don't really know when they are called, why there is a dt, why you can only draw stuff on love.draw etc..

The major problem imo is that love.run is too much hidden .
User avatar
Xii
Party member
Posts: 137
Joined: Thu Aug 13, 2020 9:09 pm
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by Xii »

LÖVE feels less like a framework for gamedev and more like a Lua wrapper for SDL. Which is fine, but it means that simple things you'd want to do are frequently implemented in weird, obtuse mechanisms.

The documentation gives the false impression that everything is simple and easy. But all of the presented examples are basically the wrong way of doing things. E.g. drawing a sprite is the first thing anyone would want to do; Having each sprite as its own image as per the examples has abysmal performance. So you need sprite atlases. But while the library is capable of drawing those, it offers no convenience functions for actually doing so.

Or reading player input: There's no function to check if a key has been pressed down in the current update frame. You have to capture all such events using the love.keypressed callback, construct your own table of keys that have been pressed, check that and of course also remember to clear it.

So what seemed like a simple library for making games, ends up being a bare-bones media library on top of which you have to write your own framework to accomplish the simplest of things.
User avatar
Gunroar:Cannon()
Party member
Posts: 1085
Joined: Thu Dec 10, 2020 1:57 am

Re: Best practices and things you'd like changed about Love2D

Post by Gunroar:Cannon() »

Xii wrote: Fri Jun 04, 2021 6:37 pm Or reading player input: There's no function to check if a key has been pressed down in the current update frame. You have to capture all such events using the love.keypressed callback, construct your own table of keys that have been pressed, check that and of course also remember to clear it.
How about love.keyboard.isDown(key)? Or am I wrong?
Xii wrote: Fri Jun 04, 2021 6:37 pm So what seemed like a simple library for making games, ends up being a bare-bones media library on top of which you have to write your own framework to accomplish the simplest of things.
Haha :rofl: I agree, but luckily they're alot of libraries though :ultrahappy:
The risk I took was calculated,
but man, am I bad at math.

-How to be saved and born again :huh:
User avatar
Xii
Party member
Posts: 137
Joined: Thu Aug 13, 2020 9:09 pm
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by Xii »

Gunroar:Cannon() wrote: Fri Jun 04, 2021 7:43 pm How about love.keyboard.isDown(key)? Or am I wrong?
That doesn't tell you the key was pressed right now. It just tells you the key was pressed sometime in the past and is still held down. It will be true for every frame until the key is released, not just the first frame after it has been pressed.
User avatar
pgimeno
Party member
Posts: 3544
Joined: Sun Oct 18, 2015 2:58 pm

Re: Best practices and things you'd like changed about Love2D

Post by pgimeno »

Edit: never mind
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 66 guests