3. Discovery-Driven Planning
While I was earning my Penn/Wharton MSE degree, I had the good fortune to attend a few lectures by Professor Ian MacMillan, coauthor of Unlocking Opportunities for Growth, and learn about discovery-driven planning. The lectures were a huge eye-opener.
The discovery-driven planning (DDP) process is explicitly tailored toward innovation-oriented projects and focuses on reducing uncertainty. For all the changes we know are inevitable in our designs, developers don't typically factor that learning into our planning or use planning methodologies directed toward identifying and reducing uncertainty.
We adopt Scrum and other "agile" methods, and we adjust our plans as circumstances change, but we generally make no effort to quantify our uncertainty from the outset or to plan in a way that will ensure that we focus on the most important risks.
On City Conquest, the DDP system forced us to explicitly identify and quantify all of our major assumptions, build a reverse income statement, and perform a sensitivity analysis of the effect of each assumption on profits. This methodology ensured that we directed our development efforts on the areas with the greatest potential for uncertainty to affect the project's costs and revenues.
But even if you don't use a DDP plan explicitly, the general principle of focusing your efforts at any given moment on those features or areas with the highest value of ((uncertainty) x (financial impact)) can go a long way toward ensuring growth while proactively managing risk.
4. Technology Choices
Technology choices are fraught with risk. There are many recent examples, including Glitch, whose developers made clear that the choice of Flash made it impossible to achieve their project goals, and another high-profile case where a developer sued their own engine vendor for technology delays and inadequacies.
Our early tech choices were critical to the success of the game. My own experiences have made me extremely paranoid about the risks associated with licensed technologies and the performance and productivity impacts of scripting languages.
City Conquest places huge performance demands on mobile hardware, including some relatively modest devices such as iPod Touch 4. It required extensive optimization and careful attention to performance at every level.
We chose to build the game with Marmalade precisely because it was not an engine, but only a thin, high-performance cross-platform API layer. It allowed all of the programmers on the team to do 95 percent of our coding and debugging on Windows in Visual Studio using C++, test the game using Marmalade's PC emulator, and deploy identical code to iOS and Android (and possibly Mac and Windows in the future now that Marmalade supports them). Outside of a bit of platform-specific multiplayer code, the initial "first-playable" Android port literally took under an hour.
Marmalade is not without its downsides. Like any tool, it comes with its own trade-offs. The lack of on-device debugging was problematic at times (though this was very rarely actually necessary, as 99 percent of our bugs were our own and were reproducible in the Visual Studio debugger using the Marmalade emulator on Windows). We also needed to extensively customize the resource management.
The use of Marmalade and C++ ensured that we could achieve the critical optimizations necessary to make such an enormously graphically intensive game run at reasonable frame rates on a wide range of mobile devices.
5. Careful Cost Management and Outsourcing
We have seen far too many studios grow too quickly and implode under the weight of their own aggressive expansion. Not only does this hiring dramatically inflate a company's cost structure and the breakeven level required for profitability, but it also usually changes the company's character for the worse. A company's teamwork usually grows much more slowly than its team size, and studios often fail to spread the culture and principles that made them successful to all of the new hires.
Our tiny studio size and careful cost management ensured that we minimized our overhead and kept our breakeven as low as possible. We are far more interested in growing slowly, hiring the right people, managing our risks, and building City Conquest and other games into stable, ever-evolving, long-term franchises. We found that our art, audio, and multiplayer engineering contractors produced a surprisingly high level of quality at reasonable costs, and we could not be happier to have been able to work with all of them.
What Went Wrong
1. Mission Design
We knew long before we even began developing City Conquest that it's best to teach players gameplay concepts in small, easily digestible pieces, and wash each one down with a good helping of fun. This is Game Design 101, and as a veteran Nintendo developer, this had almost become second nature, so obvious that it hardly merited a second thought.
Yet somehow, inexplicably, we started by building a tutorial mission that tried to teach every major gameplay concept -- building, upgrading, territory control, dropship pad swapping, game effects, cloaking fields, resource management of gold and crystals -- in a single 15-minute mission with a nonstop barrage of text popup boxes.
After all that work to develop what I felt was a very solid tutorial mission, I received some brutally honest feedback from an external tester. No one wanted to sit through 15 minutes of text popups before having any fun or actually playing the game. And it was just too much information all at once: the gameplay concepts that seemed so obvious to me were of course much less so for the playtesters.
And when they finally did get through the tutorial, they were suddenly overwhelmed with options in the very next mission: the player could immediately build all 20 buildings and use all four Mothership effects before being taught to use them properly.
Ultimately, there was no choice but to take a deep breath and refactor the mission design completely. We separated the game into five different conceptual elements -- attacking, defending, expanding your territory with Skyscrapers, using game effects, and swapping dropship pads -- and built at least one specialized mission to teach each of those five core gameplay elements and use them in an entertaining way. We also overhauled to the user interface to allow us to limit the player's building choices to a limited subset defined in the mission scripting, helping us ensure that we would not overwhelm players with options too quickly.
We released City Conquest on iOS as a free download, with a single $4.99 in-app purchase for the full game. The free version contains the full multiplayer experience plus the first five missions of the single-player campaign (out of 14) and the first of the six bonus "challenge" missions.
We had initially intended to release the game as separate "Lite" and "Full" apps, with the "Lite" version as a free limited download. However, discussions with the Marmalade team ultimately convinced us that it would be better to combine these into a single free download, with an in-game paywall separating the demo from the full game experience.
Our reasons for this were well-intentioned: this approach ensured the user only had to download the game once, minimized the potential for confusion between "lite" and "full" versions, made it easier to convert players from free players into full players, ensured that all players could play multiplayer for free, and ensured that achievements and campaign completion were shared across both the lite and full versions.
In retrospect, although we're happy with our conversion rate, it's clear that there are serious limitations to this approach and any others that aren't based on full-fledged monetization. The nature of the mobile market makes it extremely important to do proper price discrimination across the full spectrum of mobile users. There have been several articles on monetization on Gamasutra, and we refer the reader to these.
We are currently nearing completion of the Android version, which we expect to release as an advertising-supported free game.