Blog Post

App Developer Diary Part 2: Pitching My Concept

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!


In this week’s enlightening installment of the App Developer Diary, I pitch my game concept to the coders, preach the gospel of the Game Bible and muse upon the possibility of the project imploding.

Straight after submitting last week’s App Developer Diary, I packed up my MacBook Pro and headed down to Nolla, a local bar and Scandinavian restaurant. I was to meet with Markus, one of the project’s coders, and pitch my game concept to him.

Hailing from Finland, Markus Piipari is one of the three coders who invited me on board to make the game. Together, with his brother Matias and Benjamin Schuster-Böckler, the trio formed Pear Computers, a dev studio specializing in mobile development.

When I arrived at Nolla, Markus was hunched over his MacBook (one of the old white models, which was sealed, I noted, in a scruffy faux-leather hard cover). He glanced up, headphones in ear, and although he acknowledged me with a quick nod, had that glazed look of somebody whose mind is elsewhere.

The pitch process is a fundamental component of having your idea become a reality. It’s the first hurdle, as not only should it be a clear and concise outline of your concept, it should also enthuse the rest of the team. As they say in the industry, you need your team’s buy-in — if the team hasn’t bought in to the concept from the very start, then the project is almost certainly doomed to failure.

I was already nervous enough, pitching a concept that I believed in so firmly, and yet Markus seemed to want to make me sweat more than a chubby man in a Finnish sauna. Perhaps this was a Scandinavian tactic to pile on the pressure and make pitching an even more tense affair? Or maybe Markus was living up to the stereotype of a hardcore programmer: King of the Code, cold and focused.

Setting Up My Pitch

Markus uttered a few words in Finnish, clicked around on his MacBook, and the glazed look dissolved into a warm smile. He wasn’t cold or emotionless, he was just chatting to his brother, Matias, on Skype. And now he was back in the room, ushering me to sit down, already offering me a steaming glass of black coffee — a staple beverage for Finns throughout the year.

Awkwardness over, I booted up my MacBook Pro and opened Apple’s (s aapl) Keynote. Rather than bewilder Markus with the entire game design in one go, I’d prepared a short Steve Jobs-style presentation, explaining the multiplayer component of my game concept. The game was to be a multiplayer bat-and-ball game, featuring novel physics-based power-ups for an added twist.


The images that I’d prepared were mockups of the game screen, featuring arrows and captions pointing to the most important elements — describing the game-flow, control mechanic and graphical style. Markus loved the concept and insisted on immediately contacting Matias and Benjamin to enthusiastically pitch the idea to his team. The coders were on board; I had buy-in. Boom!

The Gospel of Games

With the team bought into the concept, the next step for me would be to produce what’s known as a GDD, a Game Design Document. This document is sometimes referred to as a Game Bible as, once written, it’s the point of reference for every single detail within the game.

Produced during the pre-production phase of a project, the GDD is a key asset during the game’s actual production. It provides guidelines for gameplay, user interface and menu flow, scoring and game rules. It will even include the game’s story, characters and location. Essentially, every detail of the game, no matter how seemingly inconsequential, is mapped out in this document before starting production.

The GDD defines the features and scope of the project; ideally, once production has begun, the GDD won’t change and will serve as a blueprint for the game’s development. Games being what they are — entire populated virtual worlds with their own distinct rules — they are particularly susceptible to feature creep. This project management issue occurs when new features creep in to the product design during the production phase — it drags out development, costing both time and money.

Feeling Doubtful

Over the past few days, since my meeting with Markus, my thoughts have been a flurry of game-related ideas, ready to throw in to the GDD before we begin production. It’s really happening and it’s so exciting to be part of the process. The team — Markus, Matias and Benjamin — are passionate about coding, so accomplished in their abilities, I feel lucky to be working with them.

However, my mind keeps returning to one question: Will this app really make it the App Store? It’s an exciting project indeed, but it’s such a massive undertaking and all the more intense because I’m documenting it in public, right here. It seems like an irrational doubt, but, we could be setting ourselves up for a big fall.

gomi-iphoneGomi is a forthcoming iPhone game that blends Katamari Damacy with Mario Galaxy, rolling a recycling blob creature around tiny planets to clean up the trash. Based on the preview videos, the game looks fantastic, yet its release has been delayed for several months now.

My worry is that if one element goes awry (we lose a coder, the game mechanic isn’t fun, the scope is unrealistic, our project planning is off) we could end up delaying, or worse, shutting down the project. Everything seems to have run smoothly so far, but once we get into the nitty gritty of pre-production, I wonder if that will still be the case.

Next time: Marvel at the visual delights as I unveil my conceptual character artwork, delve in to the details of gameplay mechanics and discover what happens when a hardcore coder disagrees with a journalist-cum-designer. It’s all in the next thrilling installment of TheAppleBlog’s App Developer Diary.