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…
My 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 teagames.com) 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.
