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

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, and I knew it was going to feature round planets because that's what I'd drawn on a little pad of paper. 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 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 briefly) a shooter, to it's final 'Portal-like' explorey-physics-puzzle formula. The process was painful, a little stupid, and 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 isn't quite different from just 'looking like that'. 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. 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 vs. Incoboto. Fight! Oh, actually don't. There's no point. Everyone's dead.

When showing people early builds, they were able to 'get' the mood of the game, even when they didn't fully understand the structure or the detail (and, frankly, nor did I). This was critical, and gave the game a foundation which could not be undermined, even on the darkest, self-doubty of miserable, solitary days.

Takeaways: The importance of a cohesive style cannot be exaggerated. The game's visual style was critical in gaining interest. Style utterly overshadows any other USP. It also completely eclipsed any perceived value in my background or any perceived past contribution to console gaming. 

I'd say that if you're a budding indie, this is probably the most important thing you can do. This does not even mean 'pretty'. It means, firm, resolute and defiantly 'your own'. Minecraft isn't popular because of its beauty, but because of its gameplay and sense of place, largely driven by its assured comfort with its own blocky identity.

2) Strong Characters, Understanding Their Appeal, Treating Them Appropriately
This is almost an extension of 1. 

I was lucky enough to have had a weird caffeine-dream in Amsterdam a couple of years ago. Through a fug of pounding blood and an urge to twitch, incessantly, I had the vision of a sunny face peering between large structures. I knew that, one day, I'd make a game featuring a big, smiley sun as a central character.

What people don't seem to realise is that, originally, he was intended to be an insane, mercurial bastard who would ask you to do weird stuff, just to piss you off (there is absolutely no link between this and any element of any other project I have ever worked on).

He was my version of Katamari's 'King of Infinite Space', but cheerier and madder. Once he was in-game, every time people saw him, they smiled.  He used to be in the centre of each solar system, and would pan around the screen in the background as you explored the region. This meant he was off-screen for about 90% of the time. 

I had taken something that was almost universally appealing, and neutered it through not understanding what he added: comfort.

At the point of realising this, things needed to change, and as they changed, there were many critical knock on effects:  
As Helios needed to be more visible at all times, I made him hover above you, and altered the camera to keep him in view. 
As soon as I did this, he immediately seemed like a friendly pet, rather than an antagonist. Doing anything else with him would have been a mistake. Only at this point did the game start matching my original thematic intent.

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

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 animations 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 my new ethos, 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 sprite-set for all of Incoboto's 4-hour journey is here:

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're living largely by yourself, it's easy for things to become distorted and shift 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. 

Every time someone picked up Incoboto and said it sucked, I drilled down on exactly why. 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. 

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. When they are at fault, 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 might, but set your bar really, really low).

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. 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.

5) Press and Marketing
Let me be honest and say that Incoboto hasn't sold a bazillion units. It has sold around 30, 000 at full price ($2.99, down from an original $3.99). On the other hand, that's pretty decent considering how few units many games sell. I'm sure you think you can do better. Since money isn't a zero-sum game, I'd be more than happy for you to do that. Please, be my guest. Do it now!

The reasons I sold even this many are largely down to one single fact: 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. This, in turn, seemed to give Apple confidence that the game was worthy of note, and it was featured that week. (It was pipped to the top-billing by Waking Mars - a similar-themed explorey-space game with no real violence). I harbour no resentment toward them at all (go buy their game!) but I'm sure the difference in sales was significantly altered by the relative prominence of billing.

Since then, it 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, fluctuating with things like seasonal holidays etc.

Best of 2012  had a x5 effect on my sales.
Best Platformers has a 1.5x effect on my sales.

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. Upload it again before thousands of people watch it because you can't change it once it's there!

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

• Engaging (a decent sized) community early and often. Bring them into development and they'll reward you more than isolationism. No, really.
  
• Ensuring your game uses as many of the device's key features (multi-touch etc.) as possible. No platform holder is going to push a game that is likely to be available everywhere, for everything from day 1, and doesn't show off how cool their stuff is. The only reason they are pushing your game is that they have an agenda: to sell more of their stuff. Help them do it!
  
• 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. 
  

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. 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.

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: 

• Don't try and write everything yourself if you don't need to. I know it's obvious to most people, but to some of us, a wrapped-up system is unknowable and thus suspect. Remember: for every moment you spend integrating another popular package/middleware in your game, you'll probably spend many more debugging the fundamentals in your code, things that middleware creators have already dealt with through countless revisions and feedback.
  
• Don't try to generalise too much! I wasted months trying to get box-box collisions being robust enough to ship... and then made an entire game where they weren't necessary. Don't do that. It's silly.
  

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 about 6 months later. Thus, I decided that this 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 to do this.
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 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).

As a result, despite the massive number of iPhones in the world, Incoboto sold less than 10% of the iPad's 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 and One-Shot Games
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: 

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 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.

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. 

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.

Puzzle games are one-shot games. People play 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. I'd, personally, like to avoid that in future, as it's quite disheartening to work on a game, see it peak, then fade to relative obscurity, mostly due to its inherent one-shot puzzle nature. 

BeMuse 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 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.