One of the biggest recent indie hits, Balatro, was made in Löve!
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.
Game developers sometimes make the “randomness” favor the player, because of how we perceive randomness and chance.
For example in Sid Meier’s Memoir, this is mentioned.
Quoting from a review of said book:
> People hate randomness: To placate people's busted sense of randomness and overdeveloped sense of fairness, Civ Revolutions had to implement some interesting decisions: any 3:1 battle in favor of human became a guaranteed win. Too many randomly bad outcomes in a row were mitigated.
The original link being discussed in that thread is 404 now, but archived copies of the original link exist such as for example https://archive.is/8eVqt
I worked on a game where we added a "fairness" factor to randomness. If you were unlucky in one battle, you were lucky in the next, and vice versa. Mathematically you ended up completely fair. (The game designer hated it, though, and it wasn't shipped like that)
Games like Battle for Wesnoth which have it implemented right, you’ll look at a 90-10 scenario with 2 attacks and end up with the 1% scenario. Enough to make a man rage. I have degrees in Mathematics, I am aware of statistics, and all that. And yet when I played that game I would still have an instant “wait what, that’s super unlikely” before I had to mentally control for the fact that so many battles happen in a single map.
Was good because it identified a personal mental flaw.
For a small while I've had the idea of a [game engine/fantasy console/Scratch clone?] that comes packed with a bunch of example games. The example games should be good enough that people download it just to play them, but they are also encouraged to peek into their source code. I'd hope for it to be a sneaky gateway into programming.
For that, I'll keep this in mind: "Unlucky players may look at the source code of a chance-based effect to check if the odds are actually as stated."
The Steam version was created by one guy, but the platform ports have a couple different authors. The Google Play and Xbox PC versions, for instance, have divergences.
I wonder how the ports influence the upstream and each other. How do they keep the codebases in sync, while also accounting for platform differences?
A lot of indie devs actually are fine with decompiling/viewing source. Even the STS2 devs have no issue with this. I think it is great and helps the indie dev community. Seeing this has actually made me excited about game dev to the point where I'm beginning to dig in myself.
Haven't used it in almost 10 years but at least back then one sticky point was that unlike unity and the like, opening the exe didn't open an IDE. Just kind of a dummy window. Also building for Mac from Windows was a nightmare since my end user was not technically literate and it didn't just run on their end. But that's likely just a Mac issue
I used LÖVE to build a simple Kodi alternative for my home media center setup. My first attempt was using Electron but rewriting to LÖVE meant much simpler code (turns out manually calculating coordinates is simpler than fighting CSS) and less resource consumption (not a high bar, yes). It works so well I might clean it up and open source it...
What were your (main) problems with Kodi? AFAIK it is written in C++ with Python plugins. Electron would be (on the face) a downgrade yes. But how is a Lua app much smoother?
(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.)
Kodi is super complex. The last straw was me wanting to launch Dolphin games from the UI and not being able to figure it out.
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.
Anyone who is a fan of the TV Show Community MUST try out the recreation of the 8 bit video game episode(Digital Estate Planning) called Journey to the Center of Hawkthorne.
I love LÖVE. For me it sits at the perfect intersection between high and low level abstraction. Unfortunately the latest released version is getting pretty long in the tooth now and a lot of devs use the latest HEAD from the repo since it has better performance and compatibility. One day the mythical 12.0 will get released for real…..
It’s been a recurring issue I’ve seen in open source where there is active development but no releases. I don’t get why you’d put all the work in to fixing bugs and building features but not hit the button to build a release.
Since we've stepped from interpreted language (Lua) to compiled-to-VM language (C#), let's go all the way down to compiled, low-level language (C) with Raylib!
The Lua source code is also a masterclass in C, I recommend it to anyone learning that language. It's big enough to be an involved implementation, but small and focused and well-organized enough to (at least roughly) understand what's going on at the various layers. It's a very solidly-written mass of portable C, with only minor exceptions.
There is nothing stopping you from doing someArray[0] = "the first item", you know.
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 ..
Lua will forever hold a special place in my heart. It was the first programming language that I actually managed to learn, instead of just attempting to learn it.
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.
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.
My2c. Fintech tech lead who has only a far memory of hand coding games ages ago. Community makes tech awesome. Love2D discord changed my life. Never met a more awesome and welcoming community in my whole life.
Btw, Love2D is based on SDL2. If you hate Lua but needs the same cross-platform capabilities, you can use an SDL2 binding in other languages or make your own.
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.
SDL3 is something I've been keeping an eye on, but at least one thing that held me back from diving into it was SDL_Mixer (audio library) was not updated to a release version for SDL3 until I think a month ago? I need to get back to it but lately I've been messing with SDL2 + wasm stuff using emscripten.
well, it is true that the second one is more concise.
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
1-based indexing is great. It's just _different_ - from C, where the array index is just sugar for pointer arithmetic, and from other languages which borrowed the practice without reasoning.
> we had better regard —after all those centuries!— zero as a most natural number
Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.
That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world.
The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.
Small stdlib, “implement it yourself” philosophy to even things like classes, diverging language versions and fragmentation (a lot of people don’t like any of the post 5.1 changes), bad tooling and editor support, dynamic duck typed language with no type hints
I don't necessarily hate Lua, but I prefer C and Raylib for game dev. Lua is garbage collected, dynamically typed, strays far from standard syntax patterns, and has less existing tooling than C.
I see why people might hate Lua. Especially for game dev!
A JIT is a double edged sword, it _can_ make your code faster, i remember in the early days of smartphone gaming, developers often had to manually "warm up" the JIT to prevent stutters during gameplay
Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques
JIT and GC aren't the panacea people make them out to be
True using a JIT without understanding it is not a panacea. Same as a GC. Same as malloc and free (you're often much better off with arena allocators).
Most JITs let you tune when and how they inline. It's also worth knowing how they works and what they can/can't inline.
You linked to monojit. Luajit is a whole other beast. I'd argue it's superior to anything in JS/JAVA/C# land (and I say that as someone with a reasonable understanding of the JVMs C2 JIT).
As an aside with low latency GCs like the JVM's ZGC trading manual memory management for no memory related security vulnerabilities is pretty appealing.
There is a lot more that goes into Love2D than just SDL. It uses many other libraries for sound, image loading, etc as well as using luajit so that the lua runs very fast and has a super easy C FFI.
Love2D uses openAL for audio, FreeType 2 for fonts, DevIL for image loading and Box2D for physics. It can also use image fonts. It uses luasocket for networking and has a compression API built in.
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.
Who is "the author" these days? Is it Slime? I wonder what Rude and Bartbes and vrld are up to these days. Are releases still done on holidays? Are all libraries still named after sex themes? I was active for versions 0.4 - 0.6.
It is easy to get Lua (with LuaJIT) working with SDL3, though.
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.
Lua is very fast - even without the JIT it makes Python feel like wading through molasses.
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.
I use this framework to build prototype applications and it's always a delight. Something about Lua just feels right. Once I'm satisfied with a demo or prototype, I later on port it to native C/C++ implementation.
I’m a big fan of Love2D as well. it’s simple, efficient, and really easy to get productive with. After just a short learning period, I was able to ship my first indie game on Steam, a small Chinese‑character puzzle game built entirely with Love2D. https://store.steampowered.com/app/4218330/WordJoy/
Am I really the first one to mention pico8 in this thread? Anyway, pico8 is another option that has a bit different spin, but you also implement the games in Lua :)
TIC-80 is a nice free as in freedom alternative to PICO-8, and it allows more inputs, which makes for better Tetris games (gotta have that hold piece).
TIC-80 is great indeed, I had even ore fu with it than with PICO-8 and that's a high bar.
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.
TIC-80 is wonderful to play in. Besides being free/open, another advantage over PICO-8 is TIC-80 has native support for Fennel. i.e. you can code within the system editor in Lua OR Fennel (or half a dozen other languages!) You don't have to edit and transpile to Lua on the desktop as you would with PICO-8. This has some value in debugging with error messages and line numbers.
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.
It's just that pico8 has much larger ecosystem. There's a new great game almost every day. It is sort of annoying that it's not FOSS, but on the other hand the team/author has sustainable business.
As someone that used to write 2D games with things like phaserjs, sdl and even directx7, I always regret I never tried Löve2d. I think Android and iOS packaging was also supported. Is this still the case? What if one wants to integrate IAP?
Pretty sure there is still app packaging documented somewhere. There is also, at least for Android, an official Löve2D Launcher app that can open any love-file saved to the phone and execute it. I use that all the time.
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.
I love this framework, pun intended. I made a clone of Atari's Missile Command with it many years ago when the Portal / Mario mashup game made with LÖVE was popular. https://github.com/chadpaulson/missile-command
Was going to post a link to the minimal template for setting up Löve2D with Fennel, that I can really recommend, and found this recent article describing that...
LÖVE seems amazing, I’ve always looked at it with curiosity. There’s also the legendary Harvard CS50’s Introduction to 2D Game Development, which now uses it in its latest version.
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.
I've used this for many projects that are still working to this day.
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.
I'm curious as to how you came to that conclusion. Did you run any tests, or is it just a general observation? What's your computer hardware like? This isn't an accusation of anything, I promise I'm genuinely curious.
I've not done proper scientific comparisons, but had to reimplement some games as websites to make them reliably perform on Raspberry Pi's we used embedded.
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.
I don’t usually push LÖVE to its limits because I tend to make simple games as a hobby but I do keep an eye on its framerate and often it‘s in the 100s of frames per second. So it may not be impressive (in sense of winning benchmarks) but it’s rarely perceivably slow.
They are saying web based solutions often out perform LÖVE, even though you would expect the opposite because LÖVE doesn't have the bloat of a browser engine.
explain that to my webgl TypeScript browser game running at 180+ FPS while rendering a large RPG tiled world with infinite procedurally JIT generated biomes, with heavy processing delegated to webworkers.
As you aren't posting code or stats I can't say much, but I'd bet a native app would still be smaller and more efficient, since you have to wrap what you're doing in an entire Chromium instance and deal with a web stack designed for documents, which is definitionally less efficient than a native alternative. Tiles aren't exactly cutting edge technology.
"Heavy processing delegated to webworkers?" That just sounds like threads but worse.
Love2D uses Luajit and directly calls established game libraries. The CPU usage should be far better for 2D games, luajit is faster than a browser's javascript jit. You can also create single exe games that are a few megabytes and not a few hundred megabytes.
Is Love2D a decent option for gamedev compared to Godot? I finished a really simple game using Unity3D and it was fun, but it sucks to use a closed source engine.
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.
Yeah, Love2d is a great option for gamedev. It doesn't have the same built-in tools as Godot so you'll need something else for putting together maps (use Tiled [1]), and you'll need to write your own main/render loops (these are just two for loops, nothing fancy).
It’s very different, and it depends what you are targeting. I love love2d.
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.
The fantasy computer by 100 rabbits? I love their philosophy, I'm glad Varvara exists, but I'm personally not up to program assembly for a 4-color screen, and I'm sure many others are the same.
How is it supposed to be pronounced? Is it just gratuitous diacritics? Or should I pronounce it in my native Swedish (where the names makes me think of leaves rather than love)?
(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.)
The project was started by Norwegians. So I feel like you should apply juuuust the right amount of cheesiness and sort of push that Ø-vowel looong. Not sure if Ruud would agree, though.
I haven't tried Löve, but I somehow enjoyed reading through the README.md, no AI slop, just a natural writing style with tiny indictors showing the authors' enthusiasm in creating software.
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.
For example in Sid Meier’s Memoir, this is mentioned.
Quoting from a review of said book:
> People hate randomness: To placate people's busted sense of randomness and overdeveloped sense of fairness, Civ Revolutions had to implement some interesting decisions: any 3:1 battle in favor of human became a guaranteed win. Too many randomly bad outcomes in a row were mitigated.
https://smus.com/books/sid-meiers-memoir/
Some threads on randomness and perceived fairness in video games can be found here on HN too, for example https://news.ycombinator.com/item?id=19399044
The original link being discussed in that thread is 404 now, but archived copies of the original link exist such as for example https://archive.is/8eVqt
Was good because it identified a personal mental flaw.
I've long been suspicious of the RNG/seed implementation.. but not curious enough to automate testing of it, though.
For that, I'll keep this in mind: "Unlucky players may look at the source code of a chance-based effect to check if the odds are actually as stated."
The Steam version was created by one guy, but the platform ports have a couple different authors. The Google Play and Xbox PC versions, for instance, have divergences.
I wonder how the ports influence the upstream and each other. How do they keep the codebases in sync, while also accounting for platform differences?
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.
(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.
[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.
https://monogame.net
https://www.raylib.com/
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 ..
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.
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.
https://stabyourself.net/mari0/
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.
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-...
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
> we had better regard —after all those centuries!— zero as a most natural number
Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.
I like the argument that 1-based is better for indexing and 0-based is better for offsets: https://hisham.hm/2021/01/18/again-on-0-based-vs-1-based-ind...
It's like right-click-to-select.
I see why people might hate Lua. Especially for game dev!
It still is an issue nowadays https://discussions.unity.com/t/app-needs-warmup-first-slow-...
Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques
JIT and GC aren't the panacea people make them out to be
Most JITs let you tune when and how they inline. It's also worth knowing how they works and what they can/can't inline.
You linked to monojit. Luajit is a whole other beast. I'd argue it's superior to anything in JS/JAVA/C# land (and I say that as someone with a reasonable understanding of the JVMs C2 JIT).
As an aside with low latency GCs like the JVM's ZGC trading manual memory management for no memory related security vulnerabilities is pretty appealing.
Like everything in programming it's a trade off.
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.
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.
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/antirez/load81
Anyone looking at Lua/SDL/game engines would learn a lot from antirez' fun little afternoon project ..
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.
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.
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.
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.
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.
there isnt step 2, explain is over
60MB+ for a calculator is not optimal.
"Heavy processing delegated to webworkers?" That just sounds like threads but worse.
but webgl + web workers is good enough these days.
I can't share code sorry, the project got big and I have commercial plans.
But you can tell Gemini 3.1, Opus 4.6 or GPT 5.4 High to generate a demo and they do a decent job most of the times.
that's how I got started, seeing how it was possible to have good game performance with multi threaded workloads on a browser.
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.
[1] https://www.mapeditor.org/
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.
(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.)