Last week a great blog post, followed by a seemingly innocuous tweet from @mysterycoconut, escalated into what is now known as iDevBlogADay. The concept is fairly straightforward; Every day a developer (or two) will post on their blog. We all have an allotted day so that there is at least one blog post published every day of the week. @mysterycoconut has done a great job of organising it with the #idevblogaday hashtag, a twitter list for the participants, and even an aggregated RSS feed of all the blogs. There’s a wide variety of developers joining in – Scroll to the bottom of this page to see the roster.
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!