Building Game Prototypes with LÖVE(healeycodes.com) |
Building Game Prototypes with LÖVE(healeycodes.com) |
https://www.reddit.com/r/PixelArt/comments/143ybxa/pixelated...
The OP mentions hot reloading and there are a couple of repos that may help with that:
https://github.com/clofresh/love-module
https://github.com/usysrc/LICK
Their card game prototype is really impressive for three hours' work!
There is so much "draw the rest of the Owl" between a very primitive framework like LÖVE and stylistic games like BALATRO and MOONRING.
For Android you can also install the stand-alone LÖVE Loader app that can open .love files to play. Some games on itch.io comes with a .love-download (in addition to platform-specific executables), but I guess they can sometimes be extracted from other games too.
The .love-files, if provided or if they can be extracted from a game, are also useful on desktop, for playing the games in an operating system (like FreeBSD) that the game's developer did not provide binaries for.
The stand-alone app is also a fun way to do some gamedev on an Android phone. The .love file is just a ZIP, so it can be easily created from termux.
Something else to consider is traction, if you get stuck in DragonRuby there's probably not a huge amount of docs/tutorials around it. That being said, it does seem like they have a pretty active Discord at least.
Yes, but check out: https://docs.dragonruby.org/#/misc/faq?id=dragonruby-is-not-...
And
https://docs.dragonruby.org/#/misc/faq?id=what-if-i-build-so...
> If you get stuck in DragonRuby there’s probably not a huge amount of docs/tutorials around it.
You’d be surprised. The docs are extensive and there are sample games galore in the distro. https://docs.dragonruby.org/#/
Also the Discord is incredibly helpful and the creators chime in regularly.
It’s a pretty special engine and community IMO
It sounds like the velocity was provided by consulting LLMs.
It’s fun.
I wonder if the creative feeling is an illusion, though. Does the fact that the LLM doesn’t feel like it is directly copying work it has ingested make the experience feel different than just ripping off a project you find on GitHub?
Anyway, I would be very interested in a write up that gives more details: how long did the author feel like they were “on the path” that LLM knows from existing code, vs how does it handle being “off the path”.
I love coding and didn't get any of that creative feeling with my code. But it sure was a magnified experience in terms of the creative feeling about the thing I was actually building. It was amazing to just think about features and that's it. Until it didn't work, I mean. Then it sucked.
I'm building a game in Monogame / C# right now, and LLMs have been great to help point me in the right direction or suggest architectural patterns I'm less familiar with to investigate.
e.g.
If I have a GameStateManager, an InputManager, and a UIManager, and I represent input events as an enum of GameCommand's, what is a good way to register callback functions from these objects with the InputManager to trigger actions on particular game commands?
Is it common when using an Entity Component System framework to manage the UI using ECS? Or is the UI often managed separately using a more familiar object-oriented approach?
That said, the LLMs are weak right now. They are great for getting some initial boilerplate (how do I draw a circle with HTML Canvas API?), but as the project grows you’ll be fixing them more and writing your own code. Give it a try, especially with Cursor. It’s awesome.
Good stuff OP.
If you are a programmer and want to dable then a code first framework like LÖVE might be less cognitive load. If you prefer a more featured framework then Godot is also a really great lightweight engine, but you will spend more time in the GUI than in the code.
Don't sell yourself short either, you have an advantage by knowing some backend concepts! A lot of people start from zero programming experience and jump into games.
I built a prototype Metal Fatigue tech demo (No real game logic as such, just the framework) and I found that heightmap based deforming terrain for the underground drill rig to dig through was so outside the design intent of unity that it would be the sole thing I spent hundreds of hours working on to get it past the tech demo stage. Like I got it working, but its so tenuous I could never ship it as is. Not to mention the default modules were writing my changes back to the heightmap object, saving them when that was unintended. I think the code I was using was intended for tooling, not for game logic.
And the Unity Store is great if you need a plugin to clone some mobile game system, but once you went to any depth it was just a hook to get 50 bucks out of you for no gain.
Its an interesting ecosystem.
Over Thanksgiving break I decided to see how far I could get an LLM to do all the work (using cursor) and I picked LÖVE as a minimalist all-code framework. I put the game design and descriptions of UI and every screen in my .cursorrules file, so they are included in every prompt, and for a long while mostly told cursor in composer mode to do whatever the next thing it suggested was. I chose the smallest possible full game design I could and managed to just barely get there, although there were some brick walls where I had to help the LLM, but I got fairly far without writing or reading any code.
Reviewing what went wrong, the biggest problem is the LLM code started pretty good but just got worse and worse over time, especially as soon as it couldn't fit everything in its context.
ANYWAY, I was intending to suggest choosing the smallest possible game design you can if you wanna ship something.
I'm ready to ship my tiny project and it's amazing just how much work it is to ship a thing even after you've got all the functionality done.
It's a shame that the Phaser map/level editor is a perpetual subscription fee with no fallback license. That means you're relegated to either building your own map editor or using something like Tiled.
Although I did like that I could use Typescript for Phaser, and that it was a lot easier to show off the game to other people through the web.
edit: Just wanted to add that Phaser has one of the best docs out there including a library of tons of examples that can really get one going.
Personally I prefer PIXI.js (which only focuses on sprites/graphics) as I can plug it more easily into my own data oriented architecture
Edit: by cross-platform I mean desktop + console + mobile.
That doesn't mean it's well-supported or easy to fully support those other platforms. I'm struggling with getting iOS native functions working with Love2D in iOS, for example, although Balatro proved that it's definitely possible. The basic game (the game as it works on my PC) is working on my iPhone just fine, though, and wasn't too difficult to get up and running. I also have an APK working on a cheap Android phone I got.
What does cross-platform mean to you? Just MacOS/Windows/Linux? Web? Consoles? Android? iOS? Blackberry?
Godot comes pretty close to a batteries included cross-platform engine that handles 2D/3D.
JS engines can likely be ported (with varying degrees of effort as PWAs, electron/tauri, etc) to most systems as well - look into Phaser though its intended use is 2D.
Demo https://carimbo.run/play/1.0.30/willtobyte/megarick/1.0.30/7...
You can use Lua as scripting language.
play.carimbo.cloud vs carimbo.run
Unfortunately, each and every platform has its own unique quirks[^], and I think the problem is too large for a project like LÖVE to tackle.
In fact, LÖVE's authors have already done "90% of the work in 10% of the code": you can make a ZIP file, change the extension to .love, and just distribute that. Install LÖVE, double-click YourGame.love, and you're done. You can also concatenate the game executable with the ZIP file to create a self-contained binary distribution for that target platform (super old & cute trick; it's possible because ZIP's "header" is in fact, at the end of the archive).
[^]: In 2016 I've attempted a "one game per month" challenge; but I also wanted to distribute executables for Windows, macOS, and Linux, so that all of my friends could just play them. It went something like this:
- Windows: distributing executables from your personal domain is considered a crime; the browser and the OS will yell at the user, block the download, blacklist you, etc.
- macOS: simply concatenating won't work; you need an elaborate dance to create a .app bundle, and distribute that in a .dmg - good luck building that on a Linux host, also good luck debugging without an actual Mac. Nevermind code signing, you can bypass that with shift-right-click-open. Oh wait, macOS 15 won't let you.
- Linux: are you ready for the .so hell?
- BSD: bonus! The documentation for SDL_GetPlatform doesn't even enumerate all of the possible values! You need to source-dive to get them: https://github.com/libsdl-org/SDL/blob/f45ce45603a00e92332f9... - plus any possible patches in ports; most developers won't ever care, and will just hardcode "Linux". Checking for $DISPLAY is also unreliable: macOS users may have XQuartz installed, Wayland purists may run without XWayland, etc.
That said, we can always use more game engines / frameworks!
This looks like an up-to-date introduction:
https://itch.io/jam/love2d-jam-2024/topic/3484009/getting-st...
The "absolutely minimal Löve 2D fennel" repo was useful to me as I found the other templates a bit bloated (but possibly those are more useful for real-world projects beyond small experiments?):
https://sr.ht/~benthor/absolutely-minimal-love2d-fennel/
I did find that startup-time was bad for Fennel om some very low-end devices, or when running even a small game using LoveDOS in DOSBox, so I set up my test-projects to pre-compile the fennel-code to Lua as part of building the .love-files and that solved that problem.
It's surprising given that back in June? 2024 I just extracted the .love zip from the executable, patched a file or two, and merged it into the love android apk and it Just Worked. Just goes to prove the last 5% rule
> Even with a multiplatform framework (Monogame), compilation and basic run isn't a given.
This isn't the case for Love2D. The game framework is already compiled for android, and the game is a bunch of Lua scripts. There is no issue with compiling, only very minor differences between the Lua for Android and the Lua for desktop platforms and making changes is instant except for transferring the apk to my phone and installing it to test (I didn't set up a full local android test environment for something so small). Balatro worked pretty much out of the box, except for some small changes I made — the first was to add in my profile from Steam, I didn't have to change the code for this. All the buttons were already reasonably sized. Text input was just adding a call to https://www.love2d.org/wiki/love.keyboard.setTextInput so that the on-screen keyboard appeared and disappeared when it was supposed to. I also patched a small bug that made it go blank on screen-reorientation, which was a one-line fix.
The total time spent was around an hour including codebase orientation, patching, testing and doc lookup (I haven't used the framework in a while).
Like if you want to release a game on iOS you're going to need some sort of Ad framework and access its game center for achievements and leaderboards at the very least, and that's been tricky for me to get working. I know you need to write some hooks and saw some old code that I'm trying to use for reference, but it was still giving me enough issues I gave up on it for a the time being.
And I've released games in native iOS before (although it's been a while), so it's not like I've never used them.
As much as I'd like my game to spread as far and wide as Balatro, I understand that it won't, not anywhere close. It's just not going to have the polish that Balatro has (I don't have the time or energy, I'm in my 40s with a spouse and a day job).
But hopefully it will be fun to play (it is a more fully-featured remake of an old free web game I made many, many years ago that was played millions of times).
And games that aren't already super high quality mostly don't sell on iOS anymore, at least not before people download it for free and try them. You pretty much have to make the base game free so people will download it and then provide an unlock later.
I'm not trying to be obnoxious about ads. I'm wanting to use the Zach Gage model (Knotwords, Flipflop Solitaire, Good Sudoku, SpellTower). Some minimal ads in between matches (the matches last 5-10 minutes by themselves) and a few extras like themes or detailed stats behind a one-time unlock of a few bucks. I hate the standard model of throwing ads in your face every 30 seconds and wouldn't do that for my game.
Also another native feature that Love2D doesn't support is the iOS Haptics library. Love2D only allows for a half second vibrate at full power and it's way too much. Balatro uses the iOS native haptics library as well (it's obvious, they're very light and quick vibrations). These haptics are super common in iOS games nowadays so it will seem weird if it doesn't support them properly.
Some rough numbers from my recollection: I released Card Crusade (deck building mobile game) for $4 back in 2019 and i think in the first year we got about 2k-3k downloads total. When we made it free in early 2020 we got 25k downloads in the first _week_. The revenue was less for us as a free app, but that’s with no ads and IMO we designed the IAPs pretty poorly.
But, a while after making it free, we accrued enough positive reviews that the iOS App Store started recommending the game to more people, so we have a steady 200+ downloads per week, despite not having updated the game since 2020!
I released another premium mobile game, Barnard’s Star, back in 2022 (and am still slowly updating it). Coincidentally, both apps make roughly the same amount of money (about $500 every 6 months), but Barnard’s Star makes that money from a fraction of the downloads… but the word of mouth effect (and game community) seems like it would be a lot stronger with f2p. So I’m planning on making Barnard’s Star free eventually (with hopefully better designed IAPs this time!).
One place where the “just a game and a price tag” model still works well is Steam. If i were trying to make a living off making games, I think I’d focus on releasing stuff there.
I have managed to expose some native apis from iOS, web, Windows and Steam but that is far less straightforward and the LLM is sure it knows what to do and it does NOT. Web searches are not great either.
Example: https://i.postimg.cc/P5VrVhQ4/Screenshot-20250101-103921.png
Thanks for helping to confirm my suspicions. I used to release mobile games myself but it's been well over a decade. The landscape was a lot different back then.
https://gist.github.com/kellydornhaus/45b8571807ec3ca659ea50...
I made https://love-15.com which works on the web and as of today is on the iOS app store. I'll probably get it on Steam after that. I prefer playing the native builds personally.
It's fully free and about the smallest game design I could think of - I did it partly from a longstanding desire to make this specific game (I played a very similar thing decades ago on Palm Pilot) and partly as an experiment about just how much work can you get an LLM to do.
Best of luck to you and your project.
Also after paying the 'remove ads' price, which will likely be cheaper than the price I'm planning to sell it for on Steam (thinking $2.99 for mobile right now), the game will effectively become the same as the Steam version anyway.
I agree that it sucks. I wish I could just put $2.99 as the price and it would still have a chance of selling decently. One of the iOS games I made a long time ago I did exactly that (actually I priced it at $1.99). But people were also willing to pay $1-2 for Angry Bird-style mobile games by the millions back then.
Now there are so many free games on there, they seem to just skip over to the next free game instead, and maybe pay to have ads removed (my own partner does this, bounce from free game to free game, and if she likes the game she pays to remove the ads).
This is one comment that corroborates that:
"It requires support for Mac OS and TV OS and committing to significant content updates every year for three years, at minimum. Revenue is based on how many people play your game compared to everything else on the platform.
Because of the contractual commitment and the need for marketing spend (If people don't play, you don't get paid), it's hard to recommend for a small developer without commercial experience, which is why Apple is rather particular about who they approve."[1]
[1]: https://www.reddit.com/r/gamedev/comments/dwwi87/experience_...
