Incoboto Post Mortem - or 'How to Make Development Difficult by Being Stupid'.

Introduction

When I started of making Incoboto, I knew I wanted to make something that reminded me a bit of Exile (old BBC game), a little of Ico, a smidgeon of Pixeljunk Eden, and a heap of 'Space Alone', the animation by Ilias Sounas.

I knew the game was going to be side-on 2D, and I knew it was going to feature round planets because that's what I'd drawn on a little pad of paper, so it had to be true. The other thing I knew was that I didn't want it to be a violent, shooty-game, not because I have a thing against videogame violence, but because - after being in the industry for a stupid amount of time - it has begun to bore me. Quite what was going to replace it, I didn't know.

Incoboto took 22 months from start to finish. In that time it moved from being a Roguelike random-planet with random puzzles thing, to (thankfully, very briefly) a shooter (ack), to it's final 'Portal-like' explorey-physics-puzzle formula. The process was painful, a little stupid, and the negative bits were largely avoidable. 

I think it's about time I made some of these learnings available to the general public.

Incoboto - A Post Mortem

What Went Right? 

1) Develop and Maintain A Strong Aesthetic

Luckily for me, I found Ileas Sounas's profoundly moving animation long before I started Incoboto.

It had a huge effect on the game's style, and its influence meant that, from the start, it was a game about space, about friendship, about mystery and loneliness. At any point I could hold up a screenshot of the animation and say, 'I want it to feel like that'. 

(Note - this is quite different from just 'looking like that other thing'. You need to know which aspects of the work are important to you, and use those as your baseboard rather than grabbing the whole thing and claiming it as your own, blindly. That is plagiarism. Someone once said that "Plagiarists borrow, geniuses steal." That only makes sense if by 'steal' you mean 'change it so it is clearly yours now,' and if by 'genius' you mean 'plagiarist with a clearer view of what's important'. I digress.)

Space Alone and Incoboto, or 'Depressives Inc.'

Takeaways: If people find a character (or anything else, really) in your game really appealing, that is rare, and incredibly valuable. Don't squander it.

First, Try to figure out exactly what it is about that thing that appeals. Don't let stubbornness or an attachment to some other contradictory element get in the way of it, because you may find you never find anything else your audience likes as much! In addition, if the alteration would match your theme better (as it did in this case) then you should be even more wary of intractability. 

3) Know Your Limitations (and Use Them)
I can't animate. I don't mean 'I animate badly'. I mean, I can't animate. At all. Despite this, I wrote a script for Blender that allowed me to export any animations I made (presumably by magic) at a fixed framerate to a simple text file. The file takes scaling and rotation information from the timeline curves and exports them in absolute units.  In the spirit of sharing, here it is for anyone who is interested:

DeneBlenderAnimExporter.py

Feel free to use it if you need this kind of thing. It works and is quite useful. On the other hand, I only used it once (for the doors of the Power Orb machines). The truth is, animation isn't in my nature. Coding is. As a result, I was driven toward things that were physics/simulation-orientated, and preferred to code them all from scratch. Indeed, part of the reason that Inco is so small on-screen is that I couldn't animate him properly.

Likewise, when making the art, I knew that detail wasn't going to be my strong-point, and so chose a style that de-emphasised detail over shape/silhouette - especially the nice, curved, mathematical lines of planets. 

For those who are interested, my entire 4k wide sprite-sheet for all of Incoboto's 4-hour journey is here.

Incoboto Sprite Sheet

If you download the bigger version and look around, you'll notice there is only one animation. It's buried somewhere at the top. Inco's legs go together ...and then apart. It's 2 frames. Pathetic, isn't it? Now do you see why I kept him small? (Do not look behind the curtain...)

Takeaways: You will work harder, and longer on stuff you enjoy and are good at. If your game demands you do something that you're utterly terrible at, find a way to twist the game to play to your strengths, or find someone else to do it... unless you really want to learn that skill. But still - really - do you have time to teach yourself that. Now? Really? Wow. 

4) Talk to People During Development, or 'Be Humble'

Indie game development can be maddeningly solitary. If you live by yourself most of the time, it's easy for things to become distorted and warp out of perspective. Like an annoying facial blemish the day before a big social engagement, flaws in your game can feel like they eclipse every single good thing about your work. It can lead to you wanting to lock it in a dark room until it's finished. The newsflash here is that if you do that, you're much less likely to finish it. 

Every couple of months I'd show Incoboto to someone who played games. Some played a lot of games, some people played very few games. The reactions Incoboto evoked varied:

a) "This looks cute, but I have no idea where to go, or why, and this camera makes me nause... bleaaaaargh! Oh. Sorry."
b) "Hmm. Zelda did this better."
c) "Hey! This is awesome! It's the best thing ever!"

Guess which one was the most useful? It's a trick question: the only one that sucks is c) because it tells you nothing apart from the fact that some people really don't want to hurt your feelings. They are nice. They are good people. They add no value to your work. They might give great hugs though.

Every time someone picked up Incoboto and said something about it sucked (or they gave a 'compliment sandwich' - 'Nice iPad. Game sucks. Weather's great!'), I drilled down on exactly why it sucked. If they were vague, by God, I'd force them to be precise. If they were precise, I'd make damned sure I had really understood their problem, and ensured they'd been precise about the right things, and weren't misinterpreting their own reaction. Yes, it gets complicated. 

In some cases there are translations to be made:

"It is too hard" => "I didn't have an easy win quickly enough": Fix: Give them a mini-goal
"I'm bored" => "I don't know what to do." Fix: Make sure the next mini-goal is signposted.
Etc.

The bottom line is that the player is almost never at fault. On those odd occasions when they are at fault (say, because they are too stupid to use consonants or close their mouth in the presence of flies), you still have to make a decision as to whether you want that person to give up on your game. You may, but you should probably set your bar really, really low, lest you risk being the only one prepared to play your quirky personal opus.

The most important feedback I ever received was from my wife, who said at one point: "Undelete it from your trash. It's fine. You just need to repeat that level's gameplay 10 times, and you've got a finished game." It was the work of about 4 producers packed into one tiny soundbite. It was obvious, but I was too close and I couldn't see it.

The rest is history... well, more like 6+ months of punishing level design. But some history, too. 

Takeaways: Let people play your game, even super-early-on! Don't be precious. Listen 'deep' (i.e. try to figure out the cause of vague statements you hear made about your fledgeling work). It's like being single. You'll never find Mr/Miss Right by sitting at home. Unless you're having a WoW relationship. Or have romantic inclinations toward rodentia and live in London. Ah, those were the days...

5) Press and Marketing
As my previous game, 'Flaboo!', rapidly disappeared into the App Store bin once the initial hype had died down, I decided I'd pay a PR firm for some help with press engagements for launch-week this time around. Despite their best efforts, the results were disappointing.

In all but one interview, the interviewer switched off as soon as they realised I wasn't there to 'spill the dirt' on Lionhead or any of my old friends still working there. Several had neither played the game, nor even bothered to pretend to look at it during the interview, even when prompted with a not-so-subtle: "Um... shouldn't we really be talking about Incoboto, now?" One interviewer in particular left such an odious impression that I will actively ensure I never have cause to interact with him or organisations hiring him ever again.

On the flipside, one interviewer from a major site (which gave Incoboto a Gold Award the day before) not only played my game, but actually had questions about it. He was a joy to talk to, and nearly made the entire experience seem worthwhile.

However, the overall outcome was that the PR spend had no effect whatsoever on the sales of the game, referrals to my site, or any other tangible benefit.

Incoboto has sold around 30, 000 units at full price ($2.99, down from an original $3.99 - I will never put the game on sale, nor make it free). On the other hand, that's pretty decent considering how few units many games sell.

The reason I sold even this many is largely down to one single thing: the guys at Touch Arcade. 

I did a vague arm-wavey pitch on the forums there early on, and tried to maintain a semi-mysterious relationship with the members. I never gave out too much information about the game, and provided just enough teaser-info to keep people somewhat interested as time went on. Here's a link to how I approached it in the July before the March release. (Apologies: I tried finding the initial posts I used to garner interest early on, but they seem to have gone away once the game was actually launched)

By the time the game had Beta-testers from the site and I'd prepared a few more shots and a YouTube video, there was quite a lot of interest. The site actively watches its forums, and they followed up with a couple of articles and an interview, all of which helped raise the hype more than any amount of paid PR.

This hype, in turn, seemed to give Apple confidence that the game was worthy of note, and - after telling them more about the rather unique controls - it was featured that week. 
(As a side-note, it was pipped to the top-billing by Waking Mars - a similar-themed explorey-space game with no real violence. It's a great game, but I'm sure their sales were significantly altered by the relative prominence of billing! You have zero control over this kind of thing as a developer.)

Since then, Incoboto has been featured twice more by Apple, first in the category of Best of 2012, and later in Best Platformers.

The game launched in March 2012, and even now the game averages sales between 500 and 1300 units a month, spiking with events like seasonal holidays, new iPad releases and so on.

Being part of the 'Best of 2012' campaign had a x5 effect on weekly sales.
Being included in 'Best Platformers' has a 1.5x effect on weekly sales.

Takeaways: Making any money in the indie scene is a lottery. On iOS it is even moreso. You can increase your chances by:

Okay - time to get all negative. Boo.

What Went Wrong?

1) Physics and 'Not Built Here' Syndrome
You'll have heard the term 'Not Built Here' before. Bear with me.
I started making games in the '80s, and - having worked in AAA for too many years - have an instinctive revulsion to using other people's work to make my own games. This caused particular trouble for me where physics was concerned. 

Early on in 2006 I started playing around with Verlet Integration (partly inspired by Mark Healey and Alex Evans' work on Rag Doll Kung Fu). I eventually found my way to this Gamasutra article and began playing around with physics for fun.

By the time I got to the point of making Incoboto, I was fairly comfortable with chains, ropes, rubber bands and the rest. But not collision. This was to prove a major slowdown, and an enormous impediment to progress. How apt.

Incoboto features rotating planets. These planets have their own gravity. 
I break that gravity at various points: when swinging on a chain, when using a jetpack, when changing planet etc.
These planets also have atmospheres of a density sufficient to emulate friction.
I break that friction at various points: when swinging on a chain, when throwing objects, when changing planet etc.
I break the 'standard' usage of these systems a lot. As a result, when my physics started to fall apart under pressure, and I became desperate enough to look for middleware, I had already made the foundations so reliant on the peculiarities of my game that retrofitting it became next to impossible.

For those who care for the details, Box2d's speed relies on the concept of things eventually coming 'to rest' i.e. no longer requiring processing. In a game where planets are rotating, and orbiting while rotating, this seemed a poor fit. All my kludges broke things in horrible ways that I didn't understand. 

I gave up after about 2 weeks and returned to my old, broken code feeling sure that I'd somehow committed an act of self-sabotage. While my physics worked eventually, it took a very long time to become useable in the wide range of scenarios necessary.

The entire physics for Incoboto is here, written in C. This physics does not use any rotations at all, yet everything 'physical' in the game rotates! All rotations are faked using the reactions of the verlets (bizarrely successfully). It also does not handle box-box collisions. You'll notice that there are no box-box collisions in the shipping game, only circle-box and circle-circle.

The overall time-cost for the physics was probably about 4 months.  99.9% of that was trying to fudge and kludge my way around the various edge-cases that kept appearing. It was maddening. It was stupid, and compounded by a second stupidity.

The first was was deciding that this specific game needed an equally specific tailorable physics engine.
 
The second was deciding that the physics had to deal with every single edge-case imaginable because I didn't quite know what game I was making. In truth, my physics was probably 'Good Enough (tm)' long before I'd finished with it.

Takeaways: 

2) Stubbornness and the Paying Audience
This is the flip-side of 4) in the 'What Went Right?' segment above. At one point during development I decided to go with a very, very new movement system. It's the one the game shipped with. I love it. It is the one Limbo now uses on iOS. To jump, you leave your finger on-screen, and nudge it slightly upward. You don't swipe, you nudge.

When I tested it on people, many hated it and asked for a joystick. I was appalled. To my mind the solution I had found through numerous rewrites was elegant, suited the game, more streamlined, and... well, just 'better' than an ugly on-screen-fake-analog-stick. 

My reaction was to do two things:

1) I allowed people to tap to jump, as well as nudge.
2) I begrudgingly added an on-screen joystick mode. I kind of hid it.

If I'd just allowed people (who were paying money, remember) to choose a control style they liked rather than forcing them to use the one I deigned worthy of my game, I'd not have added the tap-to-jump, and would not have hidden the joystick option.

This would have resulted in two things:

1) Nobody complaining about my 'weird' / 'scary' / 'unfamiliar' controls.
2) Nobody accidentally jumping when they meant to click on something.

I believe these would have increased the overall satisfaction with my game, and the fault lies entirely with me.

Takeaways: Remember what I said about not being precious? That. In fact, as a life strategy, I think everyone should be taught the following at school:

"When you are about to say, or do something, imagine the best and worst (likely) results from the action. If the weight is in favour of the negative, don't do it. Yes, I know it seems bloody obvious, but engaging this bit of the brain when it doesn't want to be engaged is hard, requires 'training' and will stop wars. You want to stop wars, don't you? No? Oh, right. Sorry, Mr Blair, didn't see you there."

3) Missing Your Own Wave
When Sworcery launched on iPad, Capybara launched the iPhone version more than a month later. Thus, I decided that a staggered approach was 'The Right Way to Do Things', and that it 'Would Work For Me' and that I'd 'Use Too Many Capitals and Quotes'. What I hadn't factored in was that:

a) Sworcery was PHENOMENALLY SUCCESSFUL and could thus afford this lag - if not a far longer one.
b) Missing the wave of your own successful game is stupid if you ever even remotely plan on releasing for another device using the same discovery/marketing portals!

Now, this was complicated by the fact that I wasn't sure I believed I could make Inco for phones: the main hero was tiny, the game's physics was expensive in terms of processor-cycles, and... if I'm honest... I'd grown used to the rather mature, pleasant people who buy games for the iPad (by comparison with the wider-demographic group on mobiles, who are... more volatile).

As a result, despite the massive number of iPhones in the world, Incoboto sold less than 10% of my iPad sales numbers. Is it an inferior game? No. I put a lot of work into making sure it was rejigged, stripped, reworked and ultimately suited the iPhone. But 9 months is a long time, and if you are never featured (as IncobotMini wasn't) then  you're just in the pool of random games people might happen upon, and discovery becomes a huge factor once again.

Takeaways: Think long and hard about your target devices. If you're one of the small number of mega-hits properties out there, you can do what you like. If you aren't, you want to make sure you group launch or even sim-ship. Otherwise, you risk wasting several months of dev-time on a conversion that few even know about, let alone play.

4) Faith
Incoboto was always designed more as a Nintendo love-letter than as a money-maker. I tried to maintain a clear artistic vision all the way through, and generally rejected stuff that didn't fit perfectly. As a result, for the longest time I had no game mechanics, bar tactile movement.

Every time I decided to move in a direction that would clarify the game a bit and which might look like progress to an outside observer I'd wince, suck my teeth and say: "Well... that bit has been done before."

What I failed to note was... well, the thing Southpark once observed: "The Simpsons Already Did It."

If Mr Blow had listened to people pointing out the similarities to Mario, Braid would never have been finished.

If Mr Fish had listened to people pointing out the similarities to... Paper Mario, Fez would be... well, like Fez 2.

Takeaways: Remember that bit I said in the 'Right' section about authorial voice and aesthetic? That is really, really important, and should govern your decisions... and allow you to relax a bit! Not every single feature you put into a game has to be 100% original. Even if you think it is, it's probably not. Whatever you put in will be coloured, shaped and interpreted by your authorial voice (if you've developed one).

I made a version of Flaboo! in 2005, long before Doodle Jump came out. I called it 'Bounce', and it ran on a Nokia phone with a (gasp) colour display. It was a cool little game I released to friends and family.

When I was remaking Flaboo! for Android, Doodle Jump was released and - within a couple of months - the 'endless jumper' became a new gaming trope. It was disheartening to realise that a genre I believed I had invented had been taken away from me, and Flaboo! would now appear to be the latecomer...

...until someone pointed out to me that there were precedents for this format of game long before Flaboo!

If LimaSky had listened and reacted to the same information, they may well never have released DoodleJump.

Whatever you are doing, if you have a clear, fresh authorial tone, it still has value. Have some faith. And some fun.

5) Stupid, Stupid Youtube Mistake

One last note. It's an obvious one, but I fell foul of it. If you upload a YouTube video, and you see any corruption, it is probably due to encoding, not playback. Upload a fixed version before thousands of people watch/link to it because you can't change it once it's there!

Takeaways: I know you're bored with your video. I know you've spent a week editing it together after the pain of capturing it all, but watch your YouTube video ten times before sending out links. I know it all feels like a huge annoyance, but it's less aggrieving than seeing that same slight glitch every single time someone uploads a review of your game and shows off the video. 

Conclusions

At this point, most people would go into a long diatribe about how many units were sold and and how successful and blah blah. I've already kind of used those bits up in the preceding sections. Sorry. 

Overall, I'm really proud of Incoboto. It was as solo an effort as one can be, and I'm glad to have made it. I was really quite touched by the Bafta nomination. I am occasionally delighted by a nice mail from a fan. Not often, but sometimes.

It points out one flaw with taking 22 month to make a game linear puzzle game at this period in time, for this modern audience.

One-Shot Games, and The Future
Adventure and 'proper' puzzle games (i.e. not 'match 3'/Tetris clones) are one-shot games. Peopleplay them, finish them, and forget them. They may remember them fondly, but their relationship with them is closer to a torrid fling than a marriage. Personally, I'd like to avoid that in future, as it's quite disheartening to work on a game for so long, see it peak, then fade to relative obscurity, mostly due to its inherent one-shot puzzley nature. 

My next project is my attempt to address that. The name is BeMuse because I want to enter into a dialogue with players from an early point, to get them involved, to get them talking, to have an interest and an effect on my game. In short, I want my players to become my muses. More on this with later posts.

If there's any aspect of development people would like me to cover more (or less), feel free to contact me through the Fluttermind site, the forums or anything else. 

Thanks for reading - I know it's been long and a lot of you will have thought tl;dr. 

Follow Dene Carter's 'Fluttermind' blog at http://www.fluttermind.com. 

@Fluttermind