I’m a few modules/projects into the two game development courses I’ve started, and I’ve noted a few things about Love2D which I’m turning into a blog post to get them out of my head.
The initial game development assignments have been based around taking various classic games recreated in Love2D and adding features to them.
The games have included Pong, Flappy Bird, Breakout, Match 3, and Super Mario. Through these projects they’ve introduced pausing, menu screens, FPS information on screen, basic graphics and sound, animations, saving high scores, tilesets, etc.
If I were to use Love2D regularly for prototyping, what would a good boilerplate project look like?
This question arose because initially the course teaches you in a way that introduces what I would consider to be bad practices, like all files in one folder, everything in one file, and so on. So my immediate thought was, “what would a ‘professional’ Love2D look like?”
If I’d had some patience I’d have soon found that subsequent projects started to answer some of those anyway, by separating out constants, dependencies, etc, into separate files. Creating folders for assets, game/entity states, etc. I should have realised it was teaching us bad approaches first so we could see how unmaintainable it would be for larger projects, then teaching us the better way. But any seasoned developer would have immediately shuddered at the initial projects.
I’m not quite done with the Love2D assignments so there may still be more to come, but I do want to try and define a common starting point for any prototype I want to make in Love2D. This might include:
- Auto complete – This would be useful – I’ve found Lua Language Server extension by sumneko seems to give this and more, including code warnings.
- Showing warnings – But, adding the above will result in various warnings showing in your “Problems” tab from all files in the project, including those in the lib folder, which is usually vendor libraries that you don’t really need to know about. Adding this to ,vscode/settings.json, helps with this:
{
"files.exclude": {
"**/lib": true
},
}
Which hides lib from your file explorer panel and also hides them from the problems list. But you may want to then add the “Toggle Excluded Files” extension to toggle visibility in the file explorer panel as needed.
- Debugging – Being able to debug and step through Love2D/Lua projects is very useful. The accepted answer on that stack overflow page worked for me. This page also gives details on debugging in Love2D/Lua.
- Unit testing – There have been times where I wrote code that I’d love to have written a unit test for. Anything involving randomisation, converting grid coordinates to pixel coordinates etc. Anything that includes logic/conditions. I need to investigate this further!
- Dependency management -Rather than manually copying libraries like knife, or Push, have them managed through a dependency list, like nuget/npm, would. I’ve found “Crush”, but perhaps there’s a better option?
- Clean project structure – is there a common folder/file structure for Love2D games?
- Code style – Is there a Lua code style that is recognised as the defacto standard? Roblox has a LUA code style guide – does that translate well to Love2D development?
- Common functionality – Creating common code like main.lua, game states, utility functions, to support toggling debug info, controlling the volume of music/sound effects, building in at least bare mininum accessibility options, save mechanics, etc.
I’m sure I will find more libraries alongside Knife, and Push, that make game development easier, perhaps upcoming assignments may introduce me to more of them. So this list will likely evolve over time, and hopefully I’ll have an answer to what a good Love2D project should look like. My final project for the game development course is to make a game from scratch that is at least complex as the games we’ve been introduced to. It’s possible my final project will be a game written in Love2D, so the ideas above may get answered in my initial work on that, but there’s a big difference between what would be acceptable as a final project submission vs a publicly releasible game.

No responses yet