In the meantime, I’ve got a lot of work to do. I’ve got to get the LandFormer website set up in time for launch, as well as prepping all my press materials. It will be a busy couple of days/weeks, but it should be fun to do some work that isn’t game coding for a little while.

Finally, I just want to say a big “thank you” to all my testers, once again. I appreciate all the feedback and bug reports. Testers help to make the game a great experience for everyone, so thank you!

Subscribe to the blog RSS feed, follow me on twitter, or sign up for the mailing list to get the latest LandFormer updates and find out exactly when the game becomes available.

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

However, before that can happen I’ve been taking care of some less exciting stuff. The last couple of days I’ve been working on a save system for the game. It turns out saving the state of a game that has a physics engine and is interacted with in real-time is a lot more complicated than for a turn-based puzzle game. Who knew? I kid. But seriously, what I hadn’t anticipated was having to build a whole new save game framework to handle it nicely.

At this point I’m getting a little concerned with the fact that there are only 10 days left in October. If I’m going to submit by the end of the month, I’ve got a lot of work to do. If I really buckle down I still might make it, barring any horrible problems [knocks on wood]. Otherwise I might end up pushing a week in November. Here’s hoping the next two weeks go well!

The good news is that my play testers seem to be really enjoying the game! There are a couple that keep battling for the high score in the leaderboards. It’s exciting to see! A week ago I thought I was Mr. BigShot with the high score in the game for the first level. Now I’m 5th. I love it when that happens. It means the people playing the game are discovering strategies that I hadn’t anticipated.

It should be an exciting next couple of weeks!

Owen

Wednesday night we had the 2nd Toronto iPhone Developer Meet-Up, which was a great success in my mind. We had two great presentation by local iPhone devs. James Eberhardt was able to secure us space at the Rich Media Institute, which turned out to be perfect. There was beer that could be bought, and we had a great conference room with a projector for the presentations. I’m extremely pleased with where the meet-up seems to be heading. I think everyone who came, that I talked to, enjoyed the format. I think we’ll try to stick with the format of two short (15 mins or less) presentations, followed by socializing and drinks.

If you missed the meet-up, the presenters have graciously posted their presentation slides on their sites.

• Rules You Should Break in the App Store (www.xinsight.ca – PDF) – Jason Moore from xinsight gave a presentation on tips and tricks for making the most of the App Store.
• iPhone + Box2D (blog.zincroe.com) – Luke Lutman from zinc Roe Design gave a presentation on using the open source Box2D physics engine with iPhone. He has posted his short presentation slides (that we saw) as well as a longer presentation and an example source code project.

A big thanks to both presenters! It was a great way to kick off the new format for the meetings. I think everyone enjoyed it.

If you haven’t already, please join the Facebook group for the meet-up. It’s called Mobile Developer & Designers of Toronto. I look forward to seeing you in June!

As I mentioned previously, I had be writing a chapter for a book on iPhone development. I’m pleased to say that I submitted my first draft to the publisher this week. As such, I was able to do some coding towards the end of the week. Yay!

I started working on stuff for the Dapple 1.2 update. The biggest new feature will be the inclusion of world-wide leaderboards for the game. I’ve decided to use Google’s App Engine as the server-side technology, as it scales nicely and it means that if I did somehow introduce some kind of server-side security flaw (which I don’t think I have), it’s not running on my own web server.

I’m two days into things and I’m quite impressed with the App Engine stuff. Sure, I had to learn Python pretty quickly, but at this point the server-side stuff is pretty much done. I’m sure it will need some tweaking once I actually hook the game up to it, but all my tests are working. I can add high scores to the database and I can retrieve them in a few different ways. Today I’ll be starting to work on the game-side implementation, which will probably be more work than the server-side. I have to make a few UI changes in the game to support local vs. global high scores and handle all the error cases around connecting to the server. I’m hoping to have something I can send out to testers by mid-late next week.

It feels good to get back to coding again. There are a few other things I want to put into the 1.2 update as well. I’m hoping to submit to Apple by the end of the month. After that, I’ll actually be able to start working on my next project. Shocking!

Have a good (long) weekend everyone!

Owen

I’ve been looking for a good way to track all my app sales data. The best tool I’ve found so far is AppViz. It will download your daily sales data for you and generate all kinds of pretty graphs. My biggest complaint is that the export feature doesn’t really export the data in a useful way. What I really want is a tool that will generate data that I can import into Excel or Numbers and do my own graphing and statistical analysis on. Ideally I want each country to have it’s own spreadsheet so that I can graph individual countries and then also graph total sales. I might end up building my own tool. That just seems silly, though.

As I hinted at above, I spent this morning (and this afternoon so far) sending out press releases announcing the launch of Dapple. I’ve been sending out promo codes to iPhone gaming review sites in the hopes that I’ll get a few reviews out of it.

My friend Jaysen wrote up a great review of Dapple on his site: I, Game Maker. He is a friend of mine, so I can’t say he’s completely unbiased, but I feel like he provides a pretty honest review of the game.

I’ll probably spend the rest of the day finding sites to send my press release to. Tomorrow I need to get back to my 360|iDev presentation. Time’s running out! Oh, and they just released full descriptions of all the talks at the conference on the 360|iDev site. The conference is going to be amazing. If you’re an iPhone developer, at least check out the website and see if you can make it.

Owen

Saturday morning I dug into the code (I know, I said I wasn’t going to work on the weekend, but that was assuming I didn’t find a bug like this). The bug looked minor: the mixing guide wasn’t rotating for player 2 (so it was rendering upside down from their point of view). However, as I dug into the bug I realised there was a bigger issue: player 2’s mixing guide was rendering for player 1’s current colour. This meant if player 2 started the 2 Player game and hit the mixing guide, a bunch of empty textures would render because player 1 didn’t have a colour yet. Yuck. The fix was pretty simple and localized (i.e. it was all inside one function in the code), so it was pretty low risk.

I ended up pulling my submission Saturday morning and re-uploading the build to Apple. I don’t think they review on the weekends, so I think it probably cost me a half-day off my submission. I haven’t found any more issues since, so the build should stand as it is now.

People keep asking me how long it will take before the game shows up in the App Store. The short answer is: I don’t know. The longer answer is: I don’t know, because there’s no set turn-around time. I’ve heard of some developers having apps approved in under 48 hours, but others who take over a week. Then, if the app gets rejected, I’ve heard it can take even longer to hear back. Apple will email me when the game is either accepted or rejected, so at least I don’t have to keep clicking ‘reload’ on the app store submission page.

This morning I sent out some emails to various iPhone review/news sites letting them know the game had been submitted, and telling them where to find the latest gameplay video I did last week. I figure it’s not likely any of them will write about it, but at least they’ll know they can expect another press release from me when the game launches…hopefully soon.

Speaking of the press release, I’m about to start working on that so that it’s ready to go out as soon as the game goes live. I also have to start working on my presentation for 360|iDev. I’ve got a rough idea of how I want to structure the talk, but now I need to start writing stuff down.

Owen

However, by the end of the day, I had my movie ready to release. I dropped it on YouTube this morning. You can see it on the Dapple page (www.dapplegame.com) or right here:

It was fun to actually shoot the video with my video camera and get to use my shotgun mic. My previous Dapple video was a screen-grab of the simulator running the game, but I really wanted to show the game running on the device this time.

I was Tweeting about the process while I was working on it and I got a few requests from people to share my experiences. I wrote up a quick tutorial on the steps I took, which you can find via the Tutorials page located in the left side-nav.

In Beta news, Dapple is getting very close to submission. I made one change to the game yesterday (just updating the copyright notices). If no new bugs have been logged by my testers (or by myself) by noon tomorrow, I’m going to submit. Wish me luck!

Owen

• Streaming Colour Tutorials Page (www.streamingcolour.com)

Or by hitting the “Tutorials” link in the left-hand sidebar navigation (if you’re reading this on the site).

It was really fun to write this up for some reason. Learning how to track mem leaks on the iPhone was fun, but kind of frustrating, so I wanted to help other people just experience the fun parts without all the frustration. Yes kids, tracking down memory leaks can be fun!

I’m preparing a new build this morning for my testers. I’ve gotten some great feedback from some of the new beta testers and I’m trying to incorporate changes where I feel they make sense. Most of the changes are around how the game communicates with new players.

Speaking of tester feedback, I’m kind of torn about something I’ve done. Late last week I put a pop-up into the game that comes up whenever your iPhone or iPod touch generates a “low memory” warning. This usually happens because other programs have been leaking memory and then someone boots up your game and the device doesn’t have much RAM left. This generates an event in your app and you can handle it however you want. In my experience, most apps ignore it, then crash a few minutes later when the device runs out of RAM. I didn’t want this to happen, so I bring up a pop-up saying “Your device is running low on memory. It is recommended that you reboot your device or the game may quit unexpectedly.”

The problem is this: several of my testers have mentioned to me that the message came up during their first few sessions of play. Virtually all of them have said something like this “I don’t know if it was your game’s fault, or if I just hadn’t rebooted my iPhone in a while.” This worries me because I’ve measured my game’s memory footprint; it’s not that big. It maxes out around 15-17MB of RAM used. My concern is that people will see this pop-up, and instead of seeing it as helpful, they’ll assume my game is the problem.

On the other hand, I don’t just want to do nothing, have the game crash, and then have people blame my game for crashing.

Anyone have any thoughts on that?

Finally, I just wanted to mention one aesthetic change I made to the site over the weekend: if you’re viewing the actual site (and not reading this is an RSS reader) then you’ll notice that all of the content text is now bigger. I had gotten a lot of feedback that the font was too small and too difficult to read. Well, I listened to you, my dear readers, and I have made it bigger!

Owen

Ok, I do have a looser definition of Beta than most big games companies. In the past, big companies I’ve worked for usually have had a definition that goes something like: “A minimum of X hrs has passed with no must-fix bugs found by QA”. They usually define something called “Dev Beta” as the “First Zero Bug Build”. In my case, since I don’t have any QA, I’m declaring my first zero bug build as Beta.

Basically, I’ve fixed all the bugs that I know to exist in the game. Yesterday I squished a bunch of bugs and I tracked down the last of my memory leaks (Oh Instruments! What a fantastic tool you are for developers!) I must say, the game’s looking pretty slick. (I’m so modest)

Yesterday I also created a game icon for the iPhone home screen and the corresponding 512×512 artwork that iTunes will use. I also discovered something, which is apparently a known issue: if you try to use your big image saved as the “iTunesArtwork” file, that the Apple docs tell you to do for an ad hoc build, it can prevent your app from installing on a device. Spent over an hour last night trying to figure out why my beta build wouldn’t install on my iPod. Turns out it’s because I decided to try to include my new artwork with the build. Well, I guess my beta testers get the game without the fancy new artwork then…

All in all, feeling pretty good about things. Hopefully I’ll submit to the app store by the end of next week, pending any horrible bugs that come up.

I’d feel a lot more like celebrating if a whole bunch of my friends and former coworkers hadn’t just lost their jobs yesterday:

• Disney Confirms Cuts, Consolidations (www.kotaku.com)

Sorry to end the post on a down note…

Owen

I fixed a whole bunch of bugs on the weekend and I was feeling good starting work today. Then one of my current testers sent me an email on a crash he’d experienced. So far I’ve been unable to reproduce the bug. Luckily he was able to send me crash logs, so I can see the sequence of events that led to the crash, I just can’t repro them.

So then I decided, instead of bug fixing, I’d put in a simple loading screen system. It should have been really simple, but for some reason it turned into a real nightmare. Somehow adding in a couple of animations, or triggering my game mode changes from an animation callback, is causing a memory stomp somewhere. The problem is, I haven’t been able to figure out where yet. It’s been incredibly frustrating.

I’m really feeling the stress now. I’m working too much and too many hours. I’m torn between wanting to slow things down a bit and wanting to get the game done. Right now my desire to get the game done is winning. I need to find some way to stop thinking about work when I’m not working. If anyone has any suggestions, I’m listening.

Owen