King Machine and the IGF

On October 19, 2011, in King Machine, by bateleur

On Monday I entered King Machine into the 14th annual Independent Games Festival – "the IGF" to its friends. Here's the trailer I made for the submitted version:

You may have noticed two exciting announcements hidden in there…

First, the talented Ed Fry (@Aeronic) has been persuaded to compose and produce all the music for the game! And yes, this is the same Ed Fry who did the music for Sophie Houlden's Swift*Stitch. I'll make a separate post about the game's music at some point because, as good as it sounds in the above video, there's some even cooler stuff going on with it that video cannot capture.

Second, the game now has proper voice acting thanks to some amazing work by Emma Newman (@EmApocalyptic). Best known as a fiction author, Emma also does voice work for audio books. Being an experienced roleplayer, she wasn't too hard to convince when I suggested she branch out into a spot of voice acting! The voice clip in the video above is possibly a slight plot spoiler, but again I think I'll leave discussion of how the game got its plot for a future post.

Last but not least, a hat tip to all my playtesters and to the numerous people who offered to playtest but whom I haven't yet taken up on it. I still plan to. The game may be getting a beta release of sorts in the next few months and there will need to be a lot of testing of things between now and then… including a lot of testing of stuff I haven't written yet. Speaking of which – back to work! 🙂

Tagged with:
 

The Last 90%

On September 14, 2011, in King Machine, Technical, by bateleur

It is well known amongst programmHolding a plank.ers that the first 90% of a project takes 90% or the time and then the last 10% takes 90% of the time too (originally observed by a chap called Tom Cargill at Bell Labs, I'm told). King Machine is, I think, just approaching the edge of that last 10%… or should that be "last 90%"? All the basic gameplay mechanics are there. I've been designing tutorial levels for the last couple of weeks. The game runs well even on less powerful machines.

But… from Tom Cargill to Helmuth von Moltke, who said "No plan survives contact with the enemy". Very early playtests (with friends, not enemies) turned up a critical problem: positioning objects was far too hard. I'd noticed this a long time ago when trying to build scenery, but my solution was to add special purpose tools to make scenery easier to build. What I failed to notice was that I'd become very good at the basics of the game to the point where I wasn't really conscious of the extent to which fundamental actions were still quite hard.

My usual approach to UI design is to ask the player, immediately after they experience difficulty, what their ideal interaction would be to solve whatever they're trying to do. The trouble with moving things in 3D is that their answers were along the lines of "I want to put that there!". That's an objective, but isn't an action any UI can support directly because it's too high level. So more questions had to be asked and more frustrating failures had to be watched until I had a better understanding of the problem. The main diffculty, it turned out, wasn't so much transforming objects as working out where they were in the first place!

The typical solution to this is to use shadows – and that's certainly some use – but there are two problems with this. First, it means that the game is really limited in how it uses light sources, because slightly weird lighting conditions could make object positioning hard again. Second, shadows are only available in Unity Pro. This is a piece of software I definitely want to invest in when I have the opportunity, but right now King Machine has no development budget at all. However, shadows do provide a clue as to how best to proceed.

The key observation is that intersection between objects is already quite easy to spot, so the main problem is in visualising non-contact relationships. These matter mainly when the player is planning to drop something. But dropped objects – in King Machine at least – always fall downwards. So what matters most is the relationship between the held object and what is below it. A bit of playing about with different kinds of HUD and similar gadgets quickly convinced me that the answer needed to involve rendering something within the 3D game space. A visible guide downwards from the centre of the object helped a bit, but a few more playtests showed it wasn't solving the problem. Two difficulties remained. First, if the centre of the object wasn't above anything then it was just as confusing as ever. Second, the angle of the held object made no difference.

The current (final?) solution involves guides at all corners of the held object, with the bases linked to give a better sense of their relative positions. Will this be good enough? I won't know until it's been tested…

In the meantime there are sound effects to sort out. And the artwork needs improving. And I need to design some more levels. And I have something fun planned for the help system… but it's only five and a bit weeks until the IGF deadline. It would be nice to enter if I can get the game ready in time. Or at least 90% ready!

Tagged with:
 

King Machine Spider Walker

On June 26, 2011, in King Machine, by bateleur

Tuning joint behaviour in King Machine is difficult and not very sexy, but now everything's working to my satisfaction I can make cool things like this:

Tagged with:
 

King Machine – Demo Video 2

On May 8, 2011, in King Machine, by bateleur

Work on King Machine has been very busy for the two months since the last demo. A lot of that has been boring stuff like fixing bugs, but there are exciting new features too. Here's another demo video showing off some cool stuff you can do…

(Or watch on YouTube in HD.)

Just need to fix a few more particularly hairy bugs and I can get on to the fun business of level design!

Tagged with:
 

Why King Machine?

On March 13, 2011, in King Machine, projects, by bateleur

In the announcement post for King Machine I promised a big, long waffly post about the game and my plans for it. So here it is…

Machines Want To Be 3DKing Machine logo

In the past I have actively avoided developing games with true 3D gameplay because with relatively few exceptions the games I enjoy playing the most have all been essentially 2D even when employing 3D graphics. So when I was learning Unity 3 I spent a lot of time thinking about which kinds of gameplay really worked well in 3D. Exploration games are good – and I love the idea of doing a really good 3D maze game – but that doesn't make a good first project because there's a huge amount of art and level design to do and not much game design or programming. Racing games and first person shooters aren't really my thing (and arguably aren't 3D anyway, but I'll try not to get too sidetracked).

It was when I started thinking about the third dimension as a way of not getting things tangled up that I ended up thinking about connecting things and wires and machines. This wasn't much to do with game design at first. Some of my PhD work involved automated layout of wiring for digital circuits… it gets pretty nightmarish in 2D! But then I remembered the old 2D versions of King Machine had similar problems. Not surprising really, since 2D spaces are just difficult generally. If you like fiction that makes you think I recommend A.K.Dewdney's 'The Planiverse' for some great discussion on this topic.

Machines seem like they naturally want to be 3D. So I had my project… sort of.

Too Big To Be Small

There was one big problem. For some time I've been working as a freelance programmer, working on games projects for as much of my time as I could get away with. Like most designers in a similar position I've been trying to gradually transition to full time games work. Generally this is all good, but it does place a strict constraint on my projects: any big project must be commercial. King Machine has, historically, been my favourite example of the kind of game I personally love but which could never possibly be commercial because it's just too geeky and inaccessible.

It was a conversation with my sister Josie which changed my perspective. I'd lent her my copy of Logicomix (because it's excellent – you should read it) and while we were chatting about it I offered to explain to her some stuff related to Gödel's incompleteness theorem. I tend to feel that the way mathematics is approached in academia makes ideas much less accessible than they could be and that most concepts can be explained to anyone reasonably bright provided you don't mind sacrificing a little bit of the rigor expected of actual proofs.

Later it occurred to me that this same attitude is something I should apply to games. King Machine is a huge amount of fun. So, as a game designer, I should be able to take the game and present it in a way that makes it comprehensible and accessible to a much wider audience. A combination of good user inferface design, gradual introduction of concepts and comprehensive help resources should be enough to get pretty much anyone playing and enjoying the game.

Finding the Core Gameplay

The first step in making a complex game as accessible as possible is to decide what it's really about. At first King Machine seemed pretty easy in this respect, since I knew I wanted it to be about building machines. The problem with that is that building machines isn't a goal as such, it's a means to an end. This begs the question of what that end should be. Of course I could make the game a pure sandbox, but that feels lazy to me. I want to let players play in a sandbox style if they choose to, but for some players that's just not satisfying.

Machine-based play is ridiculously versatile, so as I began to make notes about possible goals and play styles the list just got longer and longer and picking the right option started to look a bit hopeless…

…until I realised I was looking at the problem the wrong way. Instead of picking one goal I could pick all of them. The danger is that doing this sorts of thing inhibits the player from learning, but I don't think that needs to be the case. If each level gives the player a new kind of task and then provides them with the support they need to discover the solution that should keep each experience fresh whilst gradually teaching them what they can do with their machines.

That just left difficulty levels. The word "accessible" has a bad reputation in certain quarters these days because it's seen as a euphemism for "easy". I don't think that's right, but certainly the two can be related in the sense that it is difficult to find ways to present hard challenges without causing bad play experiences for some players. In the case of King Machine the approach I feel most inclined to adopt is optional challenges on the same levels as compulsory problems. That way the player can give some thought to anything they can see but doesn't need to feel as though they're stuck. Also, having seen a challenge, the player can always come back later if they have a flash of inspiration or simply learn a new trick which they think might help.

Was That Waffly Enough?

Hmm… I still have over a dozen more things I wanted to talk about. Maybe trying to fit all this into one blog post isn't such a great idea? The rest can wait for now, I'm off to do some more programming!

Tagged with:
 

Announcing King Machine!

On March 7, 2011, in King Machine, projects, by bateleur

OK, so as those of you who read my previous post will realise, this is really King Machine 5. Given that it's going to be the first commercial release and is radically different from the previous incarnations it seemed sensible to reset the numbering.

I'll make a big, long, waffly post about the project sometime soon. For now, here's a shiny video:

(Or alternatively watch it on YouTube in HD.)

And in case you don't have a chance to watch it all, there are Twitter and FaceBook accounts for you to follow and like respectively. (Hey, don't look at me like that, all the cool kids are doing it!)

Twitter: @fastramdesign

FaceBook: www.facebook.com/fastramdesign

Tagged with:
 

The History of King Machine

On December 30, 2010, in King Machine, by bateleur

I've written the same game four times.

As with film trailers, a brief glimpse of a game is often more exciting in our imaginations than the reality. Puzzle classic The Incredible Machine was like that for me. It was a long time before I got to actually play it. By the time I did, the gap between the game itself and the way I'd imagined it spoiled most of the fun. Fortunately, one of the upsides of being a game designer is that if someone else has inexplicably failed to make the game you wanted to play, you just make it yourself.

I first wrote King Machine in BBC Basic on the Acorn Archimedes in 1993. The idea was to make a game that really was about machines. Not just interactive scenery, but machines that really did things. In King Machine the game board was a grid. Each cell of the grid was a machine part. You could only do one thing to a machine part: "use" it. The simplest parts, wires, responded by using another adjacent machine part. Other parts rotated or moved one another or shot beams across the map which did various things to whatever they first struck.

The first King Machine was a lot of fun, but tremendously slow to play. Each team controlled small, furry, bipedal characters who could carry machine parts around. We only ever played one proper match. During this match, one team built a machine that flew along a short way above the ground, pulling each block below it up by one cell. This strategy was devastating, leaving the other team in a – literal and metaphorical – hole from which they had no chance of emerging.

The reason the game was only played once is because it obviously needed tweaking in some way to prevent the "earthquake machine" strategy from dominating. In the process of thinking about what needed to change I realised that the game needed a concept of a composite object. That is, it needed to be possible to stick things together. To get that kind of power back in 1993 meant I was going to have to rewrite it in ARM Assembler.

The second version of King Machine took a while to debug, but by the time I'd finished it the game was easily the best thing I'd ever written. We played it exactly once. It was great! But again the game's first play exposed a serious problem: building things took too long. Each team built a machine, they clashed, then the game was effectively over as soon as one machine couldn't fly anymore because rebuilding was so clearly impractical.

It was a while before King Machine 3 was written, but by the time it was complete it was miles ahead of KM2 in terms of technology. It was faster, supported far larger maps, included a 'factory' system allowing complex machines to be constructed in a single turn within each team's factory area and had a much better UI. We played it exactly once. Two expert teams faced off. The game took several hours. It lasted only one turn. One team built a giant robot which completed all their objectives in a single move! Everyone agreed the game was a lot of fun, but that it would have to be tweaked in some way before it could be played again.

Many years then passed. My interest in King Machine returned as the era of free-to-play internet games arrived. For fun, I began developing an updated version of King Machine in Java. This one was played zero times. It reached a fully working state, but still more alpha than beta. However, by this point it was much harder to find time for the kind of deep playtesting the game needed. Before testing was complete I shifted my work life to full time game development. King Machine development was paused for the simple reason that after working on games all day I didn't particularly want to spend my evenings working on a different game.

The key new feature of KM4 was mini-maps. An entire machine could be stored in a single map cell, with inputs and outputs interacting with the main map. This greatly improved the depth of gameplay, meaning that machines which did logically complex things no longer had to be physically large.

Perhaps most interesting from a design perspective, though: even having never played KM4 I was on some level aware of problems. A couple of years later I was explaining KM to a friend who had never seen it. He asked why I didn't ever go back and release it. I didn't really know at the time, but I thought about it afterwards. The reason is: even KM4 still had gameplay which was too much about the details of how the machines worked. If your opponent was doing something you didn't like your first recourse was to pull chunks off their machine. If you wanted to defend what you were doing, the main strategy the game rewarded was to build big walls and keep the enemy away. "Good" machines weren't usually clever, they just did simple things fast.

I've written the same game four times, but I still haven't got it right.

So why tell this story now? As you've probably guessed, this is the secret project I mentioned in my previous entry. King Machine is coming back. The details can wait for next year, but suffice to say that this time I'm doing what I explictly declared to be impossible previously: making it a commercial project. Not that I've changed my perspective on the subject significantly. There's a good reason why this is now possible. All will be revealed!

Tagged with:
 

Focus vs Flexibility

On November 8, 2010, in Knights & Ruffians, projects, by bateleur

A 3D CylinderA little over a week ago I had a week off. At least that's how I think of it, but it's perhaps the wrong word. That week was school half term, but the twins (my two eight year olds) were away with their grandparents, which meant an uninterrupted week of game design!

I could have got quite a bit of Knights & Ruffians done in that time, but instead I decided to take a break from programming to do some programming. In particular with the recent release of Unity 3 I decided the system looked like it was worth playing with. So I spent the week learning to use it. As it turns out I quite like it. Not perfect by any means, but mostly seems to run smoothly and makes a lot of common tasks quite easy. That's not what this post is about.

The thing is, I find myself unable to play with languages and development systems in an abstract way. I need to write real programs to learn. So, of course, I made a game. The problem is, I think this game is good.

The reason why this is a problem should be obvious. Independent game developers – particularly one-person teams such as myself – are always short of time. Consequently the very last thing you want to do is get distracted by things which aren't your main project. This project needs to be set aside until Knights & Ruffians is ready to launch.

Except it's not quite that simple.

It's a well-known advantage that independent developers have that their development process is supposed to be lightweight, their decisions fast and flexible. All of which is supposed to come as a result of not having the heavyweight bureaucracy of publishers and other investors applying pressure to do particular things. What good is flexibility if we don't take advantage of it?

So… project switch! Right?

It's not that simple either. Instead, a bit of proper analysis is called for. What are the pros and cons of each game from a business perspective? (I'm not ready to announce my new project yet, so I will refer to it at NewGame for now and maybe come back and add a footnote to this post at some future point.)

Knights & Ruffians

  • Gameplay is known to work.
  • Deployment definitely viable.
  • Commercial potential high, but profitability far from guaranteed.
  • Heavy ongoing commitment once launched.

NewGame

  • Gameplay not known to work.
  • Deployment probably viable provided size of binary does not make direct download support expensive.
  • Commercial potential average, but modest profitability almost guaranteed if gameplay works.
  • Low commitment once launched.

Weighing those two lists up seems to favour development work on Knights & Ruffians, but there are two factors which mean that's not the case. First, if Knights & Ruffians is completed and launched then writing episodes will slow down NewGame development work. Second, one of the biggest strikes against NewGame is that I'm not yet sure the gameplay works. Is it an option to continue with it until I find that out and then decide how to proceed?

Yes, it is. So I'm going to do that.

And the best thing about having a development blog is that you're practically guaranteed another post six months from now discussing whether this was a good call or not!

 

The Silence of the Engine Writing

On October 26, 2010, in Knights & Ruffians, Technical, by bateleur

Games are fun – if they weren't we wouldn't bother with them – and for the most part games development is fun too. However, the kind of blog friendly design exploration that people think about when you say "game design" is only a small part of the whole. I sometimes call myself a game designer because I design games every day, but most of the time during those days is spent programming.

Towards the start of a project the programming that needs doing isn't even particularly sexy. That is, most of what you're writing doesn't relate much to the interesting gameplay, doesn't involve any especially clever algorithms and isn't the sort of thing you can get done in a day. Modern approaches to development involving short "sprints" between working prototypes sound appealing, especially to novice programmers, because of the word "short". But in reality there is sometimes a big task that needs doing that you can't meaningfully split up.

So, what I've been (mostly) doing for the last few weeks is writing the core engine code for Knights & Ruffians. I use the word "engine" here because I like it, but really I'm just talking about rather dull basic modules on top of which I will build everything else.

However, there is one aspect of this I felt was worth a quick mention: why is it that I decided to write the entire motion and collision system using only integers (!).

Let me tell you a story. When the original Fantastic Contraption was released I immediately loved it and played it a lot. The first level I didn't solve straight away was Awash. Once I had eventually managed it I decided to link to my solution from my blog. My solution was messy and took a long time to complete, so I asked for suggestions for improvement. One of the responses that I got was interesting. As well as an incremental improvement, the poster pointed out that in fact my solution didn't work! Further investigation revealed that for some players it was fairly fast, for some it was slow and for others it failed outright. I posted our findings to the Fantastic Contraption forum.

What had happened was this: In common with almost every Flash application ever written, Fantastic Contraption was using Flash's built in Number class for its floating point arithmetic. This is a good thing, but one feature of doing so is that the underlying hardware is doing your floating point work for you. As it turns out, not all floating point hardware behaves 100% identically.

So the bottom line is this: if I want my game engine to run 100% identically on everything then I cannot use Numbers at all (except for purely cosmetic things).

Why does this matter? Well, suppose I use some attack which does variable damage to opponents depending on their distance from the centre of the blast. That could give rise to a situation where on my machine a particular enemy dies, but on yours it lives! This can be fixed by adopting a Diablo-II style approach where you allow your client data to drift apart but you then continously attempt to resync-it. However, this is messy and difficult to get right and even Diablo-II sometimes fails (following a period of lag you can suddenly die without warning).

The remaining question is whether the probability isn't way too small to care about. Again, the answer is no. The reason being, collision systems amplify errors very rapidly indeed.

Working with integers in Flash isn't fun since there is no 64-bit integer built-in type. Consequently you have to be very careful of overflows. But for now everything seems to be debugged and working, so more interesting tasks await!

UpBot Goes Up

On September 23, 2010, in projects, by bateleur

The process of putting the basic code structure of Knight & Ruffians into place UpBot Goes Up screenshotis, as usual, proceeding well but not quite as fast as I'd like it to. Some of the design decisions I will eventually get around to talking about in detail, but for now I want to talk about a side project I've been distracting myself with!

Last January was TIGJam UK2, a get-together of people from the TIGSource development community. This was held in Cambridge, which was very convenient for me since I grew up there and still have family there. So off I went to write games for a few days as a break from writing games. Lots of big names from the indie community turned up. So much so that I didn't even get around to saying hello to everyone. It was a huge amount of fun.

Whilst there I met Luke Davies of Manatee Games – better known to the online world as LeFishy. He was doing shiny things with Unity, so I looked over his shoulder for a while since I'm interested in learning how to use it. Then he started chatting about this rough idea he had for a game and it sounded fantastic. We decided to develop two versions of it in parallel – I'd write a Flash one whilst he was working on the Unity version. We'd barely started when Craig Forrester (Ishi of Ishisoft) offered to get involved and make art for us.

Flash being what it is I had the game working complete with demo level after not very long. In keeping with my usual style I'd made the demo much too hard. This wasn't entirely accidental. I wanted to see if the game had sufficiently deep gameplay to be worth pursuing and I wasn't going to find that out by designing tutorial levels. Of course, TIGJam was full of very skilled gamers who were delighted at the opportunity to learn a new game on a tricky level. A team of solvers gathered round and inside ten minutes had completed the level. The verdict was very positive. Luke's design was a winner!

Shortly thereafter, Craig proposed making an XBox 360 version for distribution via XBLIG. This seemed like a great idea – the more platforms the better, really. And then Neil Thapen (Pishtaco) took the project to the next level by proposing we call the game "UpBot Goes Up" in preference to its working title of "Cardinals". Presumably on the basis that this was consistently the first line of the gameplay explanation offered to new players!

Of course, the journey from prototype to finished product is pretty long, but the Flash version is now complete and beginning the process of looking for sponsorship. So I want to talk a bit about the design process…

The Design of UpBot Goes Up

The core concept of UpBot goes up remains unchanged from Luke's initial idea. It's an idea that came from a remarkably silly place, actually. Stephen Lavelle (increpare) is so ridiculously hardcore that he wrote several games on the train on the way to the Jam. One of these was Modernauts, a game I'll leave you to try out for yourself because it's too hard to describe! But anyway, Luke was telling me about this, but couldn't remember what it was called. He thought it was maybe "something like 'monobots'". Which gave him the idea for a game involving robots which could only move in one direction. He said this almost as though he was joking, but the section of my brain that likes classic puzzles and NP-hard things immediately saw the potential.

Once we started to develop the game it quickly became clear that quite a lot of good puzzles could be made with no other game elements at all! If you've played a lot of very pure puzzle games you'll know that this is pretty much the holy grail of puzzle design. You want something simple, yet very deep.

In the end we did add one more element, in the form of teleporters which can move the Bots around the level. These were worth adding since they're easy and intuitive for the player to pick up, but mean you can make complex levels in a far smaller space. Huge, sprawling levels can detract from the appeal in a puzzle game, because players often feel happier if they can ponder the entire puzzle at once. Also, reasonably small puzzles are more elegant.

I was lucky with the level design work in that Luke and Craig took one look at the mad glint in my eye and basically told me I could make as many levels as I wanted to. Experience of level design from Dozer (a puzzle game I published way back in 1993) helped a lot here. Marcus Dyson, the then editor of Amiga Format, gave me a controversial-sounding but extremely good tip for puzzle design: there should be no clutter on the level. That is, every aspect of the level must be there for a reason. This advice isn't at all obvious, because it seems as though sorting out the relevant parts of the level could be part of a puzzle too. However, brute force searching of possibilities is not fun for most people. Flashes of insight are fun. It turns out that levels which don't contain clutter are much more likely to be solved by sudden inspiration than tedious grind.

I didn't design all the levels, though. Craig came up with some brilliant designs, one of which would probably be my pick for the best level in the game. And as with many games, cooperative playtesting led to many improvements to level designs which might otherwise have been overlooked.

One question I'm still not completely sure of is: how hard should the hardest level in a puzzle game be? There is an argument that perhaps the Flash version should be quite casual, saving the really tough stuff for XBLIG and maybe iPhone (which is where the Unity version is probably heading). However, we eventually concluded that so long as the early levels provide a friendly learning curve there's no reason why the Flash version can't contain a few really fierce puzzles right at the end.

So it does.

As you can probably tell, I'm very happy with how the game's turned out. I rather doubt it's going to be massively profitable, because it's not that sort of game, but it's a more-or-less perfect example of a retro puzzle game. I'll post a link once it's finally published.

Tagged with: