Thanks but no thanks. I always unpack my tarball'd games to /mnt/buffalo_ext/games/ and, if they're a .deb, I manually extract them using ark, file-roller, or ar+tar. I then set ownership to root and mark them read-only and figure out which symlinks, if any, are necessary to force them to save their state in ~/.local/share/ where my nightly backup will catch it.

(As you might have guessed, I'm looking forward to the day when I can upgrade to a kernel with an overlay filesystem included.)

For installer-only games from Humble like the copy of Desktop Dungeons I'm currently running, I plan to write an easy "unpack as a restricted user, then copy into place using trusted code" wrapper once I finish the "Steam-like launcher for DRM-free games" project I'm currently working on.

(Here's the test GUI I'm currently using to exercise the various backends as I develop them. It currently keeps no state and what you see is all raw auto-detected and heuristically inferred information. Also, note that the blurriness on the Crayon Physics and Delve Deeper icons is because I haven't yet bypassed the PlayOnLinux and Desura client icon scaling to go direct to the source and, since I took that screenshot, I fixed the DOSBox icon size issue.)

So you would just have to launch the script preceded by 'PREFIX=/mnt/buffalo_ext/games/$game_name', seeing as the packages built by these scripts already install files only writable by root and put the user-writable data under '~/.local/share' ;)

More seriously so, I understand why "tech-savvy" users wouldn’t be interested in using these scripts that are more targeting a more "mainstream" audience. We all have our own way to dealing with game installation, and switching to another one is generally not a valid option. But you might want to have a look on the scripts contents, as I use a method similar to yours of game data writable only by root + symbolic links in $HOME.

Once again, that’s *exactly* what my scripts are! The package building process is done by your regular restricted user and end with a .deb package. The install process is *not* done by the script.
The "copy into place using trusted code" part being done by DPKG, as usual with .deb packages.

Even if you’re not interested in using them, you should totally have a look at the code, for mainly two reasons:
_it might avoid you some research work on your own projects, as the code I write is totally free to re-use elsewhere (published under BSD 2-Clause)
_I’d love to read critics of the code, as that’s in my opinion the best way to improve it (yes, this one is a good reason only for my benefit, not yours)

Anyway, is there some place where I could have a look on your code? I’m always curious about projects more or less similar to my own.

+1 for the effort

For really big games I'd prefer to avoid installing them system-wide, since in my case I use a separate home partition, which has a lot more space than the root partition does. (if you just have everything in one root partition then this obviously isn't an issue)

I've always liked trying to configure things myself. For instance, if I wanted to set up a Windows game, I just run the GOG installer under Wine and use winecfg to make some tweaks on the game as needed. Or with DOS games, I just use innoextract to put the game files in a folder (I have a "dos" directory for all my DOSBox games ;) and mess around with dosbox-0.74.conf if need be. (I sometimes create my own config files for certain games, and desktop launchers to work with them) For ScummVM games I also use innoextract to get the game data, then manually add the game to its launcher list.

Pretty much goes for all the Linux systems I use. (as of right now I'm using Debian and Arch) One-click installs are sometimes more convenient, but again, I usually like to set this stuff up myself. :P

Thanks, encouragements are always appreciated!

Actually I use a dedicated partition for /usr/local, mainly because it is the place all of my big games go.
If you prefer to install your games in user-writable directories you clearly have no use for my scripts ;)

I usually follow a similar process, except for WINE games for which I go with innoextract/unar like for DOSBox/ScummMV games. One of the objectives of my scripts is to be usable without a GUI (for use over SSH mostly), so I had to take WINE out of the equation.

At first I wrote theses scripts to avoid keeping the same game installers twice on my HDD (the original installer + the .deb package), but with time passing by I tweaked them to be more user-friendly so I could share them, as well as cleaning and commenting the code so they could be used as some base if someone would like to write something similar for another packaging method.

Today’s game is dedicated to all of you who got weary of always playing those boring heroes, and would like to be *the* dungeon master for once. I’m speaking of course of Dungeon Keeper 2!

I suppose I could wrap your scripts in something to manually unpack the .debs. The problem with .debs is that they'd still clutter up my /var with package information. I specifically want it so I can remove games simply by deleting the folder, similar to app bundles on MacOS X.
Good point. I'll probably do that once I get back to working on the install process rather than presenting an enhanced experience for stuff already present.
I didn't have it up, but what the heck. I whipped up a quick README.md and posted it to GitHub.

https://github.com/ssokolow/game_launcher

It's a mish-mash of GPLv3'd files and MIT'd files at the moment because GPLv3 is my default license when unsure and I haven't yet gone through and made a clear decision on what I want to do, license-wise.

(Phew! I finally got this to post by chopping it up and posting it in pieces.)

Nice work there!

You shouldn’t have to bother with that actually. The package building process is done via a custom function (build_package), so you’d just have to edit this function definition in the scripts to have them build .tar.something archives or whatever you prefer to use. Or even have it directly put the data where you want it to go.

Thanks. I've been thinking about this for a while and I really didn't feel like any of the existing options met my needs but, at the same time, I don't want to duplicate effort if I can avoid it, so I'm working outward from the bits that are both unique and application agnostic.

(Hence the TODO about investigating the possibility of contributing this code to Lutris once it's solid rather than writing my own GUI from scratch.)

A new game got added to the list, and as I like hacking paladins and hoarding gold my last game of choice is the first Dungeon Keeper!

Not a new game added to the list this time, but a complete rewrite of the script for Worms 2!
It now includes a way to easily install synchronized intro videos instead of the out-of-sync ones that come with the GOG installer, and is a prototype for my new way to write unified scripts that "speaks" English or French depending of your OS settings.

Here comes a new script, for the twisted SF lovers: Anachronox!

Thank you, I'll try them the next time I want to play one of the supported games (I already have a couple which remain unplayed and I'm planning to play them).

What games are the ones you’re planning to try?
I’ll put them on top of my list of scripts to update ;)

A new day, a new game, this one is for D’n’D fans: The Temple of Elemental Evil!