I’ve been using BrainWave as my primary project management tool for my games and this is primarily what has driven its development (along with suggestions from users through the built-in feedback). Overall I’m happy with the direction it’s headed. I’m trying to keep the functionality simple and focussed, avoiding a mass of unused features. In essence, it still consists of an area for capturing ideas and a list of tasks (either added directly or converted from ideas).

I’ve just released version 0.4 which is actually a fairly big deal for the project. It introduces a new look (a refinement of what already existed but making better use of the screen real estate), nails down the existing features, and fixes a myriad of bugs. For those of you not in the private beta, here are the headline changes from that initial post 5 months ago.

• A new look – Not as dark, massive amounts of idea space, and a streamlined task interface
• The positions of your ideas are automatically saved between sessions
• Filter on completed/open tasks
• The ability to create lists (Converted ideas appear in the currently selected list)
• The ability to add tasks directly to a list

With version 0.4 being such a drastic change, I’ve produced a new screencast to demo the features (which you can checkout below).

The next logical step then is version 0.5. This will be a feature release so will have some new things to play with (in addition to the usual bug fixes and further improvements to the code). I haven’t finalised what it will consist of yet but here’s a rough idea of what I want to add to BrainWave in the future.

• The ability to track multiple projects from one account (this is crucial)
• Milestones (e.g. release date, etc)
• Some way to track project progress and current phase (perhaps tied to the milestones – I’m thinking a filmstrip type of thing)
• Ordering of tasks
• Edit Ideas after creating them
• Multiple users on one account
• The ability to move tasks back into the idea space
• The ability to move tasks between lists easily
• Optimisations for use on the iPad/iDevice
• Export options

BrainWave will go public at version 1.0 – A fair way off yet but by that time I expect to have used it to manage a fair few games.

If you’re interested in BrainWave you can sign up to the private beta here. I’m also interested to hear if its a tool you think you would use in production (and perhaps even pay for). I’d like to point out that I don’t currently have any plans to monetise it.

I didn’t expect the addition of waves to be trivial but it’s certainly challenging me – I’ve already been through half a dozen custom systems. I messed around with the concept of a pattern creation system that enables me to manually control what you see on the screen. I’ve now scrapped this and moved back to a more dynamic system that lets the program decide what to throw at you – its currently fairly dumb but that can make for some interesting situations. I’m adding layers of complexity to this system to ensure that there is enough to keep you progressing through the waves. I’m also looking into tying wave progression to the scoring system (and therefore making progression a result of player skill).

I’ve modified the core mechanic slightly to include a mathematical element. This makes the game significantly more difficult but has the added effect of keeping you engaged. I think this slightly changes the target audience but it feels like its for the best – In fact I think I’m going to play off it in the marketing. I’m spending some time ensuring that this mechanic fits nicely and provides an enjoyable challenge.

I’ve integrated OpenFeint to handle scoring and achievements. I’ll share some of the achievements with you as the game nears its launch.

Powerups are an important part of the game and will definitely make the final release. I have a number of ideas for them but I haven’t implemented anything so far – I want to get the core game balancing right first before I throw in these wildcards (and balance them).

Something I’m also contemplating is the addition of bosses – a sure sign of feature creep if ever I heard one. Its likely that I’ll look at including this in a future update or expansion.

The graphics have gone through a huge amount of change in a short amount of time. I’m stretching the limits of my photoshop skills but I think the result is well worth it.

My current soft target is to have the game launched some time in September/October. I’ll look to post my marketing activities and results on this blog so you can follow me through the ups and downs of releasing the game.

…More soon, so stay tuned.

Coffee, like cooking and baking, seems to be synonymous with being a game developer (Why do game developers like cooking and baking so much?). I’m sure some game devs out there don’t actually enjoy coffee (purely for the purpose of disproving my theory). So, for those of you that fall into that camp… sorry. Keep enjoying your tea, water, or whatever (maybe someone can write a herbal tea guide). For the rest of you, here’s my guide to coffee for game devs.

Coffee is very much a personal thing and you should create a process that works for you and produces coffee that you like. This is my process.

1) Break for coffee

Usually, after about an hour or two of game development, I’m ready for a coffee break. Equally, if I’m stuck on a particular problem and struggling with the solution, I break immediately for coffee. It’s important to take a break from coding if you feel this happening. You’re unlikely to get the solution whilst sitting at your screen, and time spent making a coffee (15 minutes or so if you follow this guide) is just right for that magical solution to pop into your head. You could of course spend the time having a break without coffee but really, what’s the point? Coffee tastes great and fixes your code. What’s not to like?

2) The espresso machine

Espresso is the basis for a good Americano (my drink a choice) which consists of a single shot of espresso (the cups I use are quite small) topped up with hot water.

There are hundreds of espresso machines on the market and I’m not knowledgable enough to advise you on what to get. I currently have a Dualit Espressivo which does the job and was fairly inexpensive. I’m currently lusting after a Gaggia Achille. If you want to go cheap then get something like the AeroPress – Apparently they’re quite good and I’m interested in getting one myself.

Fill your espresso machine’s water reservoir with fresh water and turn it on now. It takes time for the machine to get up to temperature and in the case of the Espressivo I find that its better to leave it for longer than the user manual suggests.

3) Choosing your coffee

Choosing the right coffee is an important decision. It’s also completely down to your own taste. I like bold coffees with powerful flavours but you may prefer something lighter. I’m currently drinking Brazil Fazenda Cachoeira da Grama Bourbon. If you’re in the UK, Has Bean is a great place to purchase your coffee, with superb information on each coffee and a passionate coffee roaster (Perhaps those of you in other countries can suggest good places to buy your beans in the comments below).

Whichever beans you choose, once opened, they are best stored in an air-tight container, in a cool (not the fridge), dark place. Bags with one-way valves work well too.

4) Grinding the beans

The advantage of grinding your own coffee is freshness and flavour. It really does produce a superior cup. You need a good burr grinder for grinding your coffee beans. Electric burr grinders can be very expensive so I’ve adopted a slightly left-of-the-middle option and use a vintage Zassenhaus hand coffee grinder. These things are great. They’re a fraction of the price of an electric grinder and really get you closer to the experience of making coffee. You should be aware that grinding by hand requires a little more time and effort, and hand grinders also have limited bean capacity (enough for a single cup).

I find that hand grinding the beans gives me a perfect opportunity to mull over my code in my head. I’m convinced that the smell of coffee wafting up aids in thinking up some truly creative solutions.

Lazy option: Sometimes you won’t want to grind a fresh batch of beans and in these instances I have a tin of illy’s ground coffee waiting in the wings.

5) Flush the machine

Its important to flush water through the machine before you extract your espresso. Just place the empty basket in the portafilter, a cup underneath, and turn the machine on. This also serves to warm your cup. Wipe the basket and portafilter dry once you’ve done this.

6) Tamping

The next step is to transfer the ground coffee from your hand grinder to the portafilter basket. I tend to use a teaspoon for this because it helps me to distribute the coffee evenly in the basket. Get your tamper and apply a decent amount of pressure to compact the coffee. Everyone has a slightly different technique for this. The method I use is to lightly tamp to compress the coffee, then apply a good amount of pressure, and finish with a quarter twist of the tamper to seal the puck.

I find that around about now, the solution for my code problem pops into my head. Often its something simple, these things always are. Don’t rush off to fix it yet though, finish the coffee first.

7) Extraction

Okay, the extraction process. I’ll try to give you some basic guidelines on what works for me but trust your taste and don’t worry about getting it wrong.

I use a coffee shot glass, marked at 1oz, to help me with this step. You’re aiming for 1oz of espresso in about 25 seconds. I prefer to slightly under extract the espresso and retain some of the sour edge.

If your coffee tastes bitter then it is probably over extracted. That is to say, the extraction process took longer than 25 seconds to obtain a 1oz shot.

If your coffee tastes sour then its is most likely under extracted. This means the extraction process was faster than 25 seconds.

Remember, the constant is the 1oz shot. In order to compensate for under or over extraction, you’ll need to alter your ground to make it either finer (if you’re coffee is under extracted) or coarser (if you’re coffee is over extracted).

8) Finishing touches

Transfer the espresso to a cup and top it up with hot water (just off the boil). You can then add your desired finishing touches. I tend to just add a splash of whole milk.

9) Spillages

So you’ve got your awesome coffee and you’ve brought it back to your desk only to be confronted by your screen, a keyboard and mouse, 2 iPad’s and 13 iPhones trailing from the computer, and your graphics tablet taking up most of the room. You have few options here, you could use an iPhone as a coaster (There’s an App in that somewhere, especially if it farts too), you could use my preferred method of shoving the graphics tablet out of the way whilst simultaneously scratching your iPad on your laptop, or you could prepare some space beforehand (or you could have if I had mentioned this as step 1).

In the unlikely event that you spill your coffee all over your computer, don’t worry, just close your eyes and imagine it didn’t happen. When you open them again, the spillage will be miraculously cleaned up.

So there you have it. Hopefully during the process of making coffee, and truly enjoying doing so, the solution to your coding problem popped into your head and you can continue writing your epic game. Good coffee has once again saved the day.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the website, RSS feed, or Twitter.

Project Name: Interactive Fiction

Status: Abandoned

Pitch: This was my first ever iPhone project and was the reason I got into iPhone development in the first place. I wanted to drag text adventures, kicking and screaming, into the 21st century.

My plan was to utilise the iPhone’s touch interface and eradicate the need for text commands. Aside from tapping edges of the screen, to move North, South, East, and West, my game changer was a verb and noun wheel (dubbed the action wheel). I was conscious of not losing any of the charm of the traditional text adventure but at the same time I wanted to make it accessible to a new audience.

I did my research and developed the game engine to a point where it was capable of parsing an XML file. I created a custom text adventure language that formed the basis of these XML files and meant that I could easily make multiple adventures available without changing the core application.

Why was it cancelled?: Do you ever feel that you’re a little bit mad? and that you’re the only one who finds enjoyment in something relatively obscure? Thats what happened with this project. I couldn’t find a single person, gamer or otherwise, who was interested in the thought of a text adventure on the iPhone. I could have spent the necessary time completing the project (the biggest challenge remaining was writing a fresh, compelling story), but ultimately I didn’t want my first game to be something that I alone wanted to play.

Positive lessons learned: During the development of this game I learnt the basics of Xcode and the Interface builder, I created an XML parser and custom text adventure language, and I decided that developing games for the iPhone was definitely something I wanted to pursue. Writing this now, I also realise the advantage of some good market research.

Oh and for the first time ever, I’ve dug up the remains of this game, recompiled it, and recorded a video of the text adventure in action.

Project Name: Colour Mix

Status: Abandoned

Pitch: The idea behind Colour Mix (the working title) was to create a colour matching game with a steampunk theme. Three vats of liquid represent the base colours, red, green, and blue. You turn the wheels on the vats to alter the mix, flick a lever, and see how close your colour is to the colour you have to match. Time limits and power-ups were going to be added to keep things interesting and, to add complexity, you would be required to fix the machine using various tools as and when it broke down.

Why was it cancelled?: The game just didn’t have any staying power. It was interesting for a few minutes but ultimately it didn’t have anything to keep your interest long term. I think I could possibly have gone back to the drawing board and added some more depth to the game, but I’m not sure how much mileage I could have gotten from the core concept. Looking back now, I think I focussed on the art at the expense of the gameplay.

Positive lessons learned: Actually this is more like positive lessons I “should have” learned. I actually went on to make a similar mistake in the game I’ve just cancelled. The lesson is not to rush into development. Its worth spending a decent amount of time fleshing out the core concepts beforehand. I think that if I had thought through how the game might have played, I could have identified it’s weaknesses early on. I did get a decent amount of experience with vector graphics though so that was definitely a positive.

And here’s the newest resident of my game graveyard…

Project Name: Explorer

Status: On hold

Pitch: The initial pitch was for a timing based game. You moved your character around the screen, negotiating lifts and various other obstacles, with the aim of getting to the exit before the timer ran out. Pretty simple stuff.

However, this was just the initial pitch, the game actually went through several transformations to eventually become the following. A platformer in which you are an explorer. You wonder around vast, weird and wonderful levels collecting gold and searching for an artifact. Once you have the artifact, you must return to the start. However, you won’t be able to take the same route as before so must find a different way back.

In addition to this there’s a random event wheel which triggers a random event every so often – this could be a change in weather, dehydration, or unexpected gold for example. Each random event will have an effect on your ability to explore. Items to negate these effects can be purchased in a store (using gold you collect in the levels).

The game also has an in-game level editor to allow you to create your own levels and share them with your friends.

Why was it cancelled?: Quite simply, scope. The game is already 6 months into development but has gone through so many iterations that I barely recognise it anymore. Its grown into a monster and I feel like I’m fighting just to get it under control. I actually don’t think I can work through the issues and the thought of attempting to do so does not fill me with excitement. In addition to this the game feels shallow, lacks fun in its core mechanics and feels far too disjointed. I should have learnt from past experiences (see the game above) and spent longer figuring out the game design.

Positive lessons learned: Where to start. I’ve created a flexible game engine powered by data stored in an SQLite3 database. I’ve played with creating an in-game level editor. Most importantly I’ve understood the importance of spending time in the design phase, both on gameplay design and code architecture. Its tempting to rush into a project, as soon as it looks like you have a concept that will work, but if the foundation of the game isn’t simple, fun, and engaging then building layers of complexity upon this is a sure path to disaster.

As a bonus, here are some ideas that never made it past the idea stage. Games burnt at the stake and robbed of their youth.

Project Name: SpinIt (aka how to scratch the back of your iPhone)

Pitch: You put your iPhone flat on a surface and spin it as fast as you can. The screen counts the number of full revolutions, incrementing them as the phone spins. Online leaderboards would create an element of competition.

Why didn’t it go into development?: As if I need to tell you. Spinning your iPhone on a table tends to scratch the back of the device. Also is it really that fun to watch your phone spinning around – I think not.

Project Name: Personalities

Pitch: Interaction with the iPhone to elicit emotional responses. Whispering, touching, etc results in a happy response. Shaking, shouting etc results in anger. To enhance this, I was also looking into how this mechanic could be used to interact with rooms containing various puzzles.

Why didn’t it go into development?: Some very light market research highlighted that people feel like idiots whispering into their iPhone :-). Honestly, I may come back to this project.

Project Name: Weird Puppet Box thing

Pitch: You control a puppet by manipulating wheels to move along the x and y-axis. You’re given an item to create and must do so by moving your puppet to boxes (on the wall behind you) and selecting the correct combinations of materials. This is essentially a memory game. For the graphics, imagine old bookshops, wooden toys, and mysterious odds and ends.

Why didn’t it go into development?: Its just not a very compelling idea. It would rely heavily on the visuals to sell it and that’s rarely a good idea.

So there you have it, my iPhone game graveyard. It’s been interesting looking over my old game ideas and cancelled projects. Writing this post has given me the opportunity to do a mini postmortem of each of my games. I encourage you to do the same and take stock of the lessons learnt, even if you don’t share them. Cancelling a game is a tough decision but, if you learn from your mistakes, your future games will be both more enjoyable to create and more enjoyable for your players.

Any developers reading this have a game graveyard they’d like to share?

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the website, RSS feed, or Twitter.

For those of you not familiar with the original Star Fusion, here’s what its all about…

Star Fusion is a simple arcade game in which you control the Sun by dragging it along the y-axis. Stars move towards you from the right of the screen at varying speeds. In addition to the Sun you also control a thermometer which has a numeric heat value attached to it. Each of the stars also have a numeric value attached to them. Your aim is to collect the stars by matching the value of the thermometer with the numeric value of the star at the moment it touches the Sun.

There are a number of other details that help keep things interesting. For instance, you can double tap the Sun to cause any stars in your direct horizontal path to accelerate towards you. There are also time and score multiplier power-ups to be collected. Games last 2 minutes and are dynamically controlled so that no two games are the same.

(You can try the original Star Fusion at no cost. Details at the end of this post)

If you’ve read my blog or seen my tweets, you’ll know that I’m currently in full flow on my 3rd game which is proving to be an extremely lengthy, uncomfortable project (There’s a chance it may not see the light of day in its current form – more on that shortly). With all this work, and limited time, I had metaphorically pushed Star Fusion under the bed until next year.

So, you know how it is, I was developing away on my new game, making good progress but decided I needed a short break for coffee (Grinding your own beans with a vintage hand coffee grinder and taking the time to get the Espresso just right means that this “short break” is actually fairly lengthy ;-)). For some reason during said coffee break, Star Fusion popped back into my head and I wondered how easy it would be to port it to the iPad. A couple of hours later I had a basic shell working but held off implementing any of the game logic. This was great fun, I was having a blast working on Star Fusion again but I wanted to do it justice. I didn’t just want to port Star Fusion over to the iPad as it is, I wanted to make it better.

So that’s what I’m doing. I’m going to release Star Fusion HD with a completely reworked engine and a number of new additions and improvements that suit the iPad platform. I’ve already put a decent number of hours into it and expect it to take no more than a few months to complete (during my spare time).

So what’s going to be new in Star Fusion HD? Here’s my hit list…

1) A graphical overhaul with some nifty particle effects
2) The game will change from a time based system to a dynamic, endless, wave system (I may add additional modes in the future)
3) New power-ups (and a new way to collect them)
4) Lots of star types with vastly different appearances (unlocked as you progress through waves and viewable in the planetarium)
5) Open Feint integration for leaderboards and achievements
6) A chain system for reaching higher scores

The game is still very much a work in progress but I’d like you to see it anyway. Check out the screenshots below.

Oh and just for you, my dear readership, I’ve made the original Star Fusion for the iPhone free for a few days. Its not a marketing stunt but I would like you to download it and see what you think. Please leave your comments here, they will help influence the features of Star Fusion HD.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the website, RSS feed, or Twitter.

1) Don’t give up

This is easily my most important don’t. It takes vast amounts of commitment and drive to develop games independently (especially if you’re trying to hold down a job too). There will be ample opportunity to take the easy option and throw in the towel… don’t. Hopefully you’ll get lots of enjoyment out of developing and the experience of seeing your game out there should keep you going between games.

2) Don’t leave sound design until the last minute

I have first hand experience of this. Rocket Santa had a very tight development schedule and performance issues (requiring a complete refactoring of the code) made the schedule even tighter. I left sound until a few nights before submission and the result really brings down the quality of the game. Retrofitting your game with sounds is like trying to force a square peg into a round hole. Iterate your sound in the same way you iterate your graphics and code.

3) Don’t copy other games

Take your inspiration from other games but try to create something unique. It will help you stand out from the other games in the App store. I think we’re all getting tired of the number of clones in the App store. Its difficult to be unique but ultimately worth it.

4) Don’t leave marketing until the last minute

Marketing is so important for iPhone games. Whilst I have had exposure for both Star Fusion and Rocket Santa, I left marketing far too late on both. The result is that you drown amidst the hundreds of thousands of other apps on the store. You need to build anticipation before your game launches and then get as much exposure as possible on the day of launch.

5) Don’t do it for the money

There’s no doubt that there is money to be made on the App store. If your game is compelling and you put the work in, the monetary reward may follow. However, this isn’t always the case and banking on it could lead to disappointment. Focus on creating a great game and getting it in peoples hands, the money will hopefully follow and means you can keep doing what you love – making games.

6) Don’t expect to have a hit

Its getting less and less likely that your iPhone game will be a huge hit. Over the past year your odds have gone from around 50,000/1 to 225,000/1. There is, however, plenty of opportunity to have some success if you can get the marketing right.

7) Don’t develop your game in secret

I’m sure some developers will disagree with this. In my opinion, when you are a small independent developer, you can’t afford to hide your game away expecting it to be a huge hit when you unleash it upon the world. It works for big companies but they often have a pedigree which almost assures them a good number of sales. This ties into marketing and you should begin talking about and demonstrating your game as soon as its in a fit state.

8) Don’t listen to the negativity of others

Whatever you do in life there’s always someone out there ready to belittle you. Its a fact of life that these people are often the ones who don’t actually have the drive to do anything themselves. It takes absolutely no effort to take the easy path but it takes guts and determination to try and better yourself. Stay true to your dreams.

9) Don’t stop learning

There’s always more you can learn and in doing so you’ll grow your skills, and the quality of the games you produce will also improve. Also, I know that most people have a discipline at which they excel but you should try to learn a little bit about all areas of game production (Game design, time management, graphics, sound, code, marketing, etc). If you work with others, this will help you to be sympathetic to their plights and will give you an insight into how other areas of game production fit into the grand scheme.

10) Don’t forget what’s important

Honestly, its so easy to get wrapped up in game development that you forget about what is going on around you. I remember reading somewhere about the founder of Digg and how he ended up alienating friends and even losing his girlfriend over the creation of Digg. I’ve also read similar things from Stephen King in his excellent book “On Writing – A memoir of the craft” (if you haven’t already, read it now!). King talks about how he has a small desk, tucked out of the way, where he writes. When he writes there, that is all he does. This allows him to separate his writing from his family life. Don’t let your game development engulf your life, it’s better that it enhances it.

So there you have it, my 10 don’ts of iPhone game development. I hope you found it useful and agree with at least some of them. Any other developers out there have any “Don’ts” they’d like to share?

As game developers/designers, this is our source material. This is where we gather our inspiration and “research” our next big game.

I don’t want to dictate what you play, but let me offer you an alternative source of inspiration for your next big hit… the retro scene. Interestingly, what you consider “retro” is going to differ depending on your age. Lets try to give this post some context, since this is my blog, we’re talking about what I consider to be retro games – the end of the 8-bit era and the start of 16 bit consoles. This is where some of the biggest gaming franchises were born.

So what makes retro games such great reference material? Primarily its because they are simple and generally focus on a single gameplay mechanic. Due to the nature of the hardware constraints, and the relative youth of the gaming industry, the complexities we see in todays games were not possible. I’d argue that this gives retro games a pure, raw feel. You feel closer to the code and its easier to understand why specific game design choices have been made. This is part of what makes the iPhone such a great development platform. Its a chance to relive the days when game development was both simpler and faster. The iPhone lends itself to games that focus on a single, clear concept and these are often the games that do well.

I’m not suggesting you rip-off the retro games and stuff their designed-for-a-control-pad controls into the iPhone. Simply, take a look at what they offer. Most modern games are derivatives of the core concepts created in this era anyway.

Another great reason to look at retro games… they’re cheap. I’d encourage you to avoid emulators and instead buy the actual hardware so that you can experience the controls as intended by the game designers. You can pick up an original Mega Drive for around £20 (equivalent to $30 or half the price of a modern video game).

Lets take a look at some examples of the core gameplay mechanics on offer.

Sonic the Hedgehog
Core Gameplay Mechanic: Speed
Sonic is all about speed. Most of its environments are designed to be traversed at great speed. The game does a great job of motivating you to keep this speed, often putting power-ups in high-up places that can only be reached if you have enough momentum, and obstacles that can only be overcome at speed. A secondary key mechanic is the collection of rings. These rings act as your protection from enemies and as such, they introduce a great risk/reward mechanic.

Micro Machines
Core Gameplay Mechanic: Multiplayer
Micro Machines is one of the best implementations of local multiplayer you will find. Its balanced perfectly with just the right amount “close call” moments and a great competitive spirit. Oh, and no need for split screen either, the mechanics work such that your penalised for not keeping up with the pack – it works perfectly.

Kid Chameleon
Core Gameplay Mechanic: Reward
The core concept in this game is that your character can collect power-ups that significantly change his abilities and appearance. They’re more than power-ups though, they’re personas. The abilities of these personas are required in order to progress through the game. You discover new personas at key points and the anticipation of what ability you’ll find next keeps you interested in the game.

Ecco the Dolphin
Core Gameplay Mechanic: Unique
Ecco the Dolphin is all about the situation. You control a dolphin. Its totally unique and its this that creates such an interesting experience for the player. The goals are secondary to the environment, exploration, and the fact that you are swimming around as a Dolphin.

Golden Axe
Core Gameplay Mechanic: Co-op
Golden Axe excels at co-op. You have to share resources (health and magic), and you have to make decisions about how to handle enemies on the fly.

A word of caution: Don’t stop drawing inspiration from modern games totally, in favour of retro. Modern games have lots they can teach us and they can be truly innovative. Perhaps more importantly, they are current. They represent what people are trained/want to buy. Retro games should act as complementary source of inspiration.

A quick follow up note on #iDevBlogADAy: The concept continues to grow with @mysterycoconut creating an awesome website, a decent sized waiting list, and even talk of official merchandise. Its only a matter of time before someone suggests an iPhone App to promote it (and cross-sell the participants games)… oops!

We’ve already had great posts from Game from Within, Acorn Heroes, Retro Dreamer, Rizer Games and Québarium. For my post I wanted to cover something I’ve been meaning to write about for some time…

Recently I’ve had a couple of emails asking for advice on getting started with iPhone game development. I thought, to save time in future, and to reach as many people as possible, I’d write a kind of comprehensive overview post here. Bear in mind that this is my opinion. I would encourage anyone starting out to get advice/information from as many sources as possible so that you can make your own informed decissions.

A Tip

First a tip that I’ve found particularly useful. “Keep the scope of your first few games small”. Don’t try to do too much. Its better to produce something basic and focus on completing it, rather than developing something complex that you never finish. Once you’ve done this a few times, you can move on to your super-awesome RPG/FPS/RTS hybrid.

Getting Started

When developing my first iPhone game, I spent the first few months getting to know the development environment, programming language, and iPhone platform. The best way to do this is either via a book (I bought “Beginning iPhone Development” by Jeff LaMarche and David Mark) or you could look for some basic tutorials online.

You should also download Xcode and the iPhone SDK (They are both free but you will need to register). Xcode is the IDE (Integrated Development Environment) that you will use to create your iPhone games. It comes complete with an iPhone simulator so that you can test your games on your computer. Whilst the simulator does a good job of mimicking an iPhone, you will want to test your game on an actual device early on in development (particularly if your game uses the accelerometer).

iPhone Apps are written in the Objective-C programming language (although you can also use C or C++ if that suits you). You will need to get familiar with this programming language before you begin to develop a game. Books and online resources are the best way to do this, although, if you can’t wait to get started, the book I mentioned above assumes only minimal knowledge of Objective-C.

Planning your game

When it comes to writing your first game, there are numerous ways to go about it. You should be aiming to get as much information from as many sources as possible. Looks for inspiration everywhere. The first thing I usually do is sketch out some ideas (remember to keep the scope of the game small to begin with). There’s a balance to be made here. Time spent on the game concept and planning how it will work should, in theory, save you time when developing. However, it is possible to spend too much time in this planning phase. Due to the nature of the platform, iPhone game programming lends itself to rapid development and iteration. As such, decisions you make in the planning phase are likely to change during development.

As part of the planning phase I tend to develop some very light prototypes testing specific functionality/features. I find this helps me get a feel for what will work and what won’t.

Once you leave the planning phase, where to next? You have project management (maybe), graphics, code, sound design and production. I mentioned the iterative nature of iPhone game development above and this very much extends to these stages. You’re not going to want to produce final work for any of these steps in one sitting. You should aim to iterate code, graphics, and sound as your project progresses. I tend to focus on code and switch between project management, graphics, and sound as I go. Lets take a look at each one of these processes.

Project Management

You’re going to want some form of project management for your game. There are plenty of best practices out there and also plenty of professional tools. My personal view is that you should find a project management process that suits you. If pieces of paper with lists on them suits you then go with that, If you feel that a full blown project management system (complete with lists, Gantt charts, time management, etc) is what you need then that’s fine.

Some popular options you could look at include Basecamp, Pivotal Tracker, Trac, Omniplan, and Things. Ultimately I decided that none of these suited me and decided to write my own (and why the hell not? thats the beauty of being a developer right).

Whichever process you choose, you are looking for something that drives the development of your game forwards.

Graphics

Lets keep this straightforward with some tips, software, and processes you can use. I hear that @weheartgames is going to be posting some graphics related topics as part of iDevBlogADay, so look out for those.

Moodboarding is one of my favourite processes to undertake at the start of the “graphics process”. The point of this is to brainstorm images, text, and colours relating to your game. In theory it should help to define the art direction you want your game to take. Take a look at this post on Moodboards and this post on creative tools.

When it comes to producing the art assets for your game you have a myriad of options available to you. I can’t cover them all but you’ll want to make a decision between 2D vs 3D and you should also consider animation. Oh, and since this is a beginners guide, I strongly recommend you opt for a simple 2D game and remove the concept of animation (Your objects can still have movement paths but don’t animate them as they move). If you do opt for animation, “The Animators Survival Kit” by Richard Williams is a brilliant book covering the core principles of animation.

For my current project I’m using Opacity to produce vector graphics which are then exported as PNG’s. Vector packages are a good way to go because they are resolution independent. This means that you can scale them to your hearts content without losing any fidelity. This is particularly useful with the current state of the iDevice. We have the iPhone 3G/3GS (and there iPod touch counterparts) as well as the iPhone 4 and iPad. All have different resolutions and different dpi’s. With Opacity I can use “factories” to automatically export my Vectors at different resolutions (targeting different devices). A good free alternative is Inkscape.

I also use Photoshop Elements to touch up my graphics or to produce other assets such as logos, titles, screenshots etc. A good free alternative to this is Gimp.

The other tool I rely on heavily is my Wacom Graphire3 tablet. It makes producing art assets in the aforementioned packages much more natural.

Sound Effects & Music

Unless you really know what you are doing you should either have someone else produce these or buy stock sound effects and music. If you really want to produce them yourself then you might like to try some automated solutions – you can read my previous post on sound effects and music here.

Whichever route you take, its important that you consider sound effects and music early on. Leaving these until the last minute will give you a huge headache and will really degrade the quality of your game (take this from someone who knows!).

Code

The code itself. This is the best bit right? Hopefully the above shows you that there is more than just the code to think about when you’re creating your own game.

You’ll be developing your game in Xcode. As part of this you have a number of tools and libraries available to you. UIKit (Apple’s user interface framework) is fairly powerful and you can do a lot with it. However, its more than likely you will want to venture into OpenGL ES at some point.

As a beginner I recommend you choose a game framework. There are a number available but I think its fair to say that cocos2d for iPhone is one of the most popular and a good place to start. Cocos2d is a 2D framework that provides you with lots of helper classes to achieve common game related tasks. It also abstracts the OpenGL ES library to make it easier to work with.

Its important to make a distinction here. Cocos2d is a framework, it’s not a drag-and-drop Interface. Whilst it definitely simplifies the process of coding a 2d game, you still need to be able to write Objective-C. If you’re not interested in the coding side of producing a game then maybe you’d like to check out something like GameSalad which involves no programming.

Be prepared to iterate with your code. You won’t get it right first time and will most likely find yourself re-writing code often.

Testing

Test early and test often. Once you have something running on the simulator, get it running on a real device too. There are a number of differences between the simulator and the actual device. You won’t get a true feeling of your game until it’s running on a device. Interacting with your game using a mouse is a totally different experience to interacting with it via you devices touch screen.

If you can, testing on as many different devices as possible is also a good idea. Release a game to the App store means that iPod touches, iPhone 2G, iPhone 3G/3GS, iPhone 4, and iPad users will all be able to download it. These devices all have different capabilities that will impact your game in different ways.

Something you might consider is getting other people involved in testing. You can do this by creating an Ad-hoc build of your game and distributing it to your testers. This has the advantage that you don’t need to own all of the devices since your testers will cover the majority of the platforms. You will need to enrol in the iPhone Developer Program in order to distribute your Ad-hoc build.

Publishing & Marketing

In order to distribute your game to the App store you will need to enrol in the iPhone Developer Program. Once you’ve done this you can submit your application to Apple for approval. Approval can take some time but you will usually hear back within a few weeks.

Expect to spend decent amount of time on the submission process. There are lots of things to prepare such as bank details, tax forms, and the upload of details and screenshots for your game.

Marketing – This is at the end of this article but really it should be at the start. You should always be thinking about marketing. Blog about your game, tweet about it, post in forums, tell everyone you meet. There are 225,000 Apps in the App store – I bet you can only name a handful. I’ll leave the details up to you (mainly because I don’t have a magic formula) but, like testing, Market early and Market often.

Conclusion

So there you have it. A comprehensive overview of iPhone game development. Its tough developing a compelling game, and the rewards may not be what you’re expecting. You’ll have good times and bad times. Don’t be afraid to experiment, you often get unexpected results. Get involved with the iPhone development community, go to events, but most of all have fun!

Last month I hit a bit of a wall. I had far too many features stuffed into the game and was working on them all simultaneously. I felt totally overwhelmed, not knowing what to work on from one moment to the next. To remedy this I stripped the game right back, ripping out the level editor and character customisation. This has given me the clarity I needed to continue developing the game. I still hope to ship the level editor with the final game, the customisation on the other hand is unlikely to make the final cut.

In conjunction with stripping the game back, I also started to read a book titled The Art Of Game Design: A book of Lenses. This lead me to re-evaluate some of the core concepts in my game. The result is the removal of both the exploration bar and the timer. The game will still focus on exploration, but the pressure of time will be replaced with pressure of a different kind – preparing for random events.

The random event wheel

The biggest change to the game is the introduction of the random events wheel. This wheel spins at set intervals and randomly lands on one of a number of events. Preparing for these events, through the purchase of items such as water flasks and the like, will ensure that you have maximum time to explore the level and search for gold and artifacts.

The first event i’ve coded is rain. I decided to take this a step further and program the framework for a basic weather system. This will enable me to add additional weather events (such as snow) with less effort and greater flexibility. The weather system allows me to add my weather system object to the level and call the appropriate weather method .e.g rain. In order to enhance the realism of the rain, I also created a raindrop class. Each raindrop object has it’s own random position and speed. This has the effect of creating a truly dynamic rain experience – I can also vary the amount of rain with relative ease.

The next step is to create the camp where you will be able to buy supplies to prepare for each level. I’ll also be programming an inventory screen so that you can activate items in-game.

In other news, my sketchbook project sketchbook arrived from the US – I have a few ideas for filling it but nothing set in stone yet.

I also took delivery of a vintage Zassenhaus coffee grinder. It’s a huge improvement over the blade grinder I had been using previously since it uses burr’s. After talking to @rizergames on Twitter, I decided to completely dismantle it and clean it. I also took some time (and risk) to align the burrs a little better. The result is that the vintage grinder can now produce grounds fine enough to easily choke my espresso machine – so well worth the effort.

Until next time.

Somewhere along the line fate intervened and I ended up in software development. Whilst i’m certainly out of practice, my creative streak has never really left me. However, I now find myself increasingly frustrated that skills I once possessed have become dulled. “Get to the point” I hear you cry. Ok, scroll on past the pictures…

I recently stumbled across this really cool project called The Sketchbook Project 2011. The idea is that you’re sent an empty sketchbook to fill with whatever you like. To help ignite your creativity, you can choose a theme that loosely represents your sketchbook. You have until January 2011 to send your sketchbook back to the organisers. This is where it gets interesting. The sketchbooks are then barcoded and exhibited at various galleries and museums across the US. You can log into the site to track how many times your sketchbook is viewed and where. At the end of the tour they’re handed to the Brooklyn Art Library to be part of their permanent collection.

I’ve hastily handed over my $25 and am eagerly awaiting my sketchbook. This could be just the kick I need to get me back into art again. As for my theme… I chose “Happy Thoughts”.