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.

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

Tagged with:
 

5 Responses to “The Unicyclist : Post-Project Analysis”

  1. M says:

    So how much did you make, exactly? It's not a proper PM if you can't tell us as much…

  2. Thanks for posting this up! A very interesting read, particularly the commercial side. I'm thinking of developing games to sell on FlashGameLicense myself, and so this is all very useful.

    It's also interesting what you say about clarity, in the controls and level objectives. Sometimes it can be very easy for a developer to think something's obvious when it actually isn't. There's an art to that which I think only comes from experience and watching how players approach it. And the experiences from this game will doubtless help you with the next one you make 😉

    All the best with the next game! 🙂

  3. bateleur says:

    @M – Unfortunately the terms and conditions of FGL's bidding process explicitly forbid talking about bid amounts. This is sensitive commercial information for many sponsors!

    @Alistair – Yes, I think experience counts for a lot. Good luck with your games! 🙂

  4. Barton says:

    I've recently developed a game for a competition so the circumstances are a little different, but I'm hitting all the same problems as you in the design realm; the game was too difficult for most people, and as such a lot of the game was neglected entirely. In my game, most people are missing an entire hidden game mode (where I spent a lot of my time during development) because they don't play further than a level.

    It's good to hear that it isn't just me. I'll be keeping 'barrier of entry' in mind for my future games.

  5. Howdy! Our organization are scouting around for future writers, will you be interested? It won’t prepare you prosperous except there is an appealing salary and if you certainly enjoy freelance writing then this gig is for you.

Leave a Reply