See that? That's a skeleton. Useful things, skeletons. They stop you from focusing on skin. Skin is messy, clammy, complex, and superficial. It tears, gets stretch-marks, bleeds and does all manner of unsightly, god awful things besides.
In a game, the skin is often the thing that gets you past the fact that the game isn't very deep. In some cases, the non-game 'experience' is skin, and skin alone. That's fine, if you're trying to create an immersive semi-interactive artwork rather than something with rules, logic and the potential for mastery, but if that's not what you're doing, skin can just get in the way.
In the case of BeMuse, I began with pure 'art' ambitions, but swiftly found myself feeling somewhat discomfited by this. I wrote an earlier post about the 'zone of meh' that exists between a pure art creation and a content/gameplay focused game. As a one-man studio, I feel it's often too easy to fall into that zone. I have too little manpower to create a huge game-world of content, and I'm not comfortable enough with pure 'art' pretentions to try and pass off something that lasts for one hour and ends with the word 'Fin' as a worthy purchase. There's nothing wrong with that, but I'm just not built that way.
GDC and P.T.
Back in March, I took BeMuse to GDC to show a few friends and other indies. It went relatively well, but the general opinion seemed to be twofold:
a) 'Love the way it looks and feels'
b) 'Hate the fact that I have no bloody idea what's going on'
Part of me took pride in b) - I always wanted the game to be wilfully obscure and wrapped in multiple layers of mystery. I played the P.T. demo a while back and felt that it was a proof that my weird attitude to design on BeMuse was vindicated.
I was confident up until I tested P.T. on my brother, Simon. Here's how that went:
Dene: "'Hmm?' You mean 'Hmm! Genius!'"
Simon: "No. 'Hmm.' As in... 'I have a mixed feelings about this.'"
Dene: "How so? It's a game that defies you to understand it! Isn't that refreshing?"
Simon: "No. That's not true. It's a game that pretends to defy your understanding. It is, in fact a 95% linear train ride of well-orchestrated, creepy jump scares... and an obfuscated 5% at the end that defies both understanding and patience."
To be honest, making a game that is defiantly impenetrable is actually quite hard. A lot of the time you end up making decisions entirely in order to maintain mystery rather than to improve gameplay. It also makes it harder to figure out what to cut and what to keep. When you've wilfully refrained from bounding or defining the shape of your work, it's all equally cuttable and keepable. This is far from the best scenario for getting a game out in a timely manner.
Add to that the fact that every alteration requires a huge amount of work in order to not break the existing code-base, to work with all the other systems and so on, and you can probably imagine the pain.
Which brings me back to skeletons.
As soon as GDC was over, I made a decision. I replicated the main systems underpinning the game using Codea on the iPad - it's a little game development system I absolutely love. Oh, ironically, I also converted that codebase to love2d in order to enable distribution to friends and family. No bloated Unity engine. No time wasted trying to fix something that looks distractingly broken but which, in fact, doesn't help move the game design along. We did pretty much the same thing in Dungeon Keeper, and it paid off then.
The game will still look exactly as it does in the screenshots. If you're a fan of the aesthetic so far, you can be confident that this won't change. If you're a fan of the concept, then you can also relax. The testbed is allowing me to keep true to my initial design goals, and to iterate quickly and efficiently.
If you have more questions, or are curious about the current skeletal framework, then feel free to email me.
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.