Preface

This writing pertains to the concept of releasing full video game engine source code. It analyzes proclaimed reasons for maintaining proprietary ownership, potential issues, and ultimately claims that placing video game engines as free software or open source holds little personal risk and accomplishes much for global knowledge, development, and communities.

Introduction

As a game developer and a free software advocate, an inevitable question comes up of whether or not to release one’s video game engine under a free software or open source license. The immediate question that comes to mind when commercial video game production is held at the forefront is that such a release could endanger the commercial success or profit of the game due to competing products being released using the same code base. However, while this appears as an initial concern, there are, as far as I understand, no rational reasons for adhering to this belief.

To highlight the chances of risk, let us first analyze what could happen through a delayed source release pattern. Let us assume that Game A is a non-free video game that is being developed by a Studio. Game A uses Engine Z which does not include the art, sound, and other similar, non-engine related assets. In this way, Game A can be broken down into the Engine and the Assets.

After the initial release of the game, which is met with moderate success, the Studio decides to release the source code for Engine Z under a free software license. The Assets for the game are not included with the source code, as the users must generate their own content for Engine Z to allow for a new game to function. Various potentials crop up from this release, which are expounded upon and addressed in terms of probability below.

Risk 1: Competition

1. A competing product is made that potentially impacts post-release profit.

Although this could occur, the potential of it varies greatly depending on how specific the engine is towards particular game mechanics and logic. The more generalized the engine is, the greater potential there is for a new product to be made from said engine. If the engine is specialized, only similar games can be made.

However, how much probability is there in a new product being made from another engine? Given that there are, as far as my research goes, no successful commercial games that were created from an free software or open source released engine created for a commercial game, it seems fairly improbable. Licensed engines, such as id’s various idtech engines, do not count for the reason that at the time their licensing the source code was not released as open source or free software. The absence of this occurance does not guarantee that it could not happen, of course. All the same, there is no compelling argument for this occurring.

In the event of such a (thus far improbable) commercial game from a free software released engine, what would actually occur?

1. Any modifications to the engine’s code must be released under the same terms as the free software license, thus keeping knowledge available and increasing user and developer freedom.
2. Depending on the release time and the type of new game using the free software engine, profit for the original developer may or may not be impacted. Given that developing a game, especially a coherent game with a full body of assets, takes much time and effort, it seems unlikely that any substantial profit impact could even occur.

In summation, given that no examples exist of a commercial game being made from a previously released commercial game’s engine actually succeeding or even existing in the first place, it seems unlikely that it is even a concern. If a competing game was actually released, it would require a full body of new assets that take a great amount of time and effort to create, thus severely reducing chance for commercial competition. Furthermore, any engine modifications for the new game would have to be released under the same license as the original engine, thus maintaining freedom of and access to knowledge as per free software.

Risk 2: Game Exploitation

2. Game exploits are created.

This concern is far more legitimate than the first, for the reason that providing an absolute transparency and access to the engine’s inner workings mean that reverse engineering does not need to be done. However, the amount of concern for this is dependent on both the type and the design of the game in question. For most games, exploits are inevitable. If the game is a single-player game or most any non-competitive game, the exploits are irrelevent as they only serve to change the game experience for the player. This does not impact profit.

However, in the case of multiplayer games, and especially competitive games, exploits impact more than an individual user and are thus a concern. As is known within the gaming world, exploits - or hacks - are inevitable and something you have to deal with. In general, most anti-hacking systems (such as binary checksumming or similar) can be bypassed. The most trustworthy form of defense is, as is common in the gaming world, having democratic votekicking systems or knowledgable administrators to ban or kick exploitative players.

Given the premise that exploits are ultimately unavoidable, there are methods to counter based on game and network design. For example, if the game uses a centralized server model, wherein a single server ultimately controls the data and logic of all game entities, exploits such as speed hacking can be detected by ensuring the player does not exceed particular movement speeds via particular methods in some given upper limit of ticks. Furthermore, information such as player location, health, and otherwise does not have to be transferred to a given player unless the player is in line-of-sight or within some distance of the other player. Given this, even if the player modifies their client to see health or location, the server does not send enough information unless the situation requires that player knowing that information.

In a non-centralized server model, such as a client-to-client command relay design as used in RTS games such as Starcraft for Age of Empires, exploitation can be limited in that any significant changes to a client’s engine would result in a desyncronization of that client. This results in one player experiencing an entirely different outcome separate from the other players, thus nullifying the reason for exploit. However, as was and is the problem with said design, players can use the commands relayed to acquire information on the competing players’ units (maphacks, etc.). The counter is to do some form of checksumming that does not only check the binary checksum, which can be easily counterfeited, but rather checksums some amount of live game data between all clients, notifying all clients when a discrepancy is found. One method would be to use the current command history to check if an exploiting player is seeing more of the game world or accessing more than they should be from their relative position. This could be done from any of the clients connected or from a third-party service that simulates command activity.

In summation, exploitation is inevitable and releasing source code may increase the frequency. However, any increase of exploitation due to source release is entirely speculative and could actually result in a decrease due to exploitation or security patches being found and created in the first place. Furthermore, the design of an engine will likely be the most authorative method of dealing with exploits, regardless of source code availability or not. Finally, anti-exploit measures, in the form of detection systems, are possible, however the most reliable form is that of community-based policing via admins or votekicking.

Risk 3: Easy Piracy

3. Easy Piracy of the Game

Of the two concerns provided thus far, piracy is the most legitimate concern, as most any protection scheme can be by-passed with greater ease due to source availability. Some methods can be created that reduce the chance of this, such as a centralized server that authenticates users based on a product key or account information, however such methods could also be by-passed. However, I hold that this is little different than the current and historical situation of game piracy. As it stands, DRM-style systems are not effective at preventing piracy and generally do best at hindering legitimate users from playing the game they paid for.

Combating piracy is a losing game in which the only vaguely effective method is to restrict the freedoms of legitimate purchasers to such an extreme level that would inevitably lead to a decrease in overall profit due to cumbersome and annoying user restriction.

In summation, even in the non-free world, fighting piracy with DRM is a losing battle that rarely stops illegitimite users and primarily hurts legitimate users. The best combat is to create a fun game with a strong community connection that values and empowers players. If players, regardless of piracy or not, are empowered and valued, they will feel a greater compulsion to support the original developers.

Conclusion

Given this analysis, it is clear that arguments against source code release of a game’s engine ultimately hold little to no water. Competiting products made from the source code are highly unlikely due to the long development window required to create entirely new assets. Exploitation is ultimately the same regardless of source code release or not. Preventing piracy is as it is - a losing battle that fails at any real prevention and usually hurts legitimate players most in the process.

There may be some cases wherein source code release could impact long-term profit not from the original game itself, as other developers could use the source code rather than a licensed engine to develop a new game. However, they would have to release modified works under the same license. It is worth noting that the original developer could do a closed license version to another company that is non-free so long as it does not use any new code contributed under the open source license.

In conclusion, source code release, whether immediate or delayed, causes little to no substantial problems for profit, exploitation, or piracy. Left unaddressed is the potential for public relations and community support and development that could result from source code release.