I have written about the importance of considering cost during the early stages of project development, and provided a broad overview of what to expect during the production process. Now that you’ve officially launched the game, you may be considering taking your project to version 2.0.
Before developing ideas on how to best position your project for version 2.0, let’s take a moment to address the impetus behind a second round of production.
- Funding: You may have planned to have two full production cycles on purpose. While this is a more expensive option, the thought is that version 1.0 is an MVP, or an advanced prototype, that can be used as tangible evidence to gather the rest of the funding for the full version.
- Risk: Version 1.0 of your game may have introduced something novel or technically complex. In this case, you may have used version 1.0 as a research and development phase to reduce issues and help you better prepare for version 2.0.
- Content: Creating game content is time consuming. If a project has episodic content it might make sense to produce one story first and use a second project cycle to focus on adding additional content – or designing tools so educators can make their own content.
- Changes in Technology: Technology changes quickly. It’s possible that new devices hit the market, you need to scale the game to include more users, or the project needs to integrate into a service or learning management system. It’s highly plausible that your game will need an upgrade to remain relevant.
I will argue that making your game accessible on iOS, or adapting it for a smaller screen does not fundamentally change your experience. Populating your game with more content, while it may enhance the player experience, doesn’t require significant changes to the machinery of the game. The interesting discussion is when version 2.0 means going from prototype to polished product.
The one word commonly used to describe the gap between prototype and professional, high-end software is “polish”. At this point in the project lifecycle, polish isn’t about trying to add more features – it’s about refining how well the features work together. I don’t really like using the the term polish because it sounds like enhancing the existing features instead of the interplay between them. What polish should mean is the period of revisions where the focus is to simplify, refine, and streamline the user experience.
While video games borrow from software development practices, what we are creating is an experience. In that way video games are more like movies, novels, comic books, television, and other traditional entertainment. It should come as no surprise that books and movies do not improve by injecting them with more story. However, in video games there is always pressure to add more features, when what actually adds more value to a project is polish.
Polish is more than just fixing bugs. Fixing bugs is necessary, but not sufficient to crafting an experience. Similarly, a novel isn’t guaranteed to be a best seller solely because it’s grammatically correct. Polish is the intangible ‘feel’ of the game where the software is reactive and the player effortlessly transitions from thought to action.
I have often borrowed Sid Meier’s perspective that a game is “a series of interesting decisions”. It is critical to stress that the decision can’t be interesting without providing support to make that decision. Anytime there is friction on making decisions the suspension of disbelief is broken, and the player is no longer engaged in the experience.
As a game developer, it’s challenging to convince clients that an intangible thing is more important than something tangible. There is no feature in development titled “fun” or “engagement.” Those are properties we hope to elicit from a polished set of features. Gaps in fun, polish, and feel create obstacles for the player to make progress through the experience, which mean obstacles to experiencing the learning objective.