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
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.
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