At the end of last week I wrapped up my work on a contract I’d been working on since last fall. My part of the project has been passed on to the next team of developers who will wrap up the final features. It feels great to be able to get back to work on my own projects, and I look forward to seeing the game launch when it’s done.

As I am returning to working on my own games, I thought a post about the time between projects would be in order. I often get asked by players where I find the inspiration for my games. I’m sure we all have different answers for this, but I thought I’d try to explain mine.

Where an idea comes from is difficult to answer. Inspiration comes in many forms for me, and I’m never quite sure where I’m going to find it. Sometimes it comes from playing another video game, sometimes a movie, sometimes discussing politics with friends.

One of the things that I think is most misunderstood about inspiration is the idea that you don’t need to work at it, that it will just come to you in a flash. I don’t believe this ever to be the case. Inspiration takes work, it takes dedication, and it takes patience. You need to work at being inspired. You need to work at your ideas. An artist might do dozens of sketches, then several small paintings working on an idea before finding the direction they want to take the final work. We too must actively look for ideas, experiment and refine them. That flash of inspiration only comes after you’ve done the research, the work, and given it all time to let your brain process the ideas.

Well that’s great, you say, but where do I begin? If it takes all this work, where does the work start? These are some of the activities I’ll do when I’m actively looking for inspiration:

• read a book about a new subject
• watch a film
• go for a walk in nature
• go for a walk in the city
• play a video game
• play a board game
• go to a museum
• go to an art gallery
• write something
• draw
• build something with my hands
• go out for a good meal
• cook something new
• go out with friends and/or family
• walk to the river and listen the sounds of the water
• start writing ideas down

You might have your own list that’s totally different. However, I believe that one of the most important items on that list is the last one: write down your ideas. The act of forcing yourself to think about a problem will lead to inspiration. It is not easy, it may even be actively difficult, but working through it will lead you in new directions and to new solutions. The more ideas you write down, the more ideas you will have. The less you work at actively thinking of new ideas, the fewer ideas you will have. This is why inspiration takes work.

But perhaps most importantly, you need to be constantly open to new ideas. You need to be aware of when an good idea is speaking to you, and know to follow it. That means resisting the urge to make assumptions and snap judgements about an idea. It means talking with people who disagree with you. It means debating without shutting out. It means empathy. Because finding a new idea often means looking at a problem from another point of view; understanding someone else’s feelings; putting yourself in someone else’s shoes.

As game designers, we need to be engaged in the world around us. Games are about interactivity, emotion, and narrative. The world is full of all these things, we just have look for it, and work at it seeing it.

Owen

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

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

You can see there are the 5 tile heights from the game. I’ll be working from these drawing to start creating the main tiles for the theme. There’s a lot of other art that goes into a theme, but the tiles are what I start with.

Owen

One of the things I’ve been working on the for the last couple of days is a new theme for the game. You’ve seen the Earth theme already:

LandFormer Earth Theme

This is the new Colorful Blocks theme I’ve been working on:

Colorful Blocks Theme

This new theme will be available for purchase inside the game when it launches.

Now, I must get back to work!

Owen

I thought I should post an update since I’d received a lot of questions recently about how the game is coming along and was I still planning to release in April. As often happens, life and some technical challenges got in the way of me finishing the game on time. My gut tells me that I’ve got about 3 weeks of work left on the game at this point. I want to make sure the game is as awesome as possible for when it launches, so I hope you’ll understand that I’m taking this time to make sure the game is the best it can be.

Since my last post about the game, I’ve implemented some pretty major changes to the game. One of which was a complete overhaul of the artwork in the game. I liked the theme of the game, but the artwork seemed a bit dark and drab, so I’ve worked to brighten things up and make the game more appealing and enjoyable to play.

For comparison, this is the last screenshot I posted of the game back at the end of February:

Here’s a screenshot of the current state of the game:

As you can see, the game is basically the same as it was, but I think it looks a lot better. I hope you agree.

One of the other big things I managed to get working was the level editor and level sharing code. When the game ships, it will ship with a bunch of built-in levels. However, it will also contain a level editor so that you create your own levels. Not only that, but you can email levels to your friends so that you can play each others’ levels! This feature was a little more work than I had originally planned for, but I think it adds a lot of fun to the game, so it was worth it. It should allow you to keep playing LandFormer long after you’ve solved all the built-in levels.

Several people have asked for more details about how the game is played. I think it’s easiest if I create a short video showing the game in action, but that will have to wait for a few days. Hopefully I can find some time to do that soon.

Until then, please know that I’m working as fast as I can to get the game done and into your hands. I’m working hard to make sure it’s the best game it can be.

Owen

Here’s a first peek at the game. Just note that this is all still work in progress and that the look of the game may still change significantly before it ships:

Here is the write up on the game that I gave to Touch Arcade (with some modifications) when they originally covered the Game Jam:

LandFormer is a puzzle game. To complete a level, all pieces must be raised or lowered to a flat plane. However, you can only raise or lower pieces in the patterns dictated by the brushes. Strategy and intuition are required to master this simple yet challenging game.

Stay tuned for updates on the game’s progress as I continue working on it.

Owen

A lot of the anger seemed to stem from accusations of pretentiousness. In Ms. Short’s article on aging and death in games, she starts by talking about hating when the word “pretentious” is used in art criticism. I love that she talks about this. She starts her article with:

I hate the word “pretentious” in art criticism.

I understand why people use it. Often we call something pretentious when we think the artist might be concealing a lack of meaning or vision behind obscurity, jargon, or a set of conventions currently hallowed by the art establishment. It’s a way of saying “I don’t get this, and I don’t know that there’s anything to get” that shifts the blame (if blame even applies in so subjective an area as one’s response to artwork) onto the artist rather than ourselves.

The on-going debate over whether or not a video game can be considered art and art gaming is an area of great interest to me. I grew up in a family of artists, and so for a long time I assumed that everyone enjoyed art as much as I did. As I got older, and understood more about politics and people’s differing views on the world, I started to see that not everyone had the same love of art that my family did. In the age of the Web 2.0 (oh, how I hate that term) where everyone has a voice on the internet (yes, I’m aware of the irony of writing that on my blog), a wider contempt for art is becoming more and more apparent to me, especially in gaming circles.

Ms. Short’s article brings up the issue when she mentions the use of the word “pretentious”. Reading the comments on her article and on Ms. Alexander’s article, you can see the anger that erupts from some people when the concept of art is discussed. This is an attitude that greatly saddens me.

Let me take a little aside here to talk about a professor I had for one of my art courses in school. Every Monday in class we would all hang our work from the previous week on the walls and everyone would critique each others’ work. It was an important exercise for two reasons: it taught you how to think critically about someone else’s work, and it taught you how to accept criticism of your own work. However, there were also two rules: any criticism had to be constructive, and you weren’t ever allowed to use the word “interesting” when describing someone’s work.

Our prof’s reasoning for the “interesting” rule is that people use the word interesting when they don’t want to commit to a response. It shows that they haven’t thought about the work, that they haven’t even tried to understand how the works makes them feel. I think this is why Ms. Short’s article affected me so much: the word pretentious works the same way. Except that Ms. Short is right, the use of the word pretentious isn’t just about not understanding the art, it’s a statement that the viewer feels the artist is laughing at them for not understanding.

It’s here that I think a lot of the anger towards art stems from. People are intimidated by art for some reason. When they don’t understand a work, they assume that the artist is laughing at them. They are afraid of being embarrassed by art.

Complicating all of this, of course, is the fact that there are some artists out there who create work with the expressed purpose of making people angry that they called it art. I think this is also why a lot of people are afraid to express an opinion about a particular piece of art: they’re afraid that if they do form an opinion and comment on it, the artist will say, “Ha ha! It was all a joke, don’t you feel stupid.” Well I say: enough. It’s better to have an opinion on a piece than to be afraid that it’s the wrong opinion.

Other people would tell us that art can only be enjoyed by those who are educated enough to understand it. Statements like that upset me deeply. Anyone who tells you art can’t be appreciated unless you understand it is probably afraid that they themselves will end up looking stupid.

I’ve taken enough art history classes to know that you can learn to understand historical contexts that help you appreciate why a particular art movement appeared when it did. And knowing about an artist’s life and past work can help put their work into a context that can let you enjoy aspects of their work that you wouldn’t otherwise. But that’s not the point. My point is that even if you’ve never taken an art history course, even if you’ve never looked at a painting before, that should never stop you from going into a gallery and making up your own mind about the artwork in it.

This isn’t to say that we shouldn’t try to learn more about art. We should read about the artist, learn about the movements that lead to their work. This will help you enjoy the art at different levels. But we need to get over this feeling that art can’t be enjoyed without being understood. Art is for everyone! Ultimately it doesn’t matter what the artist intended for you to feel when he/she painted/sculpted/film/programmed the piece. What matters is what you feel when you experience it. We have to get rid of this idea that there’s a right way and a wrong way to feel about art. Focus instead on how it makes you feel.

Take a look at one of Mark Rothko’s paintings. This is called “Orange and Yellow” and was painted in 1956. The original piece is 71″ x 91″. That’s big! Imagine yourself standing in front of this painting that is over seven feet tall!

If you know about Rothko’s evolution from his early paintings that were much less abstract into abstract expressionism, then great. If not, I would argue that it doesn’t really matter. Look at the painting. If your first reaction is “it’s just two blocks of colour. I could have painted that” then fine. But now move on and really look at the painting. Take your time. How does it make you feel? Do you like it? What do you like about it? Do you hate it? Why do you hate it? Look at the way the colours interact. Consider the proportions of the blocks of colour. Really look. Take the time to let it affect you. Reflect on it. Don’t just make a snap judgement based on the first two seconds of looking at it. Now describe it without using the words “interesting” or “pretentious”. And remember, there’s no wrong way to look at this painting. Whatever you feel about it is valid, as long as you’ve actually taken the time to give it a chance.

So let’s please leave the ignorant yelling about how art is pretentious behind. Let’s look at art and art games with an open mind. Not every painting or art game is going to be considered good or appeal to you, just as not every book or movie will appeal to you. I’m just asking that when you criticize an art game because you don’t like it, tell us why.

As mothers everywhere have been saying to their children for generations: use your words.

Owen

Because I really enjoy reading Game Developer Magazine, I thought I’d follow their template for a postmortem and list 5 things that went right followed by 5 things that went wrong on the project.

What Went Right

1. Prototyping, Iteration, and Early Feedback. One of the processes I put into place when I started Streaming Colour Studios is the extensive use of prototyping and rapid iteration. When you build a large console game, you need to plan out everything a lot more because there are 100 people working on the game. When it’s just you, you can afford to play around with ideas a lot more.

Monkeys in Space actually started out as a completely different game. The first prototype I built involved controlling space ships with black holes. One of the things I learned with Dapple is that the sooner you get feedback the better. So this time I sent that first prototype out to a few trusted friends to get their opinions on it. The feedback that I got was that the controls weren’t intuitive enough and the game wasn’t really fun to play, just frustrating. This was fantastic feedback to get so early in the process and I was able to start trying new ideas and iterating on the design.

Eventually I got to the point where the game was fun, but the space ship theme wasn’t working for me anymore. I had had an idea for a bonus level that involved picking up monkeys floating in space with your ship, but after discussing this with a few friends over coffee (one of them ended up writing the music for the game) I decided that the game might be more fun to play if the monkeys were the focus of the game. Once this decision was made, it opened up new avenues for art direction, marketing, names, and even merchandise.

Once I had the monkeys in the game, I opened the game up to much more public play testing. People were playing the game and providing regular feedback at a much earlier stage of the development than with Dapple. This proved to be invaluable for fine tuning the design and polishing the game.

2. Gameplay. Monkeys in Space fits into the “line drawing”/”chaos management” genre of games, but it needed something to set it apart and help it to stand out. I had also learned, through my experiences with Dapple, that I needed a gameplay mechanic that was easy to understand, but offered depth to the experienced player. Monkeys in Space offers familiar gameplay goals to players familiar with the genre (get the monkeys to the bases), but adds a twist that adds depth to the game (linking monkeys together). The chaining mechanic was added about mid way through the prototyping process, but the feedback from play testers was unanimously positive. I’m very happy with how the game ended up playing out. The chaining adds a risk/reward factor to the game that has been mentioned in a lot of reviews.

3. The Name. I mentioned above that the game was originally about space ships. Well, it was a search for a name for the game that ultimately led to the game being about monkeys instead. I was brainstorming game names with some friends when I mentioned I had been thinking about adding a space monkey level to the game. Immediately we all started thinking about fun names for a game involving space monkeys. My favourite at the time was “Space Monkey Rescue”, but I ultimately abandoned it because of trademark concerns. I contacted my friend Stacy, who is a writer, and asked her for help. I sent her some of my favourites, including just “Monkeys in Space”. I told her I was looking for a 50′s or 60′s sci-fi b-movie feel for the title and she came up with “Monkeys in Space: Escape to Banana Base Alpha”, which I absolutely loved. I think the name is perfect for the game in that it captures that silly retro feel I wanted, and it says “yes this is a game set in space, but it’s not a serious sci-fi game; it’s fun and it has monkeys!”

4. Artwork. With Dapple I had decided to hire a professional artist to do the game’s artwork. While the artist did an amazing job and I was extremely happy with her work, hiring an artist is also expensive. With Monkeys in Space I decided to take a different risk and do the artwork myself. Now, I took some art classes in university, I’ve done a little life drawing since then, and I once had a job where I was using Photoshop for eight hours a day, but I’m not a professional artist, so this was kind of a risky move. However, in the end, I was quite pleased with the art in the game. I think the monkeys especially turned out quite well. No doubt a professional artist could probably have bumped the artwork up a notch (or two), but I’m happy with the results. On top of that, it was also really fun. It was great to get back into drawing regularly again and I think it’s something I’ll be considering for future games, if it’s a possibility.

5. Reviews and Apple Feature. Monkeys in Space has received some great reviews from the iPhone gaming press/critics (you can read them on the Press page). Every good review helps to build buzz around a game, but one of the biggest reviews the game got was from TouchArcade.com. Their Monkeys in Space review was on their front page for two days and during that time I saw a sales spike close to what I was to see being featured by Apple. Then a week after the Touch Arcade review ran, the game was featured on the App Store in the Games -> What’s Hot section. This happened just before Christmas, which couldn’t have been better timing. It wasn’t a front page of the App Store feature, but it was enough to push me into the Top 100 Kids Games in the U.S. store. This gave the game some momentum through the holiday boost.

I’ve decided that while I don’t want to share sales specifics about the game (like the infamous Dapple “Numbers” post), I will share the shape of the graph of sales since the game’s launch:

What Went Wrong

1. Release Date. I mentioned this earlier this week, but my release date turned out to be a big mistake. I submitted the game to apple in mid-November and wasn’t sure when to expect it to be approved. I got the email from Apple saying the app was ready for sale at about 7:30pm on Wed, Nov 25th. I was so excited that I switched the app into the “for sale” state (by setting the release date to the 25th) and started preparing the email I’d send out to the press in the morning. On Thursday morning I sent out my press release along with screenshots and video, etc, to iPhone sites. At that point I started getting back “out of office” replies and suddenly released it was Thanksgiving in the U.S. See, we Canadians celebrate Thanksgiving in October, so the date completely slipped my mind.

At first I didn’t think it would be a big problem. But then I started reading the review sites that were staffed for the holidays and most of them were just running stories about the hundreds of games that were going on sale for Black Friday in the U.S. Not only that, but it turns out a lot of people apparently take a long weekend from Thursday-Sunday, so it meant I didn’t hear from anyone until well into the next week.

However, I can’t really complain as the game eventually did get picked up by review sites, but the roll out was more gradual than I had hoped. The delay meant that my marketing lost some momentum right at the start, which isn’t ideal. In the future I will be paying closer attention to U.S. holidays when I set my release dates.

2. Delays. When I did the first concept sketches for the game that was to become Monkeys in Space, the original plan was to build the game in 2 months or less. From start to finish, the game ended up taking almost exactly 3 months. One extra month isn’t terrible, but that’s a 50% overshoot of the original plan. Now I have excuses: my wife and I moved cities, which ate up a few weeks with packing, moving, and unpacking, etc. But I think the biggest reason the game took longer than I thought it would was because I decided to do the artwork. Because I was doing the art and the programming, it meant that the two couldn’t happen concurrently. When you work with an external artist, they can be drawing while you’re coding, but I didn’t have that ability this time. The artwork took longer than I thought it would, which pushed my timeline out. Ultimately, it was worth the extra time to make sure the art was good enough to meet my expectations for the quality of the game, but it did delay its release.

3. Marketing Push. I learned some important lessons with the launch of Dapple. One of the most important was the need to have your marketing push happen all at once. You want everyone to be talking about your game at the same time. I’ve already mentioned the problems the release date caused with this, but I suspect there were some other missed marketing opportunities around advertising that I didn’t explore. I haven’t had a lot of luck with advertising driving sales. However, I think if done properly, there may be ways to leverage advertising effectively, even for $0.99 games…I just haven’t figured it out yet.

4. Not Enough Levels in v1.0. During development I had to make a call about how many levels to include in the initial version of the game. I looked at the great games in the genre (e.g. Harbor Master, Flight Control, etc) and looked at how many levels each had shipped with, and decided to ship three levels. I also chose to limit myself to three levels at first because the game was already taking longer than I had expected. However, what I discovered is that people expect new games to contain as many levels as the other games do now, not how many they contained when they shipped. Some of the reviews of Monkeys in Space have mentioned that they would have liked to have seen more levels in the game. Since then I have released a fourth level as part of a free update and I hope to release more. Regardless, what I failed to realise is that the free update system for iPhone apps creates a different set of expectations in people’s minds. They don’t care that game X shipped with one level; what matters is that it has five now. This was an important lesson in competitive analysis for me.

5. Public Recruiting of Testers. I almost listed this in the “What Went Right” section as well, and it just barely squeaks into the “What Went Wrong” list. Very early in the process (much earlier than I’d ever considered before) I started asking people to play test the game and provide feedback. I put out a call on Twitter, on this blog, and in iPhone gaming forums, looking for people who wanted to play the game and provide some honest feedback about what did and didn’t work. The reason this should also be in the “What Went Right” is that I got some terrific people playing the game and providing me with insightful and helpful feedback. However, I also had a lot of people sign up, get the builds, and I’d never hear from them again. I think there is a small group of people who say they’ll beta test a game just to get a free game. The good news is that I’ve met enough great people that I now have a decent list of preferred testers I’ll ask first next time.

Conclusion

All in all, I’m extremely proud of Monkeys in Space. I think that I learned a lot from some of the mistakes I made with my first game, but I still made a few new mistakes. I suppose that’s all part of the process of becoming a better game designer, developer, and business person. What I like most about Monkeys in Space is seeing new players pick it up and to watch how easily they get involved with the game. I also love watching people laugh when the monkeys scream and wave their arms frantically. People seem to have fun with the game, and that makes me happy. To me, that alone makes the game successful.

Owen

Owen