I finally feel that I’ve got enough perspective on things to put together some thoughts on what went wrong at Realtime Worlds. It’s been a tough piece to put together, because the scope of the question is just so big. In the end, I’ve settled for a set of observations that are cultural in nature. With my knowledge of what happened, these are the closest I feel I can get to root causes.

It does raise the questions of why we had these cultural problems, and when they crept in. These are pretty hard questions. One thing many old-timers agree on is that the investment felt like a turning point for the worse. Perhaps we just didn’t know how to handle the investment. Perhaps the new senior managers brought in were harmful. Or perhaps our resulting growth rate simply exposed latent problems that had been there from the start. Either way, the money ended up feeling like a curse, another theme you’ll see running through this piece.

There are some things I am definitely not going to talk about. For example, I am not going to discuss APB’s design flaws. For one thing, I wasn’t close enough to the decisions made there to understand how we went wrong – and if I’m being honest, I don’t play online games enough to claim any great understanding. Fortunately, there are plenty of good opinion pieces on those elsewhere.

In any case, I don’t think specific design flaws were the root cause of our problems. While it’s true that without them, APB probably could have sold much better and I wouldn’t be writing this piece, it would be a very lazy attempt to explain our failure. It would be tantamount to pointing the finger at a small number of staff and saying “it was all your fault”.

I don’t buy that. There were 300 of us, some of us there for years, and we spent over $100m. The problems had to run deeper than that. I believe our poor decisions (and there were plenty of them, not just in design!) are best explained as patterns of behaviour within the context of a system that was not healthy.

Community

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.

We had deeply ingrained approaches to development that derived from the boxed-product world. We had a deep fear of letting anyone find out anything about our game until the last possible minute. “Release early and iterate”, a proven success model for online software, was anathema to RTW. We would constantly find ways to avoid showing features off or talking openly about the product. Press interest was built by incredibly elaborately-constructed demos, choreographed with clockwork precision. Our team of QA ninjas trained night and day so as to be able to act out the same scripted combat scenario on demand (they were actually pretty impressive to watch doing this!). At first, the press would just watch these sessions as examples of “live” gameplay. Later, they’d be allowed to join in, but would be so outnumbered by our staff that they would be forced to stay on the rails of our script.

As another example, I’ve heard people complain that we should have considered the business model for APB much earlier on. The truth is that we did – we had it figured out years before release – we just decided not to tell anyone, and inadvertently gave gamers the impression it was going to be free to play. They weren’t too happy when they found out.

We wouldn’t even set up small, regular user tests to observe people playing our game. We couldn’t show anything to anyone until it was ABSOLUTELY PERFECT. The irony, of course, is that by not showing your work, you never get to perfect it – particularly with online software, whose design can only be validated by having a large number of people use it.

Stop, that’s my job!

Living amongst this culture were a significant number of employees that did get online community. This is obviously going to be the case in a company full of software developers and keen gamers, many of them actively involved in other online communities. Our best attempts to interact with the outside world were when we occasionally let some of our QA and development staff loose on the forums and in-game.

The really sad part is that, more often than not, we prevented or discouraged such people from helping out by building these bizarre internal divisions between groups. I think this was a misguided attempt to imitate how other big online games run things. 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.)

Stern-sounding codes of conduct were emailed around that, whatever their intent, in practice scared many developers away from interacting directly with our users. Not to worry, though, because our Community team was on the case! Except if a forum post was about a bug, because that wasn’t their area … bugs were for Customer Support. Who, naturally, didn’t read the forums … because that was Community’s job!

I can see how these rules make sense for big, established online games. Codes of conduct in-game to prevent developers abusing their inside position for in-game success. Codes of conduct on forums to prevent accidental PR disasters. Clear divisions between groups and processes for reporting bugs to ensure smooth handling of large volumes of data.

But these are all problems that successful games have. We had a different problem – engaging with our community and getting people to give a shit about our product – and all these rules and divisions just got in the way.

That’s all for today. Next time, I’ll continue this theme of broken corporate structure, and uncover some more ways we got it wrong …

Part 2 and Part 3 are now up.