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.
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.
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.
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.
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:
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
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:
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.
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.
Over the last few months, I've had a nagging sensation at the back of my mind, regarding this blog. I knew something was wrong, that I wasn't doing something I really should have been doing, but I couldn't put my finger on it.
Fluttermind’s director, Dene Carter, is a games industry veteran of over 25 years, and co-founder of Big Blue Box Studios, creators of the Fable franchise for the XBox and XBox 360.