Hello. It's been a while, hasn't it? I have reasons and excuses, but most of them aren't really very interesting. No, really. I mean it. Nothing to... 

...okay, I'm lying.

Since September, I've been building bits of this game, trying them out, rewriting them, trying again, refocusing on some different aspect of the huge design and then coming back to do that little circuit all over again. 

As this was driving me insane, I also decided to learn how to model in 3D which ate another chunk of time. 

I promised I'd try and make this blog useful, and I intend to keep that promise where possible. This involves making the world aware of when projects go a bit wrong, rather than always focusing on the positive, and hopefully help people avoid the same pitfalls.

Everyone knows what a Turducken is, yes? That weird thing served in the US at Thanksgiving to illustrate quite how a massive cull of wildfowl can be crammed into a single dish? Some people think it looks delicious. To me, it looks kind of like the world's worst Star Trek transporter accident, or a deleted scene from The Fly 2. 

Some people claim it is delicious. I am not convinced. Due to this, I am sure nobody in their right mind would think it a good idea for me to try making one. Bear with me. This is relevant. BeMuse has/had become somewhat of a Turducken. And we all know what the first syllable of that is, don't we? Not good. At last count, BeMuse was about 5 different games:

- Demon summoning, bargaining and defeating
- Exploration, secrets, rumours and lies
- Personal interpretation of rituals
- Multi-user Interaction
- Endless gameplay

Trying to massage these into a whole, solid thing has been extraordinarily painful, and has resulted in a messy concoction that is going to take more effort to straighten out than I have time to implement those changes. Nasty. After my experiences with Incoboto (which had turned into a Roguelike at one point, remember!), I swore I'd never do this again... and yet have done it again. 

As such, I have decided to focus my efforts entirely on the first two.

This is easy. 


"DO NOT TRY TO EMPHASISE EVERY PART OF A MULTI-ASPECT GAME"
or
"KNOW WHAT YOUR GAME IS REALLY ABOUT!"

I am better at creating linear experiences and mood than I am at developing complex, interacting systems. Despite this, with BeMuse I had five aspects of the game competing with each other, daily. My notion of creating a complex system was to try and get lots of elements of the game in... and to a finished level of quality. Yes, I know prototyping isn't supposed to work like that, but just one more hour and this inventory system will work really nicely!

Of course, this idiocy also leads you to start believing that every part of the game you start working on is the most important. I have no other partners working on this project, so there's nobody to say, "Hang on... why are you spending so much time on that?" The net result is that it's easy to start 'cycling'. As each new part of the game is emphasised, all the others get pushed out of the way, broken, or mistreated. One glance over your shoulder and you say: "Crap! Must go back and fix those bits... and polish them... and..." It is the very definition of a vicious circle.

This can all be avoided by knowing what ONE thing your game is about. If you think it's about more than one thing, you're probably wrong... or bolting two games together. 

Competing foci pull a game apart.

"BeMuse is the story of a small child who learns about the Demons that inhabit his world, and slowly learns to defeat them through exploration and ritual magic."

or

"BeMuse is a series of stories framing opportunities for experimentation and discovery."

That's it. Many of the other elements of the game as described previously are still present, but if they get a bit broken along the way, I shan't worry too much, because the game is about stories.

And that is enough.

I'll leave you with a totem illustrating four of the major demons in the game. I shall not tell you their names, as they are words of power (and spoilers!). I'd hate people to be eaten from the inside-out by tiny spiders they inadvertently summoned up. That would be bad.

If the game works out, I may well get this tattooed onto my right arm as a reminder not to lose focus quite so badly in the future. Thanks for your patience. 

A small blog today (I know, I know, 'Halleleujah'). Today is battle day. 

As I have said, previously, I am not keen on random shooty-stabby violence at this point in my career. It is dull. It is easy (or as easy as anything is when making games). I'd rather not engage with it... unless there's a twist.

The twist, in BeMuse's case is that every tricksy, evil entity in this world has a 'name'. Names are made from several words of power. Anyone remember the 'Weirding Module' in David Lynch's movie adaptation of Frank Herbert's 'Dune'? That. Today is the day all of that goes in properly. Wish me luck.

Names are both a weapon and a weakness. A Demon's name also shifts over time. Is it because their names are long, and they only reveal small segments at any time, or are Demon names constantly shifting by nature? Are they linked to outside forces? Who knows. I'm hoping folks will lie about these things sometime.

In the meantime, I'll proffer the latest screenshot.

Edit: the battle system works! Tomorrow, feedback and polish.

The Endless
So, BeMuse isn't finished, yet. In truth, it's barely even started. There are reasons for this beyond the usual. 

Part of my slowness is from moving to Unity, fresh from having developed a library of stuff that did exactly what I wanted, exactly how I wanted, predictably, reliably and understandably. Now I have to do it all again, while constantly guessing why someone would do stuff like 'let's give the angle between two vectors A and B on a plane as always positive'. Ugh. (The solution is here, incidentally)

Part of my slowness is that I don't want to make 'just a game' this time around. Ideally - I don't want the player's experience of my world to end. I want to build something huge, and beautiful, and strange - a place to be inhabited rather than a simple collection of rules to goals to interpret and beat.

It turns out that this is hard.

Art Vs. Content.
It seems to me that the more content you put in a game, the less artistic it is perceived to be. It's like there's an agreed-upon continuum all the way from 'There's nothing to do - it's meaningful art!' all the way up to 'There's so much to do - it's just a game!'

If you're at one end (Proteus, Dear Esther, Journey, Limbo, Sworcery) then you're artistic enough to have established a world people are just happy to reside in for a while, and you leave it at that. Job done.

If you're at the other end (Zelda, Nethack, Minecraft) then you put in as much content as possible and are thus gamey enough to satisfy gamers, but somehow lose any potential artistic merit... because you're too much of a game (the development version of the 'friend zone').

If you disagree, just imagine Limbo with a hookshot. Go on. Imagine it. Right stick, angle it just right, press the right trigger: 'Whoootish!' Yay! Got to that tree top! Oh, dear! The 'fun' just destroyed the 'art'!

In the middle-ground between these two is the 'Zone of Meh': games which may have been developed with artistic intent, but where the form and nature of the play have colluded to make it too 'fun' to be 'serious'... or conversely not quite 'big' enough to be considered a 'best of breed' game. Incoboto sits here.

All silliness aside (and I'm really not serious about this graph), there's something to be said for understanding your own motivations, and how perception of content works in the current culture of gaming.

If you aim to produce something 'meaningful' you have to think long and hard about your content, and ensure that every single aspect of your work reflects that, or else is cull it. It is the opposite from my usual 'Kitchen Sink with a One Man Team' approach. If I were a logical, rational individual, I'd consider this (not really serious) curve, and carefully consider how big/complex to make my next game, weighing up every line of code and every art asset against how far into the Zone of Meh it may push me. 

Fortunately, I'm not logical or rational, so you're not going to see much of that, here.

I did think it was worth noting, though.

BeMuse - inspiration, Sworcery and Splines
I've written about my Moomins fascination before, and how both Tove Jansson (and the polish animation team who brought her vision to life) have hugely inspired my work on BeMuse. So enough of that.

 The one thing I haven't mentioned is the impact of Sworcery - or more specifically, this piece of Sworcery art had: "Slyve & Sworcery" by Slyve at Capy. I think it's wonderfully evocative.

When I first saw this picture, I loved the dingy world it evoked, and it reminded me how disappointed I was that Sworcery wasn't... just bigger. There's a lot to be said for a pared-down, clean and simple story, told well, but I really wanted to feel I could get lost in that world, and I really, really couldn't. This piece of art hinted at what might have been. In particular, I loved the big overhang cliff in the background. I wanted to walk there.

This got me thinking about cameras and splines.

Splines are really rather under-used in gaming; beyond providing camera paths, they're treated as a mere smoothing method for scripted objects. A decade or so ago, when the 2.5D thing was a big deal, games like Pandemonium and Klonoa used this basic technology to allow complex 3D explorations and visualisations of 2D environments. 

The result was something that was easy to control, but not stuck to one single plane of movement. Sadly the practise rather died out, and now everything is either full 3D or 2D... bar Sonic, for better or worse.

As I was working on BeMuse, I realised that splines offer you a couple of other things, too:

1) They allow simple navigation of a 3D space. If you link several splines together, you can deliver all of the freedom of 3D world-navigation, while retaining the simplicity of 2D movement. Not only that, but the underlying structure of the splines provides a lot of pathing information for creatures trying to navigate on them. It is flexible enough to work with platformers or point-and-click adventures. Just don't expect Unity's physics to be friends any more, as spline constraint rather kills any hope of using the standard methods for moving objects... but hey! Splines!

2) They offer a unique method of terrain generation. Once you have a spline, you can loft it in all sorts of interesting ways, and use them to create organic, interesting geometry with ease.

In BeMuse I'm using both iTween and GoKit to handle my spliney needs, with a custom script on top to generate the terrain mesh.

iTween gives me the ability to find the length of a spline path. For some reason, GoKit doesn't have this.
GoKit gives me the ability to move an object at a fixed speed through an entire curve.  For some reason, iTween doesn't have this. If you bunch up your points an object will move slowly through that section of the curve. Separate them out and the object whizzes through them. Using both these libraries at the same time gives me the flexibility to do exactly the things I need until someone out there realises that this is a silly situation and fixes them (well one of them, anyway).

Here's how BeMuse started out, before the spline stuff went in:

Here's an example of one of my original experiments with the spline-generated topography. Note the fat, curvy form of the terrain:

And here's what it turned into:

Art Vs. Content Part 2: Animal Crossing, Slenderman and The SCP Foundation
So, having decided that content is unappreciated in serious circles, and that a lack of content is inimical to my own development style, I wondered if there was a third way. After wracking my brains for a while, a return to Animal Crossing showed me the path out of this dilemma.

Animal Crossing is an attempt to provide players with an alternative life of (limited) bucolic bliss. I am aware that for others it's a pointless waste of time - but they're just wrong. In giving the players simple tasks, and then slowly changing the environment and personalities around them the developers have made the world itself an oddly meaningful, constantly changing wallpaper - a background for your otherwise humdrum activities.

At the same time, I also  discovered Slenderman and the SCP Foundation. Both are new mythologies that the internet population has riffed upon, extended, interpreted and folded back into the original stories. Fiction-forms like this have bred stories, movies, games and other media, all from the basic premise of taking a tall-tale, and finding ways for the audience to riff on it and then feed that back.

Admittedly, this is not new to games. Both Starseed Pilgrim (or ??? as I like to think of it) and the Roguelike game Unreal World use some aspect of uncertainty to elevate their games.  Starseed Pilgrim is wilfully obscure in every way. Conversely, Unreal World is a fairly straightforward pre-Minecraft 'crafting RPG' where magical rituals have no fanfare, no special effects, no indication at all that they work. But one performs them anyway in the hope that they actually do something useful. I've experienced bountiful hunts after performing a ritual. Was it luck? Is there anything hooked up to the spell casting code? Who knows? I do it anyway just in case (and thusly, all the religions of the world were born). Best. Spell system. Evaaaaar.

Hello Kitty meets The Exorcist - or 'A Game for Liars'
So, after all that, what is BeMuse about? It's a little clearer than Starseed Pilgrim, but hopefully not so transparent that it falls back into the Zone of Meh, or all the way into 'Just a Game' territory.

The aims are: 

1) Provide a large, explorable world with lots and lots of locations, and lots and lots of odd things in it: statues that rotate and make unsettling piping sounds, scrawled symbols on trees that change with the phases of the moon, skulking creatures that come out at night to perform weird singsong rituals, brightly coloured clouds that wander across the world as if on the hunt and alter things they come into contact with,  weather patterns, variable time-of-day, strange phases of the moon (including 'Bitter', 'Querulous', 'Maleficent' and 'Craven'), and many other factors that change during play. There's going to be a lot for the casual tourist to see.

2) Fill the world with Demons, hidden everywhere, to be combated by understanding and manipulating both them and the world they inhabit via arcane rituals you learn about throughout play. Some rituals are lies. Be afraid. Be very afraid. Demons will swallow your soul. Demons will try to trick you.

3) Establish a feedback process by which people can lie and rumour-monger freely, about places they've seen/found a way into, which ritual behaviours work, what the effects are, which Demons they've seen, where they were seen, and how they were defeated etc.

This last part is critical. The plan is to fold back the most interesting lies people tell, so that they become truth.
There will be only one score/aim; the number of secrets you have found. Some of the things you find may not actually be secrets. They may be lies. 

Finally 
A part of the inspiration came from an old Clive Barker story, where the main 'monster' (always Barker's favoured protagonists) utters the lines:

"I am rumour. It is a blessed condition, believe me. To be whispered about at street corners. To live in other people's dreams, but not to have to be."

Remember how kids are all told that if they say Bloody Mary in a mirror 5 times, she'll come and get them? Remember how you kinda didn't believe it but never did this because it was silly definitely not because I'm scared no definitely not that.

I'm hoping to get a bit of that going in the game. 

By making this game in this particular way, I'm hoping to disconnect content and art - or more, disconnect the amount of content and the perception of art. There will be no one simple core gameplay mechanic. There will just be a world, the unknown, mystery, malice and the sound of screaming, oh God the screaming please make the screaming sto...

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.

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.

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.

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.

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. 

It's been a while since the last post. Several months, in fact. Firstly, I apologise for the scant amount of information revealed about BeMuse. The whole move to Unity has been taking a lot longer than I'd like. 

Fear not - BeMuse is still coming along - I've just had to restart it about 3 times so far, as my ambition exceeds the ability of one lone developer, requiring redirects and re-thinks about what it is I'm trying to do, and if I'd like to finish it before I turn... old. 

In other news, Fluttermind is moving to San Francisco. I just thought I'd toss that in there.
The reasons are numerous, and complex, mostly circle around the fact that:

a) My wife's work is largely based in the US these days. As is she. This is not ideal for a Londoner.
b) The indie scene in San Francisco is healthy. I am a hermit. I hope to change this in a place where...
c) ...Great vegan food is available in quantity.
d) Oh, and I have some really nice friends out there, too, which makes it better than New York. 

BeMuse is proving a tricky mistress at the moment, so I thought I'd take a few moments to tell you more about the game. 

BeMuse is primarily set on a friendly-looking, Moomins-like Island.  It is the story of a small child who is washed up on the beach one day, with no memory of where he came from or what he is doing there. Over the course of the game, the hero will learn a key fact about the island: there are Demons everywhere. 

Behind every bush. 
      In the heart of every tree. 
                    Sometimes their presence is given away by the soft tinkling of bells. 
Sometimes they disturb the leaves. 
       Sometimes they cause a ripple in the water.
                            Sometimes they just watch, the pale green orbs of their eyes glinting in the night.
They are everywhere.

The first Demon the hero meets is a giant bunny-like creature who serves as your point of contact. She says that if you can summon and then banish every other Demon, she'll recover your memory and help you escape the island.

Of course, nothing is as it seems, and over the game's span, you'll encounter many different Demons, and have to re-evaluate what you're doing and what recovering your memory really means.

"What's that? Demons? You mean Pokemon, don't you? Ahahahahaha!" said nobody.

No. These are Demons. These things will rip out your heart and feed on it just to watch the light in your eyes flicker out.
These are beings that will mislead you and get you to do things that kill you. These are the most evil, tricksy, mercurial beings in existence. Most of them want you to die... while they applaud. Summoning a Demon is a potentially life-threatening event you need to take very seriously. You'll have to learn rituals to protect yourself, and hope that you've done enough to not have your spine removed through your nose. Think 'Hello Kitty meets The Exorcist' or 'Dark Souls with bunnies'.

It's actually likely to be nastier than Dark Souls. Each time you die, you will forget much of what you knew.
Yes, that's right - I'm toying with permadeath, procedural generation and a whole host of other things that make people go "EEP!"

So why am I doing this? WHY!???? WHY NOT JUST MAKE A FIGHTY-KILLY GAME?!!! YOU PRETENTIOUS ARSE!!! AAAAAGHHH!

Well, I want to create a world people love to spend time in, regardless of whether they are actively playing the game or simply wandering about. That's how I felt about the Moomins when I rediscovered them some years ago (yes, I really said Moomins again). There's a warmth and a cosiness to knowing you're living on a pretty but dangerous island and that darkness and lethality lurk just around the corner. Ask the residents of the Isle of Man. Carefully. While backing away.

As a developer, I view this game as an ongoing relationship, rather than the 'fire-and-forget' of Incoboto. 
I'm personally going to love this island, but I'd like to keep building it and its inhabitants for years, and for players and the community to help me add to it as time goes on. 

This last point is important: I'll be asking for ideas for rituals, suggestions for how I can use the island's assets in a novel way, and even for other activities you'd like to be able to engage in. Ultimately, if I do things right, it's going to be your game as much as mine.

Like many indies, I find developing games really, really hard. The way I work (and my brother, Simon, had to point this out, such is my lack of self-awareness) is to have an aesthetic/mood in mind, to develop that into a piece of representative artwork, and then to explore that picture as I go along, in game form. It's really, really sub-optimal, as the gameplay is one of the last things I think about. Yes, really.

Anyhow, this is *that* picture:

I know, it looks a bit like a painting. That's the idea. This is what I start from.

I also start off by trying to reject every single trope I can. Movement, death, menus, violence - all are sacrificed on day one. By the end, many will have crept back into the mix, but only after fighting their way in, not just by default.  I think this is useful. If I were more intelligent, I'd make sure it was part of a well-honed process rather than a novel extension of ego and self-doubt. But that's just how it is.

I'm also aware that the approach I take is just so wrong-headed. If I were tutoring me, I'd give myself a good talking to. Luckily I'm not. For me, most good games have been done, in the same way that most stories have been told. Everything you see is likely to be 'Like X with a dash of Y'. I think it's important to take the opportunity to try something different, something that people won't just dismiss like that... or at least not immediately. 

If it doesn't work out, you can just point to this post and tell me how stupid I am. That's what the internet is for. And cats.

If you've read this article on 'releasing' and not 'launching' and found yourself nodding in agreement, then you'll be pleased to know that my aim is to follow this model. 

I shall be releasing web versions of the game in VERY early forms, long before the first Demon sets up shop. Hopefully it'll give people a chance to feed back early on and tell me how much I suck, and how they hate my stupid face, how I have ruined their lives and... be all angry and internetty and stuff. Most likely they'll just ignore me to death.

In the meantime, as ever, if you have any thoughts at all, please feel free to contact me., or post on the forums. It's still early days, but they'll be critical as time rolls on. 

Just don't ask me about timescale, or whether I'm ready to accept Jesus as my personal saviour. Come back to me after I've finished my game about summoning Demons.

In a surprise move, the BAFTA award committee have included my little game about loneliness, death, corporate power, consumer apathy, and planet-hopping in their nominations for Best Mobile / Handheld Game this year. 

I'm really, really delighted, and somewhat humbled by the august company Inco and Helios are sharing; The Room? Walking Dead? Really, really amazing.

Now I need to make a video of Incoboto to be shown on a massive screen in front of a room of gaming luminaries...
...and Dara O' Brien.

For all you lovers of Fat Chick, clouds, bouncing, and endless flappy fun, Flaboo! just had a major update. It is now retina-friendly, supports 4-inch screens and  all achievements have been shifted to Game Center.

A fair few elderly bugs were squashed at the same time. Did you know that once in every 256 games or so, you'd get NO enemies? Did you? Fixed. Also, the 'where did the 10 second time upgrade go?' question has been resolved. It was down the back of the sofa. It has now been returned, 'eeping' and wriggling in protest, allowing preposterously long games once more.

The leaderboard has also been reset, so happy bouncing!

Incoboto and Incoboto Mini have now been updated on the App Store - just in time for Christmas. The update increases the game's stability to a pretty rock-solid state. 'Woo', and indeed 'Hoo'. Thanks to brother Simon for helping find the cause, and Mr John Wilson for reporting it!

Enjoy the new version! Thanks to all of you who have supported me with advice, good wishes and kind words over the last year. Next year will be focused on getting BeMuse to a playable state, as well as finishing off the Retina-friendly version of Flaboo!. Exciting, fun times are ahead!

In the meantime, may your holiday season be as happy as Helios, and may your power not go out at a critical moment while you're cooking Christmas dinner*.

- Dene (Fluttermind)

*No, this isn't linked to anything. I just hope it doesn't happen. It would suck.

Rather wonderfully, the chaps and chapettes at the  App Store have awarded Incoboto's iPad version a place in their 'Best of 2012' run-down.

It's tucked away in the 'Hidden Gems: Games' section. 
Thanks to everyone for their support!

www.itunes.com/appstorebestof2012