Contents

Introduction What Went Right What Went Wrong A Unique Company Résumé

What Went Wrong

1. Poor scheduling and communication.

For most of its early history, Asheron's Call was the victim of poor project management. During the last year of development, a management reorganization took place that salvaged the project. Depending on how far back you look at the schedules, Asheron's Call was either one to two years late. This is attributable to a number of reasons, some of which I will explain momentarily.

When Microsoft and Turbine entered into the development agreement, neither side had any idea of the scope of the project. An initial list of milestones was drawn up by the Microsoft product manager and our development leads. Unfortunately, after the second milestone, deadlines were consistently missed. A lot of this was due simply to underestimating the time required for development tasks. This created a domino effect as we continually played catch-up, trying desperately to make up for lost time.

This is a shot of the Banderling being animated. He is performing a large swing to the front, and is caught in mid-backswing. The weapon is rooted out of the scene when the animation is preprocessed, as is the floor. Note the movement path of the weapon as it strikes.

This schedule free-fall continued into 1997 and forced us to re-evaluate the feature set. Unfortunately, feature cuts were made without considering the impact on the playability of the game. Ultimately, most of these features were added back into the game anyway, which took additional time due to the reallocation of team resources. The lesson here concerns the value of effective scheduling. Identify the risky areas in your schedule early, figure out the dependencies, and make sure you pad the time estimates for tasks.

Communication between Microsoft and Turbine was also a major factor. The teams were separated by about 3,000 miles and three time zones. Although weekly conference calls were scheduled, they lacked the collaborative mentality necessary for maintaining a successful relationship. E-mail threads were either ignored or else escalated into tense phone calls, and in some cases the bug-tracking database (RAID) was not used effectively.

Clearly, everyone would have benefited from more face-to-face time. E-mail - and even conference calls - are poor media for managing new and sensitive corporate relationships, especially ones between companies with such different corporate cultures. From a developer's perspective, it's always easy to blame the publisher for unrealistic expectations and bureaucracy. What's important to realize is that it is everyone's obligation to communicate expectations and problems before they escalate to the point of being a crisis.

2. Inexperienced development team.

None of the senior developers at Turbine (including me) had ever shipped a retail PC game. None. Many of the employees were students immediately out of college, or even college students completing a work-study program. This obviously was the source of several severe problems in the development of Asheron's Call.

This is a shot of the Banderling being animated. The motion graph shows the keyframes and the spline movement of the Banderling's chest as he makes a swing with a weapon.

It was nearly impossible for team leads to give realistic schedule estimates for tasks, since few of us had experience in professional software development. It was also initially difficult to get different teams from the programming, art, and design departments to communicate regularly with each other. The collegiate atmosphere made it very difficult for decisions to be made; meetings would happen and resolutions would seemingly be agreed upon, only to have those same questions asked in a subsequent meeting. No one likes unnecessary bureaucracy and giving up creative freedom, but ultimately one person needs to be given the authority to make a decision and hold people to it. A good supervisor takes into account the opinions of everyone involved; design by committee simply does not work.

Obviously, having a seasoned and experienced development team has innumerable advantages. While it's not critical that everyone on the development team have professional experience, at the very least team leads should have some form of professional experience. As it was, Turbine had to get by with raw talent, unabashed enthusiasm, and simply not knowing any better.

3. No feature iteration during development.

Many weaknesses of Asheron's Call at launch stemmed from the methodology we followed for feature completion. Features were scheduled by milestone and were expected to be completed in their entirety before other features were worked on. While this approach may work for more typical software applications, PC games rely on a host of interrelating systems that cannot be implemented in a vacuum.

Early shot of a mock-up UI that had very limited functionality. Some of the buttons worked, but mainly this was a prototype pasted over the 3D window, which was working at the time. The upper-left set of buttons were macros. The paper doll was hand drawn, and did not reflect the look of the character.

An example of this involved our melee combat system. This game feature was completely spec'd and implemented long before magic spells worked within the game, under the misguided assumption that it saves developer and test resources not to have to revisit completed features. Clearly, these two game systems needed to be tested and balanced in stages alongside each other, not independently.

Another example of this problem occurred during beta testing. A massively-multiplayer game cannot be considered adequately tested until thousands of players have participated in the game world for at least a few months. The first time Asheron's Call was exposed to this many users was when it went into beta testing. Unfortunately, we were placed in a code freeze situation during the beta test, and only the most serious bugs were fixed.

Both Microsoft and Turbine recognized many serious game balancing problems during beta, but at that point it was extremely difficult to make changes. This can be attributed to our tight schedule, but earlier beta tests would have accelerated the bug-finding process and resulted in a better balanced game. On future projects, Turbine is deploying a more iterative implementation process where rapid prototyping and early play-testing is encouraged.

4. An ambitious project lacking fundamental underlying technologies.

As one of the first massively-multiplayer 3D games, Asheron's Call was a bold undertaking. Several core components were still theoretical when the project was planned. Things like dynamically load-balanced servers and continuous, uninterrupted outdoor environments were still unproven concepts when we committed to them for Asheron's Call. Furthermore, we had to create our own 3D graphics engine, a latency-friendly network layer, and physics and game rule systems that would all work within a client/server model.

This is an incredibly early shot of our Character Generator screen. Much of the interface has remained unchanged, but the same cannot be said of the faces. This was probably version one of the face images. Turbine has gone through a couple of versions since then.

We learned very quickly why there hadn't been a game like Asheron's Call before us: It was damned hard to develop such a game. I don't think committing to a less aggressive feature set was the right solution, though. Instead, we should have acknowledged up front that R&D efforts are fundamentally hard to schedule, and been more flexible with our development schedule. With this in mind, we could have created more realistic estimates and done a better job managing expectations within and outside Turbine.

5.No documented high-level feature statement.

Because Asheron's Call had such a long and evolving development cycle, it was difficult to keep all the documentation up-to-date. To compound the matter, the project never had an official feature set as part of the development contract with Microsoft. The technical design document process and high-level feature overviews were basically skipped. This created severe problems when it came to prioritizing which features were important. We constantly had to justify features, and we had no documentation to fall back on to resolve our discussions.

It was difficult to play-balance the game since that aspect of development took place after the code was frozen

Without a high-level vision statement it was also very difficult to educate new employees about the game. There was a sort of oral tradition to initiate new employees that had been passed down for so long that it just became part of our company's culture. This was partially possible because the concept of a 3D graphical MUD intuitively made sense to a lot of people. Unfortunately, it was very difficult to explain what Asheron's Call was about to people who didn't understand this concept or had their own ideas about how things should be done. Having a documented vision statement and a description of the high-level feature set is absolutely essential for any title.

________________________________________________________

A Unique Company Résumé