Click through to a bigger version so you can actually read the text.
During the development of APB we had a whiteboard in our kitchen/break area on the third-floor of Realtime Worlds offices that served as a bit of a community scratch-pad for daftness. This particularly entry was started by me after we shipped but just prior to our investors pulling the plug and plunging the company into administration. The contents are contributions from all the development staff who worked on APB. We also had a “What Went Right?’ board which is sadly consigned to the mists of time.
The complaints can be broadly broken down into three areas Design, Business and Production. All opinion from here on is my own and comes with the caveats that everything happened at least three years ago and I’m writing from my own specific perspective. I worked on APB for five years as a Software Engineer specializing in Gameplay by the end of which I was probably doing a job closer to that of today’s Technical Designers.
Design
“What IS APB?”
“No clear vision”
I think this is key, naturally, because I wrote the first question! The project went under at least two major shifts of focus in the five years I worked on it but only had one (bad) prototyping period. The creative vision was extremely woolly and the end result is a mediocre third-person shooter surrounded by some odd and mismatching features. Each time we refocused we should have sat down and reprototyped the new “vision” extensively both to get a firm idea of what we wanted to make and also to know what we needed to build. This lack of cohesive and shared creative vision has been the scuppering of a whole bunch of projects I’ve been a witness too.
“Overwhelming arrogance across the board in the face of criticism.”
“‘As Designed’ and ‘Post Launch'” – Unpopular ways to close design defects.
“It’s not that type of game.” – A phrase often uttered in the face of criticism.
In my experience I’ve not seen very many development teams who weren’t very aware they were making a lemon. APB’s was no exception and our bug database teemed with obvious design flaws and people voiced criticism of the game even before we had a whole load of beta testers giving us very valuable feedback. Internal feedback is too easily dismissed and by the time we got external feedback we were basically too busy fixing defects and optimizing the game to make any sweeping changes. In hindsight the writing was on the wall for the company about 6-8 months before APB shipped. The key take away here is that criticism and how you use it should be the defining factor in how you should shape your game. That doesn’t mean you need to respond to everything people say or implement their suggestions but study the root causes of what is being complained about and look for ways to improve the experience. The very worst thing you can do with criticism is ignore it. One of the games main critics in the development team actually went on to be Lead Designer for the successful GamersFirst reboot.
Business
“Not understanding what makes people pay money for online games.”
“Not enough value to pay an on-going fee.”
I actually think this criticism is wide of the mark. GamersFirst demonstrate very obviously that there is a viable business model for APB as they’re still running it three years later! Sadly it’s not the one we chose to use. Plus we made ourselves look foolish by telling people the game wouldn’t have a subscription and then having a subscription option as part of the business model.
“Marketing”
Very simple, we didn’t market the game we had made, we marketed an ideal. If we didn’t have a design vision we had a very clear vision we marketed which was essentially GTA online. We setup elaborate videos, had tightly scripted demos run through by our ‘Publisher QA’ that involved shooting to miss a lot. If we had successfully made that game we’d probably be rolling around in piles of money and I’d be writing a very different blog!
Production
“Software Engineering versus Games Development.”
I spent a lot of my first year at Realtime Worlds exhaustively writing Requirements, Specification and Designs for everything I made. To the point where I’d have to send documents out for review and sign off. I’d get revisions back for rework with no substantive disagreement in them other than grammar use! It was a colossal waste of time and resources as well as being a known about and demonstrably bad practice for software development. Documentation isn’t a terrible thing but Big Design Up Front (BDUF) is. This will be a reoccuring theme.
“Not enough iterative development/prototyping.”
“No #1 focus on fun gameplay.”
“No focus on core gameplay.”
Its no accident that I’m a big fan of making things to prove they work and learn about the problem space. APB was very instructive about the problems that can be created by designing something, implementing it and then calling the results done and good. BDUF strikes again and in this case made worse by being in siloed teams. At one point the Gameplay Engineering team I was on had a pretty tricky working relationship with our Game Design team! This is not a conducive setup to making a good game! Cross-functional teams that are genuinely collaborative just work much better. The sense of shared ownership and ability to rapidly iterate on something make for better games and a shorter development time.
A consequence of siloed teams that couldn’t iterate is that our core game never got much love or attention. Sometimes it also felt like people didn’t consider it a problem. For example the first thing suggested by one of the senior designers to work on after the game shipped wasn’t an improvement of the core mechanics but a Zombie themed mode! After APB launched along with a bunch of other people I put together a proposal about how we could improve the core game. We proved the effectiveness of a cross-functional team freed from the constraints of bureaucracy by improving the core experience an awful lot. Sadly only a small part of this made it out before Realtime was shuttered and a lot of the work we did was incorporated into the first few released of APB: Reloaded.
“Hierarchical Management Structure.”
“Branching by Team rather than Feature.”
At first these two don’t seem related but they have the same root cause. As the reliance on BDUF and siloed teams suggests we had a deeply old-school approach to development right down to running the closest thing to a waterfall methodology I’ve actually seen in the wild. Hence why we ended up branching by team rather than feature and had a overly heavy management approach. I won’t labor the point because the problems associated with this approach were well documented decades before we used it. The solution is to become more agile.
What Went Right?
Actually an awful lot. A lot of the technology in APB has still yet to be surpassed. The level of customization was outstanding, not many games ship with a music sequencer! There was a decent niche game under the baggage of a bunch of poorly integrated systems that the GamersFirst guys appear to have made into a sustainable free-to-play business. There are a bunch of triumphs against adversity in any failed project and APB was too choked full of talent for that not to happen.
meheleventyone 