commit: b64d2ebc1a23c1799e48196f454f09d41840314f
parent ce4bacb325d6f7a818525aa342873936941c863e
Author: Drew DeVault <sir@cmpwn.com>
Date: Tue, 23 Mar 2021 13:41:52 -0400
Open sourcing video games
Diffstat:
1 file changed, 244 insertions(+), 0 deletions(-)
diff --git a/content/blog/Open-sourcing-video-games.md b/content/blog/Open-sourcing-video-games.md
@@ -0,0 +1,244 @@
+---
+title: The complete guide for open sourcing video games
+date: 2021-03-23
+---
+
+Video games are an interesting class of software. Unlike most software, they are
+a creative endeavour, rather than a practical utility. Where most software
+calls for new features to address practical needs of their users, video games
+call for new features to serve the creative vision of their makers. Similarly,
+matters like refactoring and paying down tech debt are often heavily
+de-prioritized in favor of shipping something ASAP. Many of the collaborative
+benefits of open source are less applicable to video games. It is perhaps for
+these reasons that there are very few commercial open source games.
+
+However, there are some examples of such games, and they have had a great deal
+of influence on gaming. Id is famous for this, having released the source code
+for several versions of DOOM. The Quake engine was also released under the GPL,
+and went on to be highly influential, serving as the basis for dozens of games,
+including time-honored favorites such as the Half Life series. Large swaths of
+the gaming canon were made possible thanks to the generous contributions of open
+source game publishers.
+
+Publishing open source games is also a matter of historical preservation.
+Proprietary games tend to atrophy. Long after their heyday, with suitable
+platforms scarce and physical copies difficult to obtain, many games die a slow
+and quiet death, forgotten to the annals of time. Some games have overcome this
+by releasing their source code, making it easier for fans to port the game to
+new platforms and keep it alive.
+
+What will your game's legacy be? Will it be forgotten entirely, unable to run on
+contemporary platforms? Will it be source-available, occasionally useful to the
+devoted player, but with little reach beyond? Perhaps it goes the way of DOOM,
+living forever in ports to hundreds of devices and operating systems. Maybe it
+goes the way of Quake, its soul forever a part of the beloved classics of the
+future. If you keep the source code closed, the only conclusion is the first:
+enjoyed once, now forgotten.
+
+With this in mind, how do you go about securing your game's legacy?
+
+## Source available: the bare minimum
+
+The bare minimum is to make your game "source available". Be aware that this is
+not the same thing as making it open source! Some of your famous peers in this
+category include Alien 3, Civilization IV and V, Crysis, Deus Ex, Duke Nukem 3D,
+Prince of Persia, Unreal Tournament, and VVVVVV.
+
+This approach makes your source code available to view and perhaps to compile
+and run, but prohibits derivative works. This is definitely better than leaving
+it closed source: it provides helpful resources for modders, speedrunners, and
+other fans; and devoted players may be able to use it as the basis for getting
+the game running on future platforms, albeit alone and unable to share their
+work.
+
+If you choose a minimal enforcement approach, then some players might ultimately
+share their work, but you're leaving them on tenuous legal grounds. I would
+recommend this if you're very protective of your IP, but know that you're
+limiting the potential second life of your game if you take this approach.
+
+## Copyleft with proprietary assets
+
+The next step up is to make your game open source using a *copyleft* license,
+but refraining from extending the license to the assets — anyone who wants
+to get the source code working would either need to buy the game from you and
+extract the assets, or supply their own community-made assets. This is a popular
+approach among open source games, and gives you most of the benefits and few of
+the drawbacks. You'll join the ranks of our DOOM and Quake examples, as well as
+Amnesia: the Dark Descent, System Shock, and Wolfenstein 3D.
+
+Games like this enjoy a long life as their software is more easily ported to new
+platforms and shared with other users. DOOM runs on phones, digital cameras,
+ATMs, even toasters! Its legacy is secure without any ongoing commitment from
+the original developers. This also allows derivatives works — new games
+based on your code — though it may turn some developers away. Using a
+copyleft license like the [GPL](https://www.gnu.org/licenses/gpl-3.0.en.html)
+requires derivative works to *also* be made open source. The community generally
+has no problem with this, but it may affect the willingness of future developers
+to incorporate your work into their own commercial games. I personally think
+that the proliferation of open source software that's implied in the use of a
+copyleft license is a positive thing — but you may want to use another
+approach.
+
+## Permissive license, proprietary assets
+
+If you want to allow your source code to find its way into as many future games
+as possible, a permissive open source license like [MIT][0] is the way to go.
+This will allow developers to incorporate your source code into their own games
+with little restriction, either by creating a direct derivative, or by taking
+little samples of your code and incorporating it into their own project. This
+comes with no obligation to release their own changes or works in a similar
+fashion: they can just take it, with very few strings attached. Such an approach
+makes it very easy to incorporate into new commercial games.
+
+[0]: https://opensource.org/licenses/MIT
+
+This is the most selfless way to release your code. I would recommend this if
+you don't care about what happens to your code later, and you just want to make
+it open source and move on. Though this will definitely enable the largest
+number of future projects to make use of your work, the copyleft approach is
+better for ensuring that the largest possible number of future games are *also*
+open source.
+
+## Open assets
+
+If you're feeling especially generous, you could release the assets, too. Good
+licenses for this includes the [Creative Commons](https://creativecommons.org/)
+licenses. All of them permit free redistribution of your assets, so future
+players won't have to buy your game to get them. This could be important if the
+distribution platform you used is defunct, or if you're not around to buy it
+from — consider this well before deciding that you'd rather keep your
+share of the dwindling asset sales as your game ages.
+
+Using Creative Commons also allows you to tune the degree to which your assets
+may be re-used. You can choose different CC licenses to control the
+commercialization of your assets and use in derivative works. To allow free
+redistribution and nothing else, the CC-NC-ND license (noncommercial, no
+derivatives) will do the trick. The CC-BY-SA is license the copyleft of creative
+commons: it will allow free redistribution, commercialization, and derivative
+works, *if* the derivatives are also shared with the same rights. The permissive
+approach is CC-0, which is equivalent to releasing your assets into the public
+domain.
+
+Permitting derivatives and re-commercialization of your assets can save a lot of
+time for new game developers, especially indie devs with a small budget. It's
+also cool for making derivative *games*, similar to modding, where creative
+players can remix your assets to make a new game or expansion pack.
+
+## What if I don't completely own my game?
+
+You can't give away the rights to anything you don't own. If you rely on
+proprietary libraries, or a third-party level editor, or you don't own the
+rights to the music or sprites, you cannot make them open source.
+
+In this situation, I recommend open sourcing everything that you're able to.
+This might mean that you open source an ultimately broken game — it simply
+might not work, or not even compile, without these resources. This is
+unfortunate, but by releasing everything you can, you leave your community in a
+good position to fill in the gaps themselves, perhaps by refactoring your code
+to work around them, or by replacing the proprietary bits with free
+alternatives. This also allows the parts of your game which are open to be
+reused in future games.
+
+## But cheaters could use it!
+
+This is true. And it's worth noting that if your game has a mandatory online
+component based on your own servers, then making it open source doesn't make
+nearly as much sense, especially if you ultimately decide to shut those servers
+off.
+
+There is a trade-off to be made here. In truth, it's very difficult to prevent
+cheating in your game. If you've made a popular competitive multiplayer game,
+you and I both know that there are still cheaters using it despite your best
+efforts. Keeping it proprietary is not going to stave off cheaters. Social
+solutions are better — like a system to report cheaters, or to let friends
+play on private servers.
+
+Making your game open source might help less skilled script kiddie figure out
+how to cheat more easily in your game. I can't decide for you if the trade-off
+is worth it for your game, but I can tell you that the benefits of making it
+open are vast, and the efficacy of keeping it closed to prevent cheating is
+questionable.
+
+## But my code is embarrassing!
+
+So is everyone else's. 🙂 We all know that games are running up against tight
+deadlines and clean code is not going to be the #1 priority. I assure you that
+your community will be too busy having fun to judge you for the quality of your
+code. The idea that it just needs to be "cleaned up" first is the death of many
+projects which would otherwise have been made open source. If you feel this way,
+you will probably never be satisfied, and thus you'll never open it. I assure
+you: your game is ready to make open source, no matter what state it's in!
+
+## So what do I need to do?
+
+Let's lay out the specific steps. You need to answer the following questions
+first:
+
+- Do I actually own the entire game? What parts am I allowed to open source?
+- Will I make the code source-available, copyleft, or permissively licensed?
+- And the assets? Proprietary? Creative Commons? If the latter, which version?
+
+If you're not sure what's best, I would recommend using the GPL for your code,
+and CC-BY-SA for the assets. This allows for derivative works, so long as
+they're also made open with a similar license. This enables the community to
+build on your work, porting it to new platforms, building a thriving modding
+community, and freely sharing your assets, ensuring an enduring legacy for your
+game. If you'd like to decide the details for yourself, review the comments
+above once again and pick out the licenses you'd like to use for each before
+moving on.
+
+If you need help with any of these steps, or have any questions, please [send me
+an email](mailto:sir@cmpwn.com), and I will help you to the best of my ability.
+
+**Publishing the source code**
+
+Prepare an archive of your source code, and add the license file. If you went
+with the source-available approach, simply write "Copyright ©
+<*you*> <*current year*>. All rights reserved." into a text file
+named LICENSE. If you chose something else, copy the license text into a
+LICENSE file.
+
+If you want this over with quickly, just stick the code and license into a zip
+file or a tarball and drop it on your website. A better approach, if you have
+the patience, would be to publish it as a git repository. If you already use
+version control, you may want to consider carefully if you want to publish your
+full version control history — the answer might be "yes", but if you're
+unsure, the answer is probably "no". Just make a copy of the code, delete the
+.git directory, and import it into a new repository if you need to.
+
+Double check that you aren't checking in any artifacts — assets,
+executables, libraries, etc — and then push it to the hosting service of
+your choice. GitHub is a popular choice, but I would selfishly recommend
+[sourcehut](https://sourcehut.org) as well. If you have time, write a little
+README file which gives an introduction to the project as well.
+
+**Publishing the assets**
+
+If you choose to leave the assets proprietary, then there are no further steps.
+Players can figure out how to extract the assets from their purchased game.
+
+If you choose to make them open, prepare an archive of your assets. Include a
+copy of the license you choose — e.g. which Creative Commons license you
+used — and drop it into a zip file or a tarball or something similar.
+Stick this on your website, and if you're feeling generous, prepare some
+instructions for how to incorporate the asset bundle into the game once a player
+compiles your code.
+
+**Tell the world!**
+
+Let everyone know that you've made your game open source! Write a little blog
+post, link to the source and assets, and enjoy a little bit more of the
+limelight while the press and the community thanks you for your contribution.
+
+One final request on this note: if you choose the source-available approach,
+please refer to it as such in your public statements. Source available is *not*
+the same thing as "open source", and the distinction is important.
+
+And now it's my turn to thank you: I'm so happy that you've released your game
+as an open source project! The community is much richer for your contribution to
+it, and I hope that your game will live on for many years to come, both in self
+through ports and mods, and in spirit through its contributions to future games.
+You've done a wonderful thing. Thank you!
+
+If you found this guide helpful in publishing your game, please [email
+me](mailto:sir@cmpwn.com) so I can play it!
