With a baby born over five weeks ago, I took several weeks off work entirely. But about two weeks ago I started trying to get back into doing little bits of work. Working from home with a baby in the house is proving to be quite difficult, but I’ve already learned a few things that are helping me get at least some work done. Just keep in mind, I’m still new to this. I don’t pretend to have all the answers, just some tips that work for me.

1) Start Small

When I first decided to start coding again, I set a goal of writing one hour of code per day. The first few days I failed miserably. I’m glad I hadn’t decided to work full days or I might have been very discouraged. However, after a few days I found I was able to get even up to two hours of work done, just in 20 minute increments. My main point here is don’t expect too much from yourself at first. Getting used to having a baby is a huge change, trying to work at the same time is a massive challenge. Accept that it’s going to be hard and don’t beat yourself up if you’re not working full days right away.

2) Learn to Work in Small Increments

If you haven’t read this excellent article called “The Interruptable Programmer“, do so now. All of his tips apply to working at home with a baby in the house. I’ll wait. Done? Good. The biggest take-away there is that you need to get used to working in small chunks. Always be aware of what you’re working on. Make notes about what needs to happen next. If you need to stop coding because the baby starts screaming, jot down something quick about what you were doing; put it right in the code if you have to. Personally, I bought a little Mac app called ShoveBox that allows you to take very quick notes just by pressing a key combination on your keyboard.

If you’re a programmer who likes to really dig deep into code and do marathon coding sessions (like I used to), this is going to be a huge adjustment, but it’s a necessary one. If the choice is between coding 30 minutes at a time and not coding at all, I’m going to try to code 30 minutes at a time.

3) Staying Motivated

One of the most difficult things for me over the last couple of weeks has been staying motivated when I can only code in short bursts. It’s easy to get side tracked. It’s really easy to get distracted with reading blogs posts [cough] after each break in coding. This will kill your time. You need to find ways to keep motivated and keep working. I’ve completely stopped reading RSS feeds during the last two weeks. It means I’m not as aware of what’s going on in the world of gaming, but I’ve got a contract to deliver on, so that takes priority. I try to limit my time on twitter when I’m starting a work chunk. I limit what links I click on to avoid being distracted.

The goal is to get right back in where you left off after you’ve been away from the computer for a chunk of time. This will help you stay motivated. Avoid the distractions, and you’ll find a new flow.

4) Talk to Your Partner

This is the most important point. Seriously. Make sure you do this.

If you’re a single parent, you’re amazing. I honestly don’t know how people do it on their own. A baby is a huge amount of work, even spread over two people. Single parents, I’m in awe of you.

But, if you’ve got a partner who is also at home (on maternity or paternity leave, or as a stay-at-home mom or dad), talk to them. Make sure they’re on board with you going back to work. You will need their support. You will need them to look after the baby while you’re at work. You will need them to understand that you’re going to need some time to code/design/draw/create. At the same time, make sure they understand that you’re not disappearing. If the baby won’t stop screaming and they need a break, let them know it’s OK to interrupt you and ask you for help. But also make sure they’re OK with you shouldering them with more responsibility while you’re working. As the baby gets older, and you establish more of a routine, hopefully you’ll be able to spend more time working each day.

Having an amazing wife who understands all of this has made it much easier to get back to working. I’m still only working half-days, but without her support I wouldn’t be doing even that.

5) Working With the Baby

There are times when I need to look after the baby and do work. If (and this is a big if) the baby is in the right mood, sometimes he’ll let me put him into a baby carrier and he’ll happily sleep while I sit and do some coding. It doesn’t always work, and it’s not ideal, but it is a way to look after the baby and do some work at the same time.

6) Family Comes First

Yes, I’m talking about working with a baby in the home, but the final thing I wanted to say is to remember that your baby and your family come first. If your partner needs you, be there for them. If the baby needs you, look after him/her. Yes, we need to get work done, but work isn’t everything.

Conclusion

Working at home with a baby in the house is possible, but it is very challenging. The thing I keep reminding myself is that it’s an amazing opportunity most people don’t get. Most people don’t get to go back to work yet still see their child grow up before their eyes. We’re very lucky that we get to do this. Don’t take it for granted. Enjoy it.

What about you? As a mom or dad programmer/designer/artist/creator, what are your tips for working from home?

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

The good news is that I’ve had my testers playing the game and I’ve received a tonne of great feedback and bug reports. I’ve decided that a lot of the feedback was worth implementing to make the game easier to learn and nicer to use, so it’s been taking a bit longer than I thought to wrap up. The good news is that I should be ready to declare Alpha (feature complete) by the end of the day! I’m working on the last major feature today, and I should be able to wrap it up by this afternoon. After that it’s all small improvements and bug fixing until I ship the game.

So the game is coming along. It’s taken much longer than I originally planned, but I’ve put in a lot of really cool features that I hadn’t originally planned on; things like: in-game level editor, the ability to send levels to your friends, and an in-game store so you can download more levels and game themes. All of these things take time, but the end result is a game that I’m extremely proud of and very excited to get into your hands once it’s ready.

With this game I’ve taken an “it’s done when it’s great” kind of approach. I hope it’s worth the wait.

Owen

Update: At 12:25pm today I officially declared Alpha! Just tuning, tweaks, improvements, and bug fixing now. “Just”…

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

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

Executive Summary: SO AWESOME!!!

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

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

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

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

A tiny segment of the massive GDC Expo

The IGF Awards

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

There were huge crowds in the halls between sessions!

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

Will Wright giving his presentation!

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

Owen

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

With that in mind, I thought I’d take some time today and go over a few things about Dapple. If you haven’t read my 360iDev presentation on the creation of Dapple, you might want to do that. I consider it a companion to this article, but this will go into more depth.

Effort:

The first thing I want to do is look at some numbers, because I think it’s good to put Dapple into context. The question of “how could you spend 6 months making Dapple” is interesting to me because I come from a AAA console game background. Before I moved back to Toronto and founded Streaming Colour, I worked on a team of over 100 people who all worked on a single game for 3 years. Dapple had one person (me) working on it full time for 6 months, and 3 content creators working on it, say, half-time for one month each (call it 1.5 months total). When you put it like that, it’s hard to really put that into perspective…so let’s do it this way instead.

AAA Console Title (Xbox 360 or PS3):

• 100 people (this is actually fairly conservative; some teams are up to 200 people now)
• 3 years (this is pretty standard, unless you’re EA putting out a franchise every year)
• 220 working days a year (this doesn’t include overtime, which means this will be much lower than actual effort involved)
• 6 hours of work per day (again, not including overtime)
• Total person-hours: 396,000

Dapple (iPhone):

• 1 person
• 7.5 months (this includes the contractors’ time)
• We’ll call it 160 working days
• 6 hours of work per day (again, not including overtime)
• Total person-hours: 960

Let’s call it 1,000 hours for Dapple, then. In actuality, I worked quite a bit of overtime, especially on the last 1/3 of the project. But still, for that amount of effort, I think Dapple is quite impressive. Maybe I’m biased.

Lines of Code

My friend Jay posted on his blog recently about the growth of code size between Wolfenstein 3D and Quake 3. It’s a fascinating read. It also got me thinking about Dapple’s code size. With Wolfenstein 3D being released for iPhone as open source recently, I thought I’d compare the two. I used a tool called cloc to run a line of code comparison of Wolf 3D and Dapple:

• Wolf 3D = ~28,000 lines of code
• Dapple = ~21,000 lines of code

This means that Dapple is about 3/4 the size of Wolfenstein 3D, which I actually found quite shocking. The big difference here is that Wolf 3D’s code is mostly for the game. When I broke it down further, I discovered that over 6,000 lines of code for Dapple is for the front end and user interface. If you look at Wolf 3D, they only have a few very simple menus in the game. Dapple has dozens of screens.

I’m not sure if there are any conclusions to be had here, other than to say that it does take time to write 21K lines of bug-free code.

Timeline

Finally, this will only be of interest to only the most hard-core of the hard-core, but I took an hour or two and I went through all of my change logs during development of Dapple. What I’ve done here is give a week by week summary of what I did to create Dapple. Keep in mind that most stuff relating to the business (e.g. finding and hiring contractors, dealing with international sales contracts, etc) didn’t have any mention in my change logs, so I haven’t mentioned them here. This mostly just relates to the coding tasks involved in creating Dapple. So, without further ado, here’s how you make Dapple in 6 months:

Pre-Production

Week 1:
- Downloaded, installed and learned Playfirst’s Playground SDK (2D game engine) for Mac.

Week 2:
- First pass at prototyping original game concept.
- Game isn’t fun.

Week 3:
- Created animation system.
- Changed some gameplay mechanics to make the game more fun.
- Added some simple animations.
- Game still isn’t fun.

Week 4:
- Branched prototype and started working on new gameplay mechanic, based around same idea: mixing paint colours.
- Gameplay now based around making matches (more similar to final product)
- Game is more fun, but is too complex – new players are easily confused.
- Experimented with simple SFX and background music
- Experimented with some simple HUD elements (displaying score, for example)

Week 5:
- Ported prototype to Windows.
- First draft of game design document.
- Started designing front-end UI flow (menu screens).

Week 6:
- More gameplay mechanic changes to simplify the gameplay.
- Game is now quite fun (very similar to final game mechanic).
- Added logic to detect end-of-game condition.
- Changes to underlying board data structures to make things more flexible.
- Added hint animation.
- Added in the concept of brown paint.
- Game no longer fun with current first-pass implementation.

Week 7:
- Balanced the way brown paint works.
- Added in concept of brown paint spreading.
- Game is quite fun again (and is now almost the same as final game, in terms of mechanics)
- Decided to port to iPhone, just to see if I could.
- Prototype ported to iPhone successfully (but no UI, no ability to restart a game after it ends, etc).
- Game uses CocoaTouch and UIKit for now.

Week 8 – 10:
- Working on company website and logo design.
- Other misc business stuff.

Week 11:
- Added special items to the game (water drop + diamond).
- Game much more fun, much better balance.
- Gameplay tuning.
- Fixed major bug in the search algorithms when looking for potential matches for the hint arrow.
- Hint tuning.
- Branched from prototype branch into the main trunk.

Production

Week 12:
- Now working on the game I will eventually ship – no longer prototyping.
- Deleting all the junk code from the prototype.
- Refactoring reusable code.
- Rewriting all the classes that were deleted.

Week 13:
- More refactoring and rewriting.
- Code base is much cleaning and extensible.
- Set up developer profiles, etc, and got project running on device hardware (instead of just simulator).
- Fixed some major bugs in the game logic and UI.
- Created Front End wireframes document to provide to artist.

Week 14:
- Converting game to OpenGL.
- Got the game back up to previous state, but with rendering layer swapped out and now using OpenGL instead of CocoaTouch and UIKit. Game now completely OpenGL-based.
- Adding temporary Title Screen on launch.
- Implemented game mode loading system.
- Did some event handling to disable rendering/update while device locked and handling long update times after unlocking.
- Fixed some bugs.
- Upped number of levels that game has difficulty controls for.
- Set up ad hoc distribution builds.
- Fixed some memory release bugs.

Week 15:
- Fixed bugs in touch handling.
- Implemented audio system shutdown during device lock (was causing battery drain).
- Implemented end-of-game handling to bring up simple high scores list.
- Difficulty tuning.
- Implemented paint “falling” animation and tuned.
- Implemented support for animated textures.
- Implemented paint “match” animation with temporary texture.

Week 16:
- Changed hint logic to pick random hint instead of closest to top-left.
- Adjusting scoring system to take into account special items.
- Implemented “scoring” animation.
- Fixed some bugs related to scaling/translation in animation system.
- Animation tuning.
- Fixed a bug with alpha blending for textures that had alpha in them.
- Fixed some memory leaks.
- Started adding first art assets that arrived from artist.
- Score tuning.
- Implemented score multiplier system for combos.
- Implemented “multiplier” animation.
- Refactored rendering code to separate rendering of individual HUD elements more.
- Implemented progress bar functionality.
- Implemented bitmap font rendering system just for number values in-game.
- Started implementing a Front End framework system.
- Implemented system to load/unload front end screens (i.e. menus)
- Implemented temp main menu to test FE flow system.

Week 17:
- Implemented more of the FE framework system.
- Hooked up the Pause button to load an empty pause menu.
- Added new artwork to the game.
- Implemented tinting for the bitmap font system.
- Implemented UI Widget framework to hook into the FE framework.
- Implemented “Menu” widget.
- Implemented first pass at “Main Menu” using new Menu widget.
- Implemented “Chooser” widget.
- Implemented first pass at “New Game” screen using the Chooser.
- Implemented “Slider” widget.
- Implemented “Checkbox” widget.
- Implemented first pass at “Options” popup.
- Connected widgets in Options popup to control user settings.
- Implemented first pass at “Pause Menu”.
- Implemented first pass at “How to Play” popup.
- Implemented first pass at “Credits” screen.
- Scoring tuning.
- Implemented a user data storage class.
- Connected user data to NSUserDefaults to save out user data settings.

Week 18:
- Added first SFX assets from sound designer.
- Added first music assets from composer.
- Implemented first pass at colourblind support.
- Added high scores to saved data.
- Animation tuning.
- Difficulty tuning.
- Added SFX to animations (e.g. “squish” effect when paint falls).
- Fixed a bunch of bugs and memory leaks in SoundEngine.
- Fixed some bugs around touching the screen during animations.
- Replaced all art in the game that contained text with new art with a new font (font licensing issues).
- Added new match animation.

Week 19:
- Implemented first pass at a “Generic Popup” class.
- Implemented “Quit Confirm” popup using new Generic Popup.
- Implemented system to save the user’s game in progress.
- Art tuning.
- Implemented first pass at “High Scores” popup.
- Hooked High Scores popup into the end-of-game flow.
- Implemented the “Level Up”, “Good”, “Great”, and “Amazing” animations.
- Big bug fix to do with alpha blending to do with premultiplied textures.
- Bug fixes.
- Implemented the Mixing Guide.
- Added new colourblind mode artwork.

Week 20:
- Implemented first pass at “New High Score” popup.
- Hooked New High Score popup into end-of-game flow.
- Added new SFX assets.
- Implemented all of the “How to Play” sub-popups.
- Tuned colourblind mode settings.
- Tuned all the FE positioning values to make sure everything lined up properly.
- Difficulty tuning.
- Started adding real credits to credits screen.
- Added final art assets.

Week 21:
- Christmas holiday

Week 22:
- Created game video captures and created first trailer video.
- Wrote announcement press release.
- Started gathering contact information for PR.

Week 23:
- Added new music assets.
- Added final SFX and music assets.
- Implemented system that allows user to either listen to the game’s music, or listen to their own iPod music. Game auto-detects whether user is playing their own music or not.
- Refactored audio SFX system to allow for easier playing of SFX.
- Hooked up SFX to all FE screens and widgets.
- Added “Tips” popups when user first starts the game.
- Implemented “Reset Tips” system that allows user to reset the tips state to see them all again.
- Updated and tuned the multiplier animation.
- Refactored and removed some dead code.
- Adjusting game initialization settings.
- Adjusted the Generic Popup code to make sure things looked better.

Week 24:
- Implemented first pass at “Timed” game mode.
- Implemented changes to store separate high scores for Classic and Timed modes.
- Added descriptions to Game Modes screen.
- Update High Scores screen to display separate lists for Classic and Timed modes.
- Added new “Game Mode” How to Play popups.
- Added Game Mode tips to start of game.
- Added confirmation popup to Continue button that displays info about game in progress.
- Fixed a bunch of memory leaks (mostly textures that were alloc’ed without being released).
- Implemented “3, 2, 1, Go!” animation for Timed mode.

Week 25:
- Implemented “Game Over” animation.
- Implemented audio warnings for Timed mode.
- Implemented first pass at “Two Player” game mode.
- Refactored most major classes to support a “player” parameter.
- Fixed major bug in the end-of-game detection code.
- Updated all rendering code for Two Player mode to rotate to face the current player.
- Updated all animations for Two Player mode to animate correctly for the current player.
- Update board logic so that tiles can fall in two directions.
- Implemented “Player X Wins” popup for 2P end-of-game flow.
- Optimized board rendering to get rid of some dumb, slow code.
- Fixed bugs.
- Updated FE framework so that FE screens get rotated based on the current player.
- Changed “New Game” confirmation popup to display info about game in progress.
- Animation tuning.
- Difficulty tuning.
- Added new “Board Layout” How to Play popup for 2P mode.
- Implemented “Player X Go!” animation for 2P mode.
- Hid current brush colour while input is disabled.

Post-Production

Week 26:
- Fixed a bunch of audio bugs.
- Fixed a bunch of UI bugs.
- Gameplay tuning.
- Implemented loading screens.
- Modified the sliders so that they are easier to use (bigger touch area).
- Implemented “System Layer” popup support.
- Implemented error popup if corrupt save data is detected for any reason.
- Hooked up save points to a lot more places in the game.
- Tuning score animations to render better when they’re close to edge of the screen.
- Created final icon and iTunes artwork.
- Fixed a bunch of memory leaks.
- Modified some UI widget functionality allowing for more intuitive use of Chooser widget.
- Changed the way the in-game double-tap works to make it easier to play.

Week 27:
- Updated Credits screen to support 2 pages of credits.
- Added Special Thanks credits.
- Fixed a few memory leaks.
- Major rework to SoundEngine.
- Fixed a couple of really obscure SoundEngine crashes that happened extremely rarely.
- Fixed a bunch of memory leaks in SoundEngine on engine shutdown.
- Created a “Final” build target that disables logging and asserts.
- Submitted to App Store!

Owen

I thought I’d take some time and talk in detail about 360|iDev. Overall, let me say this: the conference was fantastic. There were about 200 developers there and there were at least 3 talks running concurrently over 3 days with 5 sessions per day! That’s a lot of great content!

I think the easiest way to do this is a day-by-day breakdown, so here we go!

Day 0 – Sunday, March 1st, 2009

I arrived in San Jose on Sunday afternoon and checked into the hotel. I walked straight over to the eBay Town Hall Conference Center where the conference was being held. Sunday had some “pre-conference” hands-on presentations going on, for those who were able to attend.

Joe Pezzillo from Metafy was giving a great hands-on talk on creating 3 “Hello World” apps in 3 different ways. I arrived about half-way through the session so I just sat at the back and listened. What a great session! Dapple hardly uses any UIKit stuff, so I barely touched Interface Builder when I was working on it. Joe’s session showed me some amazingly powerful stuff you can do in Interface Builder with writing hardly any code! He also showed us some really cool stuff to do with memory management that I didn’t know about before. I was very impressed and knew the conference was going to be great right then.

After Joe’s presentation I ran into Keith Shepherd from Imangi Studios and Noel Llopis from Snappy Touch. We all talk on Twitter and it was really cool to meet these guys in person. Noel and Keith are both awesome and the three of us spent a lot of the conference together, as we had interest in a lot of the same sessions.

Sunday night has a Speaker’s Dinner where us speakers all got to meet each other. Then they opened the party up to everyone and we had drinks and played Rock Band and started meeting other people. I also got to meet Jeff Scott from 148Apps.com, who is a great guy. It was a great way to start the conference. Unfortunately, I was kind of jet lagged, so I wasn’t able to stay up very late that night and went to bed fairly early.

Day 1 – Monday, March 2nd, 2009

I got up really early Monday morning and went for a run with Noel before the conference started. It was great to run in the warm weather and not have to wear a hat or mitts. I kind of hurt my knee, though, so that was the only day I was able to run while I was there.

The first session of the day was two keynotes: one from the lead researcher at eBay (whose name I forget…sorry) and another from Mike Lee. Mike’s presentation, in particular, spoke to me as he discussed the need for the iPhone development community to work together and act as a community.

Next up with Julio Barros’s talk called “iPhone and Android?” He talked mostly about the differences in the way apps are created and distributed. It was a neat talk with a lot of questions and discussions that resulted. It’s clear that a lot of iPhone devs are considering Android as an alternate platform and wanted to know more about it.

There was a break for a delicious lunch, where I got to meet a bunch more people, like: Peter and Mike from ByteClub, Chuck Smith, Collin Donnell, Mark Johnson, and Julian Dolce from Fuel Industries (who are based in Ottawa, Ontario). And after lunch I gave my talk. I was lucky enough to be able to give a presentation on the creation of Dapple, the processes I used, and the lessons I learned. The room was nearly full for my talk and a lot of nice people said that they enjoyed the talk a lot.

Right after my talk I went to see a talk on the Unity Engine. The guy who was supposed to do the talk couldn’t be there so 4 students from a local game design school who are working at eBay gave a talk on Unity instead. They had been building a game in Unity and spoke very well about Unity and their processes.

The final talk of the day that I saw was by Scott Michaels, from a Canadian company based in Vancouver called Atimi. This was the presentation that people talked about for the rest of the show. He gave an in-depth and knowledgeable talk on marketing as it relates to iPhone apps. It was full of useful information and recommendations and I was blown away by it. It really showed me how little I understand about marketing. I started thinking about hiring a freelance marketing consultant at that point.

After that there was dinner, talking to lots of people, beer, and more Rock Band. By the end of the first day I was already convinced that the conference was worth more than the price of admission.

Day 2 – Tues, March 3rd, 2009

Up early again, but this time I met up with an old friend of mine I hadn’t seen in about 15 or 16 years. He lives in San Francisco now and I was nice enough to drive out to San Jose and meet me for breakfast. It was cool to get a chance to meet up with him after all these years. However, as a consequence I missed the first slot of speakers that day.

I arrived in time for the second slot and sat in on Tim Burks’s “Deep Geek Diving into the iPhone OS and Frameworks” session. This was a fascinating talk about how to dig into the underlying core APIs and see what’s available. There’s all kinds of cool stuff that Apple doesn’t allow developers access to, and this was just a look at what’s there that we can’t use yet. It was kind of a tease actually…look at all this cool stuff that’s available! But you can’t ship an app on the App Store if you touch this stuff… Still, a great session.

Lunch time again, more tasty treats. More chatting.

After lunch I attended Noel Llopis’s (Snappy Touch) talk on “Becoming Indie: A Professional Game Developer’s Change to the iPhone”. It was a great talk and I learned a whole bunch of information about iPhone hardware. I wish Noel’s talk could have been twice as long as there was a lot of stuff he talked about that I would have loved to have seen more on. Noel is also a huge proponent of unit testing and talked quite a bit about it in his presentation. It’s definitely something I need to do more of.

Next up with Peter Bakhyryev’s (ByteClub) presentation on “Making Multiplayer iPhone Games: Theory and Practice”. Peter had a great talk, mostly concentration on all the things you need to take into consideration when you’re designing a multiplayer game. This talk sparked dozens of ideas for new games or multiplayer extensions to Dapple in my head. I spent quite a bit of time talking with Peter and Mike at the conference and they’re both great guys. They’re doing some really cool stuff around releasing a multiplayer gaming framework.

The last talk of the day was Jonathan Saggau’s (TouchEngine) presentation on “Connecting iPhone to Google’s App Engine”. I made a bit of a mistake here and assumed this would be much higher-level than it was. The started his talk assuming that everyone knew what “The Cloud” and how Google’s App Engine worked, and so most of the presentation was kind of over my head. It wasn’t until later that I realised the talk was a 300-level talk, meaning it was an advanced topic. Oops. I’m sure it would have been cool if I’d already known how to use App Engine.

Dinner, more beer, more networking. Met some more people. Back at the hotel I ended up in the lobby with a bunch of people talking about iPhone stuff. It turns out I was talking to one of the guys who first jailbroke the iPhone, as well as the guy who wrote Cydia (saurik). They were really interesting to talk to because they have a very different perspective on things.

Day 3 – Wed, March 4th, 2009

Another early day…got up to make it to the keynote presentations. This time by Eric Litman from Medialets and a guy (whose name I forget, sorry) from AdMob. They both talked about analytics software and advertising in apps. They were neat talks. The AdMob guy talked a lot about monetizing apps by ad-enabling them, which I have no interest in, but he also talked about how I could run ads in other apps. That’s something I might look into at some point.

Next up was Sean Christmann’s presentation on “Powerful Visuals with Quartz 2D”. I didn’t know much about Quartz 2D, so this was a really neat presentation for me. I learned a lot about how it works and now I want an excuse to play around with them.

Final lunch break.

After lunch I went to Danton Chin’s “Managing and Optimizing Memory Usage”. I had hoped that this talk would be a little more in-depth, but a lot of it covered the same kind of stuff I’d written up in my Leaks Tutorial. I think it would have been a great presentation if I didn’t already know how to use Instruments to track down memory leaks. However, I did learn some things about using the Static Analysis to find mem problems at compile time.

Next I popped into a talk being given by Jeff LaMarche and another guy whose name I forget (sorry) on Open GL and the iPhone accelerometer. The accelerometer stuff was quite neat, but the OpenGL discussion kind of got side-tracked by people asking a lot of questions about how it works. OpenGL is difficult to learn in an hour. It was still a good presentation, though.

Finally, the last presentation of the show I went to was Dom Sagolla‘s “Why a Dollar?” presentation. His was about why his company only releases $0.99 apps and about the process he uses to create these apps. It was interesting to hear his point of view and to see how he does it.

With that, the conference was over! There were a bunch of us who weren’t flying out until the next day so we headed out to a Mexican restaurant for drinks and food. The conference organizers, Tom Ortega and John Wilker, were there too, so it was cool to get to hang out with them a bit. I also spent some time talking with one of the guys, Azeem Ansar, from PinchMedia, which was cool, as well as Mark Thomas, who had flown all the way from the UK for the conference.

After that, I went back to my hotel, exhausted from all the excitement and brain activity. I was up bright and early yesterday morning (4:30am) to get on a plane back to Ontario (via Chicago of course). Today has been kind of a wash. I’m having trouble concentrating as my brain tries to sort through all the amazing things I’ve learned this week and all the things I want to do in the future!

If you weren’t able to make it to 360|iDev this time, I highly recommend it. They’re talking about doing another one in 6 months, but possibly further East. When tickets go on sale, get in early!

Owen

I had an extremely productive couple of days and finished off the 2 Player Mode last night. There are still a few small things to add to the game (a few animations to spice things up in places), but all the big features are finished. At this point it’s finishing up the last of the polish items and then it’s tuning, testing, and bug fixing until submission!

My original plan was to declare Alpha by the end of December, but then I decided I had time to implement Timed Mode and 2 Player Mode. I’m really glad I spent the time to add these modes; they add so much to the game. I really feel like I’ll be able to justify the price-point I’ve been mulling over in my head (more on that later). Given that I added two game modes in the last 3 weeks I’m feeling pretty good at declaring Alpha today.

The plan now is to wrap up the last of the polish tasks and fix the bugs I’m aware of by mid next week. At that point I’ll declare Beta and send out a Beta build to everyone who has signed up for Beta Testing.

I’m still looking for more Beta Testers. If you’re interested, please send me an email (info AT streamingcolour DOT com) with “beta test” in the subject. There are full details in this previous post.

Unrelated to Dapple, I wanted to share a few links that have been sent my way over the last while:

• AppTheater (www.apptheater.com) – A site that collects videos of iPhone Apps. If you want to see what an App is like before you buy it, look for a video here.
• Oolong Engine (www.oolongengine.com) – Noel from Snappy Touch informed me about this freely available simple engine for iPhone. It looks to me like it’s based off the code from Apple’s (now removed) CrashLanding example project, but they’ve added all kinds of handy functionality. I wish I’d known about this 6 months ago…

Oh, one final note: I contacted the TTC (Toronto Transit Commission, for those outside Toronto) about advertising on buses and subways. They sent me some pricing information and I’ve realised that the old adage “you need to spend money to make money” is so true. There should perhaps be a corollary “you need money to make money”. I’ve realised I can’t afford to do that kind of physical advertising until I make some money. Ironic, ain’t it?

Owen