Nvm, I figured it out. This post can be deleted if required.

Wanna bet?

Seeing how today is Feb 8th, you're a bit late for betting on an event that took place on Feb 5th.

The game is scheduled to the next year, all indications point towards the next 'generation' of consoles being released during it.
Yes, brilliant 'solution'. Let's also spread all the games for windows in self-extracting archives that'll just install wherever, I mean who would care about such things as proper installation!

Hahahaha! :) I didn't think before writing that! Oh well we all make mistakes. But yeah, GOG is sadly not gonna support Linux :(

I am afraid pigs will be flying in a frozen hell before that happens.

There is no "proper" way to distribute these games. Install it either in the home dir under "GOG Games" or some other user specified path. Arguing about packaging, in this instance, is pointless.

It's not pointless, packaging is the correct and proper way to support a platform. Users of any OS will expect full functionality out of a product that claims to support the system, and not supporting one of the most important aspects like ability to support multiple users is just a bad, bad idea. Not to mention that this way of 'installation' might lead to problems, but I won't even go into the discussion of 'why do you put stuff where it belongs'.

Putting stuff in a tarball is still called "packaging". Ask the slackware guys. It can be a .run script with a GUI like the Qt SDK uses. It really does not matter. As long as the users are told what to do and as long as bugs get fixed and bugfixes get distributed. As for "where stuff belongs" we're not talking about core files of the system, it's a stupid application. Under Linux and Unix environments, installing software in a user's home dir has been supported for ages.

A lot of third-party packages are badly done and can screw up your package management. A game might, for instance, include it's own bundled libSDL and "provide" it, causing the game to be installed instead of libSDL at some point. Or just make poor assumptions, such as being able to create new users or to write to /usr/local.

I see nothing wrong with an installer that just asks for a single directory to install in and optionally creates links to /usr/local/bin (if permissions permit). This is how it's been done a lot since Loki ports. It works, it will never hose your system as long as you don't run it as root, and when you need to uninstall you just delete the whole directory.

Package management is a great tool for some things, but in here I can only see it getting in the way.

The same under Windows (and DOS) and Mac OS, since before either even had home directories, yet on Windows GOG does the equivalent of shoving the games under a world-writeable /opt/GOGcom (because the games very often save in their own directory).

For OS X, many developers/distributors, including GOG, don't even use an installer, but lets the user copy the package wherever they wish since it's quite self-contained in a form that doesn't really exist on other platforms - a folder that is treated as a single file and launches the application rather than opening in the file manager.

Since when is putting an application into your /home dir considered bad? In fact that's what Unix systems expect.
Package managers are a bit differently, they install applications for all users (/bin and /usr/bin) which is especially useful for getting updates.
So the only problem you might have by putting stuff in your home dir: you won't get automatic updates which is pointless here anyways.

A lot of time /home is mounted with noexec, for security reasons.

That is a good point but this is more or less true for multiuser environments where you need that extra security. In that case you're probably not allowed to install games anyways, as you would have to ask your administrator (aka root) to install that specific package.

If it's about your own system: why would you do that there?

Well quite a few people that I know of have computers in their household designed so their kids can't break anything, but can play games and do ... well, stuff. With increasing constraints come more and more issues which may arise, not to mention the simple fact that it's much easier when you can just work with a single installation as opposed to multiple. These systems were not designed the way they're designed just because it was fun to do you know,

First of all: no need to patronize me, I'm very well aware of the implications, as stated above.

So you're talking about preventing your kids from breaking stuff. How is that related to noexec? Without root access there's no way to break anything, except their own accounts and mounting a partition noexec won't even prevent that.
Granted, there are situations where you might gain root access via exploits but if your kernel is not patched and vulnerable to something like that you're in trouble anyways.

Those systems were indeed designed the way they were and that was: a multiuser environment were applications are executed with user privileges. Also, keep in mind that ANYBODY with physical access can compromise your machine at will. It doesn't matter if you're using Windows or Linux. You could simply boot from a rescue CD and chroot into your installation.