Best practices and things you'd like changed about Love2D

[milon]

...
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?

[grump]

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.

[milon]

Thanks!!

[ReFreezed]

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).

[grump]

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.

[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 .

[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.

[Gunroar:Cannon()]

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?

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 I agree, but luckily they're alot of libraries though

[Xii]

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.

[pgimeno]

Edit: never mind