Taking a genuine behind-the-scenes look at developing an app for iPhone, the latest installment finds this journalist-cum-game-designer hidden behind a mounting pile of paperwork and planning.
Last time, we left off with me pondering the possibility of the project’s failure. I’ve moved on, though, and set aside my doubts, mainly because I need to focus on the rapidly mounting stack of deliverables that seems to have been pinned to me.
To start with, there’s the game design document, the all-encompassing bible covering every aspect of the game we’re making. The fundamentals go in here, alongside the seemingly irrelevant minutiae. It’s a massive undertaking.
There’s more, though. Markus has coded an empty level, featuring our ball character bouncing around the screen. On paper, the game mechanic I’ve designed sounds like fun, but we’ve not even tested it in practice.
The task that falls to me, as game designer, is to plan out a basic level featuring several different key components: scenery, obstacles and enemies. The key is that I make sure to squeeze in any gameplay concepts that I’d like to test out at this early stage.
And, amidst having to generate blueprints for a prototype level and write what amounts to a small book, we’ve hit upon a scheduling problem.
Real Mobile Development
The three coders, Matias, Markus and Benjamin, started this project as a quick, 3-month development. Their aim was to release for September and, if they struck upon success, release a bunch of new levels in time for the Christmas rush.
Naturally, taking advantage of the iPhone’s new software features, the extra levels would be an in-app purchase. A potentially shrewd move by the trio of coders, until I threw a spanner in the works of their clever calculations.
Having worked at a mobile game studio, I’ve seen many games rushed out the door in time for what seems to be an unrealistic deadline — frequently a symptom of a studio that is run at the behest of its investors.
The investors have a quarterly plan and, for each quarter, want to see their profit targets met. To generate profit, product must be released. And so, to illustrate to the investors that profit can be generated, the studio produces a road map that specifies at least one release per quarter.
With everyone happy, development can begin. Except, in these situations, it rarely runs so smoothly. Frequently, the specific deadlines are arbitrary — they’re primarily set just to keep the investors happy, with no semblance of realism. As such, the games that are developed don’t reach their full potential. These games are essentially hastily organized attempts to garner profit before moving on to the next cash-generating attempt.
Everyone loses. The consumers receive a poor-quality product; the studio, reduced to the role of factory, farting out a stream of poor games, is demoralized; and the investors’ profit targets are barely hit.
Myself, Markus, Matias and Benjamin have a unique opportunity with this game. We’re not operating at the behest of a board of investors. Nor do we have a release schedule in which our game has to fit. What we have is an opportunity to spend a little more time on development, ensuring that this game reaches its full potential. And after explaining this to the team, they agreed — we now aim to release the game in February of next year.
With the release date moved from September through to February 2010, I’ve bought us around four months of extra development. With six months, three coders and me handling game design, art and sound, we’ve finally begun stacking the odds in our favor.
Next time: I speak to Mills, founder of mobile dev studio UsTwo, about the true cost of development. Only in the next thrilling installment of TheAppleBlog’s App Developer Diary.