Posts Tagged ‘design iphone game’

Ten things to do before creating your first iPhone game

February 17, 2009

iphone_idea_reflectLast week we wrote a post that described how Gogogic turns an idea into a game, using Symbol6 as a reference. The response to that post was so massive (THANK YOU!!!) that we figured that we had no choice but to follow up on it.

Okay, okay – we promised to do that anyway –  but 12.000 views on Youtube made sure that we couldn’t wiggle out of it.

Originally, the idea had been to write a couple of followup posts but reader feedback (via email, comments, twitter and Facebook) has made it clear that we wouldn’t be able to cover all the interesting questions and issues raised without writing two of the longest, most inconsistent posts in Internet history. And we’re kind of reluctant to do that. So we’re going to write a series – yay!

This is the first post in the series (or the second, if you include the original post) and it is intended to work as an outline for later posts – a table of contents, of sorts.

It is written in the “Top 10” style of Guy Kawazaki – mainly because currently the writer has just read a few “Top 10” posts by Guy and is stuck in the format. A recent David Letterman sketch on Youtube is also to blame…

But without further ado, here are “Ten things to do before creating your first iPhone game”:

1. Consider Your Goals

We’ve all heard the news. The iPhone is the “new black”. It’s the best thing since sliced bread. And the App Store is a one-way street to endless glory, wealth and fame. Guaranteed (yeah sure)!

Indeed, the App Store is truly disurptive and Apple has introduced a brilliant new platform with a lot of potential. They also offer a very fair deal to developers, allowing them to possibly break away from the traditional value chain and earn good money while Apple handles all the (boring?) sales and retail issues.

But before you go storming into the App Store, you should consider your goals. Are you looking for a few extra bucks or are you betting your entire future on App Store success? Are you just trying out your development skills or are you looking at this as a business opportunity? Is this “just another platform” for your titles or are you going to specifically design new games for the iPhone and the iPod Touch?

Goals are important because they are the foundation of a good plan.

2. Planning Is Important

When you know where you’re heading, you can plan on how to get there. Start by doing some research. Crunch numbers, glean stories of experience, dig until you have all the information you need. Try to figure out if your goals make sense.

At Gogogic, we decided that if the company was going to focus on this new platform, it would be a “long term” decision. This meant that we would be in it for the long haul, be willing to invest into building a brand along with a number of games that were specifically designed for the devices in question. Catering to the App Store would become a core objective. Which meant that we would truly have to believe that it was more than a phenomenon.

This is an “expensive” goal, so we had to make sure that we felt that we could “get there”. We spent a lot of time on planning and building our strategy, looking at the likelihood of success versus failure. We took our goals, broke them down and built our very own road map. Of course there is still a good chance that we’ll just fail miserably – but at least we had a map and a flashlight so we can’t blame it on not being prepared!

 3. Look At Your Resources

This is a simple one. Make sure you (or your team) can build whatever it is you want to make. If you do not have access to the resources needed to finish the project, you have a problem. Worse, you might think you have the resources needed, when in reality you don’t. Even first class programmers need a little time if they’re asked to implement something in an unfamiliar environment.

4. Think About Your Market

What audience are you going to cater to? Where can you reach them? How? Why will they look at your app? And what’s with all these questions?

Device owners are a diverse crowd so make sure you know what your niche is. It is always much harder to try to build something “for everyone” – some would say impossible – so knowing your market is important.

This also simplifies things when you think about graphics, sounds, advertising, promotional issues and communities. Your audience is at the very core of those issues.

5. Make Sure Your Concept Works

The real point of our previous post, where we talked about how we take an idea, turn it into a concept and finally into a working game, is making sure that your concept really works. Of course, this is harder than it seems because it can be very difficult for an “insider” to spot a terrible concept, simply because you’re too close to it.

The solution is to test early and test often and preferably get “outsiders” to validate the concept.

A funny fact. The game developer of Symbol6 walked around the office holding a  neatly folded paper version of an iPhone with a Symbol6 concept image on it. He argued that if it was fun imagining how it would actually play out, then we were definitely on to something.

6. First Impressions Are Important

We’re just saying. It’s something we put on our list because we wanted to build a brand and we wanted to be know for certain things – like polished game play, polished graphics and quality implementation. So we thought a lot about first impressions (still do). Maybe this isn’t as important if your goal is more “short term”… but still. At least make sure that your game works properly.

7. Do What You Do Best

For your first iPhone game, it makes sense to stick to what you do best. If you’re used to develop Flash based web games – small and casual – you should probably focus on something of similar size and content for your first iPhone game. As opposed to building a 3D shooter with 400+ levels.

There is also another level to this. Try to do what you do best, but do it better for the iPhone. Really think about how you can enhance the experience by utilizing what the device offers you.

8. Don’t Plan On 1.000.000 Downloads

Consider this a warning. Do not, under any circumstances, plan on your game getting hundreds of thousands of downloads in its first day. Or week. Or month. Or year. Expect it to get a few hundred downloads. That way, you won’t be disappointed.

The reality is that the odds are against you. Of course it is okay to expect the best – but prepare for the worst. Very few titles rise to superstar status – fewer still, if they are published by a previously unknown developer. There was a window once – when the App Store launched – but it has been closed for some time now.

This is one of the reasons why we’re in it for the long haul. We’re building a brand. We’re looking at long term success. We believe that eventually this lessens the risk of failure – but, of course, we could still fail badly (or just be terribly terribly wrong).

9. The Game Is Out There – Now What?

Think about how you intend to follow up on your game. Are you going to add features? Are you going to change the price if you’ve gone in too high or too low? Are you going to submit promotional codes to review sites? If so, which sites?

If your original goal depends on any kind of success factor (critical acclaim, sales figures, recognition) then you should plan your actions after the game is released. Building the game is just the first step in what might become a long journey. Make sure you’re not just wandering around in the desert.

10. Be Patient

This is the last point (finally)! We’re not entirely sure we’re right but our plan is to be patient. What this means is that you should probably not drop the price to $0.99 after 2 days if you’re not seeing sales figures in the hundreds.

This also means that you shouldn’t panic if you only have a handful of reviews in the App Store after the first week. Or if the only published review for your game is posted on your blog.

Instead of panicking, take a good hard look at the situation (every 2-4 days, for example) and go over your strategy. Ask yourself if there is something you should change or if there is something to respond to. If the arguments are there, by all means react. If not – don’t panic.


WOOT! Monster post, finally over. But where does this leave us?

Well. Hopefully we’ll be able to look at these issues (and others) in detail in a series of posts, as stated earlier. Those posts will also include additional thoughts on testing, marketing, promotion, tools and other issues that we feel are important to the “average iPhone game developer”.

Until then…

Bookmark and Share

Symbol6 : How We Created an iPhone Game

February 9, 2009


Yesterday, I asked my Twitter (@gogogic) followers/friends if they would be interested in a blog post about our concept and development processes. The answer was an overwhelmingly repeated “yes, please!”.

It was hopelessly clear that I would not be able procrastinate this here post… So, as promised, here is a rough look at how Gogogic operates, using Symbol6 as an example. Enjoy!

It all begins with an idea

Gogogic designs, develops and publishes games for the web, as well as the iPhone and the iPod Touch. This basically means that we have to come up with a lot of cool game concepts. Constantly. Which is what probably sets companies like Gogogic apart from companies that are more used to building “conventional” games – or “big” games (although, some of our future titles would certainly be considered big but “casual”). We work with volume while others work with size. And, of course, all good game developers constantly work with quality.

This means that ideas are very important to us. Polished game mechanics, innovative features and games that fit the intended platforms perfectly are all things that we look to incorporate in an initial idea. A lot of our time is spent on ideas. Everyone can participate and pitch their ideas. At any given time.

The process

The following image roughly describes the overall process, where an idea is molded into a concept which then becomes a formal proposal which is accompanied by an animatic that serves as an initial prototype.


At any given time we have a stock of very rough “game ideas” – some are little more than a few lines of text and a rough sketch or two. All of our “logged” ideas are stored on an internal wiki and they are developed gradually, through a very organic process of reading, reviewing, re-writing and updating.

Everyone can be involved, in one way or another. Some people have to participate, of course, but anyone can chip in. Concepts are discussed during meetings (both formal and informal), sent between staff members for comments, etc. And, of course, a lot of doodling and drawing goes on as well. The following image shows the very first paper draft for Symbol6:


Some concepts never make it past the “few lines and an image” stage (the initial idea stage), while others become drafts that are developed and “finalized” (of course concepts are never “finalized”, but there is a point where you have to stop and decide that you’ve reached the stage that separates concept from full blown design). A finalized concept feels complete when:

  • It describes the basic workings of a game
  • It captures what would initially seem to be main elements and mechanics
  • It has an initial story
  • It has a flow to it – a basic game play description
  • It holds conceptual suggestions to look/feel/sound/size
  • It suggests user stories and interactions

When a concept is “fully developed”, it becomes a part of a “proposal” pool – which basically consists of a number of concepts that we feel are all worthy of being analyzed and broken down into specific requirements.

The proposal

Symbol6 was formally picked from the proposal pool because

  • The concept indicated that the game could be a lot of fun
  • The game had the potential to reach a broad audience, even though it was especially interesting to a niche market  (puzzle game lovers)
  • The game had replay value, although it was simple and relied on a single (but unique and polished) game mechanic
  • The game was simple enough for us to implement it fairly quickly on a new platform, without compromising kick-ass graphics, sound quality or game play implementation

After being picked for production, the Symbol6 concept was turned into a full blown game proposal, where basic game design took place. Proposals also hold further implementation details, goals, feature specifications, etc.

For smaller projects, like Symbol6, the game proposal actually acts as the first draft of a design document, so when the game proposal for Symbol6 was accepted, we already had finalized most of the game design, as well.

The animatic

But the proposal (or the game design document) is not the most important part in our process. The “prototype animatic” is, however. Below, you can see the initial animatic that was created for Symbol6 (Amusing fact : the working title for Symbol6 was Hexago).

The animatic has one purpose, and one purpose only. It visualizes the experience of a conceptual player, given a specific scenario. Simple games, like Symbol6, only need a single animatic to describe the whole game, while bigger games need multiple animatics to portray different “player stories“.

As those of you who are familiar with Symbol6 can see, most of the features portrayed in the animatic were implemented in the final version of the game. The animatic instantly set the tone for the entire game, how it would look, how it would work and how a player would experience it. Everyone on the team knew what to do from the moment we reviewed the animatic.

It also allowed us to decide what features we would implement and what features we wanted to skip, based on a visual experience. Furthermore, it allowed us to quickly prioritize features, requirements and critical elements.

At Gogogic, the animatic is king.

Production and design

Finally, the game is ready for production, along with sound and graphic design. Concept images and sounds have, of course, been set up. But this is the point where everything is finalized and handed in.

The following image shows the complete symbol set for Symbol6, as the graphics department handed it over to production.



I’ll leave the production, testing and publishing processes to another post (or two) since they diserve more than a couple of lines at the end of what has become a pretty long post.

Of course, this post only covers the fundamental parts of what we do ,while I’ve tried to avoid specific details of “how we do it”. Each aspect would need a separate post, if the intent was to cover that as well.

But “what we do” leads to the question “why we do it”. The answer is simple. We’re trying to build games that are extremely fun, innovative, user friendly, slick, stylish, beautiful and immersive. We’re trying to create an experience and that is why we go to painstaking lengths to see if a concept works or not – by an iterative process that organically weeds out ideas that do not work and by visualizing what we’re trying to achieve, early on.


Hopefully we’ll be successful with Symbol6, because we have a lot of great concepts just waiting to be produced and released. I’m sure I’ll publish “sneek peak” images and examples here, on this blog, before long 😉

And remember to check out Symbol6 in the App Store,  or the offical site, if you haven’t already.

Bookmark and Share