It’s been a few weeks since my last entry in the App Developer Diary. Markus, the coder based here in Helsinki, has been busy. This week he unveiled a playable prototype of our app, allowing me to test and refine the main game mechanic.

In the meantime, Matias coded up a cute little mini-game over the course of one weekend. While he worked on the programming, I created the sound, music and artwork (above). In one weekend we created a really great little game, almost ready to be released in the App Store.

We’re not the only developers who have been working on these quick-fire app concepts. Mobile development studio Ustwo also took an idea from hasty scribble to the App Store in just 48 hours. It’s encouraging to see that their first 48 hour app, simply titled .™, is now selling as a 99 cent download.

Have You Seen the Dot?

We didn’t do much planning for our own 48 hour app. Matias came up with an idea — a button-tapping game with a bizarre musical twist — and built it. Ustwo, being a little more strategic, managed to sketch out a few concepts before coding up their app.

Ustwo founder Mills sat down with his iPhone development team and threw together a development plan. Their app would be cool, simple and addictive. Most importantly though, it would stake a claim in the App Store, showcasing their ability to think fast and be creative under pressure.

Mills laid down a fundamental ground rule too: the scope of the project would go no further than two days. The app would be submitted to Apple on hour 48 of development.

Just the Basics

Stepping up to the challenge, the Ustwo team produced three simple sketches. Their hastily drawn plan outlined the game’s control system, look and feel, and gameplay mechanic.

The sketches only cover the essentials, but that’s really all that the team needed to get coding. The first image covers the game’s accelerometer-based control method, and main character — a dot — alongside succinctly stating that the app will have a, “minimal aesthetic.”

The second sketch contains an ultra-refined executive summary of the game: control dot to select smaller dots. The gameplay mechanic is revealed in the third sketch. Your dot is shrinking, he needs to eat dots to stay alive, triangles will kill him.

In just three images we’ve got a clear idea of how a typical game will play out. You’ll be tilting and twisting the iPhone, sliding a shrinking dot around the screen and trying to collect other dots while avoiding an onslaught of death-dealing triangles.

From Paper To Flash

After sketching out the game concept, the team took the concept to the computers. Their first step was to flesh out a quick playable prototype of the game concept using Flash. Focusing on look and feel, they tested a variety of different visual designs alongside taking a closer look at the controls too.

With the prototype working as expected and with the sketches for reference, the app was hastily coded up. After a quick round of QA — searching for bugs, design and gameplay issues — the team submitted the app for App Store approval. For Ustwo, the 48 hour app concept worked. It made development fun, it reduced costs and it challenged the coders and designers to think quickly and creatively.

It’s possible that we’ll be seeing more studios take on the 48 hour app challenge. Adobe recently announced that the forthcoming update of Flash, version CS5, will render files in the iTunes App Store format. This is a serious boon for Flash-based artists and designers everywhere, putting the tools for app development into the hands of even more creatives. In the case of Ustwo, they even created a fully-functional web version of .™, using Flash.

Our own 48 hour app still needs a few final tweaks before being submitted to the App Store. Ustwo’s successful 48 hour development, .™, is currently available from the App Store for 99 cents.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• How to Market Your iPhone App: A Developer’s Guide
• Virtual Worlds: Trends and Opportunities

I have to admit that I’m still working on the Game Design Document. Something which I thought would take only a few days has grown to incorporate minute details alongside gargantuan fundamental gameplay concepts. This document is essentially Tetris in written form: piling on concept after concept, attempting to make it fit together before the whole thing becomes too unwieldy to manage.

While work on the GDD should finish this week – Matias has stated that this Friday is the absolute deadline – I’m finding the time to explore other related areas of app development. In my last entry I spoke to Mills, one of the founders of ustwo, a growing independent mobile content studio.

Mills provided me with some revealing data in terms of development costs and sales. Looking at ustwo’s costs for app development relative to the revenue that they generated led me to think about how I could lower our own development costs while increasing the app’s desirability.

I’ve managed to find three different solutions that add value to our app and cost either very little or absolutely nothing.

Recycle That Code

Recycling and reusing code is a tried and tested convention in software development, particularly in the game industry. When you write a piece of code once – for example a game engine for a first person shooter – why spend time and money writing it again for the sequel? It’s far simpler to copy, paste, modify and deploy.

Working for a game developer a few years back, there were times when I noted that code recycling wasn’t necessarily in the customer’s best interests. In particular, I remember a top-down shooter – in the style of Grand Theft Auto – recycled as two different titles. The artwork was redrawn, the in-game dialogue was chopped and changed, but it was quite clearly the same game.

We plan to be a little smarter in choosing how and where we redeploy certain pieces of code. The PearComp coders, Matias, Markus and Ben, are currently working on Facebook and Twitter integration for the game. The plan is that, from within the game, players will be able to post their high scores to the two social networking services.

Facebook and Twitter posting is the value-adding feature du jour. Being able to link an app to these services provides a seamless connection between a user’s social life and the app in question. For games in particular, it’s a great way of enabling players to shout about their achievements while generating publicity for the title among their social connections.

In effect, the code that the PearComp team have created for the game can be re-used for future iPhone app developments. It’ll benefit some of PearComp’s clients, plus it’ll cut costs, and save time and resources.

Find Your Voice

John J. Dick is a voice actor and DJ who happens to be pretty badly in debt. His biggest gig was working on Serious Sam, an explosive shooter for hardcore gamers. John’s husky vocals helped flesh out Sam, the game’s main man: an alien destroying, gun toting, time traveling mercenary.

Back in the real world though, John’s debt has become such a problem that he’s come up with a cunning way to bail himself out. John has decided to offer his voice acting talent at an incredibly competitive rate: $1 per word.

Commissioning John to record a few words for the game was an easy decision – it cuts costs for sound recording and should save us some time later in the project. Having John’s name, and by extension Serious Sam, attached to the project could also make for some fun PR when we launch.

Collaborate & Communicate

In the previous installment of the App Developer Diary, I found out a little more about ustwo’s MouthOff app for iPhone. After speaking to Mills. I realized that there was potential for a really exciting collaboration.

I called Mills back the next day and pitched my idea: ustwo would create a special version of MouthOff featuring one of the characters from our game. We’d take the MouthOff code from ustwo and put it into our app, essentially this exclusive MouthOff would be accessed from within our game.

Featuring an exclusive MouthOff mode within our app adds some serious fun and replay value to the game. It would also garner some added exposure for ustwo’s app. Of course, we’ll ensure that there’s a link to the App Store for players to purchase the full version of MouthOff.

By recycling code, finding a great deal on audio assets and collaborating with an awesome dev studio, we’ve made our game even better without breaking the bank.

Next time: I finally submit the Game Design Document to the coders at PearComp.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Mobile Q4: All Eyes Were on Android, 4G and the Rising Tablet Tide
• Report: A Mobile Video Market Overview
• In Q3, the Tablet and 4G Were the Big Stories

Going behind-the-scenes of a real iPhone app’s development, the latest installment takes a candid look at the economics of the App Store.

In my previous entry for the App Developer Diary, I was lost behind a mountain of paper-work. Since then, the rapidly growing mountain of tasks hasn’t changed too much — I’m still working on the game design document and concept artwork, but an array of new tasks have also joined the list.

The game I’m developing with Pear Computers is being created in our spare time. As such, we’re not keeping any records as to how long we’re spending on a given task. We’re working evenings and weekends, any random available hour, to push the project forward.

Although some smaller developers may work in this manner, this isn’t the way it would work at a big studio. A larger studio needs to know how much money they’re investing in an app’s development, ensuring that they’re staying on-budget and able to accurately calculate how much profit will be generated.

As we’re not keeping any official record, without running through e-mails and diary entries, we’re unable to accurately quantify the cost of development. So instead of generating a hasty approximation for the benefit of this diary’s readers, I spoke to Mills, founder of mobile content studio UsTwo, to tell me about the hidden costs of developing for iPhone.

Stepping Back

Founded in 2004, UsTwo specialize in mobile content development, their current largest client is Apple-competitor Sony Ericsson. Having grown to an impressive 43 staff, made up of designers, animators and coders, the London-based team are also opening studios in San Diego and Mälmo, Sweden.

When the App Store opened last Summer, Mills decided to experiment with developing for iPhone. “We do so much work for clients but, more importantly, we wanted to create our own apps. We’re a design-led company, the iPhone is a really exciting device and so we decided that UsTwo is the perfect space to do create apps.”

Released in February this year, UsTwo’s first project was Steppin, a tap ‘n’ drag game that tests the player’s digit dexterity. Looking back, Mills describes the project bluntly as, “how not to develop a game.” He explained that Steppin’s development cost an estimated $50,000, with it only generating around $1600 in profit.

The extraordinary development costs were really due to UsTwo’s drive to experiment and test different gameplay concepts. Mills explains, “We kept experimenting, trying to get it perfect. Rather than prototyping in Flash first, we went straight to iPhone and kept changing it as we went. Nowadays we’d never develop like that.”

Mouthing Off About Costs

With the studio’s next app, MouthOff, Mills felt that UsTwo had learned from their previous mistakes. “Before we began development, we looked at the apps that were doing well, like the fart apps, and decided to make something quickly with minimal effort and cost. It’s only made around £11,000, but it probably broke even. Development cost a tiny amount, however we spent time promoting it and have rolled out updates too.”

Despite MouthOff breaking even, Mills believes the real value for UsTwo is in the contacts the studio has made and the exposure they gained in promoting the app. MouthOff was even used in a video for Tanya Morgan. In a surprisingly candid move, Mills shared the sales figures and stats for MouthOff with me. Sales for MouthOff are revealed as averaging out at around 50 per day, the vast majority of which come from the U.S. and Great Britain.

Although he knows it could have been even more popular, Mills is happy with the general response to MouthOff, “In some ways it was a massive success and in other ways it wasn’t nearly as successful as it could have been. We made lots of contacts though and we’ve been approached by new clients too.”

Looking forward though, it’s clear that UsTwo has its eye on the App Store’s future. “The next wave in the App Store has to be coming soon,” Mills explains. He believes that, as there’s an over-saturation of duplicated app concepts, it won’t be long until people run out of novelty ideas. Hinting at the future, it’s clear that Mills sees UsTwo as a part of the next wave, “We’re in talks with a fair number of clients, discussing some interesting and genuinely useful apps.”

Only a few weeks in to developing an app for iPhone, it’s clear to me that this could be a potentially costly undertaking. Mills, with his straight-talking and utterly candid approach to development costs, gave me a serious reality-check. As a team, we need to take on UsTwo’s approach — building gorgeous, fun apps while keeping one eye on the books.

Next time: I wrestle with Apple’s Developer Center and try to test out the first playable prototype of our game concept.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Why iPad 2 Will Lead Consumers Into the Post-PC Era
• The Near-Term Evolution of Social Commerce
• Content Farms: The Players, The Benefits, The Risks

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.

Lose/Lose Game

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.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Mobile Q4: All Eyes Were on Android, 4G and the Rising Tablet Tide
• Report: A Mobile Video Market Overview
• In Q3, the Tablet and 4G Were the Big Stories

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 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 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.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• How to Market Your iPhone App: A Developer’s Guide
• Virtual Worlds: Trends and Opportunities

This is the first installment of one journalist’s diary designing a game. It is a genuine, behind-the-scenes look at what it’s like to develop an app, from conception to release, for Apple’s iPhone.

This isn’t your regular developer diary. There’ll be no talk of code and classes, no discussion of the intricacy of integers or vileness of variables. In fact, before we begin my journey into game design, I’ll take a moment to set the scene.

Late last year, I hit the 3-year mark working at a big name mobile game publisher. My grand scheme, after graduating from college — studying for a degree in “Computer & Video Games” — was to take a job at an established game studio, learn my trade, garner some valuable industry experience and then go solo. Deep down, I wanted to make the kind of games that weren’t being made enough: Katamari Damacy, Rez, Jet Set Radio Future and Vib Ribbon.

I wasn’t exactly sure what going solo entailed, but I knew it involved me ploughing my own creative furrow. More importantly, after doing the full-time thing, I also knew that my solo endeavors wouldn’t involve a regular 9-to-5: I work best during night hours, while the city sleeps, like Batman, but with less scowling and cape swishing.

Fresh from college, when many of my peers were jobless, or asking their ‘clients’ if they wanted to supersize, or, worse still, working in QA for a game developer, I landed myself a producer role at a big-name mobile publisher. In just my first year as producer, I found myself working on projects for hit Hollywood movies and my favorite comic book characters.

A New Beginning

For three years I rolled around the company, shifting job titles and launching products, hoarding experience like a demented katamari. When the time came, though, I packed up my Mac mini — the only Apple device in the office — and moved on.

And here I am now, a freelancer, doing what I love — being a creative consultant, journalist, musician. Except that in the process of working for that game publisher, disillusionment set in. I still love playing and talking about games, but those three years sitting behind the wizard’s curtain utterly dissolved my passion for creating games.

Until last week, that is, when I was approached by an iPhone development studio to get involved with their latest project. The three-man team, located in Barcelona, the UK and Finland, had developed a game engine prototype for iPhone.

Breaking Out From the Mold

The dev team’s prototype takes a traditional bat-and-ball game and injects it with physics. They need me to introduce some depth to the game’s design, though, working on everything from the gameplay mechanic and fundamental rules to artwork and sound effects.

As a game concept, though, bat and ball is a dead donkey that has been flogged, with the bat, until only dust remains and then the dust has been flogged some more, just to be sure. And then somebody set fire to the dust. A quick search for Breakout on the App Store reveals a torrent of bat-and-ball games, all reiterating the same concept.

There are some exceptions, however. Paper Breaker takes the breakout concept back to the drawing board, literally. It’s got a hand-drawn aesthetic that, although it doesn’t introduce any notable new twists on the genre, still feels good to play.

Most of the clones aren’t as imaginative as Paper Breaker, though. They seem more like thinly veiled attempts to quickly cash in at the App Store before the bubble bursts. But I’ve got an idea, something that’s going to take the traditional bat-and-ball genre and twist it into something utterly new. Now I just need to convince those clever coders to make it.

Next time: Olly pitches the concept to the coders. Is it really a new twist to an old genre? And do the coders even like his idea? Find out in the next thrilling installment of TheAppleBlog’s App Developer Diary.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• How to Market Your iPhone App: A Developer’s Guide
• Virtual Worlds: Trends and Opportunities