What Went Right

1. Combining team play and voice together. Fireteam’s design focus was on team play. Just as we’ve seen in team-oriented sports, the cooperative nature of playing as a member of a team has proven to be a very addicting and powerful gaming design. Fireteam’s cooperative nature was a symbiosis of our voice technology and team play design. We needed to give people a reason to talk to strangers on the Internet. Team play was that reason; it gives people the ability to say "Watch out behind you!" or "Good job!" Teammates can share the joys of victory or the agonies of defeat. Because there is no button to push to transmit your voice (it transmits automatically when you talk), players can hear the spontaneity of teammates yelling and laughing. Emotion comes across very clearly with voice and is definitely preferable to typing in ALL CAPS or emoticons. The ease of vocal interaction brings the team together.

In a fast-paced tactical game such as Fireteam, players don’t have time to coordinate movements with the keyboard. Without voice, you limit team communication to select macro keys (or players who can type very fast). In Fireteam’s Basetag scenario, for example, teammates protecting the base can give instant information on where the enemy is making its attack. Over the course of their lives, people have already learned how to talk; it’s an interface they understand. Vocal communication doesn’t require a key card list for communication hotkeys, just a microphone to talk into.

One of Fireteam's successes was its integration of voice communication

2. Designing the project around constraints. Multitude was founded to do a game for the Internet. The Internet offers many problems that we had to solve in order to make a fun game. The biggest technical problem was Internet latency. Fundamentally, latency causes each player to have something different on his or her screen, so there is always a delay between a player performing an action and the other players seeing that action carried out.

For example, we decided early on that we wanted the game to respond as quickly as possible. When you shoot at something during a Fireteam game, you’ll see instantly whether or not you hit your target. The actual damage will take a small amount of time to be applied to the target. So it’s possible that you’ll see someone get shot, walk a bit, and then die. The game cannot provide a perfect view of the world to each player; that’s not possible given the limitations of the Internet. So we decided not to show players their opponents’ health. If you can see that your opponent has only a sliver of health and that one shot could kill him or her, then you would expect that player to die instantly with the next shot you made. By hiding opponents health from our players, we hide the perception of lag.

A project’s constraints can also be exploited to the project’s benefits. Because the constraint was that we needed to be on the Internet, we created the community web pages to give players the ability to look at their statistics and create Fireteam Companies. We wanted a strong community for Fireteam, and the community web pages were an easy way for people to have an identity in this community and to join a group of other players.

3. Spending sufficient time to develop tools. We used several proprietary tools to create Fireteam’s game environments. Early on, we spent a lot of time building easy-to-use tools that allowed us to create content rapidly. Our internal testers used these tools to create new arenas for Fireteam. And because Fireteam is an online game, we were able to test new maps very quickly with our beta testers.

This is Tile Edit, our basic world builder. We quickly prototype the physical layout of the maps with this tool. It’s very easy to move walls around to achieve the right game balance.

With an online game, game balance is crucial. Players will find any competitive edge and map imbalance they can and exploit it. Especially in an online game with a lobby, word of cheats or advantages spreads very fast. Your tools must allow you to tweak your maps, so you can quickly fix any small problems. Many of our maps changed during the course of testing as our testers would point out weaknesses that they found.

I can recall a particular controversy over whether Gunball (a Fireteam scenario similar to combat football) was balanced enough. Many of the advanced players were complaining that Gunball’s offense was too hard. Using our Tile Edit tool, we quickly created a few maps with two endzones for each team (Gunball maps normally only have one endzone). Through testing the new maps, we discovered some of the problems with Gunball were unrelated to the maps themselves, but that the offense simply had a disadvantage when trying to score. So instead of redoing all of our map designs, we tuned the Gunball game by giving the Gunball carrier a protective drone.

We take the output from 3D Studio Max (with our plug-ins) and, with our proprietary ZHMPView tool, convert the files to a format that Fireteam can read.

An added bonus of easy-to-use tools is that you can make them available to the public and let your players customize the game and create their own content. We haven’t yet taken that last step, because we’re not sure how we want to store the maps on our servers and present them to the community.

4.Managing risk: voice technology. The biggest risk in developing Fireteam has been the voice technology. Many smart people initially said it was impossible, but we knew that the game’s design objective was a cooperative team game, and voice was very important to accomplishing the goal. So Fireteam’s first technical project was to determine whether or not voice on the Internet was even possible. Once we had the technology running over the Internet, we still faced the possibility that it wouldn’t work with the wide spectrum of sound cards in the market.

We tried to minimize the problems that voice would cause by providing users with a tool that would configure the sound card and microphone during installation. Multitude was very aware (almost scared) of the fact that Fireteam would represent most users’ first use of voice technology on their computers. So we had to make sure that it worked on as many sound cards as possible and that it was very easy to use. We eventually released Fireteam as two executables — one for systems with DirectSound and one for systems without it.

One feature that we explicitly did not put into the game was the ability for players to talk to their opponents. We wanted players’ first experience with voice to be a positive one. We didn’t think a 12-year old telling you where to put your gun in his shrieking voice would convince people that voice is a wonderful addition to gaming. Similarly, people asked for the ability to eavesdrop or steal another team’s radio and listen to the other team. This feature would impel team members not to talk if they believed they were being monitored. These types of behavior would weaken the voice feature.

5. Promoting community. If you’re going to design an online game, you cannot ignore the community. Any online game, from Fireteam to Poker on AOL to Ultima Online, will have a community because the players will be able to communicate with each other. Online game developers should take advantage the fact that their product inherently has a community. Most online games go through alpha and beta online tests mostly to test the software, but few deliberately create or test the community aspects of a product. Players are not only a source of revenue for a project, but they are a feature of your game. In an online environment, the players’ game experiences are dictated by their teammates and the opponents against whom they play. You want the players to follow guidelines and really care about the game and the community. If your population is full of a bunch of player killers, then that’s the experience that the players will get.

Multitude succeeded in developing community-enabling tools. We spent significant time and discussion on our lobby and community web pages. Given Fireteam’s team nature, we wanted players to feel a sense of belonging so that they would want to save each other’s lives. The Fireteam product is not just the game itself. The game is an important piece of the Fireteam experience, but it’s only a piece. The community plays a large part of the whole experience.