I first started hearing about the app on twitter a little before release, as some friends of mine were beta testing it. When it launched, I decided to check it out, long having wished for some way to write and run code on my iPad. I’ve spent several hours with it, and I’m quite impressed so far.

The first thing you need to know is that this will not let you create incredibly complex stuff. It’s 2D only, and it has a limited set of API calls available. However, what it is, is a fantastic prototyping tool, as long as you don’t mind typing on your iPad. They provide APIs that allow you to handle touches, and even accelerometer input. They also provide some basic vector graphic drawing tools (draw lines, rectangles, and ellipses). They even include Daniel Cook’s open source sprite collections, so that you can do some basic sprite work.

When I started playing around with it, two things annoyed me almost immediately:

1. There was no font support
2. There was no way to add my own sprites to the app

However, in reading through the (very active) forums, I discovered a bunch of people sharing code to solve problems. One person wrote a vector-based font rendering class and shared it. I’m now using that and it’s great. Others pointed out that by using tools like iExplorer to access the iPad’s file system, you can dump folders of sprites into the app and have them show up. However, I quickly discovered was that I find myself using vector graphics for eveything instead of sprites. This keeps me focused on working on gameplay prototyping instead of getting bogged down in Photoshop doing pixel pushing to procrastinate. TwoLivesLeft say they’re also working on getting a bunch of this stuff working in future updates, so I can only see it getting better.

However, there are still some things you should be aware of:

1. Right now there’s no way to get code to/from the app, except via copying/pasting, or using iExplorer
2. Support for Undo/Redo is pretty limited right now
3. You can’t (nor will you ever be able to) export a game right from Codea to the App Store
4. There’s no way to share code/projects with anyone else from within the app

But these are limitations I’m OK with. Having some way to retrieve files and drop new files in from my computer would be pretty great, though. I’m missing not having any kind of source control on my files.

Finally, I thought I’d share a screenshot of the game prototype I’ve been working on in Codea. This is for a word game concept I’ve been playing around with. What you see is about 4 hours of work. I have built a working button class, I can build words out of letter tiles, and the words detect touches.

Screenshot of my word game prototype running in Codea

The other cool thing is this is only 4 files of code, each no more than 100 lines of lua. The vector graphics make it very fast to get stuff quickly drawing, and with prototyping, that’s extremely important. And let’s not forget that I can now write code while I’m not at my computer!

So yes, colour me impressed. The app is still a little rough in places, but the developers seem to be actively working on improving it. Even still, at under $10 it’s an amazing prototyping tool to have on my iPad.

Owen

* I chose to write this review on my own. I did not receive a review copy from the developer, nor did they request that I write anything. I just think their app is cool.

The game is about keeping a room full of babies happy. Over time, babies become unhappy because they either want to be fed, changed, or rocked. It’s your job to drag an action up from the bottom of the screen to make the baby happy again. As time goes on, they get more unhappy more frequently.

I think it turned out quite well, so I’ve decided to try to get it into the store at some point. Right now I’m extremely busy with some contract work, but I’m trying to find a few hours here and there to finish it up and submit it.

One of things I decided to try with this game was to build it as a universal app (that is, one app that runs on iPhone/iPod touch, and iPad, instead of separate apps for iPhone and iPad). The game is 100% OpenGL on the rendering side, so I needed to figure out how to set up my frame buffers for a universal app. I thought I’d go through that today. (Holy moly, a technical post instead of an indie lifestyle post! Hold on to your hats!)

Project Setup

The first thing you need to do for a universal app is set up your Xcode project so that it knows to build the app as universal. I went to Jeff LaMarche’s excellent blog and followed his instructions to do this part (and read the follow-up post for a few more details).

Once you’ve done that, you should have a project that can at least compile for iPad or iPhone. Good.

Frame Buffer Setup

Now that you’ve got your app building for multiple devices, you’re going to need to do some work to support multiple screen resolutions. As of this writing, there are three different resolutions to worry about:

• iPad: 1024 x 768
• iPhone/iPod touch (non-retina display): 320 x 480
• iPhone/iPod touch (retina display): 640 x 960

However, Apple does some clever stuff to help you with the retina displays. If you query the size of the screen:

CGRect screenFrame = [[UIScreen mainScreen] applicationFrame];

You’ll get 320 x 480 on both retina and non-retina displays. This is because they measure the screen in “points” instead of pixels now. On a retina display, there are 2 pixels for every point. The nice thing is that it lets you treat all iPhone/iPod touch screens the same way, with the same positioning code.

Ok, so we’ve got these different screen sizes, we need to tell OpenGL to create different sized frame buffers. Somewhere in your code you’ve probably got something like this, which creates a render buffer from an EAGLDrawable CAEAGLLayer:

glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle);
[oglContext renderbufferStorage:GL_RENDERBUFFER_OES fromDrawable:drawable];
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &buffer.m_width);
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_HEIGHT_OES, &buffer.m_height);

If you build and run, what you’ll find is that your render buffer will be created with the proper size for iPad and non-retina displays, but you’ll end up with a 320 x 480 render buffer for retina displays (which need 640 x 960), and your retina display game will look awful. This is because the CAEAGLLayer is telling OpenGL that it’s dimensions are 320 x 480 on the retina display.

In order to remedy this, we need to make use of two new UIView properties found in iOS 4.0 and up called: scale and contentScaleFactor.

scale

The new scale property will tell you the amount the point values of the UIView are being scaled. If you’re running on a non-retina display and query a view’s scale, it will be 1.0. If you’re running on an retina display, you’ll find that it’s 2.0. This gives you a way to test which kind of display we’re working with, and we’ll use this later.

contentScaleFactor

The contentScaleFactor is a different beast. This will always be 1.0. However, if you’re running OpenGL in a view on a retina display, you need to set this value to match the scale value of the view. This will tell the CAEAGLLayer to update its dimensions to match the actual pixel size of the screen, allowing you to create an appropriately sized render buffer.

Now, if you’re planning to support iOS versions prior to 4.0, these properties won’t be available, so you need to do runtime checks for them.

This is what I do inside my EAGLView’s -layoutSubviews method to set the contentScaleFactor on the view:

// Set the scale factor to be the same as the main screen
if ([self respondsToSelector: NSSelectorFromString(@"contentScaleFactor")]) {
    [self setContentScaleFactor:[[UIScreen mainScreen] scale]];
}

Now, when I tell the render buffer to create itself based on the size of the layer, it will create a 640 x 960 render buffer on a retina display, but a 320 x 480 buffer on a non-retina display. Hooray! But, we’re not quite there yet…

Viewport Setup

We’ve got our render buffer set up to create itself at the proper resolution now. It will match the screen dimension and contentScaleFactor of the EAGLView, which is what we want. Now we need to tell OpenGL to create an appropriately sized viewport. This code is for a 2D game, so adjust as necessary for a 3D game.

You’ll need to create a viewport that matches the frame buffer size for the given screen. Something like this:

glViewport(0, 0, buffer.m_width, buffer.m_height);

For a 2D game, you then need to set up an orthogonal projection. There’s a good chance that you have a line in your code somewhere that looks like this:

glOrthof(0.0f, 480.f, 320.f, 0.0f, -1.0f, 1.0f);

Clearly this isn’t going to work. Now, there are two options here for creating the transform:

1) Create the transform based on the UIScreen size

The code for this is simple:

CGRect appFrame = [[UIScreen mainScreen] applicationFrame];
glOrthof(0.0f, appFrame.size.width, appFrame.size.height, 0.0f, -1.0f, 1.0f);

However, let’s look at what this does. On iPad, it creates a 1024 x 768 sized viewport. Great, that’s what we want. On a non-retina display, it creates a 320 x 480 viewport. Also good. But, on a retina display, it also creates a 320 x 480 display. Now, this is OK. The framebuffer is 640 x 960, so the pixels are there. So what does this mean?

The Good

You only need to write two code paths for positioning sprites on the screen: one for iPad, and one for iPhone, and let OpenGL handle matching the render buffer to the viewport appropriately for you. The only caveat here is that you’ll need to manually scale all your sprites’ sizes by 50%. If you do this, you’ll scale them down to the correct point size, and then OpenGL will render them at 100% resolution when it pushes the textures through the render pipeline.

Confused? Think about it this way: you’ve got a view port of 320 x 480 but a render buffer of 640 x 960. Take a sprite that’s 100 pixels x 100 pixels and render it as a 100 x 100 point sprite in the viewport. This is actually 200 x 200 pixels in the render buffer. So in order to render it as 100 x 100 pixels, you need to scale your vertices down by 50% to a 50 x 50 point sprite.

The Bad

You’ll need to write some code into your sprite system (and bitmap font system) to scale things to 50% if you’re on a retina display.

This is the approach I use. At app startup, I get the screen scaling factor, and then use it to scale all my sprites:

if ([[UIScreen mainScreen] respondsToSelector: NSSelectorFromString(@"scale")]) {
    ScreenScaleFactor = [[UIScreen mainScreen] scale];
    InverseScaleFactor = 1.f / ScreenScaleFactor;
}

2) Create the transform based on the layer size

The alternative is to create a different viewport size based on the actual pixel size of the screen. You can do this by getting the size of your created render buffer. Something like this:

glOrthof(0.0f, frameBuffer.m_width, frameBuffer.m_height, 0.0f, -1.0f, 1.0f);

This will give you a viewport that matches the screen size in pixels, not points.

The Good

The advantage here is that you don’t need to do any sprite scaling. You just render everything at 100%.

The Bad

You’ll need to have three different code paths for sprite positioning, based on the size of the screen, as you’ll now have three different sized viewports to worry about.

Art Work

You’ll probably want to have different sized artwork for non-retina displays than for iPad and retina displays. For Dirty Diapers I’ve got two game texture atlases: one for iPad and retina displays, and one for non-retina displays. The non-retina atlas is identical to the larger one, it’s just scaled down 50% in Photoshop. You could scale your graphics in OpenGL, but it will never look as good. If you’re like me, the imperfections will just drive you nuts.

So I have two texture atlases, but there are 3 possible screen sizes to worry about (see the next section). I do a check like this to determine which texture atlas to load:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad ||
    ScreenSizeConsts::ScreenScaleFactor > 1.01f)
{
    // Load texture atlas for iPad/Retina display
}
else
{
    // Load texture atlas for Original iPhone display
}

If you want to load 3 different textures (iPad, non-retina, retina), you can use the @2x.png file naming convention (depending on how you’re loading your textures) and just check for iPad or not, but now you’re dealing with 3 sets of textures. The choice is yours. If you’re loading textures manually and the @2x trick doesn’t work, you can split things out like this:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
{
    // Load texture atlas for iPad display
}
else if (ScreenSizeConsts::ScreenScaleFactor > 1.01f)
{
    // Load texture atlas for Retina display
}
else
{
    // Load texture atlas for Original iPhone display
}

Finally, Positioning

Now you’ve got your different artwork loading, you’ve got your render buffer set up, and your viewport set up. Now you just need to tell your objects to render in different positions, based on the screen. To do this, I set up a bunch of member variables for positioning code (for static items), and then on init, check the device and screen scale factors and adjust them accordingly. This is necessary for 2D art layout, but if you’re working with a viewport into a 3D world, you may not need to do nearly as much work here.

That’s it…

There you go. I hope you were able to follow along and I wasn’t too confusing. If you’ve got better ways of doing any of this, feel free to post suggestions in the comments.

Owen

So, you’ve got some programming under your belt. Maybe you’ve been building web site back ends, or accounting software, and you’d like to try your hand at games. Where do you start? If you’ve got an idea, how on earth do you approach the process of turning that idea into a prototype?

1. Consider Scope

I’m putting this right up front, because it’s the biggest and one of the most common traps a new developer can fall into: your idea is just too big. It’s very easy to bite off more than you can chew with a game idea. If you’ve never made a game before, don’t try to build a huge RPG in a massive world for your first game; you will almost certainly not finish it. What about something like tic-tac-toe instead? Or your favorite card game? Or a match-3 game (my first game, Dapple, was chosen because it had a very defined scope, and it still took nearly 6 months to make).

To put things into perspective: a triple-A Xbox 360 or PS3 game will have a team of 100-200 people working for 1-3 years on it. If you’re one person expecting to work on a game for six months, you need to make sure you’re working with an idea you can finish. You can’t build Halo by yourself. That’s ok. Pick a game idea you know you can finish; it will be challenging enough.

Also don’t forget that there are lots of parts to making a game that aren’t immediately obvious that you’ll need to build: menus, save systems, high score boards, platform specific requirements, etc, etc, etc. If you think your game is going to take you three months to make, bank on it taking six. So if you only have three months of savings to live off, maybe pick a game idea you think you can complete in a month and a half.

2. Learn About Games

This is a tough one, are you ready? You need to learn more about games. This means, yes, even playing other games for research. It’s a tough job, but someone’s got to do it. Take a look at other games in the genre that you’re targeting. Look at what they do well, and more importantly, what they don’t. What bugs you about the way they implemented things? What stands out as being done well? Are their menus clunky? Do the animations add that extra punch to really augment the gameplay? Does the music help draw you in? Take notes. Remember that you’re playing to learn, not just to have fun.

If you’re coming at this from a background other than game design, you may also need to do some reading. There are lots of great books written on the subject, and more being written every day, as the industry grows. See what expert game designers can teach you about designing games by reading their books.

One of my favourites, which is also a very quick read, is Raph Koster’s “A Theory of Fun for Game Design“. It’s great book to get you started thinking about designing games and what makes games fun. Another book I haven’t read yet, but have heard a lot of great things about, is Jesse Schell’s “The Art of Game Design: A Book of Lenses“. There are many other great ones, I’m sure. The important thing to remember is that making games is a constant learning experience, so get learning!

If you’re already a game developer reading this, what about you? What are you favourite books? What developer forums do you read? What blogs are the most useful?

3. Choose a Prototyping Technology

So you’ve got your idea and you’ve got some ideas about how to make it work as a game. Now you need to choose your technology for implementing a prototype. I gave a talk in April at the amazing 360iDev conference (their fall conference starts today in Austin) on rapid prototyping. One of the things I talked about is that when you’re prototyping, use whatever technology you are most comfortable with. This doesn’t have to be the same technology you’re going to implement the game with. If you’re targeting releasing an iOS game, but you’ve never touched Objective-C, but you’re a Flash wizard, prototype in Flash. If you’re an expert in javascript, prototype in javascript. If you’re not overly comfortable in any technology, prototype with pen and paper! Do whatever you need to do to get a working version of the game as quickly as possible. All the planning in the world won’t tell you whether or not the game is fun. Playing it will tell you that instantly.

If you’re doing iOS development, cocos2D is a fantastic platform with which to do 2D game prototyping. Flash is a great prototyping tool. If you’ve used Unity, I’m told it’s also great for prototyping. If you’ve got your own engine you’ve been building, use that, just be careful not to spend your prototyping time implementing engine features.

4. The 2-Minute Guide to Game Architecture

Ok, so what I’ve talked about is all well and good, but if you’ve never looked at game code before, you may be wondering how on earth a game works. This is obviously a HUGE topic, one that’s covered in immense detail in many books. However, I will attempt to give the extremely high level overview of how a game works. Ahem…wish me luck.

The Game Loop

At the heart of your game is a loop. This loop executes as long as the game is running. In fact, in many games, it’s a while (1) loop. In iOS development, you’ll be working with an event-driven timer instead. However it’s structured, the important thing is that you’ve got a chunk of code that’s going to execute over and over again. This chunk of code makes up one frame of execution. Most games aim for either 30 or 60 fps (frames per second). This means that your game loop needs to execute in less than 1/30 or 1/60 of a second.

At its most basic, your game loop is going to do two things every frame: update and then render.

The Update

This is where your per frame game logic resides. The update will do things like: pump the physics system (if there is one), update all the active animations, handle collision detection, etc. Basically, it updates the state of the game world in 1/30 or 1/60 second intervals. It says, 1/60 second has passed since the last time I was called, what needs to update? Oh, this character animation needs to be updated, these sprite positions needs to change, these two objects collided, etc. At the end of the update function, your game is in a new state and is ready for rendering.

The Render

Now that the world’s state has been updated, it’s time to render everything to the screen. This means going through all the renderable objects in the world and drawing them. If you’re using a graphics engine, then renderable objects (like sprites) may automatically get a draw() call made on them. If you’re using OpenGL or DirectX directly, then this is where you’ll be making calls into the graphics libraries to do the drawing yourself.

Building a rendering engine that runs quickly is an absolutely massive topic. You’ll need to pick up a book or two (and brush up on your 2D and 3D linear algebra, as well as low-level graphics hardware achitecture) if you’re going to roll your own.

Events

But let’s remember, games are interactive media. This means that at some point you need to handle user interaction with the game. This is often event-driven, in that it’s handled outside your main game loop. You’ll get calls into your code saying “this button was pressed” or “the user touched the screen here”. Some more traditional game loops would have input polling before the update was done. Many modern game frameworks (or platform APIs) rely much more heavily on event-driven code. Much more of your game logic will happen in your event handlers.

At any rate, these events are where you’re going to change game state based on what the user is doing. In a board game, the user might click a button to roll the dice, so your button click event handler is where you’ll trigger a dice roll. In a first-person shooter, you’ll be handling analog stick position updates to update the camera orientation and player’s position in the world.

You may also need to respond to system events, like an iPhone going to sleep, or the user alt-tabbing out of your full-screen game.

The Other Stuff

Those are the basics, but there is so much more that goes into a game: audio systems, user interface systems, front end menus, HUDs (heads up displays), physics systems, animation systems, game logic systems, font rendering systems, save game systems, leaderboard systems, achievement systems, and localization systems (to name but a few). But remember, not every game needs all of these things. That’s why it’s important to remember #1 and limit the scope of your first game.

The hardest thing about creating your first game is finishing it.

It will take dedication to work through the bugs and the tedious parts of building a game (yes, there are tedious parts), but in the end, it’s worth it. You’ll have a game that you made ready for the world to play and enjoy. So what are you waiting for? Start learning. Go make a game!

Owen

The Menu button in the bottom left will allow you to view it fullscreen, if you wish. It can be downloaded as a PDF if you click “view on SlideShare” and click the “Download” button at the top of the presentation.

When you get to the code part, you can download the sample project here:

http://www.streamingcolour.com/presentations/memLeakExampleProject.zip

Note: The code and sample project are distributed under the MIT License. See the README inside the zip file for details on what that specifically means, but basically you’re free to use the code however you want as long as you keep the copyright notice and don’t blame me for anything.

I hope those of you who attended the talk found it useful.

Update (2010-09-21 – 5:44PM) - If you’re not familiar with the Leaks Instrument tool, have a read through my tutorial on how to use it. I demonstrated how to use the tool during the session, but there were no slides for that part: Tutorial: Tracking iPhone Memory Leaks with Instruments

Owen

I’m going to be speaking at FITC Mobile in Toronto, running Sept 16-18, 2010. I’m giving a talk on memory leaks in iOS on Friday the 17th, from 12:00-1:00pm. Specifically, I’ll be talking about memory management, what a memory leak is, some common ways they’re introduced in iOS programming, and show you how to use the tools to track them down and fix them. If you’re an iOS programmer and you’re coming to FITC Mobile, I hope you’ll check out my talk. Bring your coding hat, though; I’m going to be showing code, and actually demonstrating stuff in Xcode.

I hope to see you there!

Owen

Introduction

If you haven’t played the game, LandFormer is a puzzle game for iPhone/iPod touch. Each level is made up of a 5×5 grid of terrain at different heights (oceans, up to mountains). The goal on each level is to use land forming tools to modify the heights of the terrain tiles to flatten things out. It’s a challenging game that starts off very easy, but get quite difficult in the harder levels. It’s a game that requires skill, patience, but most of all, intuition.

The game is free to download and try (there are 12 levels currently in the free version of the game), with In-App Purchase (IAP) available to upgrade to the “full” version of the game, as well as IAP for additional visual themes and additional levels. I think of it like a demo, where the user gets to try it and then decide if they want to spend money on more levels. The free version also contains ads, which are disabled if the player buys any content from the in-game shop.

The game launched on June 29, 2010 and has had 147,000 downloads of the free version of the game so far.

What Went Right?

1) Gameplay

I’m really happy with how the game itself turned out. LandFormer started as a prototype called “UpDown” that I did in 6 hours at the all-night GameJam for 360iDev Denver in September, 2009 (I participated via Skype). After I launched Monkeys in Space, I returned to the prototype in early 2010 and started playing around with ways to make it more fun, and settled on the terraforming theme, which helps players understand what they’re supposed to do, and why.

What I like most about the game is that I haven’t really seen other puzzle games like it. It’s similar in play-style to sliding block puzzle games (it requires a similar combination of spatial reasoning and intuition), but the up/down movement of the pieces makes it feel very new and requires new ways of thinking. It’s also very easy to learn how to play, but takes time to really master it and get good at the more difficult puzzles. In the end, I think the gameplay stands as being strong, and I’m very pleased with how the game turned out.

2) Strong Launch

This is my 3rd game, and thus my 3rd game launch. However, with LandFormer I decided it was time to try a new launch strategy. With my previous games, I launched the games as soon as Apple approved them. This caused all sorts of problems in terms of getting press materials out, and reviews trickling out gradually. With LandFormer, I decided to set a proper release date. When Apple approved the game, I set the release date for a week and a half into the future. I immediately sent out press releases to sites along with promo codes (yes, they work once the game has been approved, but before it’s available in the store) for press to try the game. Because my content is all IAP on my server, I could also make it available to the press for free during the pre-launch review period. Very handy.

The result of this new launch strategy was that several large review sites had reviews out within one or two days of launch. This helped pick up momentum for the game, then the first Thursday after launch Apple featured it as a Hot New Game. The Friday immediately after the feature, Gizmodo ran a review of the game, which boosted downloads tremendously for the following weekend.

I really couldn’t have asked for much better a launch. The only way it could have been better was by getting a front-page feature, or App of the Week feature from Apple. They’re probably just saving that for my next game (har har).

3) Free + IAP

As all developers do, I struggled a lot with the pricing model for the game. My other games are both paid games, but Dapple has a separate Lite version for players to “try before they buy”. The thing I don’t like about the Lite model is that it requires players to download two separate apps if they then want to buy the game. It always felt kludgy to me. Ultimately I decided to set things up like a PC or XBLA demo: free to download it, but if you like it, buy the full upgrade from within the game. This is the really exciting monetization path that IAP opened up when Apple introduced it.

Because I was implementing the in-game store for this anyway, it also allowed me to developing a theming system for the game and sell themes. It also means I can continue to release new level packs for users without having to update the game itself.

I think the model has a lot of potential on the app store. The free download gets you maximum visibility on the store (people are willing to download something just because it’s free), but then you have a way to earn some money within the app. However, it’s not all rainbows and unicorns: see the corresponding section in What Went Wrong.

4) Level Editor

When I started building the game, I was building levels as string of data then loading them into the game and testing them. This was ridiculous. I realized early on that building a level could be seen as solving a level in reverse. I was able to very quickly build a first pass at a level editor just by reversing the rules: start with a flat plane, and use the tools to deform it. This had two advantages: 1) it made building levels much easier, and 2) it meant that any level created in the level editor was guaranteed to have a solution.

Once I had it working for my own purposes I decided that it needed to be available to players in the game. The level editor is so easy and intuitive to use, I need people to be able to play with it. I’m happy I took the time to do the UI work required to build the level editor out into something that everyone could use.

The editor allows players to create their own levels, but beyond that, I implemented a sharing system based on URLs, where players could email a level to a friend. The friend clicks a link in the email and the level opens inside their copy of the game for them to play. It’s a simple system, that I think works quite nicely.

5) Doing Everything (Almost)

Since Monkeys in Space, I’ve been doing everything except the music in my games by myself. For both Monkeys and LandFormer I did all of the game design, programmer, artwork, UI design, sound design, PR, and marketing. I don’t do music, because that’s just something I’m not capable of doing myself. However, doing everything myself has given me a lot of freedom to make the game exactly how I want to make it. It also allows me to think about how a change will impact all the various aspects of the game. And, perhaps most importantly, it allows me to save a huge amount of out-of-pocket expense. I would love to have the funds to pay a full-time artist to work on the game, but that’s just not in the cards for me yet. I do have some art background, but doing all my own art for these games has helped me get a lot better than I was. I hope I’ll continue to improve. However, this is also another one of those things that also appears on the What Went Wrong section. So let’s get to that now.

What Went Wrong?

1) Free + IAP

I listed the reasons why I thought Free + IAP was great for LandFormer, but it’s also something that didn’t work great. One thing I was not at all prepared for was a backlash from users over the pricing model. I thought that players would be happy that they were given an opportunity to try the game before spending any money on it. However, the reaction from a lot of players instead was “The game says it’s free, but you have to buy stuff!” I got called a cheat, a liar, and a con artist.

My immediate reaction was that my app description clearly states that you only get the Beginner levels for free and have to buy the others. The app page in the store also lists the top IAP. But what I learned is that no one reads that stuff. I think I got a lot of downloads (especially after some of the big press stories ran) from people who saw the name, the icon, and “free” and downloaded it.

The problem is that there’s a disconnect between my view of the pricing model, and that of the minority of angry, vocal, app store consumers. I saw: “LandFormer offers you a way to try the game for free, and if you like it, buy it.” That customer sees: “Hey, a free game!” And then is angry when they discover they can’t play all the levels for free.

In the end, I’m not sure if the pricing model I chose for LandFormer was the right call or not. I’m not convinced that I wouldn’t have made more money by distributing a Lite version and a separate paid version (or only a paid version). App Store customers have gotten used to that model. I think it’s a problem with the fact that IAP didn’t exist from the start. Users had a year to get used to a certain business model, now we’re trying to change that. It’s going to be a difficult transition.

Not to go on about this for too long, but I think the Free + IAP model works best for games where you’re giving away a complete game for free, and then selling IAP for additional content that’s not required. If I ever do another free game, I’ll be looking toward that model.

2) iOS 4 + Multitasking

Apple launched iOS 4 on June 21, 2010, 8 days before I launched LandFormer, but 2 days after Apple had approved it. I had time with the beta SDK to make sure the game didn’t crash and that the game could be put into the background and restored properly before shipping it. However, I spent a great deal of time over the next 3 updates fixing weird little issues that cropped up because of iOS 4 multitasking. Multitasking caused all kinds of problems with my level sharing system, as well as my save system. I believe there was also one crash that only showed up in iOS 4 because of a change in the way some touch events fired. I’m not blaming Apple, it was just bad luck on my part that I launched so close to iOS 4, and I couldn’t afford to delay the launch of the game any more to deal with all the little issues that cropped up.

3) Ad Network

I mentioned in the introduction that I decided to include ads in the free version of the game. This is in this section for several reasons. At the peak of LandFormer’s popularity, it was being downloaded about 12,000 times per day. This translated into about 50,000 ad impressions a day. However, my click-through rate (CTR) was abysmal. It turned out that the way I was loading ads meant that a lot of people never saw the ads I requested. On my best day, I made about $5 off of ads. In the first update to the game (v1.1) I released a fix that made sure that ads were displayed properly to users. However, by the time it was approved I was down to a few hundred downloads a day of the free game. Even though my CTR increased dramatically with the change, my earnings averaged out around $0.30-0.40/day.

On top of that, the ad network I used had a crash bug in its code. After a couple of weeks trying to help them track the problem down, they told me they weren’t going to look into it any further. I was getting several support requests a week from players about this crash, so ultimately I pulled their ad network out of my game and I wrote my own custom system.

The game now (in v1.1.2) pulls ads of my own server. This is cool for several reasons. Now I get to decide what ads get shown in the game, it means I can cross promote my other games, and it means that I can promote games that I actually buy and play. I use LinkShare to get a small royalty any time someone actually buys through this system, but that’s been next to nothing so far. Still, I’d rather help support developers whose work I respect and have no crashes, than get the $0.30/day but with 10% of users experiencing a crash every time they launch the game.

4) Themes

When I built the IAP system I was very excited to be able to sell themes (skins) for the game. The way I had set up the graphics engine meant that it would be easy for me to load different textures to change the look of the game. I thought players would like the chance to be able to customize their experience a bit more too, but I was wrong. I’m seeing about a 0.1% conversion rate on themes (i.e. about 1 in 1000 people download a theme).

At this point, I only have one theme for sale. So it could be that people just don’t like that theme. It could also be that people just like the default art more. Or it could just be that people really don’t care about theming this kind of game. Though, if you think about it another way, if 1 in 100 people buy the premium content, the users who would buy a theme are probably a subset of that 1 in 100. So that means about 1 in 10 of those people have bought the theme, so maybe that’s ok. Still, when you do the math, that’s about $100 made off the theme so far, and it took almost a week of art work to build it (not even counting the time it took to put the theming system in place). When you look at it like that, it’s not as worth it.

I’m currently working on another theme. If it doesn’t sell, I probably won’t be releasing more themes. I think themes would sell better in a game where you could play the whole game for free. I think people might be willing to buy a theme in that case.

5) Doing Everything (Almost)

I’ve already outlined why I thought this worked for the project, but doing everything by oneself also comes with some big downsides. The biggest is time. LandFormer took 5 months from start to launch (then another month of work after launch). I’d guess that at least 2 months of that was doing the artwork and UI design for the game. If I could have afforded to pay a professional artist to do that for me, they probably would have taken half the time, and they could have been doing it while I programmed.

The other big downside is not having someone to bounce ideas off of. Working with an artist allows you to brainstorm, to try new things, and play with the concepts in the artistic direction of the game. When you’re doing it all yourself, it’s easy to get caught in the trap of just doing the first thing that comes to mind. It’s hard to force yourself to try multiple things and to find the best artistic solution to a problem.

Conclusion

In the end, I’m extremely pleased with the way that LandFormer turned out. I think it’s my strongest game to date. The game was also an opportunity for me to experiment with several new things I’d never tried before: IAP, free games, ad-supported games, and user-created content and sharing. I’m very happy with the number of free downloads the game has had. I find it absolutely amazing to think that almost 150,000 people have downloaded my game! At the same time, I’d be lying if I said I was happy with the conversion rate I’ve seen from free to paid.

The game continues to get a couple hundred downloads a day, and it seems to have stabilized there. I hope that it will maintain this level (or higher) for quite some time. The fact that it’s free seems to help keep the downloads alive.

Every game is an incredible learning experience, and I’ve learned a lot in making and launching LandFormer. I’ll be continuing to support it and add new content, but I’m also looking ahead to what’s next. Onward!

Owen

I’ve just added the tutorial over on the Tutorials page: Using the Expressions Window

The Expressions window is a powerful debugging tool available in Xcode that allows you to evaluate expressions or even call methods on your objects while stopped at a breakpoint in your code. Check out the tutorial for an introduction to some of the cool things you can do with it.

You’ll also noticed that I added a new page in the sidebar for Essays. I’ll group blog posts related to art and video games under that page. Right now there’s just one from January of this year, but I’ve been working on a new one that I hope to have up soon.

Owen

Have you ever thought “I wish there was a way to click a link in an email and launch my app…” Well there is, through the magic of custom app URLs. The basic idea is this: register a custom URL protocol with the iPhone, and if someone clicks a link with that protocol on that device, it will launch your app. But wait, there’s more: because it’s a URL, you can pass parameters into the app on launch. If you’re a C programmer, this is like being able to pass command line parameters into the application as an argv list.

I first started looking into this in detail while working on LandFormer. In LandFormer, I wanted a nice and simple way for users to share levels they had created without having to use a 3rd party social gaming system or Facebook. I started looking into custom URLs and discovered it could do everything I wanted. Using these URLs, I can encode a level’s data as a URL, embed it in an email, and let the user send an email to their friend. When the friend opens the email on their iPhone and clicks the link, LandFormer is launched, it parses the URL, and loads the level. It’s simple, elegant, and it’s easy to set up once you know where to look. So let’s do that now.

Define a Protocol

The first thing you need to do is decide on a custom URL protocol for your app. Choose something that other apps aren’t going to use. Don’t pick http, because that’s already taken. Pick something related to your app name, or website URL (e.g. “myAwesomeApp://”).

Once you’ve picked your custom protocol, you need to tell your app to register it with the phone. You do this through the app’s Info.plist file. Open the plist file in Xcode. Add a new row of type “URL types”. When created it will contain one item by default, “Item 0″. Expand Item 0 and you’ll see one element inside called “URL identifier”. This is an identifier that must be unique. Use the reverse domain naming system that Apple recommends (e.g. “com.mycompany.myawesomeapp”). Now add a new item to the array under the URL identifier row. Set the new item to “URL Schemes”. This creates an array with one item in it, “Item 0″. Set Item 0′s value to be your custom URL protocol (e.g. “myAwesomeApp”). Save the plist.

Great! Now you’ve told the iPhone that when a URL starts with “myAwesomeApp://” that it should launch your app. If that’s all you want to do, you’re done! Go have a soda. However, this method allows us a lot more power over how we launch the app, so let’s see what we can do with it.

Handling a Launch URL

When your app is launched with a custom URL, you have access to that string when the app launches. This means that you can take different launch actions based on what’s in that string. Let’s take a look at how to do that.

Right now in your app you probably have a function in your app delegate that looks like this:

- (void)applicationDidFinishLaunching:(UIApplication *) application
{
    // Do some launch stuff
}

That’s the application where you’d set up your connections between your window and your root viewcontroller, etc. However, in order to handle that custom URL, we need to handle things a bit differently. There are two options.

1) Leave your code in applicationDidFinishLaunching: and handle the URL in a later call to application:handleOpenURL:

2) Replace your applicationDidFinishLaunching: method with application:didFinishLaunchingWithOptions:

[EDIT (2010-07-30): As Jerrod pointed out in the comments below, if you want your app to handle URLs when your app is in the background in iOS 4, you must use handleOpenURL. When an app regains focus because the user clicked a custom URL, you will not get a call to application:didFinishLaunchingWithOptions, but you will get a call to application:handleOpenURL.]

I’m going to talk about the 2nd method, since I’m assuming we’re in a situation where we want to set up a different initialization sequence based on the URL passed in. So lets replace our applicationDidFinishLaunching: method with this:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Do our launch stuff here now
}

Notice that we now get an extra parameter passed to us in the form of an NSDictionary of launch options. One of these options is our launch URL, so let’s fish that out:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Get our launch URL
    if (launchOptions != nil)
    {
        // Launch dictionary has data
        NSURL* launchURL = [launchOptions objectForKey: UIApplicationLaunchOptionsURLKey];
 
        // Get the part of the URL after the ://
        NSString* queryString = [launchURL query];
 
        // Escape the string
        NSString* escapedQuery = [queryString stringByReplacingPercentEscapesUsingEncoding: NSUTF8StringEncoding];
 
        // Parse the URL string
        ...
    }
 
    // Do our launch stuff here now
}

So all I’ve done there is grab the URL out of the dictionary. The call to [launchURL query] grabs the part of the URL after the ://. So if the URL was:

myAwesomeApp://?myString=test&myInt=0

then calling -query on the URL returns:

myString=test&myInt=0

The call to -stringByReplacingPercentEscapesUsingEncoding will convert all the URL-safe characters (like %20 for a ‘space’ character) back into the proper ascii char (or in this case, UTF8 char).

Parsing the data can then be done with your favourite parsing method (in LandFormer I used NSScanner to parse each element). You could also parse the data and store the vars into an NSMutableDictionary so that you could then do key-based lookups on the data.

After that, it’s up to you how you want to use that data. You can make decisions about how you want the game to load.

The LandFormer Example

To put this into perspective, the LandFormer URL looks like this for a created level that someone is mailing to a friend:

landformer://?title=Over%20The%20Hills%20And%20Mountain&moves=13
    &level=3343333333141222311002000
    &check=13F24CFE848198A8BDB8196494904B16

So you can see that the URL is made up of 4 variables: title, moves, level, and check. The check is a checksum done on the data to make sure that the URL hasn’t been messed around with (so as to stop players from sending their friends impossible levels). The rest of the data is self-explanatory.

When the game loads, if a URL is found, it parses the data to get all the information it needs to load that level, then lets the user start playing the level. So if the user has loaded the game directly from clicking on a link, they aren’t taken to the Main Menu, they’re taken straight into the game so they can play their friend’s level.

Cool Side-Effects

One of the really cool side-effects of this method for sharing levels is that these links work from inside a web browser, email, or even a twitter client. So if someone creates a level, sure, they can send it to a friend via email inside the game. But, they can also collect level URLs they’ve created and create their own level packs by posting the links to their website. Then anyone can click those links to play their levels. They can also share the links on twitter, and anyone browsing using an iPhone twitter client (who also has the game), can just click the link to download the level. The possibilities are endless!

Another cool potential use for this would be to allow you to pass data between two of your own apps. Say you make a new game. You could register a custom URL protocol for it, then add a special link inside your old game that allows users who have that game to click it to unlock something in the new game.

A Word on Error Handling

So far everything I’ve mentioned is all of the “look how awesome this is” variety. However, it’s important to mention code security. Any time you allow the user access to data that affects your game, you need to be careful. When parsing the URL coming into your app, make sure you’re handling failure cases well. You don’t want your app to crash if someone starts messing around with the URL manually. You don’t want to give them access to your app’s memory. Be careful with how you parse that data, make your error checking and handling robust, and you should be fine.

Now go have fun!

Owen

I returned home from the Game Developers Conference (GDC) nearly a week ago, but I feel like it has taken me this long to be able to recover from the late nights, the jetlag, the cold I caught, and put things into perspective. I thought I’d share a summary of my experience there, for those who are thinking of maybe going next year.

Executive Summary: SO AWESOME!!!

GDC is held every year in San Francisco. I’ve been in the games industry for over 6 years now, but this was my first time at the conference, so I wasn’t really sure what to expect. I managed to get an All Access Pass to the conference, so I was there for the summits and tutorials, as well as the main conference.

Let me back up a little and talk about my reasoning for going, as that will help you understand why the conference was so valuable to me. At the beginning of the year I started thinking about what conferences I wanted to attend. 360iDev was a must-attend for me, so I booked that first. However, I was torn between attending WWDC (Apple’s big annual conference) or GDC. I attended WWDC last year and it was great. But this year I felt like what I really needed was general game design inspiration, and less Apple-specific technical inspiration. With that in mind, I chose GDC. My goal for the conference was to focus mainly on game design sessions and take in a few technical and business sessions.

So, I arrived in San Francisco Monday, March 8th, the day before the Summits started. I managed to meet up with a bunch of iPhone devs I know from Toronto, other conferences, or Twitter. We had a few beers and tried to adjust to west coast time. It was a good way to ease myself into the week.

Tuesday and Wednesday were the Summit & Tutorial days at GDC. There were two summits I was interested in: the iPhone Summit, and the Independent Games Summit (IGS). I think I spent about 60% of my time at the IGS and about 40% at the iPhone Summit. I saw some great technical iPhone talks by Noel Llopis from SnappyTouch and Phil Hassey from Galcon. I also saw some great IGS talks that ranged in topic from managing an independent game studio’s creative process, to how to better design indie games. I saw a session by Ron Carmel from 2D Boy, several awesome sessions by the people at thatgamecompany (Flower is one of my favourite games), and a terrific session by Randy Smith from Tiger Style (among so many others!). By the end of the Summits, my head was already spinning with inspiration. The IGS design talks in particular were extremely motivating for me. Getting a chance to meet and hear amazing indie game designers/developers talk about their processes was fantastic. It started me thinking about a lot of things as they relate to my own processes. More on that later…

A tiny segment of the massive GDC Expo

The IGF Awards

Thursday through Saturday were the main conference, expo, and Independent Games Festival Awards. I sat in session after amazing session listening to industry leaders in game design, technical development, and business talk about their processes. I saw Peter Molyneux talk, Sid Meier talk, and even Will Wright talk. I saw a moving and inspirational talk by Brenda Brathwaite on her exploration into board games with serious themes. I saw a head-ache inducing (in a good way!) talk on PixelJunk Shooter’s real-time fluid dynamics system that made me really miss doing PS3 SPU programming. I saw an in-depth and honest look a the successes and problems encountered by Naughty Dog’s attempts to create an active cinematic experience for Uncharted 2. I was blown away by the quality of the content, and I was left reeling by how the talks started forcing me to think about the direction I want to take with my own games.

There were huge crowds in the halls between sessions!

But of course, the sessions are only part of GDC. The other part comes from meetings and parties. I was able to set up a few meetings with iPhone press to show them my new game. That was really great to be able to demo the game in person. I think it was extremely valuable. Then each night there were countless parties happening. Each party was a great chance to meet people in person who I’ve only communicated with on twitter or via email. It was a chance to discuss iPhone development with other people going through the same thing as me. It was a chance to discuss game design in general with other game designers and developers. It was a chance to have fun with people who share in the same daily challenges that I do.

Will Wright giving his presentation!

For me, I got out of GDC exactly what I wanted: design inspiration, new friends, new business connections and a wealth of knowledge. But perhaps most importantly, GDC helped me to put me back on track with where I want to take my games. When I decided to go indie in 2008, it was because I wanted to make the games that I was compelled to make. What I’ve noticed is that I’ve been making more and more design decisions lately based on what I think will sell well. This isn’t how I want to make games. I want to make the games that I have to make, not that I think I should make because I think it might make some money, even though the idea doesn’t excite me. Granted, I would love to be able to make the games that I feel compelled to make and have them also become a financial success. And obviously I can’t ignore the fact that I’m running a business. But GDC helped to remind me of what I want my priorities to be, and that, to me, is the most important part of having gone.

Owen

However, over the last few days I’ve been returning to my own projects and getting back into the swing of things. As you might recall, I took part (remotely) in September’s 360iDev Game Jam night and created a prototype for a puzzle game idea I had. I’m happy to report that I’ve been developing that idea further and it’s coming along nicely. The game now looks very different from the screenshot I posted on Touch Arcade, by the way. As for a preliminary look at what the game is becoming, I might have something to show early next week, so keep an eye out for that!

Yesterday I decided to rewrite the rendering part of my engine to take advantage of a bunch of optimizations I had been putting off making. It turns out that the changes I made over the last day reduced my render time by about 40%! That means that I can render nearly double the sprites on the screen without dropping my framerate. This is great news, and I’m looking at porting the changes back into Monkeys in Space at some point to help out with that game’s performance.

In other news, I thought I’d mention that I’ve decided to attend two conferences this spring: the Game Developers Conference (GDC) in March and 360iDev in April. I’m looking forward to both conferences, but I’m especially excited about GDC as I’ve been in the games industry for over 6 years now, but I’ve never gone to GDC! I’m really excited to get a chance to finally go and see what all the fuss is about. I’m also looking forward to attending sessions on game design that are more broad than just iPhone games.

That being said, I’m also happy to be attending 360iDev again. It will be great to see the iPhone developers I speak with every day on twitter in person again. Last year I had a fantastic time at the conference and I expect no less this time. I’ll also be speaking at 360iDev. For my presentation I will attempt to create an iPhone game prototype in 80 minutes based on audience suggestions. While doing that, I’ll be highlighting some of my best practices for rapid prototyping. If you’re attending the conference, I hope you’ll check it out. If you’re not attending the conference, why not? Check out this amazing schedule of speakers. And if you’re thinking about it, go register!

Owen