|
Wowsers. What a month. After about 9 months of continuous development, testing and tweaking and one aborted launch, Space Pirates has finally made it out in to the real world. It's considered "best practice" in a lot of Indie circles to examine exactly what happened, what went well, and what went badly. I'd like to think I've conducted myself pretty well throughout the experience, but every aspect of our work is up for questioning in this post mortem process. So we'll go back to the very beginning, consider the viability of the overall idea of Space Pirates, our ability to implement it and get it to market in a playable and reliable form, the impact of the various things we have to do on the XNA Creator's Club, our pre- and post- release media management, how we related to our customers and the impact on the MStar Games "brand".
Space Pirates was originally going to be our first XBLIG title, and had been through 2 "incarnations" by December 2008. Development had started in May 2008, long before the Community Games channel (as it was at the time) was launched. The initial version was supposed to be ready for the launch of the channel in (I think) November 2008 but it wasn't really ready to go and I'd suffered a real case of elephantitis of the code block and thought knew that I needed to refactor the entire project - partly becuase the code by that point was just a mess, and secondly because a lot of the engine wasn't going to meet the requirements of large playing area, complex mission and gameplay pump and frankly the graphics were poor. So I put Space Pirates to one side for a while and following a particularly boozy pre-Christmas poker game where I asserted that I could write a Carrum game in about 3 weeks, I started on what would become our first game, unsurprisingly called Carrum. Carrum was never realistically going to be a hit - it's not a well-known enough game in the western world to drive reasonable sales and it was our first release after all, and on a channel which hadn't settled down after launch. We got more good reviews than bad, and in my hubris I ignored the bad ones. But Carrum isn't the subject of this article so we'll move on now to the early "version 3" coding for Space Pirates.
As I've said it was pretty clear that the code base as it stood just wasn't up to the job in terms of features, framerate, reliability or extensibility. However I'd learned one hell of a lot from the first two attempts and from getting Carrum to the marketplace. So I threw all of the old code out and started again. At this point my aims were to code up a number of key elements and getting those elements stable while leaving room and scope for new features to be added. I still have my 2 notebooks from this period, and looking at the "To Do" lists, scrap notes on "move the HUD in 10 px to keep inside title safe screen area", class designs and so on is a revelation. I'm not going to scan all those notes in, but I certainly intend to keep them as a window on to the thought processes behind the game. I'll be referring to them in "loose" terms because they're largely written in a kind of personal vanacular which no-one but me would really get the flavor of.
The development went through a number of stages, which I would catagorise as follows:
1) Basic features - 3D space flight with basic HUD, player lasers and missiles, very basic enemy AI, planet texture generation and solar system data generation
2) Game-driving data logic (large-scale sector generation, which basically means taking about 4 numbers and generating a complete solar system from those numbers including market, tech level, law strength, pirate hostility)
3) Jumps between systems
4) AI combat (this was revisited several times throughout the dev cycle but this is where it started) including crate recovery and powerups
5) Onboard computer (largely in what I call "mandrill" form - initially non-functional representations of game features, which are coded as the required behaviours and structures are designed or discovered)
6) Market engine
7) Email engine
8) Mission engine
9) Shaders
10) Polish to "playtest" standard
Now this was the initial coding runthough. I had only rough design notes but Charlotta had pretty firm briefs for the artwork. Looking back this was MAJOR mistake number one. I've spoken many times about "strength of vision" for a game and I still believe it's vitally important that you have a strong vision but without planning and distillation of that vision it's useless, particularly with a game of this size and complexity. Between steps 1 and 10 there were plenty of long nights and I think I was working more hours a day than I wasn't, if you see what I mean. We got to step 10 and had a semi-reliable, semi-playable game and we went to an early playest. At this point ALL of the code should have been up for review, particularly and especially the control model. Control models are absolutely vital to the success of any game, so I'm going to devote a little thought to it here.
There are two interfaces between the player and the game. The screen is one, and how the player uses the controller and the effect that has on the game is the other. You can get away with mediocre onscreen work IF the controls provide a compelling and attractive gameplay experience. We had better than mediocre visuals, but the control model was, in retrospect, awful. Initially you couldn't customise it at all, and coupled with the amount of time you spend in space this was probably the biggest letdown in the game (aside from the code4 crashes) when we got to market. Why didn't I design and code it better? It's one of the easier things to do in XNA with even a little thought. Unfortunately I got caught out thinking "good enough is good enough" when it very rarely is good enough. Flightsim controls are a matter of personal preference at the best of times, and offering no customisation options was a huge mistake. I can actually remember the evening that I put the yaw attitude controls on the shoulder buttons - it was a Thursday evening, I was hosting our regular poker game, and some of the guys had a look at the game and asked for a yaw control. I coded it up in about 10 minutes and while it was a material improvement, it was only an improvement on a poor starting point. Hubris, hubris, hubris. So, MAJOR mistake number two was the control model.
At this point I was also writing the music for the game. Now I'm really very very proud of some of the tunes I produced for Space Pirates (some were lifted from Carrum but most of them are bespoke). But in a game of such size, where you want players to be engaged in the game for hours at a time, using a jukebox system is crazy. You need lots and lots and LOTS of music to have even a hope of getting away with it, the music only synchronises with the mood of the game by chance, and my particular brand of semi-ambient electronica isn't exactly a good bckground to epic space combat. I should have written a procedural music engine which reacts to gameplay. It wouldn't have been the biggest coding challenge in the game and would have injected much more vibrancy in to the gameplay experience. Not a major MAJOR mistake, but certainly lazy. I had written a game component for music management which "groped" the configured media libraries on the player's Xbox and had no trouble with it at all during testing, but as it turned out this was a MAJOR mistake. Number three to be exact. When paying punters who had network media libraries configured fired the game up, every item in the library was getting enumerated. This was taking anywhere between 2 and 10 minutes. One user even signed up to the XNA club (as a free member thankfully) to report the problem and it was this which tipped the scales and mde us decide to pull the game.
Playtest feedback is very, very hard to get in any volumes, especially since you have to be a premium member of the XNA club to download and test games - and most premium members are busy working on their own games. At any given time there can be anywhere between 25 and 55 games in playtest, with about 50 in peer review so testing feedback is hard to come by. But even from the early stages people were asking for a better control model. I put it on the list of things to "consider" (which for me normally means "I don't agree/can't find the time") and focussed on getting the game Best Practice compliant and crash-free. Also mentioned at this stage was the visibility (or lack of visibility) of motion in space. Another one on the "consider" list. So this then was MAJOR mistake number four - not listening to the testers, all of whom were very enthusiastic about the game generally and wanted to help.
Getting players in to a game is hard at the best of times. Both the trial mode and any how-to-play or tutorial stuff has to be good, snappy, memorable and compelling. In order to get some proper action going on in the trial (demo) mode, I simply inserted a conditional code block in to the player initialization routine to give them a higher than normal ranking and more powerful lasers. The result of that was that people were getting pounded sensless as soon as the game started. Stupid, really stupid, because the demo is how you convert downloads in to sales. Not only that, but the tutorial scripting had some oversights. The idea was to introduce the player to their laser cannon by letting them shoot a ship nd collecting the cargo, but I'd left the missile system enabled, and so if the player killed the "laser tutorial" enemy with a missile then the game would not advance. This was really dumb of me - I know perfectly well that gamers are apt to do all sorts of strange things, and having messages onscreen which say "press X to lock missile" and "press B to launch missile" when I didn't want the player to even think about the missiles yet was amazingly simple-minded. MAJOR mistake number five. Couple this with the complexity of playing the game and a msitake becomes something which really alienates players. What am I supposed to be doing? And once I've decided that, how do I do it? I don't know, I'm going to stop playing. Also we didn't put enough upsell oppertunities in the game when running in trial mode.
And finally (in this section at least), the Dreaded Mystery Code4 Crashes. This is probably the most inexcusable mistake of the lot, and has directly led to us producing what is pretty much bound to be a commercial failure. When we got the first crash reports I thought we might have some corrupted content, but there were 2 individual problems leading to the crashes. One was to do with the missile guidance code and one was due to a poorly coded pop-up message using an illegal character when you reach the top ranking. Two bugs like that are bad enough, but to compound the problem the missile crash usually happened during the tutorial/hyperspace licence phase of the game so if you missed the missile problem and continued playing, you're bound to get clobbered by the ranking message bug. Add to that a non-crashing bug in the market code which meant you could very quickly get enough cash to buy all the weapons and upgrades and you have a complete disaster on your hands. When I saw just how bad things were, I felt we had no choice in pulling the game. Our ratings were being dragged down, our downloads were falling off very very quickly, and while some lucky reviewers weren't getting the missile bug problem and actually quite liked the game it was obviously not helping the game to have it in the wild in such a poor state. Lazy testing, pure and simple. So there's MAJOR mistake number six.
December 2009 we went for an initial peer review. This was too early - moving to peer review should only happen when the game is in the final, complete, totally done and polished state and looking back Space Pirates was NOT in that state in erly December - it's really only just hit that point now after the second release. Going to peer review also means that you're mentally locking out any feature changes, because ANY substantial change in the code base should automatically bring 2 or 3 weeks in playtest to bed the changes in. We failed that peer review, and it's just as well because looking back we clearly hadn't spent long enough in playtest, or roped in enough mates to test the game locally. But fail we did, and went back to playtest, fixing the obvious "surface" problems as we went. This mistake was also compounded by the way that we returned to peer review at the earliest chance. We got through that time, with the version which caused all the stink.
So those are the mistakes we made in terms of development and release, but there are other areas I'd like to look at. It's starting to become clear that the indie channel is picking up. Toward the end of last year, the best selling indie games were competing with LIVE Arcade games in terms of volumes downloaded. But the games which did really well were the short and sweet, pick-up-and-play casual games which have made companies like PopCap so much money. Gamers seem now to be expecting short games on the service, and SPfT is the very antithesis of these titles. We boasted quite openly about 2,000 hours of gameplay, infinite this and endless that. Some bloggers were very interested, we had some great feedback, and things were looking positive. But the very size and complexity of the game is one of the things that drove us on to the rocks. So gamers really weren't expecting a game of the size we'd produced on the channel (aside from the committed band of Indie Games devotees, particularly on Twitter). You wouldn't even expect a game with the playable area of SPfT on LIVE Arcade for 1200 points, let alone on the indie channel for 240 points, and it makes it kind of hard to believe. So we were trying to sell a large, complex game to people expecting much smaller, casual game experiences. The success of games like "Your Doodles Are Bugged" really proves this point for me. It was the wrong game to write, and not just because of the image of the channel - it was far FAR too big a game for me to manage and test properly in the timeframe I was aiming for. If I were to write the game over again, I would want an entire year of development before going to playtest, and 4 months of playtest before going to peer review. Now I can put some of this down to the fact that the flavor of the channel was still being established and by the time it became clear we were 5 or 6 months down the line and I was "pot commited" as poker players say. That makes it hard to walk away from a project, hard to even acknowledge the problem, and to be honest I still had (and have) great belief in the game. But it should never be too late to admit you're wrong, and we certainly got a lesson in that after release.
Happily and somewhat strangely, things after we pulled the game got a lot better, as anyone who spends a little time wandering around the site here will see. We acknowledged the problems, listened to feedback, fixed the problems and implemented as many improvements as we could. I should admit at this point that I did actually sit and think "right, how much more dev time can I justify given that we're only going to sell a couple of hundred games if we're lucky?" - but to be honest 90% of the feedback was for stuff which a) had been suggested before and b) was embarrasingly easy to implement. The colourblind option for example - that was 5 lines of code for the new option, 3 lines of code in the heads-up routines, and bang it was done. Allowing the user to reassign attitude controls was also very very easy, proving again that we should have done it sooner.
So where are we now? Back on market for less than a day, it's obviously impossible to even estimate the sales we'll see. The only thing which is going to realistically save the project is if we get consistent high ratings for the game, and make it on to either the top rated or top downloads lists on the dashboard. I've been running an experiment using Google Adwords for Carrum and over three weeks we've seen about a 1.5% increase in downloads, and without wishing to alienate any reviewers it's a widely held opinion in the XNA community that web-based publicity doesn't translate in to sales. That's not to say that I shun reviews - they're another valuable form of feedback, usually expressed in very clear terms. But for downloads and sales, dashboard publicity is the only publicity which really matters.
So we move on to whatever lessons we've learned and how we're going to implement them. Firstly, Know Your Audience. Write what they want to play. That's no easy thing, and if it were we'd all be billionaire games magnates. But I'm not talking about getting too specific, I'm talking about the longevity and flavor of the game experience. There's no shame in selling a game for 80 points which gets played for 2 or 3 hours and is then forgotten. People are PLAYING the game, and that's why you do it. There's no shame in making a game which people play for 500 hours either provided it doesn't crash, but you've got soooo much more work on your hands coding, testing and selling the game to a possibly unresponsive audience you're better off in commercial terms devoting energy in to achievable goals which translate into sellable products which buys you the time and gets you the experience to build bigger games.
That leads on nicely to the next lesson - Know Your Limits and know how to work round them and expand them sensibly. In terms of technical programming ability I know I'm not the best in the world by a long chalk, but I'm far from a bad programmer and given time I can pretty much achieve whatever I want. But the size of a project presents it's own problems. If you change one line of code in one method, you then have to test everything downstream of that change. In a game the size of Space Pirates that can be literally tens of thousands of lines of code. That means you HAVE to not only set aside time for testing, but to PLAN WHAT YOU TEST AND HOW YOU TEST. Be aware of the workload challenges which come from every change, feature addition, tweak and fiddle and take the amount of time required to test those changes in to the very ground.
Thirdly, no-one gives feedback for giggles. No-one says "I think it would be better if..." unless they think it would be better. And you always want your game to be better. If we'd have listened to more of the early testing feedback we'd have avoided the (justified) controller model criticism, (justified) motion perception criticism and trial diffuculty issues. Those three problems alone are enough to make people think it's a failed game in the broadest sense - a game which is no fun to play. Ouch. We're still getting good feedback, even now. One of the peer reviewers this time out said it would be a good idea to seperate the load and save functions to stop people saving when they want to load, or vice versa (either of which can be a disaster for the gamer). We're going to work that into a new build over the next month, along with a minor tightening of the tutorials.
So it's has been a real education for us over the last few weeks. Would I write the game again? Probably not. Will there ever be a sequal to the game? I'm not sure. We'll need to see a whole lot of something to give me the time I fell I'd need to do it properly, and I've got some good ideas of what to start on after Blazin' Balls so we'll have to wait and see. We're already taking thge e testing feedback we've got for BB very seriously and it's a much smaller, simpler, less serious game than Space Pirates so hopefully we'll catch the casual games wave and recoup the ground and sales we've lost. It's easy to get carried away with the possibility of writing a hit - especially when bloggers say you could have a hit on your hands - and that's another lessen to learn. YOU don't decide if your game is a hit, but you certainly control if it's going to flop like a landed trout. When you undertake to write a game to be published on what is for me the greates gaming platform devised by man, you take on certain responsibilities to the rest of the indie dev community, the team who give us such an excellent framework in XNA, the MVPs on the Creators Club who work so hard to help us all out, the people who you hope will play your game, and above all to yourself. I pains me to admit it, but it took the drastic action of pulling the game for us to discharge that responsibility properly. We're determined that such a shameful event won't happen again, and I hope that other indie devs will read this, learn from it, and not repeat the many mistakes we made. I'm very sorry that we made those mistakes, but I'm hopeful that by identifying them we can produce better games. Because that's the only real reason to want to spend hour after hour after hour slaving over a hot keyboard and if the fruits of your labour are unstable, unplayable or unappealing then you have failed and it's one hell of a climb out of that hole if you're not willing to give in. Better get my climbing boots on.
Add this page to your favorite Social Bookmarking websites
|
