It's been a while since 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.
Commercial
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 teagames.com 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.
Conclusions
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…
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.