LÖVE

BrotSagtMist wrote: ↑Thu Mar 14, 2024 2:56 pm games and their runtimes are usually in different packages.

I don't think this is usually true. As a game developer you wouldn't want to rely on a global install of love on someone else's system having a version that's coincidentally compatible with your code. And if you use something like Unity instead of love and it somehow allowed that (which it doesn't) that becomes a much bigger issue because there are many, many more versions and new ones are released at a much higher rate.

Well the guy quoted the debian packaging guide and they instruct to use the global install.
With only one Löve game in there thats a bad example tho.

And if you look for other games in the debian repo, they are mostly split into several parts.
With some containing only resources and no exectutables at all. So no this is not a requirement.

slime wrote: ↑Sat Mar 16, 2024 9:13 pm I don't think this is usually true. As a game developer you wouldn't want to rely on a global install of love on someone else's system having a version that's coincidentally compatible with your code. And if you use something like Unity instead of love and it somehow allowed that (which it doesn't) that becomes a much bigger issue because there are many, many more versions and new ones are released at a much higher rate.

In the case of distributions, their packaging system has a dependencies feature designed to address exactly that. It doesn't rely on a random version of the runtime that the user would have installed; it specifies which runtime version is needed for a certain game package, and it would pull that version. MrRescue is not a good example because it doesn't specify what version of love it expects, which I consider a packaging bug. But see for example gemrb-baldurs-gate which depends on a very specific version of gemrb.

BrotSagtMist wrote: ↑Sun Mar 17, 2024 11:00 am And if you look for other games in the debian repo, they are mostly split into several parts.
With some containing only resources and no exectutables at all. So no this is not a requirement.

They are split into architecture-independent and architecture-dependent packages. I guess that's done instead of having one copy of the data per architecture, to reduce the repository size. Löve games that have no architecture-dependent files, can be in a single package.

pgimeno wrote: ↑Sun Mar 17, 2024 1:16 pm It doesn't rely on a random version of the runtime that the user would have installed; it specifies which runtime version is needed for a certain game package, and it would pull that version.

Other thing to consider is that since the version 1.0.0, love is claimed to be backwards compatible. So the problem of incompatible love versions being installed on the system is no longer as serious as it used to be, assuming users perform updates regularly.

But that got me thinking about LTS/stable releases. I haven't used non-rolling release for desktop in a good decade so I forgot that not all systems will have access to the newest version of every package. Maybe I should reconsider the APPIMAGE distribution route. I doubt I'll get my game in an official Ubuntu repo (neither do I have such ambitions) so the version mismatch between required version and latest available is almost certain to be an issue if I use the newest love version.

pgimeno wrote: ↑Sun Mar 17, 2024 1:16 pm In the case of distributions, their packaging system has a dependencies feature designed to address exactly that. It doesn't rely on a random version of the runtime that the user would have installed; it specifies which runtime version is needed for a certain game package, and it would pull that version.

It'd need to provide the exact same thing as a (perhaps unpacked) appimage of love at that point, right? Since you'd also want all of love's dependencies to be the version you made your game for as well otherwise you'll run into similar problems.

As an example, love 11.5 ships with SDL 2.28.5. I've had a few people using love through a package manager report bugs to me recently that it takes a long time to start up. As it turns out this is a regression in SDL 2.30's joystick module initialization code on Linux. The package manager they use started providing that version even though love 11.5 wasn't tested against it. If the package manager provided reliable dependencies this wouldn't be a problem.

Or another example, love 11.5 ships with a specific recent version of LuaJIT 2.1 which fixes many issues with pairs iteration causing freezes, crashes, missing keys, and other weird behaviour. Some package managers which use a global install of LuaJIT 2.1 haven't updated to this version, so if you don't use a standalone love with its dependencies self-contained like the AppImage, you're risking your Lua code randomly freezing on someone's system.

reverent.lapwing wrote: ↑Sun Mar 17, 2024 1:35 pm Other thing to consider is that since the version 1.0.0, love is claimed to be backwards compatible.

We don't claim this. love 12 is not going to be backwards-compatible with code written for love 11.

Patch versions (e.g. love 11.4 to 11.5) generally are, but sometimes your game might rely on buggy or implementation-defined behaviour from a specific patch version as well.

slime wrote: ↑Sun Mar 17, 2024 3:19 pm We don't claim this. love 12 is not going to be backwards-compatible with code written for love 11.

Patch versions (e.g. love 11.4 to 11.5) generally are, but sometimes your game might rely on buggy or implementation-defined behaviour from a specific patch version as well.

Funny, I found the topic where I got that misconception from and you already answered my follow-up question there 9 years ago. For what it's worth, I recently ported a game from 0.8.0 to 11.0 and it works fine. I guess it ought to, I didn't realize the first stable Love version is also the newest.

slime wrote: ↑Sun Mar 17, 2024 3:19 pm It'd need to provide the exact same thing as a (perhaps unpacked) appimage of love at that point, right? Since you'd also want all of love's dependencies to be the version you made your game for as well otherwise you'll run into similar problems.

<snip>

I'm not sure how any of that is relevant when talking about packages that are to be included in a distribution. The packager is rarely the same person that created the package; e.g. in the case of Mr. Rescue, the packager is the "Debian Games Team". They are supposed to test the game with the libraries that are to be provided with the release, before it happens. Of course bugs may arise that go undetected by the packager - that's why distros have their own bug reporting system and recommend (or at least Debian does) reporting issues to them first before reporting them upstream.

You may do as you wish. Personally as someone whose project is included in many different package managers that are maintained by many different people, I have more than enough first-hand experience to see how that system can break down with complex and long-lasting projects and ends up accumulating unique combinations of bugs over time. I like having consistent software, even when the goal of being bug free is never 100% achievable.

The most reliable way to provide a game is to provide the exact dependencies you've developed against, which means the entire dependency tree including dependencies of dependencies of dependencies needs to be the same. Which is what the appimage (packed or unpacked) is, to the best of its ability anyway. My examples illustrated situations where the dependency (love) may have the same version and it breaks because dependencies of dependencies (SDL or luajit in the examples) are different.

That reasoning feels like the classic "works on my maschine" excuse.
And appimages feel like a step back to a time where we had no shared libs.
I now in the recent years shipping the entire thing has dramatically grown again, probably because everything grew so big and complicated and has tons of depends, so i get the reasoning.
But i dont like it. I dont do it. And out of stubbornness i refuse to use appimages.

Repo maintainers actually love adding stuff if they are pointed to it, so whenever something is missing ill just drop a message and its in my distros repo the next day with the version i need.
And if its not the right version, discovering bugs is a plus in my book.

Maybe i will think different about this when releasing comercial software tho.

BrotSagtMist wrote: ↑Mon Mar 18, 2024 12:54 am That reasoning feels like the classic "works on my maschine" excuse.

It's the exact opposite - making sure other people will get the same experience that you developed, instead of shrugging off differences or bugs as something that's not your responsibility to handle as the game's developer because details of the installation were decided by some third party (actually many many third parties usually, given how many distro package managers and package solutions there are).