APB Tutorial Part II

In a previous article I identified many of the failings in APB’s tutorial and initial user experience. The extent of how poor it was does leave you asking the question how did anyone deem it shippable and why wasn’t it addressed earlier? This isn’t something unique to this area but to the entirity of APB (combat and missions being notable examples).

When I joined Realtime Worlds in early 2008 the talk was of being 6 months away from release. Of course it would be over two years until APB would actually be released and throughout this period of time the project was always about 6 months away from release. It became a bit of a joke to be honest. The result of this pronlongued “nearly there” stage was that production and management were generally opposed to the idea of making significant changes. Despite there being obvious flaws in the mission and combat systems there was a reluctance to really address them. Quick fixes could be afforded but that was about it.

A lot of the systems were derived from early prototypes. Combat and missions are prime suspects here. APB changed a lot from its original conception, however the early prototypes for core systems weren’t sufficiently adapted. Combat was still based on a system designed for a hard lock game and missions on a prototype to test a few ideas.

When it became clear that tutorials weren’t up to the job, only quick fixes were considered. The best “bang for buck” that would take no more than a week or two of development time. There was no willingness to step back and think “we need a new approach”. If it didn’t work, try try the same approach over and over. Either that or it was just removed from the game. Saying that, there was a significant difference of “before and after” when we did set aside a few weeks of development time for to improve the experience. The original starting point when I started work on tutorials was just messages that looked rather similar to HUD messages so naturally having a tutorial district, improved visual styling, highlighting and so forth was a substantial improvement. However it was still polishing a turd. There was still no guided learning or structure. We still relied on players to read these messages that appeared seemingly randomly.

Out of the many systems in the game, tutorials maybe got the most rehauls (unless you count reskinning the UI & HUD about a dozen times). Before the point where I got lumped with the system another approach had been tried, using popup messages. However that was even more unpopular than boring ignorable text messages so it was scrapped.

The problem maybe was that tutorials weren’t sufficiently considered from the outset. A boot camp style tutorial was request at a point along with other ideas but everything was put on a back burner. The original text messages idea was put in as a prototype and left in for some time. After it was clear that such a shoddy system WILL impact revenues, quick fixes were sought and applied.

So there you have it. Realtime Worlds weren’t lazy, nor were the design team clueless or QA unable to observe the issues. Pretty much everyone on the team knew it wasn’t good enough and tests with people outside of APB confirmed this. However poor project management led to the core issue not being sufficiently addressed. For sure, there were mistakes, poor designs and a host of other reasons but that isn’t anything new to a game’s development cycle. Prototypes should be evaluate by design and if they don’t work, try again. Once something has been made, it can be iterated upon. They shouldn’t be tried out, found to not work and then decide “should we keep it or drop it?”.

As the game evolved from Ganglands, an urban themed MMO, into APB, the persistent online action title the early protypes and designs didn’t really fit. With a constant need to release soon, insufficient effort was put into taking a step back and saying “this isn’t good enough, let’s fix it” and on the occassions when a system was deemed worth fixing, only something quick could be considered.

Leave a Reply