For the Löve(2D) of Games

This has been an interesting one! For this project I got to explore not just Löve2D, but also how to build for a non-web platform, and publishing that code to Itch.io. I think the variety of things I got to explore have made this the most fun build so far. I found myself trying an idea and refactoring much more than anything previously. I also am writing this before I have finished this game, mostly because I want to put my thoughts about Löve to paper and because I think I can talk about the game itself in its own piece. So let’s dive in!

First off, I wanna talk about some complaints about Lua, the scripting language for Löve (i.e. what you build a game in). This might have to do with being an older language (it was originally released in 1993) and it being an “extension” language, but the fact that most Love tutorials have you copy-pasta dependencies into your codebase feels real bad. It is a practice that is counter to using version control. And the fact that lots of resources recommend it is wild to me. After some exploring, I was able to find some Lua dependency managers, LuaRocks & a Löve focused branch of LuaRocks called Crush. However, these didn’t work with the version of Lua that Löve uses on Windows, Lua 5.1. So if I wanted to use a dependency manager I would need to have two installations of Lua on my machine. Next I did some more googling to see if there was a Lua version of NVM and found some tools, but none of them looked super well supported.

After those letdowns, I decided to use something I was fairly comfortable with and landed on using git submodules for dependencies. Now lots of people have lots of feelings about submodules. But for this use case, and since this was a solo project, I saw no reason to not use them instead of having multiple Lua versions on my machines or committing a dependency to my codebase 😱.

Even with that initial shock about working in Löve, I was still down to dig in and see what I found. From my exploration, the third party libraries are all really good and the docs I’ve encountered are solid. There are def some gaps in docs, but generally they answer the questions you might have. However, I do think Löve could use a little SEO love (yes, pun intended) to help with searching for docs though. Often times, I would google a problem that I had and the top results were forum posts from mid 2010’s, with the Löve docs coming up as result #3 or later.

Let’s example something simple like changing the font color of text you want to print on screen. You might google something like love2d font color:

Results for how to change font color shouldn’t go back over a decade in time, especially because the APIs have changed

Even if your eye noticed the dates of those links and you went to the new reddit posts, you would still be presented with the same approach:

love.graphics.setColor(0, 0, 0, 1) -- Sets the color to black
love.graphics.print("Text to print", XCoord, YCoord) -- Prints text at some coordinates
love.graphics.setColor(1, 1, 1, 1) -- Sets color back to white so other stuff renders correctly

This changes the color used for all drawing done by Löve; writes the text you want to use; and then sets the global color back. That also means if you forget to change the color back everything your game draws just becomes black. However, there is a better way, which you can find in the docs:

-- This sets the color only for this print of text with the table
love.graphics.print({{0, 0, 0, 1}, "Colored Text"}, XCoord, YCoord)

Another complaint about the docs though is that they don’t expose that way of doing things well. For example, I can link to the page for love.graphics.print, but not to the specific section that tells you you can do that snippet I posted above. Most markdown systems used for software docs have the ability to link to specific parts of their own page. For example, Typescripts docs let me link exactly to this section about primitives. This is super helpful for people using the docs and it also makes search engines better. And when you have a language that overloads functions ‘tis much easier to dig into the print method to find all the method calls. So yeah, some SEO/markdown work feels like it could really help specific docs come up instead of very outdated forum posts (especially when those posts have suboptimal ways to do things).

All that being said, I actually really liked worked in Löve and get why people like it so much, ’tis currently #12 on itch.io’s list of most used game engines. Godot is the next engine I’m planning on looking into which is #3. But I chose to look at Löve first, because it seemed very similar to Pixi in how it is a code first engine. What I mean by that is it doesn’t have its own UI I would need to learn instead of just working in VSCode. And that is one less hurtle while learning the nuances of a new language. (Upon reflecting that hurtle might always have been a part of why I got scared away from Unity😅)

I feel like the amount that I quickly accomplished with Löve is a great display of how much I was enjoying working and learning this system. While I didn’t really talk too much about the game here, I am currently working on building a small 10–15 min RPG. This was something much bigger than all my previous games and required creating a build system using Github Actions and learning other new tools like Tiled to create maps. Shoutout again to Challacade for the amazing jumping points and well done tutorials and open source code. Learning how to organize and structure stuff in Lua/Löve was super helpful from their source.

Check out the current build of the game here and the code here (which includes the build work here) and hopefully I’ll have a write up about the whole game soon!