Technology is an ever-changing landscape. There are constant stories about the death of platforms, new ‘game-changing’ software or hardware, and wild successes or tragic failures for seemingly arbitrary reasons. Let’s explore how you can mitigate those risks and develop a project that has a lifespan measured in years.
Selecting Technology
One of the first decisions you make in the planning process is which technology you will use to build your game. You want to make sure that the technology you select is used by your target audience (as well as developers) and the adoption rate is on the rise. I’ve talked about the importance of adoption in reference to HTML5. Change is inevitable. At some point you might need to make updates to your software and you will want to be able to easily find developers that can do the work. For these reasons picking a brand new unproven technology, or writing your own custom game engine as opposed to using commercial products, can be viewed as risky.
After the big technology platform decision is made, there are several powerful software development strategies that make projects easier to edit and grow over time. All of these take additional engineering resources upfront, but the investments pay for themselves by making the project easier to edit and update.
Data Driven Development
The idea is pretty simple: keep the game content external to the actual code of the game and have the game load it. Examples of content that you can make data-driven include: the text of the game, configuration values (names of servers and other web addresses), references to art and sound files, and designer controls for the pacing of the game. The game will adapt to whatever data is provided to it. With content in a simple text file, all developers are empowered to edit content, not just programmers. Furthermore, you can make basic updates to your game even after it launches.
Version 1.0 Doesn’t Mean There is One Version
Playtesting takes a lot of time and, when done during the development phase, it can be hard to determine the severity of issues that users are experiencing. We have to ask ourselves: “Would this feedback be fixed by features we are already planning to implement?” There can also be complications getting access to our audience. Since building games isn’t an exact science, we build flexibility into the project. In an ideal world we would release the game with the best possible configuration inside of that band of flexibility. It can be advantageous to combine Data Driven Development with testing different versions or turning entire features on and off so that games can be fine-tuned after they launch.
Zero Maintenance Features
This is the gold standard of software development. I’ve heard it described in different ways, such as the “Zero, One, Infinity Rule“. The concept is that you should evaluate code quality through the lens of how many times it needs to be updated and revised, with a goal of zero. This is an overarching concept that requires strong programming fundamentals like encapsulation, handling arbitrary amounts of data, event driven development, and writing for the generic case. There are two important corollaries to this development practice: it implies that you shouldn’t have to keep updating old features as you write new ones and you shouldn’t need complete knowledge of the system to update one feature.
Even if you are not technically inclined, one of the easiest ways to gauge your project’s code quality (besides defects generated, or searching the code base for “TODO”) is how expensive it is to make edits and updates. It is hard to realize this form of technical debt unless you are familiar with software development. Also referred to as “code smell,” “design smell,” “software brittleness,” and “software entropy”; the result of taking shortcuts in the near term is reduced productivity in the long term. It’s always more efficient to write things well with the first implementation. Your end users have no idea what you used to make your game, or if the code barely works. However, they care a great deal about whether or not it will run on their devices, if you can quickly resolve bugs, and if you can adapt with new features that fit their needs.