I really like it, the developer experience is so smooth for beginners, just drag a zip onto the exe and it starts. And the APIs are simple enough to memorize while allowing pretty cool rendering stuff.
I once checked if the odds stated on a card were implemented wrong. Turns out no, the code checks out, I'm just that unlucky.
https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/ba...
I wrote half a blog post when I did the derivation. One day, I should finish it and post it here.
Moonring[1] is another one that that is written in Löve (apparently by the co-creator of XBox's Fable series). The base game is even available for free. I had lots of fun playing it.
Rinse and repeat over months, with volunteers, in a game engine no less, and I can easily see many projects being unable to not fall into that trap.
Anyways, I think it's less of an issue for people in practicality, most people who use LÖVE today tends to start with the HEAD source version, which also sets them up to easier contribute back upstream, when they inevitably hit something non-optimal, so maybe it works out in favor for everyone in the end anyways.
Right now I have a workflow breaking bug in Inkscape which was fixed last year on main but hasn’t made it to a release yet. So my only option is to compile from source.
There being a stigma about a release being “ready” needs to go. Stuff should get only get merged in to main when it’s ready to go live, or behind a feature flag.
How? has Lua changed any?
Or all the references are to old versions?
[1]: https://projecthawkthorne.com/
It is now available to play straight in the browser(I guess using LÖVE Web Builder?).
[1]:https://schellingb.github.io/LoveWebBuilder/
This engine has really come a long way and enabled such a memorable game for me.
(My personal pet peeve is that Kodi still doesn't know how to minimize CPU consumption when one is doing nothing on the UI. It should just stop rendering. This means I have to turn Kodi off on my HTPC+server setup to stop it from pushing my CPU in a higher power consumption mode.)
My custom media center is basically just a glorified 10ft-UI file browser. Opens media files in mpv (with some extra GUI to download subtitles and select audio tracks), Wii games in Dolphin, runs shell scripts (I have ones launch Steam Link etc.)
I realize that this might be a case of "simplify by limiting use cases" but I made it for me so it's fine.
Maybe because you can fit the whole language spec on a single sheet of paper and adding more advanced features is pretty easy.
Love looks really cool. I never got into it personally but I still might
Thanks for the tip. That should make for a fun weekend
“It makes more sense this way” is not a good enough reason to break convention.
For me, the table is extremely powerful. I like it that it can be used as a sparse array, a hash, a vector, whatever. Of course one must know, at heart, the difference between pairs() and ipairs() and what it means for your data, though ..
So, as someone only very peripherally familiar with Lua, can someone please explain the table thing to me? I've heard Lua fans gush that Lua is tables all the way down, except it seems like there's these tables on the one hand that work like arrays, and those other tables on the other hand that work like objects, and you can't mix them up...
Is that not just an ordinary dynamically typed language with arrays and objects then, except it overloads the word "table" to refer to both?
I'm sure I'm missing something, happy to hear what that is.
Yes, there is:
local l = {[0] = 'a', [1] = 'b', [2] = 'c'}
for i, c in ipairs(l) do
print(i, c)
end
It was chosen around 2008 or so to be the scripting language in Multi Theft Auto: San Andreas.
We build entire worlds in Lua, there were many gamemodes, but my favorite was Roleplay.
Good old carefree times.
A single data structure (tables), no built in OOP (you build it with metatables).
Coroutines instead of threads.
I was curious and explored it in detail here - https://vectree.io/c/lua-language-design-metatables-coroutin...
It doesn’t pretend to be more than it is. Anyone can learn it a couple of sessions. It has all the stuff you need to write a program.
Imagine if we had Lua instead of JS in the browser.
In fact the latter was once closer to Lua, but didn’t have the same philosophy of wanting to stay minimal.
Pity it's not playable in even mildly current versions of love because being backwards compatible takes some slight effort on behalf of framework maintainers.
Lua is so small and simple (but not simplistic) that you can keep it completely in your head. Even if you only get to work on your project once every weekend you won’t have to relearn half of it every time.
https://github.com/willtobyte/carimbo
I have a game on Steam made with it, the game is open-source now.
To me this sounds similar to Love2D. How is Carimbo different, from the perspective of a dev working with it?
On top of that there are love2d specific libraries people have written to deal with 2D games like GUIs and tile libraries.
Then there is the ease of debugging, where you can use lua to have runtime access to the table of variables and can print them on screen if you need to, not to mention dynamically loading new update and draw and input functions.
This is all to say that just downloading SDL is not going to get anywhere close to what love2d has included.
The SDL3 GPU API[1] provided a cross-platform GPU API even before WebGPU.
In Rust it's a good alternative for winit/wgpu. For that reason I added it to areweguiyet.com[2] last week, where apparently it wasn't even listed before.
I am currently using it to develop a space game[3] inspired by the original BBC Elite. Using emscripten to get on the web and QUIC/Webtransport for networking.
[1]: https://wiki.libsdl.org/SDL3/CategoryGPU
[2]: https://areweguiyet.com/#ecosystem
[3]: https://git.levitati.ng/LevitatingBusinessMan/elite/src/bran...
[1] https://github.com/libsdl-org/SDL/issues/11148#issuecomment-...
But if it is about using it as an embedded language. you want just enough language to get you started and be able to tweak controls. so that the embedded language itself doesn't take up unnecessary space, on its own.
It's a design choice to have a language as small as possible while still offering cool tools.
local alive_enemies = {}
for _, enemy in ipairs(enemies) do
if not enemy.dead then
table.insert(alive_enemies, enemy)
end
end
enemies = alive_enemies
enemies = enemies.filter(enemy => enemy.alive) enemies = array.filter(enemies, function(e) return e.alive end)
enemies = enemies.filter(function(e) return e.alive end)The only difference is that one of the language is embedded and barely takes any place. it's just a few C files :-D It offers just enough functionality while not making it overly complicated to make basic things.
The other one is way way bigger. and even Array.filter didn't exist from the start
I see why people might hate Lua. Especially for game dev!
Author is currently building version 12 which will be using SDL3. But it's been in development for quite some time with no clear end date afaik.
That obviously isn't a replacement for the framework but it is perfectly doable if someone just wants to write a game in Lua with minimal overhead.
Edit: I mention LuaJIT specifically because it lets you create metaclasses around C objects, which is much easier than messing with the Lua stack from C, and it's easy to make a 2d vector class from an SDL Point or a spritesheet or what have you. There are a few rough edges like dealing with pointers and gc but to me it's the best of both worlds (the speed of C, and some implicit type checking, and the flexibility of Lua.)
Obviously you could do it the hard way and the other way around with normal modern Lua but it's such a pain in the ass.
Also move or die is running on love2d, which is an awesome game.
Also I love that trick that you can just zip your files and binary Comcast them to the love2d binary and it will load it.
It's also just plain cool to rock the TIC-80 editor fullscreen with narrow font, coding natively in Lisp and publishing the result to a webpage you can share.
I wish the iOS (app) deployment story was a little smoother for TIC-80.
There are a lot of free-as-in-freedom alternatives to (and clones of) PICO-8, but TIC-80 is indeed the most popular one, by far. And popularity is important for any software ecosystem. I really like that it supports other languages, even if that kinda inhibits its ability to be embedded into small hardware.
Apparently the nightly release supports DCPM samples now. Dunno why.
But there is one gripe -- when packaging apps into executable, TIC-80 pulls templates from the Internet.
On one hand, it's not that big deal, we are online basically all time nowadays. But on the other hand, I would expect that kind of software to be self-contained.
I found a quite simple (but definitely not frictionless) workaround though - you can build the templates yourself, edit source code to work with localhost instead of TIC website, and host the templates on local webserver.
As I said, it's not a frictionless solution, but I don't know C well enough to make more substantial changes to this behaviour.
https://github.com/antirez/load81
Anyone looking at Lua/SDL/game engines would learn a lot from antirez' fun little afternoon project ..
People would be better off looking at the examples page and repo for SDL itself.
(It is neither open source nor free)
Lua's small footprint is it's one big advantage in addition to its pleasent syntax but with tiny cc (which raylib supports when I last checked a few years ago) you can get a compact c runtime as well.
I haven't worked on a project with either of these frameworks but a couple of years back I was researching into some frameworks and was surprised to learn that I can use raylib on my phone with termux!
But I’m wondering: why do mature tools like this sometimes end up on Hacker News’ front page without any particular news (like new releases or updates)? It’s just a curiosity, not a critique.
The Launcher is available also for old Android versions, which means that old obsolete Android devices (I have some tablets and phones) can be used for whatever it can be fun to still write some GUI for on some spare touchscreen device.
https://itch.io/jam/love2d-jam-2026/topic/6082771/how-to-get...
... posted in the site of the 2026 Löve2D Game Jam, that sounds like something also worth mentioning: https://itch.io/jam/love2d-jam-2026
Too late to enter. Jam was last month. But there are 47 games to check out there, plus many from previous years.
Löve on the other hand is 100% just code. You'll not have the gui things and the pletora of different components that go with them. Still gives you freedom. Just too much freedom and not as much helpful preset tools.
I think love2d is better if what you love is coding, everything is code, love2d just executes Lua.
If what someone wants to do is make (for example) a 2d platformer, or definately for 3d, and the coding is something you need to do to make your game, goody is better, it includes so many batteries, have a built in gui level editor, etc.
One big advantage of love2d (although ironically not loved by many in its audience) is it is the AI friendly engine, as AIs love text and hate GUIs.
... Why is that? Personally, both as a game developer and modder, dynamic languages like Lua and alike tend to be a lot easier to make moddable and also force in mods regardless of how the authors felt about modding in the first place. Isn't it quite the opposite?
Gravity Wars - turn based artillery game in space (planets' gravity affect shot path)
That said, i'm not impressed. A web-based solution is usually better performing, despite all the bloatware necessary. This says a lot about the state of software development unfortunately.
This is a bit of an apples to oranges scenario, because the algorithm and architecture is not exactly the same, despite the game functioning identical.
The main weak points of LÖVE that we hit were mainly around embedded video playback though, which is probably very well optimized in chromium.
https://love2d.org/forums/viewtopic.php?t=94760
It's unfortunate as Love2D is generally VERY snappy on x86. I used it on a 300MHz laptop back in the day.
löve is getting a vulkan backend. I would have prefered löve to be plain and simple C coded instead of this abomination which is c++ (but it seems coding AIs may be very good at assisting mass c++ to plain and simple C port).
(Throwing diacritics on English words look extremely silly to me, since I know how åäö are supposed to be pronounced. It makes something like Motorhead just sound laughable rather than metal.)