Contents

Origins of the Team What Went Right What Went Wrong Onwards to the Next Projects

What Went Wrong

1. Staying on schedule

Drakan was originally slated for release in February 1999, but ended up being released six months later. Even with careful scheduling and task planning, we failed to meet the final deadlines. Part of the problem was that we didn’t account for the time the team would spend creating versions of the game for E3 and for magazine and Internet demos. Each demo pulled nearly two weeks of time away from our normally scheduled tasks. The majority of the scheduling problems were due to feature creep and other improvements that were considered necessary during development.

In March 1998, the design team was faced with a mountain of work ahead in order to complete the 14 original levels as designed. After careful consideration, the designers decided to spend their efforts on enlarging and improving upon the ten best level designs. They also ended up cutting many features that did not show much game-play promise. The dart gun and the boomerang weapons were among those eliminated from the game. Even though these tasks had already been mostly completed (in terms of code) for several months, they had not yet been put into the game. By the end of the project, the designers did not have adequate time left to work with programmers to play-balance those features, and the art staff had not done any work on them either. So they got cut. The decision allowed us to focus on improving the weapons that worked well, such as the bows and arrows. We now know that it’s critical that programming tasks get put into the game and tested almost immediately so that their effectiveness can be realized early on. This lack of coordination between designers, artists, and programmers often caused problems during development. Some of this was because our design document wasn’t updated when weapons, levels, or AI were redesigned.

The war giant towered above Rynn and had multiple high-resolution texture maps.

The initial AI programming followed the original design document, but didn’t work well when put into the game. It wasn’t until our designers worked with the AI programmers to figure out exactly what they wanted for our combat system that the AI really came together. This kind of collaboration should have occurred at the beginning of the AI programming process and the lack of it caused moderate delays.

Drakan’s art team often rebuilt geometry and model textures, sometimes up to three times before they were satisfactory. This may have been partially due to Surreal’s high aesthetic standards, but a lack of consistent artistic vision is also to blame. Drakan had lots of character conceptual art, but no “art bible” to document all the models and environments for the game. This meant that if our art lead was not satisfied with work of another artist, he would often rebuild it himself. At various points during development his time was spread thin across many different tasks. In addition, the art team went through communication problems and power struggles that hampered the coordination of the team.

2. Inadequate testing

Although we tracked bugs internally before and during the alpha and beta releases, Psygnosis was responsible for the bulk of the testing after alpha. For a game as vast and ambitious as Drakan, the time that we allocated for testing was inadequate. Multiplayer and collision detection issues, in particular, were not given enough testing time. When the final shipping date approached, we reluctantly agreed to allow some noncritical bugs to slip through to the gold master in the interest of meeting the deadline. A patch was inevitable.

Other testing complications added to the problems. As Psygnosis was being reorganized by its parent company, Sony Computer Entertainment Europe (SCEE), half the testing department was let go and merged with SCEE’s U.K. testing group. This caused minor hiccups in tester allocations to Drakan. Since the testing team was located in Europe, communication was difficult, and often messages were delayed by a day or two. Bug reports were sent to us via Microsoft Excel worksheets, which were converted from an Oracle database that sat isolated on their LAN in the U.K. Often the Excel worksheets would come to us corrupted or would have incomplete bug descriptions. Bug responses from Surreal’s programmers had to be tracked carefully and entered back into the Oracle database by hand.

The island level showing the organic qualities of the terrain and textures.

We kept our own internal database at Surreal using Outlook forms in special public folders on our Exchange Server. We ended up generating almost 1,000 internal design, art, and programming bugs during the entire project. This rivaled the number of bugs generated by the testing team during alpha and beta. The internal system worked very well, but it could have been more useful if the Psygnosis testers had access to the system as well. We tried getting on-site testers, and some of the U.K. team did come to Surreal for about a week. But it was too late in the project and for too short a time to be effective.

3. Collision detection and response

One of the biggest chores for the testing team was to make sure that all of our hundreds of 3D models could not be penetrated by missiles, NPCs, or Rynn. Each model had to be properly bounded by the artist during the model’s construction, a process which took about 20 percent of their modeling time to construct. Bounding was generated in our custom modeling tool and approximated the polygons of the model using a hierarchy (tree) of bounding spheres or oriented bounding boxes (OBBs). This made the collision detection system very fast and accurate, but it also meant that if an artist made a mistake in the bounding tree, collision detection might not work. To say this created a testing challenge would be an understatement.

Lighting effects created varying moods. This bridge model was reused from the islands level.

Even though the engine was capable of rendering arbitrary meshes, the collision detection system was not designed to handle some of the detailed meshes that the artists produced. Some of our AI used the bounding information at the lowest level, while Rynn’s collision response system used a polygon-accurate analysis, which didn’t work perfectly for some complex models. Frame-rate variations across machines also caused differing results, making it hard for programmers to reproduce the bugs and correct the problems. Finally, our indoor/outdoor landscape system created some challenging collision-detection problems that we hadn’t anticipated when it was originally designed.

4. Multiplayer

Considered by some the Achilles’ heel of Drakan, its multiplayer suffered from developmental neglect. For the game’s multiplayer to have succeeded, the design, art, and programming teams would have had to spend at least twice as much time on it than they did. The two multiplayer designers did most of their level and weapon work during the alpha and beta periods. The same designers also created most of the artwork for the multiplayer effects and weapons. Any game-related bugs that came up were fixed by our single network programmer, who already had his hands full optimizing the underlying network engine. Most of these game-related problems arose because the same weapons were used in both single and multiplayer games, but the original programmers were not careful to make them “network aware.”

A multiplayer ground deathmatch level.

Originally, we thought that DirectPlay was the easiest networking solution for us. But as the design got more complex, we found that DirectPlay just did not work well for us. DirectPlay was a debugging nightmare. The network programmer’s machine crashed several times per day when debugging the networking code and we couldn’t determine what was causing that to happen. It wasn’t until we switched to Winsock that we discovered that the crashes were caused by DirectPlay. DirectPlay also caused a serious problem for us while we debugged the game under the first release of Windows 98. DirectPlay actually caused the system clock to slow down. This caused the game to run slower and sucked up tons of CPU cycles, forcing a reboot. When put to the test, DirectPlay also had issues with firewalls, which we were not able to resolve. Under certain circumstances, the way DirectPlay handled the message queues sometimes caused messages to pile up until the application hung. Perhaps Microsoft will be addressing these issues in future releases.

It was clear even before alpha that the networking code would need to be rewritten. In the final design, we only used the TCP/IP portion of DirectPlay, and we used a Winsock front end to handle communication with the master server. We proposed to Psygnosis that they give us more time to convert the system over to Winsock, to which they replied yes — but only as a downloadable patch, since the additional work would have delayed the game’s release. The Winsock conversion was not finished until a month after Drakan’s release, and greatly stabilized the multiplayer experience. This, combined with the release of the level editor and mods, has created a resurgence in multiplayer support, but it will never be as good as it could have been.

5. Badly executed story

Although the overall story concept of Drakan was a great, the script and execution of the idea were lacking. We hired a movie scriptwriter to do the initial work on the script, but he was not familiar with the fantasy genre and did not have a firm grasp on Alan’s vision for the design. From there, the script was edited and rewritten by several more people: members of Surreal, members of Psygnosis, even one of the voice actors. Under pressure to finish the script, it was completed with cheesy one-liners and other badly written dialog. Once it had been recorded by the voice actors, it was very difficult to re-record lines that were badly written or acted. Some were re-recorded, but that was a luxury we could only afford for the completely failed lines. The voice acting was difficult to get right, because just as some of the writers had almost no vision of the game, the voice actors likewise had little understanding of the characters they portrayed.

Dragon’s-eye view of a fantastical island formation.

Another problem with the execution of the story was that most of the construction of the cutscenes was left until the last minute, since all the levels had to be “geometry complete” before cutscenes could be created. This meant that the scenes at the end of the game were hastily done, and some even had to be cut from the game.

________________________________________________________

Onwards to the Next Projects