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.


  • 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:

The Unicyclist : Post-Project Analysis

On August 18, 2010, in projects, by bateleur

It's been a while sinceOlaf, the Unicyclist I was actually working on The Unicyclist, but that's not to say I've forgotten all about it since launch. I've been reading feedback, watching the stats on Playtomic (the Flash analytics service formerly known as SWFStats) and testing out some of the extraordinary techniques players have introduced me to.

So, let's have lots of little subheadings!

Game Design

What Was Good? – The game's content seemed to succeed in being innovative, challenging and both pacy and thoughtful. The stats showing how far each player got in terms of level progression form a beautiful curve. Also, on average I seem to have got the two medal levels about right (apart from an isolated few calibration misjudgements). The game's concept and core gameplay ideas seemed to be well received. There was plenty of reward for good players.

What Was Bad? – The difficulty curve may have been a good shape, but players on average found the game hard to play. Having talked in detail to several players who had trouble there seem to be a number of recurring themes. First and foremost, many players find the controls frustrating. This isn't quite the same thing as difficult. The primary cause of trouble was players wanting to do things which were not intended to be possible, but then giving up because they couldn't. The best example of this was the grappling hook. Players wanted to fire it at things with pinpoint precision, then complained of "bad controls" when they failed to do so. Similarly, some players were extremely reluctant to use the hook as a manoevrability aid and accordingly hated the low power of the propeller. Their descriptions of the propeller were spot on: it is terrible! This generates a lot of gameplay of course, but that's no excuse for annoying players. The second cause of trouble was players largely ignoring the in-game tutorial hints. Indeed, I heard tell of one player who completed more than half the game with no use of quicksave (!) because he hadn't realised what it did.

The design of the hidden second character also went a bit wrong in the sense that almost nobody has actually been finding the unlock mechanism. On two of the levels it's possible to exit from one of two teleporters. Take the difficult option on both and you get to play as Nina. It's not that hard (you even get a big hint when you do the first one), but people just didn't spot it. Evidently my assessment of player psychology is a bit off.

Development Process

What Was Good?The Unicyclist was developed reusing large amounts of code from Vgypt. This worked very well. I've long been a champion of modularity, code reuse and so on, but it was nice to see it all work in practice. The choice of Flash/Actionscript was therefore made for me on this project, but that nonetheless also worked out well. There were no significant performance problems even on moderately low end machines and development was fast and easy. The choice to use Box2D was also a good one. In general I dislike middleware, but Box2D is not only open source but leaves everything public (in code terms). This is good because it means the package cannot be rendered useless by a poorly chosen API. I just took the lid off from day one and had no problems with it.

Writing the level designer and game as a single app was also a very good call. This isn't the first game where I've done this, but it's noteworthy that this approach isn't just good during prototyping. Right up to the final version this continued to be very useful, particularly from a timesaving standpoint. (Likewise the decision to make quicksaves use the level storage format proved to be a good plan.)

What Was Bad? – Much, much more of the game's framework could have been made reusable. Decisions about how the game's art would be rendered also proved to be poorly thought out later in development. Basically the problem is that the way the layers work in the game loses a lot of the potential efficiencies of pre-rendering stuff to bitmaps. This in turn limits the art styles possible. Which is a shame, because the game could have been much prettier.


What Was Good?The Unicyclist was consciously developed with intent to submit to FlashGameLicense, to see whether or not it works. On the basis of a single data point, I can confirm that it does indeed work. Late in the bidding I took a risk of sorts in going with as a sponsor since I hadn't heard of them before. They turned out to be a good choice, since the members of their team I was working with had a good understanding of games and not only didn't request stupid changes but actually came up with some good insight on various aspects of the UI and player experience.

What Was Bad? – Even accounting for the fact that the game got decent sponsorship and employed a lot of reused code it still didn't make much money per developer hour. The reason for this is pretty simple: I did not sit down prior to each design decision and ask whether the time taken was justified in terms of expected additional revenue. I'm not too sad about this because it was mostly deliberate – I wanted to make the game as good as possible – but it does mean I can't aim in future to replicate the success of this project, because commercially it wasn't a success.

The other problem was post-launch marketing. Sending emails about the launch to various sites didn't quite have the effect I expected. The Unicyclist received basically no coverage anywhere. In some cases I wasn't surprised. In other cases – naming no site names – I was astonished given the nature of content typically promoted. My best guess is that in a couple of cases the failure of the gameplay to be sufficiently accessible caused an immediate negative reaction to the game which was sufficient to rule it out of contention. Hopefully this is the case, since that can be addressed by fixing things which want fixing anyway.

It's interesting to note that the players at Newgrounds and Kongregate both gave the game rather unenthusiastic ratings (3.2 and 2.8 respectively) which in turn led to no promotion on those sites and therefore fewer plays than I got from many much smaller sites. I think the take-away message from this is that if you're going to do something innovative you have to have super-accessible gameplay and no rough edges if you want to get above a few hundred thousand plays, because irritated players vote one star every time.


Flash seems like a great way to release small games and, in combination with FlashGameLicense, to do so in a way that at least partly pays for itself. Nor is the Flash game market all casual players. The stats shows some extraordinarily skilled players getting deep into the game and seemingly having fun. However, to make the jump from a game that pays generous pocket money to a game which pays something resembling a salary looks tricky within the free-to-play market.

I'm sure I'll write more games like this in future. Maybe it's useful to have the concept of something halfway between work and recreation? Certainly I expect I'll make prototypes which don't look like they want to be huge projects, at which point the tempation to release them as Flash games will be considerable. For some time I've been tempted to write a sequel to Ballrooms. In many respects I'm inclined to use Unity for that, but it might be a while before I really have time to learn that, so maybe Flash would be better?

Oh look, I've drifted completely off topic. Burble, burble, burble.

Last but not least: moustaches! The gaming public love Olaf's moustache. I'm trying hard not to think of Rule 34

Tagged with:

Everyone Gets to Play

On August 15, 2010, in Knights & Ruffians, by bateleur

Some cartoon peopleTell someone you're making a game and pretty much their first question is always: For what platform? It's a good question. After all, who cares about a game if you never get to play it.

Knights and Ruffians is going to be web based. The reason is this simple: I want everyone to be able to play it. The underlying technology is Adobe's Flash, so I suppose technically when I say "everyone" there I mean "everyone except people with iPads". That's a shame, but Mr Jobs assures me you hip cats wouldn't dream of playing a game without multitouch anyway.

As well as web deployment I'm also trying something new with this game… it's going to be episodic. And by episodic I don't mean like Half Life has become with very infrequent episodes. Nor do I mean like Sam and Max. I mean more like a webcomic, with weekly episodes.

I suppose you could almost think of Knights and Ruffians as being like a playable webcomic.

Has anyone done this before? If not, maybe you're thinking that this sounds crazy or even impossible. The reason why it isn't is because I'm not talking about ten hour episodes here. Each week's episode will be really short. The experience will be more like playing a level of a game than playing an entire game. And no, there won't be groundbreaking new game features in every episode. But nor will there be filler. The idea is for each week's new episode to be compact but fun. People don't always have lots of free time, so I don't want a big time commitment to be necessary to play every week.

The other key question which needs resolving after platform is payment. Well, I want everyone to be able to play it, so it has to be free. End of story.

Well OK, that's not quite the end of the story because I'm an evil money-grubbing developer who likes to indulge in such shameful luxuries as eating food and having a roof over my head. But I'm serious about making it free. If there's one thing all the endless drama about pirates has taught me it's that it's better to persuade people to pay you than to try to insist. Where Knights and Ruffians is concerned that means identifying worthwhile things I can provide to players willing to pay without spoiling the fun for those who cannot or choose not to.

Fortunately there are quite a lot of things that can be done here without being evil. The most obvious one is enabling customization and variation. Knights and Ruffians, like a webcomic, will feature characters scripted by the authors of the episodes. There's no reason why players can't pay to play with alternate characters or even design their own instead of using the canonical ones. Such payments wouldn't be per episode, so the cost to the player would still be very low. Another possibility is multiplayer. A small one-off cost to let you play through episodes with your friends should again not spoil the experience for solo players. Last but not least, access to old episodes is something I'm likely to charge for. Not the previous week's episode, of course, but if someone wants to go back 100 weeks and play catch-up then I want to be charging something for it or my server bills are going to be a problem.

Longer term I might also release downloadables such as an entire series as a standalone executable or even a level editor. I have a lot to say about level editors. Maybe another time.

Remember when I said this game was going to be big? Well, the truth is I literally have no idea how big. If the concept turns out not to work, maybe I'll never get past half a dozen episodes. But if it does… what's it going to look like after several years?! Exciting. And a bit scary. But it's the kind of project where having come up with it I can't let go of the idea.

Knights & Ruffians

On August 6, 2010, in Knights & Ruffians, projects, by bateleur

OK, let's talk about gameplay!

Knights and Ruffians – my new game – is about trying to bring to video gaming the kinds of experiences I used to enjoy from the skirmish scale adventure games I used to play as a kid. Possibly you're scratching your head at this point. Surely "skirmish scale" should be followed by "wargames" not "adventure games"? Well, therein lies an interesting quirk of the history of adventures…

I'm not quite old enough to have been around for the birth of pen and paper roleplaying games, but I found the hobby soon enough afterwards to experience old school roleplaying first hand. We taught ourselves roleplaying with those games as a framework, but really they were wargames. The interesting part was, they were cooperative wargames. In recent years cooperative gaming has really become a hot area, but back in the early 80s we spent all day doing exactly that without really being conscious of it. Later roleplaying systems dramatically reduced the wargaming aspects, although they never fully disappeared, as a consequence of which this style of gaming was almost lost.

I also played a great many Games Workshop games, from Warhammer and 40K to the excellent Space Hulk. However, Games Workshop were always more interested in selling miniatures than making great games. When they got rid of Richard Halliwell – who was full of incredible ideas that he was never allowed to develop – I started to lose interest. Still, games like Space Hulk and Advanced Heroquest remain important landmarks in my gaming history and are sources of inspiration for Knights and Ruffians.

Not all of the ideas behind Knights and Ruffians come from the tabletop world, though. The old C64 game Laser Squad was a pure wargame, but its mechanics set the standard for turn based play in video games. Also, whilst I don't really play RTS games, ever since Warcraft I've had my eye on the genre for its attempts to give players a high level of control without resorting to turn based play.

So what's wrong with turn based play?

The primary problem is that it encourages a glacially slow pace of play. Players will always find more things to think about. There's a reason why Chess needs clocks! Real time play also isn't right for the style of play I want. The trouble with real time is that either each player must be limited to controlling a single character or the behaviour and interactions of their characters must be simplified. Not that simplification is inherently a bad thing. But the kind of game I'm aiming for wants rich, interactive, moment-by-moment tactics. If a player is controlling multiple characters it must feel more like the way a good sports team interact than like a herd of sheep.

Knights and Ruffians is going to use a compromise between the two approaches. It will have turn-based play, but with a very short turn timer. Players will have enough time to do things with several characters each turn, but only if they issue orders fairly quickly. I'll write a whole entry sometime about my plans for the UI. It needs to be very good, because otherwise the fast turn cycle will be irritating rather than being a source of good gameplay.

In theme terms the game is going to be about looting rare and valuable treasures, many of which will also be useful items. It's going to be about fighting off enemies and rivals and monsters. It's going to be about characters and stories and mysteries and… Actually, I don't even know all the things it's going to be about because I'm going to have some assistance on the writing side. More about that another time.

Also, since this is a development blog I really ought to get around to talking about the technical side of things. Soon. Very soon.

Tagged with:

You Are Not Goldilocks

On July 29, 2010, in projects, by bateleur

A picture of GoldilocksMy experience of game design as an activity has always been that it is easy to have fun with. This is a good thing, of course, but it also gives rise to a problem. If you spend your time having fun it makes it easy to avoid being critical of what you do. This is particularly true of video games, because most developers seem to enjoy the design work more than the implementation and both of those more than polishing or debugging. Therefore during the early stages of a project there is a temptation to make grand plans likely to take years to complete. During implementation, the huge size of the project becomes a burden and – as is well known – few reach completion. Experienced developers then tend to drift towards shorter and shorter projects for the simple reason that they come to value their ability to complete them. Very reasonable. But maybe still bad. Indie designers have become good at finding games they are able to make at the expense of making the games they want to make.

In this context, let me talk about my new project!

What I realised, just before starting it, was that I was about to make what I call a Three Bears mistake. You know the story of Goldilocks and the Three Bears, right? Well, my previous two projects were two of the bears. Vgypt was extremely large and ambitious. I was very excited about it and developed all kinds of clever tech for it and developed enough to submit a prototype to the IGF last year. The problem was, the project was too big. It got to the point where I was having performance problems and needed to rewrite the entire game engine and probably switch language too. I decided I couldn't justify the cost of doing so and reluctantly put the project on hold. The Unicyclist was my next project. It was much less ambitious and I completed it easily. It's good, if I say so myself, you should play it! The trouble is, it's too small to do well commercially. I got some good sponsorship (from but free games just can't pay enough to justify the kind of development time involved. So, time for a new project that was bigger than The Unicyclist but smaller than Vgypt. Time for Baby Bear's game, the size of which would be just right.

Or maybe not. Because that's the Three Bears mistake. Having identified two problems at opposite extremes, it does not follow that the best strategy is the average of the two bad ones.

The real problem with Vgypt was not that the game was too big, it was that the software required to implement it was too big. If I were to go ahead and write a medium sized game I might well complete it, but I'd leave myself with an awkward marketing problem. Like Terry Cavanagh's VVVVVV my game would be seen as too small for a commercial release whilst at the same time being too big to finance as a free release. (Incidentally, VVVVVV is very good and I personally found it well worth the price even at launch.) Also, who wants to start off a game design with a size constraint before you even have a concept? That can't be good.

The real lesson of these designs has to do with risk. At the start of a project the question to ask is: "What is most likely to go wrong here?". The trick is to make sure that the foreseeable problems are all things you can handle. Working as an indie designer has many positive points but one of the biggest negatives is that you're very vulnerable to risk. I'm lucky to be in a position where I can have an unprofitable year without needing to pack it all in and go and work in a bank.

My new game, as you may have guessed by now, is actually a bigger project than Vgypt. In fact it's easily the biggest game I've worked on. It's the reason this development blog has made it's appearance. I want to talk about the gameplay too, but I think that deserves its own entry.

Tagged with:

Blog is Live!

On July 4, 2010, in admin, by bateleur

After many years of staying quiet and not releasing anything, now seems like a good time to be slightly less quiet. We have a new project starting soon which is likely to take a long time to develop. The process may be quite interesting. So I have decided to document it.

More on the project soon. For now: Welcome to the blog!

Tagged with: