Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Wednesday, February 17, 2021

Adventures in Old-School Gaming on Linux Mint 20.1

Linux Mint 20.1 was released shortly after my last post, and now I guess that saves me the trouble of putting a "Part 2" in the title of this addendum to that earlier post. Nothing below actually has anything to do with the upgrade to Linux Mint, though; everything done here should work on Linux Mint 20 and everything described in the earlier post should work on Linux Mint 20.1. If the title of this post misleads the hypothetical reader into thinking otherwise, then the reader must not be reading this opening paragraph and probably deserves to be confused.

Anyway, I installed some more extremely ancient video games on my Linux computer with varying degrees of ease. I'm documenting this mostly for my own sake — but if it helps anyone else, that's super neat.

Game Data Packager

I was able to install a few more games with this nice little tool whose general usage is documented a bit more in my previous post.

Some LucasArts Adventure Games

I happen to have copies of Indiana Jones and the Fate of Atlantis, Sam & Max Hit the Road, Full Throttle, and The Dig on the original CDs. Linux Mint makes mounting CDs and ISOs pretty easy, so without even really knowing how it works, I was able to mount each CD and run game-data-packager for each.

game-data-packager -d ~/deb/ -i atlantis /media/michael/ATLANTIS/  # with Indiana Jones mounted
game-data-packager -d ~/deb/ -i sam-and-max /media/michael/disk  # with Sam & Max mounted
game-data-packager -d ~/deb/ -i dig /media/michael/DIG1/  # with The Dig mounted

I tried the same with Full Throttle, but for some reason it didn't recognize the game data on my disc. Maybe the data is corrupted due to an unfortunate scratch on the disc; maybe there are different versions of the game and game-data-packager just doesn't recognize mine. In any case, I do have Full Throttle Remastered on Steam which is natively Linux-compatible so I guess it's not a big deal.

For Atlantis, Sam & Max, and The Dig — which all run in ScummVM — the use of game-data-packager saved me the trouble of manually locating and copying the necessary game data files, and also created menu shortcuts. I think it also would have installed ScummVM automatically, if I hadn't already installed it for some free games acquired via Linux Mint's package manager:

sudo apt install beneath-a-steel-sky drascula flight-of-the-amazon-queen lure-of-the-temptress

Some Apogee Games

I've had The Apogee Throwback Pack in my Steam account for a while, but had never actually installed it before this week. The pack comes with Blake Stone: Aliens of Gold, Blake Stone: Planet Strike, Rise of the Triad, and Extreme Rise of the Triad. The game-data-packager tool supports all of them.

Rise of the Triad

With the pack installed via Steam, I executed the following:

mkdir -p ~/deb
game-data-packager -d ~/deb/ -i rott

This automatically installed a Rise of the Triad source port for me. However, the correct usage of it wasn't immediately obvious. It created a single menu shortcut called "Rise of the Triad" which simply runs rott; meanwhile, the newly installed /usr/games/rott is a link to /etc/alternatives/rott which by default is a link to /usr/games/rott-shareware which runs the game's shareware episode, even though game-data-packager did find the full game in my Steam directory. A separate executable, /usr/games/rott-commercial, runs the full game. Meanwhile, /etc/alternatives/rott can be updated to point to rott-commercial instead of rott-shareware by running update-alternatives --config rott and selecting the appropriate option. Confused yet? Well, I guess it's really not that confusing, but I'm a little disappointed that game-data-packager effectively provided only a shareware menu shortcut out of the box when I was trying to install the full game.

I didn't bother with update-alternatives; I just created my own menu shortcut (in ~/.local/share/applications/ to override the existing one in /usr/share/applications) which explicitly runs rott-commercial instead of rott. (Later on, I also went back and created another shortcut which explicitly runs rott-shareware, which seems worth having because the shareware episode is actually separate from any of the episodes in the commercial release.)

Running Extreme Rise of the Triad was a bit trickier. At first, I had no idea how to do it. Documentation is sparse, even on the source port's official site. Then I opened up Synaptic Package Manager and checked the description of the rott-extreme-data package installed by game-data-packager; it indicates Extreme Rise of the Triad is played by running rott-commercial -filertl extreme.rtl. However, even this isn't quite right. That file's name is actually uppercase, and I had to provide the full path, so the correct command to run Extreme Rise of the Triad is rott-commercial -filertl /usr/share/games/rott/EXTREME.RTL. I made a menu shortcut for that too, so now I don't have to think about it anymore.

Blake Stone

Next up are the Blake Stone games. Again, with The Apogee Throwback Pack installed via Steam, I used game-data-packager to package up the game files:

mkdir -p ~/deb
game-data-packager -d ~/deb/ -i blakestone

Unfortunately... well, this didn't do much for me. It didn't automatically install any Blake Stone source port, or anything else with which to run the game. It just packaged up the game data files and installed them to /usr/share/games/blakestone/. So I had to install a Blake Stone source port called BStone myself. The installation was done approximately as recommended in the README on the project's GitHub page, the only differences being the install location and the fact that I had to install cmake on the spot:

mkdir -p ~/git
cd ~/git
git clone https://github.com/bibendovsky/bstone.git
cd bstone/build
sudo apt install cmake
cmake ../src -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/git/bstone/build/install
make install

I don't know why the documentation recommended installing to a subdirectory of the build folder. I shouldn't have listened. To make things a bit less horrible, though, I just had to create a link to the bstone executable in a location that appears in my $PATH:

sudo ln -s ~/git/bstone/build/install/bstone /usr/local/games/

Now I can just run bstone. But the source port doesn't know to look for data in /usr/share/games/blakestone/, where game-data-packager installed it, so I actually have to run bstone --data_dir /usr/share/games/blakestone to make it work. Meanwhile, running bstone --aog --data_dir /usr/share/games/blakestone makes it run Aliens of Gold without prompting to select a game, and bstone --ps --data_dir /usr/share/games/blakestone does the same for Planet Strike.

Aleph One

Marathon Trilogy

I wanted to play Marathon again, so I set out to install Aleph One. For the same reasons mentioned a while ago, I was hesitant to rely on the probably outdated tarball made available on the official Aleph One site. So, as I've done before, I checked out the latest source code from GitHub and compiled it. This required installing some dependencies as documented in the README on the project's GitHub page. I had neglected to document the exact process before, so now here it is:

mkdir -p git
cd git
git clone https://github.com/Aleph-One-Marathon/alephone.git
cd alephone
sudo apt install autoconf automake
sudo apt install libboost-all-dev  # Boost
sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-net-dev libsdl2-ttf-dev libsdl2-mixer-dev  # SDL2-related
sudo apt install libavcodec-dev libavformat-dev libavutil-dev libswscale-dev  # FFmpeg-related
sudo apt install libspeexdsp-dev libzzip-dev libpng-dev libcurl4-gnutls-dev  # Other
./autogen.sh
make
sudo make install

With that done, I downloaded the game files from the Aleph One site, and created a menu shortcut for each of the three Marathon games. Each shortcut just runs alephone <dir>, where <dir> is the location of that game's files.

After doing this, I noticed that game-data-packager does support the Marathon trilogy, but I'm not sure what it would have done for me here except perhaps installing the game files to some system-wide location instead of the ~/.local/share/games/ folder where I dumped them. It wouldn't have installed Aleph One for me, because it's not in my distro's package repository.

Saturday, January 2, 2021

Adventures in Old-School Gaming on Linux Mint 20

I had some free time recently, so I finally did a clean install of Linux Mint 20 on my PC, which seemed preferable to attempting an upgrade from Linux Mint 19.3. As usual, after getting all of the basic programs installed, I started reinstalling some essential games: Wolfenstein 3D, Doom, etc.

I did things a bit differently from last time — better, and less hacky, I hope — which required educating myself a bit. I also found a bug which doesn't seem to have been documented anywhere, and I honestly cannot be bothered to figure out where or how to submit a bug report, so I'm just going to document it here. Maybe it will help someone.

ECWolf and GZDoom

As I had done before, I started by installing some source ports: ECWolf for Wolfenstein 3D and Wolfenstein 3D: Spear of Destiny; and GZDoom for The Ultimate Doom, Doom II: Hell on Earth, Final Doom, Heretic: Shadow of the Serpent Riders, Hexen: Beyond Heretic, and Hexen: Deathkings of the Dark Citadel. Unfortunately, these source ports are not provided in Linux Mint 20's default package repository. Perhaps the easiest way to get ECWolf and GZDoom is to download .deb files from here and here respectively, but for the sake of automatic updates, I think it's best to grab them from the DRD Team repository:

wget -O- https://debian.drdteam.org/drdteam.gpg | sudo apt-key add -
sudo apt-add-repository 'deb https://debian.drdteam.org/ stable multiverse'
sudo apt-get update
sudo apt install ecwolf gzdoom

These don't actually come with the game files, though, so I downloaded the relevant games from Steam. (Although they could easily be acquired by... other means... they happen to be in my account thanks to bundles and gifts, and it's just the easiest way for me to get the data.) The Steam versions of the aforementioned games run in DOSBox by default, and the classic Doom games now come with the Unity ports as mentioned in an earlier post, but I would rather take the files provided by Steam and use them with Linux-native source ports.

Manual file management

What I did next, I now realize you probably shouldn't do. I manually copied the necessary game data into ~/.config/ecwolf/ and ~/.config/gzdoom/ as appropriate:

cp -t ~/.config/ecwolf/ -- \
    ~/.steam/steam/steamapps/common/Wolfenstein\ 3D/base/*.WL6 \
    ~/.steam/steam/steamapps/common/Spear\ of\ Destiny/base/*.SOD \
    ~/.steam/steam/steamapps/common/Spear\ of\ Destiny/base/*.SD1 \
    ~/.steam/steam/steamapps/common/Spear\ of\ Destiny/base/*.SD2 \
    ~/.steam/steam/steamapps/common/Spear\ of\ Destiny/base/*.SD3
for sd1 in ~/.config/ecwolf/*.SD1; do mv -f $sd1 $(echo $sd1 | sed s/SD1/SOD/); done
cp -t ~/.config/gzdoom/ -- \
    ~/.steam/steam/steamapps/common/Ultimate\ Doom/base/Doom.WAD \
    ~/.steam/steam/steamapps/common/Doom\ 2/base/Doom2.WAD \
    ~/.steam/steam/steamapps/common/Final\ Doom/base/PLUTONIA.WAD \
    ~/.steam/steam/steamapps/common/Final\ Doom/base/TNT.WAD \
    ~/.steam/steam/steamapps/common/Heretic\ Shadow\ of\ the\ Serpent\ Riders/base/HERETIC.WAD \
    ~/.steam/steam/steamapps/common/Hexen/base/HEXEN.WAD \
    ~/.steam/steam/steamapps/common/Hexen\ Deathkings\ of\ the\ Dark\ Citadel/base/HEXDD.WAD

For the most part, this is pretty straightforward, but things get a bit weird when we look at the Wolfenstein 3D: Spear of Destiny files. That ugly file renaming in the for loop ensures that the *.SD1 files that come with the Steam version of Spear of Destiny have the proper *.SOD names. I think Steam has these *.SD1 files because, when running the game with DOSBox, it needs to rename the *.SD1, *.SD2, or *.SD3 files to the appropriate *.SOD names depending on which mission pack is being played. ECWolf, meanwhile, just wants the Mission 2: Return to Danger and Mission 3: Ultimate Challenge files to be named with *.SD2 and *.SD3 respectively. At least, I think that's how it works. In any case, the manual renaming above resulted in ECWolf running each mission pack correcty with no complaints. So this manual file copying and renaming is an option if you just want to run the Steam versions of all these games with ECWolf and GZDoom.

However, I ended up undoing all of this manual file management in favor of experimenting with a program called game-data-packager, which took some work to understand but seems to work quite nicely most of the time.

Game Data Packager

I became aware of game-data-packager not because I went looking for such a tool, but simply because it was installed automatically as a dependency when I installed some Linux-native engines for Hexen II and the Quake trilogy (more on that later). If you don't already have it installed automatically for similar reasons, you should be able to install it on Linux Mint 20 as follows:

sudo apt install game-data-packager

Once installed, the game-data-packager program can be used to identify the required files for various games, and install them for use with various source ports.

The basic syntax is

game-data-packager [-d OUTDIR] [-i] GAME [PATH ...]

where GAME is the name of a supported game, and PATH tells the program where to look for the game's files (if it can't find them on its own). The game's files are packaged into one or more .deb files, which are written to the current working directory by default but can be sent to some other directory OUTDIR using the optional -d argument. The optional -i flag tells game-data-packager to go ahead and install the new .deb file(s) using the system's package manager. I think it's safe to delete the .deb files after installation unless you want to keep them. At this point, however, you'll need to use sudo apt remove with the name of the locally installed package (e.g. sudo apt remove doom-wad) in order to uninstall the game data from your system.

When executed with the -i flag, game-data-packager also attempts to install dependencies, including source ports and native engines, if they're not already installed. Basically, it should give you everything you need in order to play the game, as long as you supply the copyrighted data.

Wolfenstein 3D

For Wolfenstein 3D and Spear of Destiny, my usage of game-data-packager was as follows:

mkdir -p ~/deb/
game-data-packager -d ~/deb/ -i wolf3d
game-data-packager -d ~/deb/ -i spear-of-destiny

Additional positional arguments would specify folders in which to search for each game's files, but game-data-packager is smart enough to look in Steam's directories. Since I had already downloaded the games via Steam, the above commands were enough to locate the games on my system, package the necessary data into .deb files (which I saved to a ~/deb/ folder I had created), and install the games from those .deb files. In this case, the Wolfenstein 3D and Spear of Destiny data files get installed to /usr/share/games/wolf3d/. The package manager tracks these games' data as the locally installed packages wolf3d-v14-id-data, spear-of-destiny-data, spear-of-destiny-mission1-data, spear-of-destiny-mission2-data, and spear-of-destiny-mission3-data.

However, it assumes you want to use Wolf4SDL for Wolfenstein 3D; it did not care that I already had ECWolf installed, so it installed Wolf4SDL for me. If you want to use Wolf4SDL, you're in luck. If you're like me and you want to use ECWolf instead, you can either edit the BaseDataPaths field in ~/.config/ecwolf/ecwolf.cfg to include /usr/share/games/wolf3d/, or you can make some links:

ln -s -t ~/.config/ecwolf/ -- \
    /usr/share/games/wolf3d/*.wl6 /usr/share/games/wolf3d/*.sod \
    /usr/share/games/wolf3d/*.sd2 /usr/share/games/wolf3d/*.sd3

This got ECWolf to see all of the files it needs on my system. Wolf4SDL is still installed, which is a bit redundant, but I don't mind.

Doom

Next I used game-data-packager to package up the classic Doom games — The Ultimate Doom, Doom II: Hell on Earth, Master Levels for Doom II, and Final Doom — which I had also downloaded via Steam:

mkdir -p ~/deb/
game-data-packager -d ~/deb/ -i doom
game-data-packager -d ~/deb/ -i doom2
game-data-packager -d ~/deb/ -i final-doom

This installs all of the relevant .wad files to /usr/share/games/doom/, tracked by the local packages doom-wad, doom2-wad, doom2-masterlevels-wad, plutonia-wad, and tnt-wad. As with the Wolfenstein games, game-data-packager also automatically provided me with a source port, Chocolate Doom. I probably won't it use very much, because I already have GZDoom installed, but it doesn't hurt. Meanwhile, no tweaks were required to get GZDoom to find the data files; its default configuration included /usr/share/games/doom/ in the search path.

Master Levels

In addition to Chocolate Doom, the automatically installed dependencies also included a program called doom2-masterlevels which provides a simple GUI for selecting maps from the Master Levels pack. (Note that the command ending in doom2, above, took care of packaging the Master Levels for Doom II data as well as the Doom II: Hell on Earth data.) Here's where things get weird, though: I didn't even notice this doom2-masterlevels program until I found it by accident. There should have been a shortcut created in the Linux Mint menu, but it wasn't there. This is because the desktop entry file at /usr/share/applications/doom2-masterlevels.desktop contained a mistake:

TryExec=/usr/share/games/doom2-masterlevels-tryexec

The file referenced in that TryExec field, /usr/share/games/doom2-masterlevels-tryexec, does not exist. As a result, the entry was ignored and did not show up in the menu. However, the file /usr/share/games/doom/doom2-masterlevels-tryexec does exist. This discrepancy in the .desktop file is obviously a bug. I honestly cannot be bothered to figure out how to report this bug, to whom it should be reported, or whether it has perhaps already been fixed in a newer version of game-data-packager than my package manager provides. (Linux Mint does not always have the latest version of everything.) However, it's easy enough to fix the desktop file by changing the TryExec line:

TryExec=/usr/share/games/doom/doom2-masterlevels-tryexec

If you don't want to use a text editor, this can also be done from the command line using sed:

sed s/\\/usr\\/share\\/games\\doom2-masterlevels-tryexec/\\/usr\\/share\\/games\\doom\\/doom2-masterlevels-tryexec/ -i /usr/share/applications/doom2-masterlevels.desktop

With that fixed, the "Doom 2: Master Levels" entry now shows up in the menu.

Heretic and Hexen

I ran into some more minor trouble when I tried to package the Heretic and Hexen files. As with the previous games, I had downloaded them from Steam and tried running game-data-packager with the -i, and it failed with errors about engines not being available. Specifically, for Heretic:

ERROR:game_data_packager.build:Engine "chocolate-heretic" is not (yet) available, aborting

And for Hexen:

ERROR:game_data_packager.build:Engine "chocolate-hexen" is not (yet) available, aborting

However, these errors are nonsense. When the Chocolate Doom source port was automatically installed to /usr/games/chocolate-doom upon packaging and installation of the classic Doom games, the executables /usr/games/chocolate-heretic and /usr/games/chocolate-hexen were installed as well. These actually appear to be Chocolate Doom under the hood, but I quickly confirmed that they were able to run Heretic and Hexen respectively if executed with the appropriate -iwad arguments. Perhaps game-data-packager gets confused because chocolate-heretic and chocolate-hexen are virtual packages. In any case, to get past these bogus errors, we can omit the -i flags so that game-data-packager just creates the .deb files, and then install from those .deb files using apt:

mkdir -p ~/deb/
game-data-packager -d ~/deb/ heretic
game-data-packager -d ~/deb/ hexen
sudo apt install ~/deb/heretic-wad_64_all.deb
sudo apt install ~/deb/hexen-wad_64_all.deb
sudo apt install ~/deb/hexen-deathkings-wad_64_all.deb

I've probably discovered an actual bug here as well, but again, I really don't know how and to whom it should be formally reported, and the workaround was easy enough.

Hexen II

Hexen II is playable on Linux with the Hammer of Thyrion source port, which is called uhexen2 in Linux Mint 20's package repository. Hammer of Thyrion recognizes game data placed in ~/.hexen2/data1/, so we can copy the appropriate .pak files into that directory manually after installing uhexen2. Alternatively, we can use game-data-packager to install the files to /usr/share/games/hexen2/data1/, tracked by the local package hexen2-data. Again, I had downloaded Hexen II via Steam, so I didn't need to tell game-data-packager where to look for the files:

mkdir -p ~/deb
game-data-packager -d ~/deb/ -i hexen2

I think this would have resulted in the automatic installation of uhexen2, if not for the fact that I had already installed it beforehand using apt:

sudo apt install uhexen2

So that probably could have been skipped.

Quake

Linux Mint 20 also provides native engines for Quake, Quake II, and Quake III Arena, and all of these games are supported by game-data-packager. All three games are also on Steam, but I don't have the Steam versions. I have them on a set of CDs, in a box set called The Ultimate Quake, which I had purchased before I even created a Steam account. Fortunately, my outdated PC still has an optical disc drive, and game-data-packager can read from CDs (although it apparently needs to be told explicitly where to look).

The funny thing about Quake and Quake II is that the discs contain both game data and CD audio. In other words, each CD-ROM is also a music CD. Not surprisingly, game-data-packager creates separate packages for game data and music, hence the separate game-data-packager commands below. (Maybe the game files and music packages for a game can be created with a single command, but I used separate commands anyway because I don't think combining them would make things less confusing.) Meanwhile, ripping the CD audio required some extra dependencies which were not made known to me until game-data-packager started complaining that it could not find cdparanoia or oggenc. I assume these were not automatically installed as required dependencies because they are only sometimes needed. In any case, installing cdparanoia is trivial because that's the exact package name, and oggenc is made available for Linux Mint 20 in the package vorbis-tools, so I installed both:

sudo apt install cdparanoia vorbis-tools

Now, to install Quake, I ran the following commands with the CD inserted:

mkdir -p ~/deb
game-data-packager -d ~/deb/ -i quake /media/michael/Winquake/
game-data-packager -d ~/deb/ -i quake -p quake-music /dev/cdrom
game-data-packager -d ~/deb/ -i quake -p quake-aopfm

In the command to package and install the game data, /media/michael/Winquake/ is the location to which Linux Mint automatically mounted the CD when it was inserted, so that part will vary. The game's music doesn't show up in /media/michael/Winquake/ (because, I guess, that's just not how CD audio works), so in the command to rip the music, I used /dev/cdrom (which is a reference to the optical disc drive itself, and is actually a symbolic link to /dev/sr0). The last command installs the package quake-aopfm which is a free expansion. I can't vouch for whether this expansion is any good, because I haven't played it yet — but I noticed after installing the base game that a shortcut for the expansion had already been created in my menu, and that expansion shortcut wouldn't work without the expansion's package installed, so I figured I might as well install it instead of deleting the broken shortcut.

Installing Quake II was similar. I swapped out the Quake CD for my Quake II CD and ran the following:

mkdir -p ~/deb
game-data-packager -d ~/deb/ -i quake2 /media/michael/Quake2/
game-data-packager -d ~/deb/ -i quake2 -p quake2-music /dev/cdrom

Finally, Quake III Arena had no CD audio portion on the disc, so it required only this:

mkdir -p ~/deb
game-data-packager -d ~/deb/ -i quake3 /media/michael/Quake3/

I think these commands would have triggered automatic installations of these games' native engines, but I had already installed them manually beforehand:

sudo apt install quake quake2 quake3

Other Notes

I think much of what's written above could also be applied to other versions of Linux Mint, but I've been clear about the fact that I'm using Linux Mint 20 just in case I'm wrong about that. Meanwhile, as of the time of this post, I'm using gzdoom version 4.5.0, ecwolf version 1.3.3, game-data-packager version 64, chocolate-doom version 3.0.0-5, and uhexen version 1.5.9+dfsg-1.

Also note that game-data-packager gave me some warnings about being unable to unpack certain files due to missing programs, so I installed a couple of additional packages just to make the warnings shut up:

sudo apt install innoextract lhasa

However, these don't appear to be strictly necessary, and I'm not sure if it really made a difference. At least for the Doom games, game-data-packager was already finding all of the data needed for playing the games, despite the warnings.

Saturday, September 12, 2020

Classic Doom Unity Ports and Linux

This seems to be turning into a Linux gaming blog, and there's probably no stopping it, so I might as well not even try.

So, hey, the classic Doom games on Steam got updated to include those official Unity engine ports. That's cool. I mean, I guess it's cool. I'll defer to the video by GmanLives on YouTube for what's actually cool about it:

Update: It seems GmanLives has made the above video private, for some reason. Uh, okay...? Whatever. You don't need to watch this video before reading anything that follows. It was just a general overview of the Unity ports of the classic Doom games, and apparently some people disagreed with the opinions therein, but I don't remember any part of it being so controversial as to warrant removal.

It was thanks to GmanLives that I even found out about the updates to my Steam copies of these games. I go back to Doom and Doom II somewhat frequently, and in fact I do play the copies I bought from Steam, but I don't typically launch them through Steam. Last time I installed them, I immediately copied the WAD files out of the Steam folders to use them with GZDoom and then uninstalled the Steam copies. Therefore I don't often look at these games in my Steam library, and therefore didn't see the big "MAJOR UPDATE" notices, which I now see have been there since September 3rd.

So I was a bit excited when I heard that the Unity ports had come to Steam a week prior, because I thought I might be able to play the No Rest for the Living expansion for Doom II, which had previously been available on Steam only via Doom 3: BFG Edition, which I'm not going to buy because I already have regular old Doom 3. However, once I launched the game, I saw that the Unity version of Doom II includes only Hell on Earth and Master Levels by default. I think you can get No Rest for the Living as an official add-on, but that seems to require a Bethesda account. Maybe I'll create one. Maybe I'll download the WAD from elsewhere. I would rather play any add-on WADs in GZDoom anyway.

The real disappointment — and I'm fully aware that I'm nitpicking here — is that the inclusion of the Unity versions technically breaks the out-of-the-box Proton compatibility of Steam's The Ultimate Doom and Doom II: Hell on Earth on Linux. That's not a tragedy, because they can still be made to run on Linux quite easily. However, it's not a good look for Proton, because both games were whitelisted by Valve for Proton 3.7-8, and that whitelisting is now incorrectly applied to the Unity ports because they were added as updates to the existing games instead of showing up in users' libraries as separate items. Steam for Linux will launch the Unity ports with Proton 3.7-8 by default, and it won't work. Valve whitelisted these games only on the basis of their DOSBox-powered versions running well with that version of Proton.

Of course, using Proton to run the classic Doom games in the Windows version of DOSBox is a bit of a joke. You'll have a better experience running them in a natively Linux-compatible source port like GZDoom. If you really want to run them in DOSBox, there's a native Linux version of that too (and you can make Steam use it for DOS games by installing the compatibility tool Boxtron), so there's no good reason to run the Windows version of DOSBox in Proton. Nonetheless, Valve whitelisted the games for Proton 3.7-8 based on the fact that their old DOSBox-powered versions, in spite of themselves, did work perfectly in Proton 3.7-8 (and, in theory, still should). The new Unity versions don't run with Proton 3.7-8, nor do they work with the current version, Proton 5.0-9. They do seem to work perfectly with Proton 5.9-GE-5-ST, a fork of Proton which is not included in Steam by default but which is easy to install. So if you want to play the Unity ports on Linux, it requires only minimal effort.

The real problem here is that someone is bound to see "Proton 3.7-8 selected by Valve testing" on the newly updated classic Doom games and understandably assume the default versions of the games will run with Proton 3.7-8 out of the box. Now that the default versions are the Unity ports, that's not the case. When you launch either The Ultimate Doom or Doom II: Hell on Earth in Steam now, you will be presented with the option to run either the Unity version (which is the default) or the DOS version, and the default Proton version selected by Valve itself is good only for the DOS version which is now relegated to a secondary or extra option.

The other problem is that, because the Unity versions don't show up as separate games in the Steam library, you can't select different compatibility tools for the DOS and Unity versions. These versions being combined is good in general for those who don't want cluttered libraries, but preliminary testing on my own machine suggests that the DOSBox-powered version of The Ultimate Doom doesn't want to run using Proton 5.9-GE-5-ST which is the only way I know how to run the Unity version. If this is true and it's not just me, alternating between the two versions would require changing the game's compatibility settings each time. I suppose most people, upon deciding which version of the game they prefer, would just stick with it. Still, this bugs me.

Even if there is a Proton version which runs both DOSBox and the Unity ports, I still maintain that using Proton is sub-optimal for the DOSBox-powered versions anyway, and one should really be using Luxtorpeda as an alternative to Proton. Luxtorpeda runs the Steam versions of the classic Doom games in GZDoom automatically, and I probably would have used Luxtorpeda if I hadn't already set up GZDoom manually before I knew Luxtorpeda existed. However, selecting Luxtorpeda as a compatibility tool for The Ultimate Doom would work only for the classic DOS version; it wouldn't be able to run the Unity port. You can't select a single compatibility tool which runs both versions optimally, and you can't select separate compatibility tools for different modes of running a single entry in the Steam library.

In short, I'm slightly annoyed. I'm still just going to keep using GZDoom to run the original WADs anyway, so I guess you could say I'm annoyed on behalf of anyone who hasn't already figured this out. But I guess it's reasonable to assume that anyone who can't figure it out probably lacks the patience for playing games on Linux in the first place.

Saturday, July 25, 2020

Pinstripe and Broken Achievements

I wanted to write this post at the end of December, but the winter holiday season is a busy time, so that didn't happen. Then, by the time the holidays were over, I was already back at work, and forgot about it. Later on, I had an idea about writing this as a follow-up to How to Cheat in Spec Ops: The Line, but that didn't happen either, mostly due to laziness. Now I have a moment and I can only hope that I remember accurately the details of what I had meant to document in December.

So anyway, there's this game called Pinstripe. I have a hefty collection of random indie stuff in my Steam library, mostly from Humble Bundle and from Fanatical (formerly Bundle Stars), so I probably wouldn't remember exactly where I got this one in particular if there weren't records of it. Cross-referencing my Steam account's history of product key activations with IsThereAnyDeal's list of bundles featuring the game, I see that I must have gotten it from the $1 tier of Humble Jumbo Bundle 12, in late November of 2018. My achievement history shows that this is around the time I first played the game as well, so it didn't languish in my backlog for an extended period of time as many indie games from bundles tend to do. Late November into early December was a nice time to play the game as well, given the snowy winter setting.

Overall, it's a cute game. In any mini-review of any kind of game, I feel morally obligated to judge the gameplay first and foremost; but, in this kind of indie game, it would probably be a lie to say that the game and its mechanics are much more than a vehicle for the developer's artistic expression, which could have been channeled into a short film instead if it could have survived becoming that much less engaging. I won't claim to know the developer's intentions but I suspect the goal was to tell a story in an interactive medium and not to get the player hooked on addictive gameplay. So I'll just say that the gameplay is all right; it gets the job done, and manages to be neither frustrating nor entirely boring. But if you don't care for the story or the music or the art direction, you won't care for the game itself.

What stands out to me in hindsight is the audio. The soundtrack is really nice. The voice acting is also pretty great by video game standards. By the end, the story is perhaps a bit clichéd — well, perhaps incredibly clichéd, if I'm being perfectly honest — but its presentation is not as unbearably pretentious as so many indie games are. In short, they did a good job. It's a nice game. I should feel bad for having paid so little for it.

After having played through the game once or twice, I had unlocked all but one achievement:


Beating Pinstripe in an hour is not a remarkable feat. It's a short game. So, I thought, I might as well try it. There's no visible in-game timer, so I took note of the clock on my computer when I started, and played through the game, already knowing where to go and the solutions to the puzzles. I finished in less than an hour. The achievement didn't unlock. I figured the problem was that I had essentially started a "New Game Plus" so I deleted my save and even reinstalled the game to ensure I was starting with a clean slate. I finished the game in less than an hour again. The achievement didn't unlock.

A trip to the game's discussion forum on the Steam Community site revealed that I wasn't the only one having trouble with unlocking the achievement. It was apparently bugged. I checked the forum again today and it's apparently still bugged. There are workarounds which have solved the problem for some players. At least one guy claimed to have done it just by reinstalling the game, but that hadn't worked for me. In mid-December of 2018, someone came up with another fix which seemingly solved the problem for a lot of other players.

This fix involved editing the Windows registry. Specifically, according to this Steam forum post, one must clear a TotalPlayTime entry from HKEY_CURRENT_USER\Software\Atmos Games, LLC\Pinstripe. Yes, the game apparently tracks total play time in the registry. That just boggles my mind. I don't understand it. Perhaps I just don't understand game development or Windows software development well enough to see why Atmos Games would do this, but it seems insane to me. In any case, for whatever reason, this workaround didn't work for me. I assume I must have done it incorrectly, because it had worked for others. However, having failed once with this attempted registry hack, I had already failed the speedrun achievement at least three times in total, and I was fed up. I uninstalled the game.

However, this was not before I had seen another post claiming to have a fix for the Linux version of the game. At the time, I wasn't using Linux on my personal computer yet, but I figured I might try it someday. Sure enough, I started using Linux the following year. Attempting again to get the last achievement in Pinstripe wasn't really my top priority as a new Linux user, but I was bound to come back to it eventually.

So at the end of 2019, I reinstalled Pinstripe on Linux Mint. Now there was no longer a Windows registry claiming I had played for hours, so if I had still remembered how to finish the game quickly, I probably could have just unlocked the achievement fair and square in one attempt. Unfortunately, I hadn't played the game in about a year. I would most likely have had to play through the game once to remember what to do, and then a second time for the speedrun achievement. I had already messed around with this game enough, and I had already beaten the game in under an hour multiple times as verified by my own clock, so I didn't feel like playing fair. If this Linux workaround documented on Steam could be used to unbreak the achievement, it could also be used to cheat. So I decided to remove any chance of failure, and cheat.

I mean, in my defense, it was barely cheating. The game had already cheated me.

I played through most of the game, and sure enough, as I neared the end, I was not on track to beat the game in under 60 minutes. So I closed the game and, following the advice found in the Steam forum, I opened up the file ~/.config/unity3d/Atmos\ Games\,\ LLC/Pinstripe/prefs. It's a plaintext file in some XML-like format with a handful of tags specifying various preferences such as screen resolution height and width. As promised, there's also a line of the form
<pref name="TotalPlayTime" type="float">xxx</pref>
where xxx is the elapsed play time in seconds. Note that, for the sake of verifying what units are used here (for it could have been milliseconds for all I remember of December 2019), I just reinstalled the game and played it for about a minute, and this line in my current copy of this file now reads as follows:
<pref name="TotalPlayTime" type="float">62.1948</pref>
At the time I first found this file, I suppose it must have read something closer to 3600, as I was approaching the one-hour mark with not enough time to spare. So I opened up the file in vim, decreased the value by a few hundred seconds, opened the game back up, and played to the end. The achievement finally unlocked.

Now I've got my 100% completion in Pinstripe. Was it worth it? Well, no and yes. The time I spent trying to unlock the achievement on Windows was a waste of time. However, I still liked the game and wanted to play through it again last December; I also wanted to test drive the Linux version; and, while I was doing that, I figured I might as well get the achievement I was owed. Editing a text file, by the way, was a lot easier than playing around with the Windows registry. Linux wins again, I guess.

There are people who pay absolutely no attention to achievements. For the sake of my mental health, perhaps I should try to be one of them. For the most part, I guess I am. I have far too many games to be caring about unlocking all of the achievements in all of them, considering how many games have achievements which are just arbitrarily time-consuming, seemingly for no reason other than to decrease the number of players willing and able to unlock them and thus to increase their perceived value among self-proclaimed achievement hunters.

If I've already unlocked over 90% of a game's achievements, though, it's hard not to go for 100%. If there's only one achievement left, it's almost impossible not to try, or to be annoyed by it forever if I know it's unattainable. I have other games which, like Pinstripe, have some broken achievements, but there are not always easy workarounds to unbreak them. Do achievements really matter? Not really. But they're a part of the game, and you shouldn't sell broken stuff.

Dear game developers,
Stop selling broken stuff.

Thursday, February 6, 2020

How to Cheat in Spec Ops: The Line

Why Cheat?: A Quick Review of My Experience with a Not-Completely-Awful Game


I don't usually play military first-person shooters, let alone cover-based shooters like Spec Ops: The Line. But I got it for $1.00 (along with Duke Nukem Forever and The Darkness II) from Humble 2K Bundle 2, and... it wasn't that bad, at least on the default difficulty setting. I suppose it's precisely because I don't usually play this type of game that I didn't just see Spec Ops: The Line's cover-based shooting mechanics as an inferior version of what you would find in, say, a Gears of War game. For me, it was something different, and I enjoyed it, even though it was occasionally frustrating. Having gotten to the end of my first play-through, I could see myself playing it more, and none of the achievements seemed particularly hard to unlock, so I decided to play through the game a couple more times to go for 100% completion.

It was only at the point where I had unlocked all but one of the game's achievements — the one for beating the game on the hardest difficulty setting, FUBAR — that I realized how anti-fun the game could be. So I dropped it for a while. But after a few years of seeing 49/50 on the game's achievement tracker, it began to bother me.

The thing about me and achievements is that, while I'll make some effort to unlock them if they actually happen to be fun to unlock, I don't really care a whole lot about them otherwise... except in that they annoy me when they serve as a reminder of what's almost finished. In other words, while I don't normally treat a game with achievements as a tedious "to-do" list, 98% complete is just irritating.

So eventually, I did go back to the game and try to beat FUBAR mode, thinking it just couldn't be as bad as I remembered. But it was worse than I remembered. It was an enjoyable challenge for a while, and I actually got all the way to chapter 11 out of 15, but after a certain point, I couldn't play for more than 30 minutes at a time without getting annoyed. I wasn't enjoying it anymore, and while there were occasional moments of satisfaction in which I was able to pass a checkpoint by figuring out some optimal strategy and executing it perfectly, these moments were outnumbered by all the times when having gotten through a tough fight seemed like blind luck. The game's FUBAR difficulty setting isn't just unreasonable at times; it's also where the inherent flaws in the game's design really shine.

When one isn't having fun with a game anymore, does it make sense to keep playing just for an achievement? Not really. Not when nobody else is ever going to see or care about that achievement. When a game isn't fun anymore, the rational choice is either to drop it or to make it fun. I had begun to wonder if there was a way to cheat my way through the last bit of the game, as venting my frustration by breaking the game in some amusing way might make up for what felt like a waste of time so far. Turning that 49/50 into a 50/50 (so that even my undiagnosed OCD could accept that I'm done with the game) without having to subject myself to any more of this sadistic FUBAR nonsense would be nice too.

That's when I realized that the game's configuration files, which are encrypted in the Windows version on which I did the first half of my FUBAR play-through, are human-readable plaintext in the Linux version on which I continued the game after the termination of Windows 7 support gave me the final push towards using Linux for almost everything.

How To Cheat, The Easy Way: Step One Is To Install Linux (Which You Should Do Anyway Unless You Really Love Windows 10)


Install the Linux version of the game using the Linux version of the Steam client, and go to
~/.steam/steam/steamapps/common/SpecOps_TheLine/SRGame/Config
and you'll find a bunch of .ini files — 94 of them, by my count — and a single .txt file. I haven't fully explored the contents of these configuration files, because some of them are rather large, and there are too many of them to summarize here even if I had looked at them all. However, a quick browse through a few of them suggests that they contain variables for almost all the numerical and Boolean values one might want to alter, such as: player health, health regeneration rate, enemy health, the amount of damage required to explode enemies' heads, weapon damage, amount of ammo each weapon gets from ammo boxes, et cetera.

Some files have multiple variations. For example, the files
SRPawnEasy.ini
SRPawnEasy_Coop.ini
SRPawn.ini
SRPawn_Coop.ini
SRPawnHard.ini
SRPawnHard_Coop.ini
SRPawnInsane.ini
SRPawnInsane_Coop.ini
all contain values like character health. The ones with the "Coop" suffix obviously apply to the game's cooperative multiplayer mode, while the files marked "Easy", "Hard", and "Insane" presumably apply to the the game's "Walk on the Beach", "Suicide Mission", and "FUBAR" difficulty modes, respectively. I assume the "Combat Op" difficulty (which lies between "Walk on the Beach" and "Suicide Mission") is considered the default setting, so it probably just uses the values from SRPawn.ini (or SRPawn_Coop.ini for cooperative mode). Furthermore, I assume other difficulty modes will also fall back on SRPawn.ini for values which don't appear in their specific files, as SRPawn.ini has many more lines than the other variations.

I'm making some educated guesses here, because I haven't actually tried editing each of these files individually to confirm that the effects are what we might reasonably expect based on their names and contents. However, I did try editing the file SRPawnInsane.ini with the intent of modifying FUBAR mode. I started by modifying the health values of the player character, Walker, and his two squad mates, Lugo and Adams. This is just a matter of finding the right m_defaultHealth values. There are several m_defaultHealth lines, each appearing in a separate section indicating which character's default health level is being modified. Here's a snippet of SRPawnInsane.ini:
[SRGame.YPawn_Walker]
m_defaultHealth=60.0

[SRGame.YGamePawn_Player]
m_damageModifierExecuting=0.3
m_damageModifierReviving=0.3

[SRGame.YPawn_Lugo]
m_defaultHealth=220.0

[SRGame.YPawn_Adams]
m_defaultHealth=220.0

[SRGame.YPawn_AdamsAlone]

[SRGame.YPawn_Enemy]
m_defaultHealth=155.0
m_chanceToGrantGrenadeToExecutor=0.2
m_vaporizeModifier=3.56
m_headExplodeModifier=1.52
When I found this, I vastly increased the m_defaultHealth values found under [SRGame.YPawn_Walker], [SRGame.YPawn_Lugo], and [SRGame.YPawn_Adams]. I was unsure if it would actually work, but when I started up the game and continued my FUBAR mode campaign, it was clear that the player character and his squad mates were all practically invincible. It seemed too easy but it actually worked.

There are a few other things to note in the snippet above:
  • The [SRGame.YGamePawn_Player] section has a couple of damage modifier values; based on the names, I assume these will alter the amount of damage which the player will take while performing execution moves on enemies and reviving squad mates. However, I haven't tried changing these yet, so I don't know whether they are positive or negative modifiers. Does setting them to 0.0 mean the player takes full damage or that the player takes no damage? Presumably it's one or the other. Either way, setting them to 1.0 probably does the opposite of whatever setting them to 0.0 does, because the fact that each value is currently set to 0.3 suggests that these are fractions of the normal amount of damage.
  • The [SRGame.YPawn_AdamsAlone] section in SRPawnInsane.ini is, in fact, empty. However, it's not empty in SRPawn.ini or SRPawnEasy.ini. In each of those files, this section contains another m_defaultHealth line, so it's safe to assume that we can add one here as well, if we want to. When placed in this section, m_defaultHealth probably modifies the amount of health that Adams has during a sequence in which he is separated from the player.
  • The [SRGame.YPawn_Enemy] section contains some very specific modifiers; you can probably guess what they do based on the names. The file SRPawn.ini has even more values, any of which could most likely be modified here in SRPawnInsane.ini as well. The section name might be a bit misleading, though, as it seems to pertain only to one type of enemy. There are other sections called [SRGame.YPawn_MediumEnemy], [SRGame.YPawn_EnemyMarauder], [SRGame.YPawn_EnemyElite], and so on.
I'm just trying to give you an idea of what can be done with these configuration files. As noted above, some of the .ini files are rather large, so I'm probably just scratching the surface of what can be modified here. I haven't tried making substantial modifications myself — but it looks like you could, in theory, fine-tune many aspects of the game to be exactly how you want them. If you don't like the fact that the player can take damage while reviving squad mates, change it. If you don't like the amount of health that a particular enemy has, change it. If you want enemies' heads to explode with every headshot from any weapon, you can probably make it happen. Whether anyone cares enough about this game to do any of this, however, is another matter entirely.

I only went as far as modifying the health of Walker, Lugo, and Adams — adding a few zeroes to each number, before the decimal of course — and the rest of the FUBAR campaign was a hilarious joke. I got to the end in a tiny fraction of the time it would have taken if I had played the game fairly, and it's probably the only way I would have been willing to get to the end, as my patience had run out. And, for the record, this did unlock the achievement for finishing the game on FUBAR difficulty. Modifying these configuration files does not disable achievements.

Therefore, those of you who actually take achievements seriously as an indicator of your skill level, or something, might want to avoid playing with these configuration files while doing anything which might unlock an achievement. Personally, as noted above, I don't really care — but I can understand how others might regret unlocking a tough achievement by cheating. If you're the kind of person who takes pride in achievements, unlocking one by modifying the game might leave a bad taste in your mouth.

The Case For More Games Being This Easy To Exploit


The encrypted configuration files used by the Windows version of the game actually can be decrypted, but I can't personally vouch for the tool used to do so. I didn't bother with it when I played the Windows version of the game, because I didn't want to cheat at this game badly enough to put up with the extra steps, let alone the mysterious executable. (I trust it a bit more now that I've found it on PC Gaming Wiki, but when I first became aware of the decryption tool, it was through a link on some random forum.)

The fact that the files are not encrypted in the Linux version of the game is probably an oversight — or maybe they just didn't care, or maybe they figured Linux users would find out how to break into the files anyway, or maybe they already knew about the decryption tool for the Windows version by the time they made the Linux version so they decided decryption was pointless. In any case, the fact that the files are encrypted in the Windows version is a clear indication that players were not meant to mess with these files.

But why not?

Cheating in multiplayer games is not okay, because it spoils the experience for other players, hence the existence of anti-cheat measures in multiplayer games. When it comes to single-player games, though, I don't see why we shouldn't be able to do whatever we want with a game that we bought. Many single-player games are made to be (or just are) easily modifiable; Skyrim, for example, is famous for community-made mods. Other single-player games, however, are made to be (or just are) very difficult to modify, as the Windows version of Spec Ops: The Line would be if nobody had figured out how to decrypt its files.

It's almost a shame that a game like Spec Ops: The Line, which is considered by many to be thoroughly mediocre, happens to be one of the games in which so much of the configuration is exposed to players through plaintext or easily decrypted files. A lot of games expose graphical settings not found in-game via configuration files, but in my experience, the ability to change the gameplay this way is rare. I wish I could so easily make similar modifications to games like Alan Wake, not because they're hard and I need to cheat, but because it would be fun. I'd actually like to make Alan Wake harder. Unfortunately, it's not an easily modifiable game.

Achievements are a possible reason that a game's developers might not want players to have unmitigated access to configuration values like player health. Some people take achievements seriously, especially rare achievements which are difficult to unlock; the perceived value of such an achievement, for players able to unlock it through skill and perseverance, is lessened when someone like me unapologetically cheats to unlock it by modifying configuration values.

But just as developers can program a game to disable achievements when built-in cheat codes are activated, they could also program a game to disable achievements when some deliberately exposed configuration file differs from the intended defaults, as verified by a checksum or whatever. I guess I'm advocating for games to offer the same level of easy modification as Spec Ops: The Line, if not more, but on purpose instead of by accident.

Some developers release powerful tools for modding their games, which is great. Changing a configuration file is also great, though, especially for players who aren't going to bother learning how to use whatever modding tools exist. My philosophy as a software developer is that hard-coding arbitrary numbers is bad and everything which reasonably could be configurable should be configurable, and maybe that's far easier said than done when it comes to games — I'm a software developer, not a game developer — but I have a feeling that most games hide configuration from players on purpose, and doing this just to prevent a human from cheating against a computer is silly. The ability to cheat is not going to ruin a game for anyone with any self-control.

I'm also a big fan of games having plaintext save files, for similar reasons. I've played a few, and although I've rarely bothered to skip ahead or otherwise cheat by editing their save files, knowing that I had the option was nice. Save editing is probably hard to detect, so I don't expect it from games whose developers want achievements to mean something — but as with all forms of unintended cheating, my selfish take on the subject is that I should be able to cheat to unlock achievements, and also, deal with it.

Sorry for making the global achievement statistics for Spec Ops: The Line slightly less accurate though, I guess.

Sunday, August 25, 2019

Adventures in Linux Gaming

Last month I wrote about Playnite and GOG Galaxy 2.0. What I forgot to mention is that, for me personally, the major downside of each is the lack of Linux support.

I've been using Windows 7 for a long time. I didn't like the look of Windows 8 when it came out, and never saw the point in switching. Having used Windows 10 at work, I definitely have no interest in using it on my home PC, regardless of all the spying it supposedly does. I just don't enjoy using it. I suppose I don't particularly enjoy using Windows 7 either; I've had my share of problems with it. It just happens to be the best version of Windows which is still officially supported. Unfortunately, with that support ending at the start of next year, I would be forced to "upgrade" to a worse version of Windows if I want to continue to get security updates.

Do I really need security updates? I don't know. Is Windows 10 really worse or am I just biased? I guess it's a little of both. Ultimately, though, it probably doesn't matter. I've been somewhat unhappy with Windows in general, and... well, Linux is free.

Switching to Linux, and Why You Should, Maybe


Switching to Linux is seen by some as a daunting task, and perhaps there's good reason for those with no experience with Linux to be just a bit intimidated. To those terrified Linux beginners, I would recommend a user-friendly distribution like Linux Mint. That's what I'm using, despite several years of experience with Linux as a software engineer. It's just incredibly convenient. The Cinnamon desktop environment is fairly Windows-like, and Linux Mint comes with nearly all the features you need in order to avoid ever touching the command line if you don't want to. The installer is also very easy to use. Some casual PC users might not know what all of the options mean, but for those users, I think the defaults are probably fine.

Of course, no matter how automated the installer and how fully-featured the desktop environment, every Linux user will inevitably run into some kind of problem. The very same is true on Windows; the difference is that, when you search the internet for a solution to a problem on Windows, you'll almost certainly find a solution posted by someone who uses the same version of Windows. There are many Linux distributions, though; if you're not using one of the popular ones, you might find solutions which aren't quite what you need, or you might not even find any reliable documentation of the exact problem you're experiencing.

When I turn to the internet for help with installing something or fixing some error on Linux, the solutions I find are usually tailored to Ubuntu, which is fine because Linux Mint is based on Ubuntu, but it's not always the case. Sometimes the answers I find are all about Debian or Fedora. Sometimes it doesn't matter. Other times it does. I'm not saying that troubleshooting on Linux is a nightmare. These days, it really isn't. However, the fact that there isn't just one Linux comes with some inherent problems, such as this one, and troubleshooting does require a bit more patience.

But the fact that there are so many distributions means that, if you hit a roadblock and absolutely nothing works, you could always just try a different distribution.

How I Ended Up with Linux Mint


When I first decided to install Linux on my home computer, I tried Ubuntu. The installation process was mostly easy. I had some difficulty setting up dual-boot with Windows 7, but it wasn't Ubuntu's fault. It was because, while attempting to install Ubuntu from a USB stick, and I had inadvertently booted to my USB stick in UEFI mode while my Windows installation was using legacy BIOS. If you don't know what that means, don't feel bad; neither did I.

The short version of this story is that, when I booted my USB stick in legacy BIOS mode, the installation and dual-boot set-up went smoothly. However, I found Ubuntu's default desktop environment difficult to customize and annoying to use in general. Even after a bit of research, I couldn't figure out if my problems were the result of bugs or just obtuse design. Ultimately, for this reason and others, I decided that Ubuntu just wasn't for me.

That's when I tried installing Debian. The installation process seemed to work perfectly. Then I tried to boot to Debian, and nothing happened. I got a black screen. I did some research but there was really no way for me to try any of the solutions proposed to others who had similar problems, because I didn't even have a working terminal. I couldn't enter any commands. I assume that it was a video driver issue, and I could have attempted to fix it, but I decided that it wasn't worth my time. I had heard good things about Linux Mint, and I hadn't tried it yet, so I dropped Debian like a hot turd and started downloading Linux Mint.

That turned out to be the right decision; Linux Mint was easy to install, it booted up just fine, and to this day I've had no significant problems with it... except when trying to run games that were never meant to run on Linux.

Gaming On Linux


It always takes me a while to get to the point.

Linux Mint is great as a general-use desktop operating system. It comes with Firefox, LibreOffice, a media player, etc. But how is it for playing video games? Well, I'd say it's just as good for games as any other Linux distribution, and gaming on Linux today is better than ever, thanks in part to Steam.

Steam Play and Proton


A Linux version of the Steam client has been available since 2013, allowing Steam users to play any games which happened to have official Linux versions. It was only about a year ago, however, that Steam rolled out an update to the cross-platform Steam Play feature, allowing Windows games to be installed using the Linux client and providing a Wine-based compatibility tool called Proton which allows many of those games to run on Linux with very little effort from the user.

Installing Steam on Linux Mint doesn't require any command line usage, nor does it even require a web browser. You just open the Software Manager, search for Steam, select the first result, and click the install button. Meanwhile, enabling Steam Play for all games is just a matter of checking a box in the Steam settings menu. If I remember correctly, this option is disabled by default, and initially Steam Play is enabled only for officially supported games, which is no surprise; it's sensible for anything that isn't guaranteed to work to be disabled by default. But the option isn't hard to find, and often no effort is required to get games to work even if they're not officially supported.

ProtonDB tracks how well Steam games work with Proton by aggregating user-submitted reports. Games without native Linux support are rated on a scale of Borked (meaning it won't run at all) to Platinum (meaning it runs perfectly out-of-the-box), with three ratings (Bronze, Silver, and Gold) in between. I'll let the statistics on ProtonDB speak for themselves, but they appear to indicate that the majority of games are playable.

My own personal experience with running Steam games on Linux has been better than expected. Of course, I've been using ProtonDB as a resource since the beginning, and I haven't bothered to install games which are definitively rated Borked. In general, I've gravitated more toward the games with higher ratings. Therefore, I can't claim that the games I've tried playing on Linux via Proton, of which there are about a dozen, are a random sample. However, even when I've tried to play games rated Bronze or Silver, I've been mostly successful, as I've found solutions in ProtonDB's comments to some of the minor problems I've encountered. And the only game rated Borked which I've really gotten the urge to play since installing Linux Mint is L.A. Noire, and for such games, I still have Windows 7 installed on my other hard drive.

I won't describe my experience with every game in detail, but the first Windows-only game I played on Linux Mint was Max Payne, and... frankly, it just worked. It worked perfectly, actually. The only difficulty I had was not with the game itself but rather with the unofficial widescreen patch, and it was only a momentary setback. The comments on ProtonDB quickly set me straight; I added WINEDLLOVERRIDES="d3d8=n,b" %command% to the game's launch options in Steam and even the widescreen patch worked perfectly.

Similarly, Max Payne 2 works perfectly in Linux, and getting the unofficial widescreen patch to work simply requires adding WINEDLLOVERRIDES="d3d9=n,b" %command% to the game's launch options. Playing Max Payne 3 was a bit more difficult; initially, it wouldn't launch. Following the advice of comments on ProtonDB, I added PROTON_USE_WINED3D11=1 %command% to the game's launch options, and it worked, but with some bugs. The minor issues with Max Payne 3 which remain can probably be fixed, perhaps by trying one of the other Proton versions offered by Steam or by further modifying the runtime configuration, but I had only installed it for testing purposes anyway. I was really more interested in playing the first two games in the series, so I didn't spend much time troubleshooting the third.

Non-Steam Games and Wine


Despite needing the occasional web search to find the correct configuration with which to run a certain game, Steam Play with Proton is actually so convenient it's easier than ever for me to ignore the games I bought from other online stores such as GOG. While there are games on GOG with official Linux support, the GOG Galaxy client does not have a Linux version (despite a lot of GOG users wanting one). Downloading games directly from the GOG web site isn't hard, but clients such as Steam and Galaxy do offer a lot of convenience.

Furthermore, although I could probably use Wine or other tools to play many of the Windows-only games from my GOG account on Linux, it would require more effort than running Windows games via Steam, which very often just works automatically. I did install Wine with the intention of playing non-Steam Windows games, but I just haven't used it yet, because Proton — when it works, which it usually does — is just so effortless. If I'm trying to decide what to play, and I've narrowed down my choices to one GOG game and one Steam game, I'm likely to pick whichever is easiest to run on Linux, and that's going to be the Steam game nine times out of ten.

That might change a bit when I get around to trying Lutris, a game client not associated with any particular store, which also claims to reduce installation of many Windows games on Linux to a zero-effort, one click process. It looks like a promising solution for playing some of my GOG games on Linux. For what it's worth, though, installing Lutris is one extra step. I'm going to have to be a jerk and say that Steam still makes it easier by having Proton integration built in to its own client. So many of my games were already working on Linux as soon as I installed Steam that I haven't taken the time to use much of anything else.

So I don't have much to say about running Windows games with Wine, via Lutris or otherwise. I plan on experimenting with it eventually, and once I've done so, I'll probably write a sequel to this post. Right now, though, I'm looking at a huge Steam library and a high success rate with using Proton with very little tweaking, so I probably won't be straying away from Steam very often, except for the sake of experimentation. When I just want to play a game, Proton is often the best way to make it happen.

The Classics


There is one category of games for which I've already strayed outside the Steam bubble: Old-school shooters. I've got to have them.

The Steam versions of The Ultimate DOOM, DOOM II: Hell on Earth, Final DOOM, Heretic, HeXen: Beyond Heretic, and HeXen: Deathkings of the Dark Citadel all run in Proton. They were all, in fact, officially tested by Valve with specific versions of Proton, so that they show up in my Steam library with labels like "Proton [version number] selected by Valve testing" and will run with the indicated Proton version instead of the default I selected in the global Steam settings.

I find this rather amusing because the Steam versions of these games run through DOSBox which, if I'm not mistaken, has a Linux version. However, I'm not suprised that the game's publisher, id Software, hasn't made the effort to repackage these old games with the Linux version of DOSBox for an official Linux release on Steam, especially given that most users who are computer-savvy enough to use Linux will just take the game files downloaded via Steam and run them in a source port instead of DOSBox anyway.

That's what I did with all of these games, immediately after installing them. There's a Linux version of GZDoom, which isn't a suitable source port for anyone who wants the games to run exactly as they did in the '90s, but it's good enough for me. Like any sane person, I did disable major gameplay options which were not in the original games (such as vertical freelook in the DOOM games, jumping in DOOM and Heretic, and ridiculous stuff like crouching), but the graphical upgrades don't bother me.

Getting GZDoom to launch with the correct options for each game was a bit of a hassle, but no more than it was on Windows. The only real problem is that GZDoom, on my system, encounters some kind of error when I close it, which might have something to do with the fact that it doesn't seem to save changes to the gzdoom.ini file unless I enter the writeini console command while running GZDoom. Knowing the workaround, I'm not really bothered by it.

Satisfied with the DOOM and Heretic/HeXen games, I moved on to Wolfenstein 3D and its expansion Spear of Destiny, and installed the source port ECWolf. To my surprise, it seems to work perfectly despite being, in my estimation, less widely used than GZDoom. So then I moved on to the Marathon trilogy, available as freeware since 2005, and attempted to install the source port, Aleph One. That, unfortunately, could have gone more smoothly.

Not Everything is User-Friendly


The official Aleph One web site has some pretty basic instructions for installing the Linux version: Unpack the .tar.bz2 file and, in the unpacked directory, run ./configure && make && make install. Unpacking the file was easy, but I started having problems as soon as I ran the configure command. I won't bother going into all of the messy details, but I went through several iterations of trying the installation, which would fail due to missing dependencies, and then installing those dependencies.

Synaptic Package Manager, included in Linux Mint, makes finding and installing missing packages about as easy as it can be; doing it on the command line using apt or apt-get isn't very hard either. But I had never needed to hunt down dependencies like this. When installing software through Linux Mint's Software Manager, or even when installing a program using apt install, all dependencies are installed automatically (which I now regard as a miracle). Installing software manually, however, isn't quite so easy. Perhaps I was to blame for not knowing what all of the dependencies were beforehand, but it was getting frustrating.

When I finally got Aleph One installed, I was able to launch Marathon, but it printed some errors to the screen and there was no HUD. Searching the internet for a solution, it turned out I was still missing some "optional" dependencies, and installing those made things worse; my next attempt at installing Aleph One failed outright, seemingly due to a dependency which I had already installed.

That's when a comment on the Aleph One GitHub repository, posted only eight minutes before I saw it, clued me in to the fact that I had gone down the wrong rabbit hole. The easier and more reliable way to install Aleph One is to clone the Git repo, go into the root level folder, and run ./autogen.sh followed by make and make install. I had to install git (which I've used extensively but not at home) and I was still missing a couple of dependencies required by the autogen.sh script, but it told me exactly what the dependencies were, so installing them was just a matter of running the correct sudo apt install command.

So I've got Marathon and its sequels working on Linux now, but installing Aleph One took more than an hour after all was said and done. I've learned a lot, though, and ultimately the solution to every problem was revealed with a simple internet search. This story could scare people away from trying to play games on Linux, but it's important to keep in mind that I had this much trouble only because I was trying to play a 25-year-old game. Doing that on Windows isn't always easy either.

I still haven't installed the classic Quake games, and I think those are next. I can only hope installing their source ports will be a bit easier.

Conclusion


I guess the moral of this story is that installing and running games on Linux can take a bit of patience, but I only came close to running out of patience when I tried to do things that only an old-school game enthusiast determined to use Linux at all costs would ever try to do. With Steam, many of the games that work on Linux will "just work" and, for non-Steam games, I'm told that Wine isn't very hard to use either. However, I do know just enough about Wine to know that it requires some effort. The average consumer expects things to work with a single mouse click. They want one-click install and one-click launch of every game.

For games with native Linux support, you can have that. For the rest, Steam comes pretty close to providing that level of convenience. Until other stores like GOG implement some kind of compatibility layer like Proton into their own clients, Steam will dominate Linux gaming for the same reason that Windows dominates gaming in general: It's just easier.