The Diligent Circle

The Gaming Trap

This article is retained for archival purposes only. While the information herein is technically correct to the best of my knowledge, I don't engage in the business of telling people what software to avoid anymore. See my newer article, Actions Speak Louder than Words. Thank you for your understanding.

The following is a common position in the libre software community: "Proprietary software is not acceptable, but proprietary non-functional data is fine." This is the position of the Free Software Foundation. Personally, while I think proprietary artistic works are unethical, I basically adhere to this position in practice, because I don't think boycotting an artistic work does any good. To have a meaningful effect on a culture, you must be a part of it, and unfortunately, the vast majority of our culture is copyrighted and proprietary.

However, it seems to be a common mistake for people to take this permissiveness excessively far for games, to the point where lines are drawn in arbitrary places concerning what software is. It can be very easy to say that a game is "entirely libre software, but has proprietary data", and therefore conclude that the game is fine. This is an oversimplification. In fact, it is quite common for "data" in games to include software, such as scripts, and so a lot of games that seem on the surface to be libre software, in fact, are partially powered by proprietary software.

To address such mistakes, this article lists cases of "gaming traps" – games which contain proprietary software that you're likely not to notice, usually because of software that is a part of the game's data.

Table of Contents:


Emulators

I have seen some people talk about emulators running proprietary games as if they were libre. The justifications vary, but they are always weak. The simple fact is that a ROM for a system like the NES, the MegaDrive, or the PlayStation contains a program, compiled for the respective system's architecture. It's no different from a program compiled for x86, and any justification for considering a proprietary game for these systems to be acceptable would apply just as well to a proprietary game compiled for x86, either on an x86 computer with no Internet connectivity or in a virtual machine that is not granted network access.

In fact, it often goes further than that. Firstly, the games in question are typically developed with some sort of proprietary SDK, although in many cases this SDK is no longer necessary today (at least if you aren't concerned with your game not working on the original hardware). Secondly, many emulators are proprietary. Some prominent examples of proprietary emulators include Snes9x and ePSXe. Thirdly, some emulators (such as those for the Playstation) simply will not work without a proprietary program from the original system (typically referred to as a "BIOS", though this is technically incorrect).

Games made with Proprietary Game Engines

This should go without saying, but like any other program, an otherwise libre video game which depends on a proprietary program is not truly libre. Most of the time, for games, such dependencies are game engines, like Game Maker, Unity3D, or Construct.

Game Maker is an interesting case: there is a libre compiler called ENIGMA which is in theory supposed to be compatible with Game Maker, but it in practice cannot successfully compile most Game Maker games, both because of features which have not been implemented in ENIGMA and because of problems with the binary formats of Game Maker 8.1 and older.

It is worth noting that while the current release of Construct is proprietary, "Construct Classic" (the first release of Construct) is libre. However, it is copiled with the proprietary MSVC compiler and depends on DirectX. It should be possible to compile it with MinGW and run it and games built with it in Wine, but I have not found instructions to do this.

Game Mods and ROM Hacks

It is very common for popular games to have "mods" made for them, i.e. modifications to the games' software made by fans. How this is done varies; some games have official mechanisms to support mods, while some are modified by changing the binary directly. ROM hacking is the latter type.

To be perfectly clear, a mod of a proprietary game will produce a proprietary game, end of story, so any mod of a proprietary game is by extension proprietary. However, even mods of libre games can include proprietary software added in by the modder, either in the form of direct code changes or in the form of new scripts.

Adventure Game Engines (e.g. ScummVM)

This is actually a mistake I personally made. ScummVM, a project to recreate several proprietary adventure game engines, is entirely libre software, so it can be easy to believe that any game it supports is acceptable. You would be wrong, unfortunately, in almost every case.

In fact, adventure games are quite complicated, so some sort of scripting is always necessary. This scripting is so essential that it is the primary function of many adventure game engines. For example, "SCI", the name of one of the engines used by Sierra, stands for "Sierra Creative Interpreter", referring to it mainly as an interpreter for the custom scripting language involved.

Many, or perhaps all, of these scripts are compiled into a sort of bytecode. The good news is that the ScummVM team has done a pretty good job uncovering the meaning of this bytecode, and many games even have patches to their scripts applied in a dynamic fashion. The bad news is that the scripts are still copyrighted, and will remain copyrighted for decades under the current copyright system.

There are a few games supported by ScummVM which have been released under libre licenses. Be sure to actually check the license; some of the freeware releases do not permit modifications. As of February 2017, the only ScummVM-supported games under libre licenses are Beneath a Steel Sky, Flight of the Amazon Queen, Drascula, Lure of the Temptress, Sfinx, and Soltys.

As a general rule, this also applies to any other adventure game engine, including those for so-called interactive fiction games (which are essentially text-based adventure games). ScummVM is just the most well-known example.

Visual Novels

Like with ScummVM, being overly trusting of visual novels was a mistake I personally made. There are various visual novel engines. Some are libre, and some are not. It can be tempting to believe that a visual novel utilizing a libre engine, such as Ren'Py, is automatically acceptable. You would, of course, be wrong.

Much like adventure games, visual novels have a high dependence on scripting to work. In Ren'Py's case, scripts come in the form of .rpy files, which are written in a custom language that also supports executing Python code directly. Unfortunately, just about every visual novel I have checked is under a proprietary license, or more commonly, no license at all.

One particularly egregious example of this mistake I have seen is Katawa Shoujo. I have seen this visual novel described as "open source" and a claim that the engine is under the Expat/MIT license. This characterization is only accurate as far as Ren'Py itself. Not only are the Ren'Py scripts for Katawa Shoujo under CC BY-NC-ND – which forbids both commercial use and modifications – but Katawa Shoujo's distribution doesn't even include source code for these scripts. They are distributed only as compiled bytecode, which suggests a deliberate attempt from the novel's developers to obstruct people's technical ability to modify it.

Web-based Games

We all know that Flash games are bad because Flash Player is proprietary. However, some people seem to be under the false impression that using Gnash or Lightspark solves the problem. In fact, even if Flash were libre, most Flash content on the Web would still be unacceptable. This is because most Flash objects include ActionScript code, this code almost never carries a license, and source code for the Flash object is almost never supplied anyway.

The same holds true for Java applets and "HTML5" games. Java applets obviously include Java code, and "HTML5" games pretty much universally use JavaScript code (meaning they are really JavaScript games). In almost all cases, this software is proprietary. JavaScript code is often minified, meaning you don't have source code, and Java applets almost always contain only compiled bytecode, not source code.

Of course, not all programs you find on the Web are proprietary, but this is something you have to check.

Cave Story

The original Cave Story is entirely proprietary, but the engine has been mostly rewritten; the rewrite is called NXEngine. Unfortunately, NXEngine imports stage data from the original Cave Story, which includes scripts.[1] Interestingly, these scripts are not only compiled into bytecode, but also encrypted. NXEngine is able to decrypt them by extracting the key from Cave Story's files, but this does suggest that the author of Cave Story intended to make these scripts unchangeable.

Cube, AssaultCube, and Cube 2: Sauerbraten

All three of these games' data include several ".cfg" files which are programs.[2] They do not carry any license, which (as the readmes of these games are sure to tell you) means they must be assumed to be proprietary.

At least one reader has objected to calling these files software based on the assertion that they are "configuration" files that are "like .rc files". This is only a partial truth. They do not configure user options; instead, they "configure" the behavior of the game. They are also not automatically generated on the user's machine; they are distributed with the games along with the rest of the "data" and never modified or replaced. Attempting to run these games without the associated .cfg files will not succeed because they are essential to making the games work. Coupled with the fact that they are implemented as scripts on a technical level, this makes it naïve at best to pretend that they are not software. They are referred to as "configuration" files, but they are really just scripts which more finely control the Cube engine.

Confusingly, there is a package in Debian called "cube2". Despite its name, and what the window title of this game says, this is not Cube 2: Sauerbraten. Rather, it is a different game made from the libre components of Cube 2 along with some other components, and it is entirely libre. Red Eclipse, another game which uses the Cube 2 engine as a base, is also entirely libre.

Frogatto

Frogatto is advertised as driven by an open source engine, and that's technically correct; the basic shell of Frogatto's engine has been released as "Anura". A lot of Frogatto is also released under CC BY, a libre license. However, everything under data/level is proprietary, and some scripts are included in these files. They are found in various ".cfg" files (such as "data/level/General/titlescreen.cfg" and "data/level/Cave/subterranean-scuffle.cfg"), usually controlling in-game events.

Paintown

Paintown's licensing is a huge mess. Its "data", which does not carry any sort of license, includes at least one copyrightable script. It also includes some shaders, but these shaders are duplicated in the source code repository, where it is implied that all "source code" files are under the 3-clause BSD License, so they may not be a problem.

Paintown character definitions are reasonably simple configuration files with no scripting. The M.U.G.E.N. character definitions are a bit more complicated. Most of the files for M.U.G.E.N. characters seem to also be simple configuration or image files, but I have been unable to deduce what the ".act" files are, since they are binary and I have been unable to find any explanation anywhere or locate where they are parsed in Paintown's source code.

In short: seemingly mostly because of sloppiness in how it is developed, Paintown appears to be a minor trap, and M.U.G.E.N. characters in general may be a trap; further analysis is needed.

PlaneShift

PlaneShift is presented very loudly by its developers as "open source", but this claim rides on a technicality that flies in the face of not only libre software, but even open source.

PlaneShift has parts under the GNU GPL and parts under a custom proprietary license, the "PlaneShift Content License" (which I will abbreviate as "PCL"). PlaneShift's page describing the licensing scheme has some wording that suggests that some software might be included under the PCL-licensed umbrella, although I was not able to find any in my brief trove through the PlaneShift source code repository. If it does, that alone is enough to classify PlaneShift as a trap. Additionally, there was an announcement made in 2015 that PlaneShift's engine would become dependent on the proprietary Unreal Engine, although I don't know if this change has been made yet.

Regardless, the PCL effectively makes PlaneShift proprietary software. The PCL states that anything under the PCL may be used "for personal use only, to connect to an Official PlaneShift Server only in conjunction with a Planeshift Client, distributed by Atomic Blue." In other words, you are not even allowed to run modified versions of PlaneShift in conjunction with the proprietary "content", and you are not even allowed to use the authorized client combination to connect to competing PlaneShift-compatible servers should you find a way to do so.

PlaneShift's developers went to great lengths in the aforementioned page trying to justify this absurd and malicious licensing scheme, which all comes down to an attempt to sabotage forking. But the fact of the matter is that this licensing, if it can be enforced, is even more draconean than most proprietary game licenses and completely subverts whatever freedoms the game's developers claim to grant by putting the source code under the GNU GPL. The PCL even makes digital restriction mechanisms (DRM) a very realistic possibility, and you don't even get the protection from the WIPO copyright treaty of version 3 of the GNU GPL since most of PlaneShift's source code is strictly under version 2. All of this is not even mentioning that the core intention of sabotaging forking is fundamentally in opposition to both the libre software movement and the idea of open source.

No one should find doing this and having the audacity to still call the project "open source" acceptable. I would encourage everyone to avoid associating with this project and the company behind it, Atomic Blue. This includes the so-called, deceptively named "Free Game Alliance", which is hosted by Atomic Blue and features PlaneShift very prominently in its rather small and arbitrary line-up of recommendations.

In short, PlaneShift is in practice no better than any fully proprietary game, and in some ways is even worse than most fully proprietary games. For examples of actual libre MMORPGs, see Ryzom and The Mana World.

Games by id Software (Doom, Quake, etc)

The original Doom engine, which powers Doom and Doom II, does not include any sort of scripting support. The variant of the Doom engine used by Heretic similarly does not support scripting. Therefore, if you run one of these games in a libre Doom source port (such as Odamex, PrBoom+, or Chocolate Doom), no proprietary software gets executed.

However, scripting support was added to id Software's engines later on. Shader scripts are supported in id Tech 3 (the engine of Quake III), and a more powerful scripting system was added to id Tech 4 (the engine of Doom 3). The scripts of Quake III and Doom 3 were not released along with the rest of the source code, so these games are traps. Additionally, any other generally proprietary game using the id Tech 3 or id Tech 4 engine is likely to be a trap.

The variant of the Doom engine used by Hexen also added scripting support in the form of ACS. Hexen of course makes use of this support. ACS is supported by ZDoom, so it is common for WADs that are meant to be played with ZDoom to include scripts as well. Therefore, many WADs designed for ZDoom are traps, even if a libre ZDoom-compatible replacement can be used to play them. For this reason, you should check the license of all WADs made for ZDoom (or another variant of the Doom engine that supports ACS scripting); if the license is proprietary, you should assume it is a trap.

The Quake and id Tech 2 engines are a little more complicated. These engines do not support scripting, and Quake, QuakeWorld, and Quake II are not traps. However, mods for these games are often traps, because they use either QuakeC programs (in the case of the Quake Engine) or DLLs to extend and modify the overall behavior of the game. The reason Quake, QuakeWorld, and Quake II are not traps is because while they have such code, it was all included in the source code id Software released under the GNU GPL.

WADs compatible with vanilla Doom, Boom, or MBF are universally fine. None of these contain any software portions. DeHackEd files are also fine; DeHackEd originally worked by patching the Doom binary for MS-DOS, so the files do contain software, but modern source ports simply read the patches and choose different behaviors accordingly, treating them like style sheets.

References

  1. The scripts are stored in ".tsc" files. See "tsc.cpp" in the NXEngine source code.
  2. For Cube, see the "data" directory in the "Unix" distribution of Cube. For AssaultCube, see the "config" directory in the Git repository of AssaultCube. For Sauerbraten, see the "data" directory in the Subversion repository of Sauerbraten.