Why I made Freedoom for Android (open source):
Ever since getting a Playstation 2 for Christmas in the 2nd grade, I’ve been a fan of videogames as a way to keep mentally active. In my opinion, a great game generally incorporates some kind of core game system (e.g. an role-playing game with equipment and spells, or a first person game with gun-play) with some kind of open-ended exploration system that feeds into the main game and rewards creativity and risk-taking.
In Half-Life 2 for instance, you could play most of the main game completely oblivious to your surroundings, but if you were ever in a pinch you could scrounge around and find resources in unexpected areas (pull a cinder-block out of a basket to lower down a health-pack via pulleys? Genius.)
Games for the small screen:
So, in college I found I was often too busy for games with lectures and homework and would often just read or play with my phone between classes. I’ve tried mobile games in the past, but I think my problems with mobile games can be summarized in two images:
Unfortunately for most mobile games, they often operate on the freemium model instead of the paid model since users aren’t as wiling to pay up front for mobile games, and they heavily court the top 2-6% of “whale” players who are willing to spend lots of money on in app purchases. This means the games are designed to be somewhat fun on the free tier, but not too fun, otherwise no one would pay. Also there’s generally a core gameplay system, but instead of a “open-ended exploration” system designed to make gameplay more varied, there’s generally a “add a small pain point to the gameplay that can be fixed with 💰💵 🤑 ” system. Granted, many of these games are fun and have a lot of passion put into them, but I have a strict rule that:
- If something in my wallet affects
- How well I can do in the game
- I probably won’t have fun with the game
Alternatives?
So, my goals were to:
- On a mobile phone or small, lightweight laptop
- Find game(s) that can be played for 5-15 minutes at a time at a minimum
- The games are deep enough to be fun to play for longer if time permits
So, I found that I ended up liking a lot of older games ranging from the early 90’s to the early 2000’s. 90’s Games for the Super NES generally have beautiful pixel art with colors that pop on a smartphone’s OLED screen, and the PC games of the 90’s and early 2000’s had excellent core gameplay and design creativity before advanced graphics made it too expensive for mid-sized studios to compete.
With platforms like retroarch nowadays, I could even play games on my phone with a Bluetooth controller and I could use scripts to have the save files sync across all of my devices.
Doom!
John Romero (game designer) plays Doom E1M1:
The original Doom from 1993 would fall under my definition of a “great game” because it has:
- Great core gameplay system (fast and rewarding movement mechanics, varied and responsive enemies, etc.)
- Interesting, expansive, and varied levels with hidden “secrets” that reward creativity, exploration, and risk-taking
Open Source:
Also, thanks to the technical genius John Carmack (+), the source code for the original Doom was released as “open source” to the public for anyone to tinker with and improve. As such, in the more than 25 years since the game’s release the game has been a model example of an open source software community with loyal and active members, multiple new and updated versions, and countless add-on levels and mods.
What’s great about open source software like Doom, or Firefox, Linux, and Apache is that anyone can use, improve, or redistribute modified versions of these programs and look at the source code that controls how the software runs. Open source can also work well for business, both for vendors and companies using software.
Freedoom:
While the Doom engine was released as open source, the game asset files (including monsters, music, and game levels) were kept under copyright by Id software and were not legal to redistribute. If the Doom engine is the “peanut butter”, the Doom asset or WAD files could be considered the “jelly” of the game needed for the full, delicious PB&J. Without free and open source WAD files, it is impossible to distribute version of Doom that doesn’t require a purchased copy of the original game.
A community rose to the task and created Freedoom, which is licensed under a BSD-like license and allows for modification and redistribution. It is also distinctly not Doom: the maps, music, levels, enemies, weapons are original works that are different than the original Doom, yet are still compatible with fan-made add-ons and mods. The terms of the license also means that it can be included or modified for free with Linux distributions, open source Doom engines, on app stores, etc. as long as the the license is included with the software.
Other common open source licenses, such as some versions of the GPL (i.e. the license with which Carmack released the doom engine) require that code is available to customers upon request
Publishing Freedoom for Android on the Play Store:
The Fork:
An open source developer had developed a fork of Doom designed to run on Android smartphones by using the native development kit (NDK) and published it as a paid app on the Play store, but it had been taken down due to a copyright strike at the time I was working. Another developer had taken the publicly published code of his open source components (as required by the GPL) and repackaged it as an open source GZDoom for android.
I decided to create something known in the software world as a fork of GZDoom for android and called it “Freedoom for Android” (forks can occur in software for any number of reasons, such as when MariaDB forked from MySQL or Amazon forked Elasticsearch). While I didn’t strictly need to, I first got permission via email from both the GZDoom for Android developer and the Freedoom community to use their resources.
Building:
It was a bit tricky to get the project to build on my computer, and I ran into some frustrating build errors with the compilation of the C and C++ code that runs in a simulated execution environment with the NDK. By digging through “tombstone” stack dumps and working with the “GZDoom for Android” developer over email, I was able to debug the error outputs of the low level code and fix a problem in the game engine.
Once I had it building, I then decided to modify the code further to fix various bugs such as a file permissions error, problems with the user interface, and music not working in game with the default settings.
Publishing:
Once I had built my app, I was able to publish Freedoom for Android to the Play store. I very quickly started receiving a growing number of users and installations.
Then, my app was taken down from the Play store due to a copyright strike. I was able to appeal it by submitting the emails I had received from the Freedoom community, emails from the GZDoom Android developer, and the open source software license that came with the code and proved I had the right to modify and redistribute the code.
In addition, I removed any mention of the word “Doom” in the description and replaced it with “everyone’s favorite 1993 game” as well as adding a legal disclaimer at the bottom indicating that this game was not affiliated with Id or Bethesda. This seemed to do the trick and my app was re-published after review. I still believe the app was somehow hidden from showing up in trending pages or other areas of the Play store however, and think this might explain the reduced install rate after the strike.
Competition:
After publishing Freedoom for Android on the Play store, the developer of my upstream Delta Touch decided to continue development of his app and was able to fight his copyright strike and republish on the Play store (though he hasn’t yet published his updated code as required by the GPL, tsk, tsk).
[Edit: it may be that he’s publishing only the required GPL components such as the GZDoom engine, but not his full app packages or other modules which he formerly had as open source, which is understandable].
Bethesda (the current owner of the Doom franchise) decided to join in on the fun and release their own mobile port, but their initial launch was marred by online-only DRM and a 300Mb install due to using the Unity game engine in order to avoid using any GPL licensed code (for whatever reason?).
Internationalization:
By writing some GitHub integrations with a cloud translation service called Transifex, I was able to add translations for my app into many different languages. Because my project was open source, Transifex allowed me to use their service for free. I translated the Play store listing pages, set up A/B testing for the translations, and then published an internationalized version on the Play store.
After the update, I immediately started having more installs and more reviews in non-English languages. I got reviews ranging from a Hatian user with a phone with only ~250-300mb of usable storage who chastised me for the size of an app update (I deserved it) to reviews in Thai, Vietnamese, and a tribal dialect of Turkish.
Some of my translations weren’t great; however, what was great about Transifex was I could invite reviewers and native speakers of each language to improve the translations (even if they had no coding experience).
Bundling
Around the same time, John Romero released for free a “megawad” map pack SI6IL for the 25th anniversary of Doom. I emailed him asking for permission to distribute SI6IL.wad with Freedoom for Android and I got a reply somewhere along the lines:
Sure thing! As long as it’s the only wad of mine that you include 🙂
I also decided to include 10sectors.wad with the app. It was a community made map pack with small, action-packed levels that I figured would be fun to play in 5-15 minute settings on a mobile device.
Future:
I really liked playing through 10sectors.wad on the phone, and want to modify the app to make it easy to download and install new doom levels, or any of the plethora of existing wads on the idgames archive. The “killer app” for Freedoom for Android would likely be if you could download and play a small addon level on your lunch break. To plan for writing this feature, I wrote three user stories and drew a quick mock-up. This kind of thing is common in Agile software development.
If you’re interested in contributing to this feature, this app, or anything else I’m interested in, feel free to check me out on GitHub.
Previous in this series:
