Wondering what happened within Realtime Worlds which could take a once celebrated developer, and an anticipated game, and destroy both in under 4 months? Well Luke Halliwell has the answers for you. This ex-Realtime Worlds employee has taken to the internets, through his blog, to bring you the entire sordid tale.
It makes for some fantastic reading, not just for us journalistic types, but for anyone who may just find themselves in the position of developing and publishing a game. It reads like a comprehensive "Not to-do" list for game development, and should probably be mailed around to every office in the Industry.
Some interesting points of note:
Let’s start with our attitude to the outside world. Here we were, supposedly trying to build these great online games, but we were stunningly inept at outside interaction. There were some high-profile release window gaffes – like attempting to BAN THE INTERNET FROM REVIEWING APB for a whole week – and then telling the world that they just didn’t understand our game – but it’s what we didn’t say that was most harmful of all. We had this incredible secrecy around everything we did. I liked this approach for early development – no point boasting about stuff that’s not ready – but at some point, with an online product, you have to engage your users.
On listening to community feedback:
For example, I once heard one of our fine QA staff being berated for – wait for it – emailing a summary of forum activity around QA. This guy had gone through every single forum post looking for complaints that might signify bugs, and summarised it in a plan of action for the QA team to investigate further. Commendable stuff indeed, but here he was, being told that ONLY OUR DEDICATED COMMUNITY TEAM were allowed to summarise forum activity for others (usually in the form of a number from 1-100 representing how favourable forum feedback was that week. Never found out how they computed that or what we were supposed to do with it.)
On communication with their companies financial sector:
Once we took that investment, responsibility for anything with a £ sign in front fell to a small group of “business” people, most of them in our US office. We’d ask these people how much gameplay bandwidth cost us on APB, in case we needed to optimise our usage to make the game profitable. We’d ask how much patch bandwidth on our CDN cost, in case it was worth adding bittorrent support to our patching system. We’d ask how much running a server cost, in case it made business sense to spend more time on server code optimisation and reduce the number of servers we needed.Every time, we’d be met with a condescending pat on the shoulders. “Don’t you worry about that, son, you just get on with making the game. Let us take care of the money.” We asked, and we asked, and we asked, and were eventually point-blank refused, and later just ignored, on these and other important questions.
The complacency showed through in so many ways. We were complacent about game design, papering over APB’s obvious shortcomings and telling ourselves it would somehow come together at the last minute before release (an argument that was strengthened by the experience of seeing Crackdown do just that). We were complacent about business planning, deciding to spend all our investment getting APB to launch, assuming that we would sell zillions of copies and over-spending on server hardware. When we were told we were being made redundant, we were told something along the lines of “the market is just so bad right now … we could never have predicted this … even our worst sales projections were so much higher than this”. I think that was supposed to be consolation but it was just complacent, and dumb.
Its really worth going through the entire thing so Have a read for yourself.
Source: Luke Halliwell's Weblog