Dunn started off by comparing ArenaNet to InGen, the fictional company behind the creation of Jurassic Park. In the comparison, he talked about how InGen had to deal with the difficulties of running a major theme park combined with a major zoo. Dunn said that's a luxury compared to the technical struggles his team members had to conquer when building Guild Wars 2. They needed a great engine, great gameplay, great features, and because they use don't use a subscription-based model, they had to focus on the best performance and efficiency with a reasonable cost.
Dunn broke down ArenaNet's system design into three areas: server infrastructure, client metrics, and content tools. He started off by explaining the patch system, which allows anyone on the team to do a build at any time. That was extremely helpful during beta, and while there are limitations on who can put forth a build now that the game is live, patching is a smooth process because of what was learned during beta. He showed a graph illustrating the wave-like peaks and valleys of players logged in and asked us if we could spot the moment on the graph when the team launched a new patch. It wasn't until the next slide, which zoomed in on one of the peaks, that you could spot a small dip in the users, which immediately shot back up to where it had previously been. He explained that players get a window of time before they need to patch, so if a player is out in the world, he might get a few minutes, whereas if he's in a dungeon, he'll get a longer grace period. In short, patches can be done more regularly, yet they're less disruptive to gameplay.
Another slide showed metrics for memory use during beta. The team was focused on making the best use of the memory it had purchased, which helps keep the costs reasonable. During beta, the devs spotted right away that over time, they were using too much memory per user. As a result, they were able to make adjustments. Dunn showed a graph of the memory use in the live game, which was dramatically different and showed nice even bars compared to the massive slopes of the beta slide.
Next, he explained that the use of bot testing helped the devs find bugs and test content. They used Amazon EC2 to create instances and generate hundreds of thousands of bots, and they put them to work in every possible way in the game. He added that Amazon didn't exactly like the rigorous use of its service, so ArenaNet had to stay one step ahead and jump from server to server in order to continue bot testing. Overall, though, bot testing, along with internal testers and beta testers, helped the team pinpoint bugs and gameplay issues to get the game ready for launch.
Dunn went on to explain that it was a huge challenge to design Guild Wars 2
because there were 10 different environments to work on ranging from character creation and cutscenes to the interiors (5-mans) and underwater zones and large maps. In all of these, the team had to make sure the characters looked good, even though the environments were drastically different.
The developers also needed to make sure gameplay was as smooth as possible for the players, and they used metrics to help that cause. They were able to collect information about the systems of every player, and while it was all anonymous, they could tell how the game ran on the wide variety of game systems that players owned. The metrics also told them what game settings players used, when they turned up certain options, and when they turned down others, which helps ANet work to improve framerate in problem areas. The team even mapped out the framerates on an overlay map of the in-game world. Green areas were places on the map where framerate was good, while yellow and red areas signaled lower framerates. In the slide, much of the map was green, but you could see small dots of red here and there, which were probably towns or dynamic event locations. From there, analysts could pinpoint problem areas and focus on making gameplay smoother.
Even when it comes to designing and editing the game, ArenaNet built tools that helped designers edit and then play as they go. They can set up dynamic events and place NPCs and interactive objects and then immediately test them out. This means devs can adjust as they go and keep track of the total number of items used in any given dynamic event.
Overall, Dunn argued, ArenaNet worked hard to build an infrastructure that allows it to edit quickly and collaborate easily. Once a developer had something in place that she was happy with, she could push it to QA for testing and then add it to the live servers through the patch system, which gives users the latest update with virtually no downtime. The tools the studio built to design, edit, and test the game helped not only the team but the customers, who get gameplay that's all the better for it.Massively sent two plucky game journalists -- Beau Hindman and Karen Bryan -- to Austin, Texas, for this year's GDC Online, where they'll be reporting back on MMO trends, community theory, old favorites, and new classics. Stay tuned for even more highlights from the show!