James Kelm is the COO of social mobile studio Wormhole Games. Before co-founding the company in Q3 2012, and announcing it to the world in January 2013, Kelm held positions at Apple, Google and Funzio.

During a recent press interview, I was asked about how past experiences at Google influence us at Wormhole Games.

This got me thinking about how different developing a game is from developing a consumer internet product or service.

I figured there are many who make the jump from internet to games – and there appear to be enough existing game developers in social mobile falling into familiar traps – that it would make sense to elaborate on what in your toolbox works and what doesn’t work.

You can't iterate a shipping product

At Google, a talented tech lead, good product manager, and a strong UX designer could build pretty much anything.

The keys to success were simple: identify the minimum viable product (MVP) you need for a domain, build it quickly, and iterate rapidly based on user feedback to the MVP.

The web is an awesome substrate for iterative product development, as you can test features and functionality server-side, monitor response in real time, and respond accordingly. This feedback loop is incredibly powerful, so for the consumer internet, what mattered most was identifying a core MVP for addressing a problem and shipping it quickly.

Unfortunately, the ability to iterate rapidly breaks with native mobile apps. Distribution – be it platform approval processes or waiting for users to update/install the latest version of your binary – slows everything down.

Whereas on the web you could deploy and test a new version of a feature in minutes, for native apps it takes days or weeks to get your client engineer’s code to your users' devices.

You can cleverly bake an experimental framework into your client, enabling you to test, turn on, or turn off functionality based on server-side flags. But the ability to fix bugs, tune and polish quickly on a live product is gone.

So how does a lack of rapid iteration affect development? I would argue it increases the investment you have to make in an idea before you can test it.

You're not just throwing something up on the web and seeing if people use it, you’re putting a product on a virtual shelf in a virtual store.

But you can iterate on game design

The above point on iteration should be pretty obvious to a product person making the shift from web apps to mobile/tablet apps.

But when it comes to games, as opposed to apps, there's a more profound difference. Games aren't just products, they're entertainment content. They need stories, skill elements, puzzles and balance; and judging by the top grossing listings, they increasingly need great art and polish.

For this reason, our game development is driven more by creative and design processes than technical ones.

At Wormhole Games we've tried to apply the rapid iteration of web apps to the game design process. After brainstorming a big list of game ideas, we laid out rough game designs, concept art, and storyboards for our favourite ideas.

In parallel, the technical team would prototype killer features or functionality (e.g., a special effect or a new use of gesture) and try it on native devices.

Assembling, tearing apart, modifying and rebuilding game designs, storyboards and technical proofs-of-concepts honed our game ideas into strong, focused candidates.

Five games in particular resonated with us, and we can’t wait to get them in the hands of users.

Art production: Beyond artistry, workflows and tools

Consumer internet products require visual assets, but games require art on a much larger scale. While web developers may be used to thinking of a UX designer as a single provider of all things visual for a product, game art requires multiple disciplines.

We brought together a concept artist, character artist, character animator, landscape artist and UI artist to create the visual experience of our forthcoming game. Art, not engineering, is likely to be the long pole of the project.

Despite art production being very different from building consumer web products, experiences at Google influenced two of the approaches we use to manage production.

First, we thought about the handoffs across our workflows – particularly at the junction between art production and engineering – and we nailed down a spec for each step in the flow prior to going into full art production.

How are files named? How will they be delivered? If multiple assets are intended to interact in the game – e.g., a marionette of sprites that form an animated character – how do you tag the points where each image interacts with another?

Second, we focused on tools we could create that would enable non-engineers to validate art assets and integrate them into the project. This freed additional engineering time to focus on building instead of visually debugging.

These two tactics – clear definition at each handoff and tools for validation and integration – enabled us to ramp up art production quickly with minimal rework or impact on engineering bandwidth.

Enable and empower creativity

From my perspective, making games is quite different from building consumer internet products. Reflecting on experiences at Google, there are three general bits of advice I would give a web developer looking to build a game.

First, re-think iteration. Iterate early and repeatedly on evolving your storyboards and design. You need to do this to create compelling, original entertainment. Make that investment upfront, knowing that once you ship the game, the story is set.

Second, once you’ve locked in a design, commit yourself to polish. Set a high quality bar on what you ship; polishing after you ship is almost impossible (and really, it’s too late).

And finally, focus early on production workflow. Clearly define deliverables at each handoff in workflow, and build tools to reduce engineering overhead.

The familiar thread running through all these tactics is the recognition that we are dealing with an entertainment product, which is fundamentally different from any other consumer product.

You have to enable and empower creativity to incubate, and drive the early formation of the product, for it to flourish later. It’s not something you can patch up after the fact. Instead, it’s the best investment you can make in your game’s success.
For more information on Wormhole Games, take a look around the company's website.