Rotor was our first release, which sees you take control of an agile helicopter zipping amongst a city's buildings as you race to beat the clock. Taking inspiration from the likes of Crazy Taxi, we created a fun flight physics model and married it to a colourful procedural art style for playful results.
Built using XNA, Rotor is available now on the Indie game channel on your Xbox 360 for 80 points, and we hope you enjoy it.
The earliest designs featured a rescue chopper, ferrying people around to safety using a neat winch mechanic. This concept quickly morphed into a more combat oriented structure, where waves of robots would attack areas of the city, with the player utilising the same winch mechanics, alongside weapons, to destroy robots and pick up debris for resupply of your bases.
This premise was not iterated on for long before it became clear that the overall structure was slightly overcooked. To do shooting well required more time and resources than were available. In the best traditions of the Zen of game design we began to remove features, until what was left was the core of what was good - the simple fun of flying a little chopper around a visually interesting city. And so we arrived at the current design for Rotor.
The city was built using Softimage, which integrates nicely with XNA, once configured, via the Crosswalk importer. The first step was to lay out the streets using the top of a cylinder with some added edges which were then jumbled around. This provided a series of city blocks to further divide up; most buildings were then grown upward using some custom scripts. Lastly came the more laborious task of adding some window and roof detail as well as colouring the faces.
It would have been impractical to texture the whole city by hand in the time available, so the final look is accomplised by combining these with a custom shader. The player can pick their favourite colours using a palette chooser; the greys of the buildings are swapped out and combined with an ambient occlusion texture.
The game is written in C#, using Microsoft's XNA Framework, a great development platform for those who are tired of the downsides of game development's lingua franca. In addition, Thorben Linneweber's JigLibX was incorporated to provide the physics engine heavy lifting. Grateful nods are nodded in the general direction of Microsoft (which would be west, from where we're sitting), for a great, and more importantly free, tool set.
Download via skydrive Rotor game trailer - 720p (45Mb)
Download via skydrive Screenshots (6mb) with some additional shots included to those you see below.
Sales data for the first month of release:
First some hard data. We achieved a strong number of trial downloads but a painfully low conversion rate. In the first two days alone we had nearly 6k downloads. Had this been accompanied by stronger conversion rates, we might well have had a decent hit on our hands. In comparison, many of the top selling XBLIG games get strong double digit conversions, sometimes as high as 30% or 40%.
Whether the response was good or bad, we want to thank the reviewers for taking the time to look over our game and for venturing into the xbox indie marketplace. It's probably against the rules of marketing to link to the bad reviews but, what the heck. If we missed your review, please send us an email.
Rotor, here lies thy record.
A game by - Richard Clifford & Nick McCrea
Additonal thanks to...
Rotor's art style, and graphics. This was almost universally praised and liked. This was easily our standout feature; Rotor looked great. The outcome was derived from simple, geometrically clean building design, baked-in ambient occlusion to give depth, and a limited colour palette. Players also enjoyed the chance to paint the world to give it their own style. A happy marriage between us not having to do tons of texturing and offering the player customisation.
When we made the game, we conciously aimed for a strong visuals that, whilst not attempting to compete with medium and big budget games, strived for a more stylised look that negated the need for too much art investment - also avoiding the usual indie fallback of geometry wars-esque visuals. We definitely succeeded. We like to think we made something that, visually at least, is up there with the best on the Indie marketplace. The graphical style contributed to a strong number of trial downloads - we had good box art, and some really nice screenshots to help draw players into giving us a try. As a result, our download figures over the first two days were excellent - 6000 players downloaded the trial in the first 48 hours.
One of our favourite little drawing tricks was the shadow projected by the helicopter. Without a shadow it was difficult to judge position or speed relative to the geometry. We tried a typical shadow pass, even going as far as implementing cascading shadow maps to cope with the outdoor scene, but the performance impact on the 360 didn't seem worth it, and depending on the light direction it didn't always help. A drop shadow was out, as it was useless for oblique geometry. Our solution? We added a distance based point light to the main city shader, centred on the helicopter, but instead of adding light to the scene we simply subtract it. It was fast, worked everywhere and in all directions and looked perfectly fine.
We were technically pretty solid. We had a deadline with the 3.1 to 4.0 XNA switchover in February, and as we were finishing the game so close to this, we really only had a single shot at peer review. If we'd failed peer review, we'd have had a hugely morale-sapping rewrite on our hands - JigLibx (Physics) and the crosswalk importer (softimage integration with XNA) have never been upversioned to 4.0, and whilst this might not have been insurmountable, it would have been a massive pain. This really gave us huge incentive to be as bug free as possible going into peer review, and for a title that spent zero time in play test, to pass first time was a big achievement, and a huge relief.
Passing peer review first time was no fluke. We spent plenty of time at the end of the project meticulously going through the 'evil checklist' over and over making sure nothing failed. A couple of mean bugs almost slipped by...towards release we realised we were falling foul of the managed code version of a memory leak, in that certain resources were never going out of scope. Playing about twenty games in a row resulted in an out-of-memory exception on the 360. A last-minute download of the ANTS memory profiler (highly recommended) revealed the issue. It's a given, but worth re-iterating - leave plenty of time before release for copious play testing and bug fixing - many games fail peer review for entirely foreseeable issues with some basic testing.
We also had very few issues with the 360 version, which is often a problem in XNA development. We got things running on the 360 nice and early, and kept things up to date (even though Windows was the primary development platform for convenience). The game hit a solid 60 fps, and rarely drops below, and there are few garbage collection issues (the other main bugbear on 360 due to the .NET compact framework).
From a code standpoint, a number of game systems proved themselves flexible and up to the ever changing design. Many game subsystems were heavily event driven, and the use of a general event system reduced unecessary coupling between unrelated components. This worked best when handling fire-and-forget game events, with the classic use cases here being both particle and sound effects. Mission generation and management was another system that withstood the ever-changing design landscape, and survived and thrived when last minute missions were added and tweaked.The use of a general event system allows multiple subsystems to behave in a coordinated fashion without a rats nest of dependencies between them, and is something we'll definitely take forward.
Really fun core flying. In our opinion, it was genuinely fun to fly the chopper around the city, particularly as you mastered the controls. Not to say there wasn't problems; more that we judge them to be a failure to properly teach players the controls, rather than the controls themselves. It was clear that, if players got over the initial difficulty, they had a lot of fun.
Our trial experience was unquestionably not good enough. Again, a by-product of the 3.1 deprecation, we really neglected this. We included a help menu explaining controls and the goals of the game, but we did not want to force new players to watch it, thinking it would be irritating - many didn't even realise it was there - it should have at least been visible from the main title menu, rather than only from pause. An unfortunate side effect of JigLibX and the physics based gameplay meant it was possible to get stuck in the city geometry. We were so good at the game we didn't think of this as a huge problem, but anticipating issues from new players we included a teleport move. What we should have realised was that new players would never find this, whilst good players would never need it. As such, there's a significant number of players who struggled to even start a mission, which seems so utterly obvious now, but honestly didn't occur to us, mid-development - we were undeniably naive. In future, we will pay much more attention to the starting experience, and the difficulty curve.
Without a solid trial experience, you are written off incredibly quickly. There are no allowances for low price. There are no allowances for the fact you had a hard deadline. The customer demands a lot, even for 80 points, and there are plenty of games on the channel that do deliver this. The place to cut corners, we have learned, is NOT in the initial experience. This is the very last thing that should be cut. Our conversion rate didn't lie - the vast majority of people who tried the game didn't buy it, and we were well below the conversion rates of the top performers on the platform.
We were in some ways content-light, or at least it seemed that way. We only had 3 challenge types, and the game modes were identical other than the time limits. The main culprit here was our hard deadline of the 3.1 submission cutoff. We're pretty happy with how it turned out, all things considered - the problem is that the consumer neither knows nor cares about the 'all things considered' part. All games are judged on a level playing field, as they should be.
This is an interesting point for us. There are games out there that have as little in the way of actual mechanics as Rotor (or less), yet feel more complete. Internally, when we debated whether or not we had enough to ship with, our comparison point was many of the twin stick shooters you see on the channel - a handful of levels, a handful of weapons, a catchy tune and away they go. What became clear to us as the reviews came in was that we were being judged on a different benchmark, in terms of content - people expected a bit more. What games like I MAED A G4ME have is a complete experience; Rotor, in contrast, perhaps felt like it was missing something. Whether it was the lack of game modes, mission types, or online score boards, to some the game felt aimless.
Some less than stellar code decisions. Whilst we were happy overall with things technically, a number of systems we built were less than ideal, and some were pressed into service in unforeseen ways. We were very happy with the event system and the ways in which it helped reduce system coupling, but there was a principle lesson we learned in its overuse - event systems are absolutely best used for fire-and-forget logic. Any attempts to control even more marginally complicated game state via game events will result in bugs, because it's almost inevitable that the finely-honed sequence of events that lead to valid state gets circumvented in an unforeseen edge case; audio that triggers on but not off, particle emitters that activate but don't deactivate etc. The lesson here is simple - event systems are great things, but they are not a substitute for direct collaboration between game subsystems where complex state must be managed. Just one example - even trying to manage something as simple as turning the boost sound on and off via events proved to be a rich vein of minor-but-irritating bugs.
Some other game systems were simply badly designed. Our combo system was a horrendous tangled mishmash of UI and game logic. It was the standard case of some rushed prototype work being pressed into full service, when really it should have been nuked from orbit. It's the only way to be sure. The results were pretty terrible - it was difficult to add new combos to the game and the logic for calculating player score was distributed all over the place and hard to track. Bad programmer - no biscuit!
The Top Downloads list. The commercial strategy for the XBox Live Indie Game marketplace is relatively uncomplicated. It's an impulse purchase channel, mostly (there are exceptions - TripleB's College Lacrosse series, for instance). Traditional PR activities are surprisingly ineffective at generating sales. Almost the most important thing you can do is have good box art, followed by decent screenshots (Which we nailed). Just as important is having a good trial (which we failed to do).
Games are guaranteed an initial period of high visibility via prominent placement in the New Releases list. From then on, it's up to the game to generate enough sales to feature in Top Downloads, or to rate highly enough to feature in Top Rated. On or around the 11th of February, the day of our release, the Top Downloads list froze - it stopped being updated - and it remained thus for several days. That meant that for the first five days of sales - our highest sales period - we did not feature at all, anywhere, on the top downloads list. On day 5 or so after release, we appeared at around position 22 or so, but by then our peak sales had passed.
We have no idea how much (if at all) we were affected by this. Given our low conversion rate, it seems safe to assume that we were our own worst enemy, rather than being victims here. But the experience has rammed the lesson home - the top downloads list, via social proof, is a virtuous circle - featuring highly in it more or less guarantees strong sales for a long time to come, and thus secures your place in the list. Equally, failing to break into either top downloads or top rated is a guarantee of sales obscurity.
Richard - Rotor was a failure, but a noble one. Though I prefer to think of it in other terms. Like Eddison, "I am not discouraged, because every wrong attempt discarded is another step forward".
Nick - As Richard is feeling quotatious, I'll add another "Do not look where you fell, but where you slipped". Here's to making a whole different set of mistakes next time.
Course heading for pocket starship...second star to the right, and straight on till morning.
