I'd say everyone agreed on Flaptak for such cases. Snap is Ubuntu only idea for the same thing.

I find all three quite bad on general level, when we are talking about distribution of OSS with sources available, I still strongly prefer classic packaging (and from those I personally prefer "deb", because I like the whole Debian project and the ideas and community behind it).
(so I'm kinda annoyed by this push for snaps for regular apps, it's like deja vu from the ~199x, when the package management was being developed to get rid of statically linked large binaries, for me it feels like snaps are just going back to this era, just being more fancy and having few extras like containerization/isolation... (but I may be misunderstanding it completely))

But as long as game distribution goes, where the supporting libraries count probably only as few percent of total package size any way (at least with current games which are usually 1+GB), and the code is not available as source, it makes some sense to use something like appImage/etc... like full offline archive of all dependencies.

One would need some kind of VM or emulator in future to run these any way, but at least it will be less painful to find+collect the dependencies, which may turn out to be really difficult over time, as the older repositories are taken down, etc.

A perfect solution to the virtually non-existent problem. We are at the point where the true Linux game developers (e.g. not the casual Windows-oriented companies like Larian or CDPR who got themselves in a bind and ordered a one-time hack-job to porters) have already figured out the exact libraries that must be included.
I've been using Fedora almost exclusively with GOG and the only time I've come across a nasty dependency problem is with "Undertale" and "VA-11 Hall-A: Cyberpunk Bartender Action", both using the same ancient game engine depending on the old Ubuntu "libssl.so.1.0.0" and "libcrypto.so.1.0.0". And yes, the developers/GOG know about the problem but refuse to bundle the libs with the games, so "containers" are not helpful here.

And what about the games like "X series" or "Kerbal Space Program", where one should install mods into the game installation directory (and in case of "KSP", due to bad/legacy programming habits, the savefiles also go into the install dir)? Should users repack the the games every time they need to install a mod/save the game?
I'd say, GOG (for starters) should properly support Linux in general: actually implement automatic (and timely!) updates, GOG Galaxy, multiplayer support, beta version channels, incremental patches etc.
They have more urgent work to do; I am willing to put up with "less than perfect" game packaging system, assuming that everyone using something other than Ubuntu knows what (s)he is doing and is capable of installing some additional libs (as per instructions on the game pages! and forum threads) from time to time.

Asking for forgiveness for The Witcher III "Coming to Steam OS" scam also should be nice!

Just my two cents.

I was more of thinking ahead, and this is not related only to GOG, but using Linux (also for gaming) in general. How to reduce the risk that I can't play some game (be it a native Linux game, or a Windows game running in WINE) ten or 15 years from now on a future Linux platform. I got the impression that these self-contained packages are also more future-proof. As in, the game does not work with some future version of a system dependency which has changed so much or maybe even removed: who cares, as the game container includes the very dependency with which the game works.

Of the three, appimage appears to be closest or most suitable for GOG's way of doing things, releasing games in standalone packages that don't depend on being online when you try to install and/or run the game.

I was also thinking of the recent Linux discussion here where someone complained that Linux in itself is against the ideals of GOG, as Linux in general relies so much on being online when you try to get the correct dependencies to run a certain piece of software etc. I don't recall if .appimage was mentioned in that discussion, but it should have been.

EDIT: Pretty much what ped7g said. Also if some Linux game developer chose to use e.g. appimages to release their Linux games on Steam (so that the Steam client mostly just downloads and launches the appimage), maybe that would also increase the likelihood of the same game (Linux version) appear on GOG, as I presume there would be no need to modify the appimage at all for GOG, from its Steam counterpart. (I have no idea how an appimage game would interact with Steam and Galaxy extra features though, like cloud saves, achievements etc.).

The self-contained packages are not more future-proof than a simple bundling. In fact, the opposite is true.
Some of the problems:
1) these packages are an applications per se and may require additional libraries to the ones needed for the contained payload (I personally have run into an Appimage of the FreeCAD that refused to load due to system/required library mismatch);
2) in order to provide full compatibility one need to encapsulate the Linux kernel itself. Even though Linus Torvalds is strongly opposed to ABI changes, there is no guarantee they will not occur in the future. And containerization will not save from that. Not to mention future removal of 32bit support on 64bit kernels (AKA "multilib").
Next time you hear that tell him/her about "Windows 10" mandatory online updates. :) Last time I checked (which was literally yesterday :) ) Linux could work without any internet connection just fine.
And you can order a complete collection of software for Debian (5 DVD's as I can recall) for complete offline install. Needless to say, GOG is an online game store, entirely relying on its customers being… well… online. :)
If anything, there is no such thing as "ideals of GOG". To us, customers, GOG tells one story (old game preservation, you don't games, you own them, yadda, yadda, blah, blah, blah) but to its owners (stock share holders) CDProjekt Group tells entirely different things: social platform, online services, GOG Galaxy as a key factor in evolving into something more than just a store (not a single mention of the term "DRM-free" :) ). You can check their annual reports.
A flawed approach:
1) it uses an external redundant wrapper to bypass/fool Steam's and GOG's infrastructures. Another part of the mechanism -- another point of falure;
2) it uses an external redundant wrapper to bypass/fool Steam's and GOG's infrastructures. Valve will most probably not be amused when someone intentionally toys with its service;
3) it uses an external redundant wrapper to bypass/fool Steam's and GOG's infrastructures. Even provided Valve can not be bothered to actually check on every one of its developers, GOG, on the other hand, takes pride in actual manual checking of the games/patches delivered for distribution, ensuring everything works and repackaging/bundling with Galaxy. Even if it means a weekly delay after an initial Steam release (many developers have reported it takes additional and draining effort to provide simultanious release on GOG, as all of the materials should be sent preemptively). There is no way GOG is gonna handle this distribution process down to developers. It is a political descision and can not be negotiated.

AppImage still recommends to rely on the base system for standard, common dependencies and only bundle libraries that you don't expect on every platform you are targeting. This is basically the same strategy that GOG is currently following with their packaging.

Especially when running 32bit games from an AppImage, you will very likely have to install the basic dependencies from your distro first, ie glibc / opengl stack. Same way you have to do it with the current packaging.
In the end, the debate of which libraries to bundle with the application and which to expect from the base system is the same, whether you use AppImage or keep GOGs current installers.

I vaguely recall that somebody from GOG mentioned before that they looked into AppImage, but aside from the problem for modding, they also found that it had a negativ impact on the performance.

personal opinion: the idea that you'll find a deployment method that guarantees long-term functionality in an ever changing software/hardware environment without further maintenance (ie keeping the product in a frozen state), that's just a pipe dream. like chasing magic unicorns.
All these new tools, whether flatpak, snap or AppImage, may mitigate the cross-distro differences and bridge some gaps between a bleeding-edge Arch install and a 6 year old Ubuntu (in exchange for some drawbacks), but they won't give you a perfect solution to preserve a working game in all eternity.
The only way to achieve that is ongoing maintenance and, if necessary, adapting to newer platforms.

But hey, one of the core reason why people buy on GOG is that they committed themselves to doing exactly that. Though arguably more on windows than on linux (and arguably not really 100% perfect).

(of course all that could be a lot easier if game developers would take long-term preservation into account, instead of the usually prevalent "develop, release and forget" attitude.)

To me that is similar argumentation as:

- DRM doesn't matter because at some point you can't play your old games anymore anyway.

- A seatbelt is useless because you will still die if your car drops from a high cliff or a meteor hits your car.

A solution does not need to be perfect, as long as it mitigates a problem. Like using a seatbelt helps in certain situations, and DRM-free makes your games more (but not fully) future-proof.

To me, that sounds great already. And of course it doesn't have to be used for all software running on your system, on others the RPM/DEB repository model probably makes more sense. Games just happen to be one piece of software where people seem to face these compatibility issues more often (when they e.g. want to play older games), but hardly anyone cares if they can't run WinZip 1.0 or Word 1.0 on their modern Windows 10 system anymore, as they have better choices available already (like the latest 64bit 7-zip).

I assume it would make GOG's work easier too if they could ship (and keep) older dependencies with a game with which the game works, instead of trying to make the game work on non-compatible or missing dependencies, using various workarounds.

They are businesses making money (ie. they concentrate their development efforts on newer games that make more or any money), and game studios come and go. Releasing games as DRM-free appimages, to me, sounds one way to take long-term preservation into account. :)

A seatbelt doesn't save your life if a meteor hits your car, but that doesn't mean a seatbelt is completely useless and you should never use it.

I don't get this argumentation that a solution can be only 100% perfect or completely useless.

the probability of running into incompatibilities issues despite the software being packaged as an AppImage is a lot higher than getting hit by a meteor. Not sure that analogy makes any sense.
The idea that you can cleanly and totally separate the game+dependencies from the software of your base system just doesn't work that well in practice. Which is not so much a problem as long as the base systems are still relatively similar. But since you specifically asked about long-term preservation, like 15 years, I still believe the form of packaging doesn't really solve that issue.


If you just want some improvement now, so that users don't have to install additional dependencies, and things "just work", then sure flatpak & co might offer some more convenience.
The question remains whether the plus on convenience versus their individual flaws versus time & effort to implement the changes is worth it?
I'm still not entirely convinced that these new forms of packaging are good enough to be worth it.

just shipping older dependencies (and hope they continue working) is their current modus operandi already.

On principal level, you can add middle layer between game's file system calls and the original image, so any mods or saves can be then stored in separate image or even in native host fs (not sure if something like this is already easy to configure for snaps/flatpak/appimage, but for example docker images are layered like this, if you base your modification on previously known/cached image, only the delta of your newly added/modified files is added as new layer, making it easier to upload new image back to cache or preserve it). The fs performance will suffer a bit by all this indirection, but I don't think it would be *that* bad.

About game-dev attitude to "develop, release and forget"... would be fine by me, if that "release" part would include a source too. I don't see any reason why a dev should care about his SW more than he is willing to. Other artists are not bound to keep updating their art, after they decide they are done with it, either. (speaking outside of commercial contract, if somebody advertises a SW with some target platforms, and you buy it, and it doesn't run, then they definitely should do something about it, because that's business contract ... but without that contract agreed upon ahead, if you want to use some SW, it's just yours problem and business)

And with game-dev biz you don't have any chance to care about old projects, there's not enough funds to do this. But people releasing their projects without full source are creating zombie SW. It may look alive and working upon arrival, but it's already dead.

I'm actually curious why so much effort goes into trying to preserve these zombies. I understand it would be quite some loss, but then again these efforts are kinda making it even worse, because then the SW authors thinks there will be always somebody who will take care of it. Or actually, lot more likely, they don't have even time to think about this stuff. Maybe after they are retired, they will note all of it is gone, but from talks with some people in the game-dev who are doing it 30+ years, they usually don't even care that much. For many of them all the older projects are kinda lame, because "they would be able to create them so much better today" (sentiment thing, don't take it as fact, in reality people remastering some of their older gems sometimes just ruin it :D )

But overall, it's enough fuss to support SW which has sources. If you are having fun preserving old SW, don't bother with zombies, try to help with the regular OSS, it will bring lot more value over time, as those things have at least some slight chance to be long-term preserved. For closed-source the open-source emulator is pretty much **only** hope.

Sorry if this has been covered in one of the previous 71 pages, but I'm finding that I can play all the games I want to play through wine if I run the installer every time, and click "launch game" after the installation. So really, I'm quite happy with that situation, as it's a fairly minor inconvenience, but I can't work out how to make the games work though wine without re-installing.

Does anyone have tip on this specific case? I've tried copying the important params from the desktop link and the launcher in the installation directory, but I've had no luck so far.

(FWIW, here are the games I currently have installed Banished, 'Interstate 76', 'Lands Of Lore', 'Legend of Kyrandia - Hand of Fate', LIMBO, 'Might and Magic 7', 'Mini Metro', 'Monkey Island 1 SE', 'Space Quest 4', 'Space Quest 5,' 'Torchlight 2', 'Ultima Underworld')

Are you familiar with how to set up a Wine prefix, and launch something in it? One recommended details is to always be in the directory of where the binary is located when launching it (like from your script).

It may help to provide some info about your system at least. Not all Linux distros behave the same way. It would also be helpful to know how exactly you're trying to launch your games. Are you using or do you want to use your GUI file browser, desktop icons, a tool like Lutris or maybe the terminal? All are possible, some you may find more comfortable.

Starting WindOS games:
Navigate to the installation folder and double click on the appropriate .exe file of the game. This will invoke your system's Wine version.

Starting Linux games:
To start GOG games manually you'd execute the shell script in the game installation folder (that's where also a file called 'gameinfo' is located), you do this by first making it executable (chmod a+x) and then executing it (that depends on your distro, e.g. double click in file browser or ./startscript.sh in the CLI).

I recommend looking at Lutris though. It displays all your games with a little icon and you can simply start them by pressing the 'Play' button. If you ever want to adjust some Wine settings or use different Wine versions for different games, it lets you do that easily. You can also use Lutris to get a newer or older Wine version than your current system's one to make certain games run better or use DXVK or Esync etc. It's pretty convenient imho.

Hey umm..recently started using linux and like it except the limitations for games and programmes etc available for it compared to windows,

Basically wondering... the old dos based games on here are pre set up to run on modern systems using dosbox, right?

I also know old windows games can run on linux via dosbox as it emulates the necessary environment....(although using dosbox in windows is so much easier and straightforward , I'm still trying to figure it out in linux)

So....is there any way to make games like the KQ series on here to run on linux even if they are listed as windows only by accessing and changing the dosbox commands used? Or...no?

Correct

Not really correct unless you mean Windows 3.11 or older. For running games made for Windows, you want Wine and possibly other programs as well like DXVK.

Yes, two ways but both demand that you have some understanding on how DOSBox works. Read up here: https://www.dosbox.com/DOSBoxManual.html

So the two (or three) ways would be either unpacking the Windows installer with Innoextract or, less neat, installing it in Wine in Linux and then moving it to where you want ( like /home) or just playing it in Wine.