Archive for the ‘Design’ Category

Why I Attend GDC

Hello, my long neglected readers! I have been a terrible blogger as of late. I have been extremely busy with my current contract work, so I haven’t had a lot that I can talk about here on the ‘ol blog. The game I’m working on is nearing completion, at which point I’ll be returning to my own projects and I should have more to talk about.

The good news is that my turn rolled around for #iDevBlogADay and it has pushed me into writing this post. Hooray! This is precisely the purpose of iDBaD, but I digress…

I’m long overdue for a post-GDC blog entry. Last year was my first time attending the Game Developers Conference and I wrote up a post about how much I enjoyed it. This year was even more exiting for me, and I had intended to come home and write up a post about how great it was, and then life and work got in the way. However, it is time. Let’s talk GDC!

I will say this right now: GDC is expensive. It’s not a cheap conference. Most people attending are there because their large company is paying for them to be there, so cost isn’t really an issue. For us indies, plunking down $1400 for a full-access pass is like taking a swift blow to the stomach. Add the cost of a flight from Toronto, and 5 nights of staying in a hotel, and you’ve got quite a bill. So the question everyone wants to know is: is it worth it? I’ve heard some devs say “why should I go to GDC when I can get a new computer instead for the same price?” Is it worth it? My answer: an emphatic YES.

GDC has three parts to the show: the 2-day summits and tutorials, the 3-day main conference, and the 3-day expo that runs at the same time as the main conference. You can buy a pass for the summits, the main conference, or both. I like to do both. The reason is this: the summits have a big indie emphasis, so you get to meet a lot of amazing people and get inspired by the top indies in the world; the main conference has some amazingly inspirational talks from some of the top minds in the industry. I wouldn’t miss either. Together they form a near-perfect conference for me.

This year for the 2-day summits & tutorials I decided to gamble on taking part in the 2-day game design workshop. I was nervous about doing this because it meant I couldn’t attend any of the indie sessions. However, I think I made the right choice for me. The workshop was an intense 2-day crash course in game design, and it was absolutely invaluable. I learned an incredible amount about game design process, which is one of the areas of game development where I feel I have the most to learn. This workshop gave me a language to use to talk about game design; it let me interact with other designs and solve design problems together; and I came away with some invaluable tools for solving game design problems. If you’re attending GDC and considering the game design workshop, I can’t recommend it highly enough. After those first two days, I felt I had already gotten my money’s worth for the conference, but there were still 3 days of awesomeness remaining!

Last year at GDC, I didn’t really know what to expect from the main conference, so I went to a lot of different sessions in a lot of different fields: programming, art, game design, business, etc. This year I focused on design sessions and this really worked for me. I saw some mind-blowing talks on game design and design process from some of the game designers I most look up to. (Check out the GDC Vault and you can watch some of the classic game post-mortems for free.) By the end of the conference my mind was bursting with ideas, and my heart was filled with hope for games as a medium and inspiration for my own games.

That feeling right there, that’s why I go to GDC. Nowhere else have I ever felt so excited to be a game designer and developer. Nowhere else have I become so inspired to create new and innovative games. Nowhere else have I met so many amazing game developers who are all striving to make the best games the world has ever experienced. Nowhere else have I had so many amazing conversations with other developers and designers about games and their importance.

By the end of February, I was feeling pretty burnt out about making games. I hadn’t worked on my own projects in quite some time. I was starting to wonder why I do what I do. By the time I left GDC, I was alight with creativity, a renewal of excitement about having the best job in the world, and a hunger to create something new and important. GDC was a reminder that there are amazing people making incredible games all around the world; a reminder that there are people trying to make games that matter to themselves and to others; a reminder that making games is extremely difficult, but also profoundly rewarding. This is why I will choose GDC over a new computer, any day.


Indie Challenges

Several weeks ago I wrote up a post called “I’m Indie, and I’m Proud” about the things I love about being an indie game developer. The post was full of all the positive things I love about indie life. A few people pointed out that I wasn’t representing the whole picture, so I thought I’d write up a companion post about some of the biggest challenges I have encountered being indie. This is not meant to dissuade anyone from becoming indie, but merely to show both sides of the issue. Going indie is still one of the best decisions I’ve made.

Note: This article refers to being “indie” in the sense of running your own business. If you’re working a salaried position at a small indie studio, much of this won’t apply.

1. Lack of Stable Income

Let’s get this out of the way right off the bat, because it’s the biggie. As an indie developer, you will most likely not have a steady income. Your income will fluctuate greatly from day to day. Until you launch that first game, your income will be $0. Even after you launch that first game, your income may very well still be close to $0. You need to be ready for that.

Game Developer Magazine does an annual survey of game developer salaries around the world (but mostly centred in the US). This past year they did the first indie salary survey [1]. The survey found that the average annual income for a solo indie developer (i.e. a dev working by his or herself) is about $11,000 USD. The average increases to about $20,000 if the developer works as part of a team of two or more people. This is why so many indie developers do contract work on the side. Making your own game is a risk, but being paid to develop someone else’s game is less risky.

But there’s an upside: if you’re one of the few lucky ones to release a really killer game that takes off and becomes a hit, the potential to make a lot of money is there. Just don’t rely on it as your plan for sustaining the business.

What does this mean? It’s going to be an adjustment. If you’re used to working a job with a regular salary, working for yourself will take some time to get used to. You’ll start thinking about your time differently, and also start thinking about money differently. Instead of thinking “This DVD is only $20, I’ll take it!” You’ll start thinking “Wow, $20…that’s like selling 29 copies of my game at $0.99…that’s like…three days of sales.”

2. Work/Life Balance

In my other post I talked about the freedom we have as indie developers to work the hours we want to work. However, the flip side of that is that the line between home life and work life can easily become blurred. If you’re working for a larger indie studio you may have office space and this isn’t as much of a problem. But if you’re working from home, it’s easy to “just work one more hour” after dinner, or “just write a few more emails before bed”. Next thing you know it’s 2:00 AM and you’re introducing three bugs every 15 minutes into your rendering system. When your work computer is in your home, it can be difficult to force yourself to stop working, or sometimes to start working.

I’m a guy who likes his routine (boy is that changing now that I have a one-month-old baby). My routine helps me to work during “working hours” and not work when I want to spend time with my family. Even though I work from home, (before the baby) I got up every day at 7:30, showered, ate breakfast, got dressed, and “went to work”. It helps me to delineate the difference between being at home, and being at work. A friend of mine told me about his friend who used to walk around the block and return home to force himself to think about being “at work” differently. Where I still struggle the most is at the end of the day. 5:30 or 6:00 rolls around and I need to start cooking dinner, but it’s easy to “just write a couple more lines of code” and get lost in it.

However, it can be done. You can find a really nice balance between work and life outside of work. It’s just going to take more discipline than if you worked for someone else.

3. Oh So Much Paperwork

All you want to do is make great games, but if you’re reading this, you’re probably pretty serious about it. You’re running a business. Running a business comes with a lot of work that isn’t much fun: filling out international tax treaty forms, doing your monthly bookkeeping (did I say monthly? er…yearly?), filing your taxes, dealing with copyright or trademark infringement, figuring out how to make money, etc, etc. But it all needs to be done. Your brain will want to say to you “hey man, you could be logging your business receipts in your accounting software right now…but wouldn’t you much rather be implementing that new animation system you’ve been dying to try??” Sometimes you need to tell that little voice to shut up and take care of the business.

4. Feeling Like a Failure

Ok, this is starting to get kind of personal…and I really hope I’m not the only one who feels this sometimes. 😉 As much as you’ll have days where you absolutely LOVE being indie and making your own games, you will probably have days where it just sucks. You’ll get your daily sales report (if you’re selling on the App Store) and have a day where you made $1.43 the previous day and you’ll start to wonder what you’re doing with your life. You’ll hit a roadblock with your game and wonder if you’ll ever be able to solve it. You’ll get to an alpha build with your game and realize all the fun work is done and now you just have to hunker down and finish the boring parts of making a game. You’ll have a day where all your ideas feel like they’re the worst idea you’ve ever had.

I’m here to tell you: that’s ok. But this is why it’s so important that you LOVE making games. Because not all parts of the process are fun. Some parts suck. Some parts will make you want to quit. But if you really love it, if you can’t think of anything else you’d rather be doing with your life, then you’ll push through the bad days and you’ll get back to loving it again.

But…It’s Worth It

So yes, there are parts of being an indie developer that aren’t all sunshine, lollipops, and rainbows (you really should click that link). But you know what? I still love it! Because for all the annoyances and hard days, they all pale in comparison to the fact that I get to make the games I want to make every day!


[1] Brandon Sheffield and Jeffrey Fleming. “9th Annual Game Developer Salary Survey“. Game Developer Magazine. April 2010: 12.

Game Dev: Getting Started

A friend of mine sent me a message on Twitter the other day asking if I had any tips for someone looking to get started in game development. I mentioned this was quite a large question, so I asked him to narrow the scope of his question. He came back with “between idea and prototype.” That seemed like a good subject for a blog post!

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.


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!


Creative Block

After failing to meet my deadline for #iDevBlogADay on my second week, I was put to the end of the waiting list. Just over three months later and my turn is back up! I’ve taken the Sunday slot, which has a history of not lasting very long, so we’ll see how many weeks I can keep this up…

For my (triumphant?) return I’ve decided to not write a technical post. I was going through a list of technical things I could write about, but I just wasn’t feeling it. I decided I’d rather write about game design today, and perhaps more generally, about the creative process in general. Specifically, I’d like to talk about the problem of creative block.

What I’m talking about is getting stuck on a creative problem; being paralyzed by creative decisions. It happens to everyone. And if it hasn’t happened to you, then, well, I envy you. The block can happen in a number of ways: you have too many ideas and can’t decide which one to look at first; you have lots of ideas, but now they all seem terrible; you have no ideas at all; you have a few ideas, but they all seem equally interesting; and on and on.

For me, I run into these problems most commonly at the start of a new game. I’ve just wrapped up a previous game where I’ve spent the last month or two dealing with the tiniest minutia of polish and wrap-up and marketing. It’s been a while since I’ve had to do “big picture” thinking and come up with a new concept. It’s usually at this point that I’m also in my post-release “blues” period, coming back down to reality from a post-release high (perhaps I’ll devote next week’s post to this alone). I start going through my various notebooks and sketches looking at all the ideas I’ve written down and looking for those few that scream out for more exploration. It’s at this point where I’m most likely to become stuck.

“What if all the ideas I have written down are terrible?” “What if none of these are doable?” “What I spent several months building this game and no one buys it?” “What if…” “What if…” It’s easy to get sucked into a place where you can’t make a decision and spend all day reading twitter and other iDevBlogADay posts in an effort to avoid actually doing something. [wink]

Of course, this sort of paralysis can come at other points in the project too: you’ve got a working prototype but you’re uncertain how to take the next step into starting to turn it into a game; you can’t decide whether your game data structure would be better represented as a graph or as a b-tree; you can’t decide whether the game should feature zombies or pirates or both; you can’t decide whether your pause button should be green or red; and on and on. So off to twitter and your favourite RSS reader you go to avoid the problem.

Now I should probably state that I don’t have a solution. Oops, maybe I should have said that before you started reading this far. But honestly, if I did, I’d be on the motivational speaking circuit instead of making indie games. However, I have a few tricks that I try, and usually one or two of them will help me push through a rough spot and let me get on with it:

1) Make a Decision and Go

This is probably the hardest of the things I’m about to say, but this is probably one of the most useful. Flip a coin, write the options down on paper and draw one out of a hat, or just pick whatever seems most reasonable, then start working on it. Often after a few hours of working on anything it’ll get you out of your own head and the ideas will start flowing again in some kind of helpful way. The process of building something instead of thinking about it may also expose problems you hadn’t thought about, or even better, solutions you hadn’t thought about.

Got too many game ideas you like? Pick one, build an eight hour prototype, and see how it feels. If you don’t like it, try another one. Repeat as necessary. Don’t know if your pause button should be red or green? Try both and see how they feel in the game. Can’t decide on a data structure? Pick one and start coding. Five minutes in you may realize that the one you’ve chosen won’t support the API you need and you can start over. But at least you’ve moved on.

2) Use Tools

In 1975 Brian Eno and Peter Schmidt came up with a deck of cards to help get through creative block called The Oblique Strategies. The idea is that each card has a bit of text on it to help you think about a problem in a new way. When you’re stuck on something, you draw a card at random from the deck and it might say something like “Only one element of each kind.” The idea is to force your brain to think about the problem in a new way.

There are Oblique Strategies iOS apps available in the app store if you search for them. I’m not sure which ones have the actual rights to use the text and which are in violation of copyright, so I’m not linking to any of them.

3) Think About Something New

If I’m stuck on a game idea and I’m just not sure if I can make it work, sometimes it helps me to think about a different game for a few minutes. It’s a similar strategy to using the Oblique Strategies. Except in this case, I have a little script I go to that generates a random game idea. I’m making this script available on the site now. You can find it in the right-hand sidebar under the Pages header, called “Game Idea Generator“. Go play with it for a couple of minutes and come back…I’ll wait here.

Back? Good. Moving on.

4) Talk it Out

Still stuck? Talk it out with a friend. Even someone who knows nothing about what you’re trying to do. In fact, sometimes that helps. They might be able to offer suggestions you wouldn’t think about. Even just saying the problem aloud to yourself can sometimes help (though can also lead people to believe you may not be right in the head). Talk to a friend, your husband or wife, your cat or dog, or post a question on twitter or your blog and see what people say.

5) Take a Break; Do Something Inspiring

If all of the above don’t work, maybe it’s time to take a break. I like to try to find something to do that will inspire me in new ways: play a video game, watch a film, read a book, do some sketching, go to a life drawing class, listen to music, go to an art gallery, go for a walk in a forest, go for a bike ride, talk to someone you love, grab a coffee with a friend. The important thing is not to dwell on the fact that you’re stuck. Get your mind onto something else. Have fun. Be inspired in new ways and the block will become unstuck. Just remember: you do need to come back to the problem at some point. Don’t let taking a break become taking ten breaks.


Making games is hard work. We all know that. But we also know it’s the best job in the world. We make games because we love what we do. But we often don’t talk to each other about the hard parts, about the frustrations of getting creatively blocked, the financial challenges, and the emotional ups and downs. Maybe it’s time we started doing that a little bit more so we can help each other out.


LandFormer Postmortem

A couple of months after I launch a game, I like to sit down and take a hard and honest look at the things that went right and the things that went wrong: a postmortem. It’s a great exercise to go through after a game is launched to learn from your successes and, more importantly, your mistakes. I wrote up a postmortem after launching Monkeys in Space that was based on the structure that Game Developer Magazine uses. I’m going to use that same format for this LandFormer postmortem.


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.


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!