What Went Wrong
1. Misjudging market conditions. When Multitude was founded in April 1996, there was a lot of buzz in the online game space. Mpath and Ten had big plans. Ultima Online was about to go through testing. We believed that an online-only game, sold directly to customers via the Internet, would be acceptable to the market when we eventually shipped. What we’ve discovered is that the online game market has not matured to the level that we expected. Very few online-only games have been released, with Ultima Online being the only clear success. We made two decisions early on that should have been reexamined when it became clear that customer acceptance of an online-only game was not a forgone conclusion.
Fireteam would have been more willingly accepted by the market if it contained some artificial intelligence (AI). With such an implementation, players could practice using the interface by themselves and, more importantly, players could practice as a team against AIs. With computer-controlled opponents in place, players could play offline or possibly on a LAN against computers opponents. Many users are intimidated by having to learn a new game while playing against other more experienced human players. AIs would have helped ease players into the online-only part of the game, providing a feature that many players expect to find in games today.
Fireteam also should have had a demo available on day one. As an online game, providing a demo presented an interesting problem because of the server issues. With a traditional game, developers can hand out a million demo disks and never think about the problems their users might experience. If we gave out a million demo disks, then we would need to have enough servers to support all those people that actually play the demo. We didn’t create an infrastructure to support a demo mode of Fireteam. Fireteam is a new type of game — people aren’t yet accustomed to online tactical team games with voice technology. We should have made some extra promotional effort to get potential users to make that initial leap and try out the game.
2. Managing contractors. Fireteam was a large and extremely challenging project. We had to look outside of our own company for help with certain parts of the project. Our mistake was in assuming that these experts held the same priorities as the rest of the development team. These groups have their own objectives and aren’t expected to understand the big picture or know how to create fun games. We realized that when working with contractors, we needed to give those contractors a very precise and clear specification. Because a good game design evolves over the course of a project, a project manager must constantly make certain that the contractors are following the latest version of the specification.
A 3D Studio Max layout of one of the maps. Our artists take the game-tested layout from Tile Edit to create backgrounds for each map.
As we were developing Fireteam, our attention was also focused on growing our new company. We found that it was easy to forget what the contractors were doing and how they fit into the project. We made the naïve assumption that they would be willing to work with an evolving specification. However, when a project is fix-bid, an external developer will only do so much tuning and reworking of code before he or she starts charging you for it. If you don’t manage this relationship closely, these costs add up very quickly. For example, the cost for developing the community web pages doubled from the original quote because the design evolved. The final version of the community web pages was great, but a more thoughtful initial design specification and better management of the process would have saved Multitude significant money and time.
3. Internet technical issues. The Internet poses significant problems for developers. Although we did our best in designing the game around the limitations of the Internet, we did have some technical problems. We originally designed Fireteam around TCP/IP because it’s a reliable transport protocol for network traffic. However, the reliability comes at a very high cost: retransmission times. If a packet is lost on the Internet (which happens a lot), it takes some time for the machines on both ends to realize this and resend the data. TCP/IP guarantees that all packets are in order; therefore, all of the packets after the lost packet will be delayed until the lost packet is sent again. In a fast-paced game such as Fireteam, lost packets can really cause problems. As soon as we started doing real Internet tests, we realized that we needed to start sending some packets unreliably via UDP. These packets could get lost, be out of order, or even duplicated, but they wouldn’t be delayed by other packets. We learned that different packets require different sets of reliability and timeliness, and that developers should use all the tools available to them, both TCP/IP and UDP. We initially labored under the idea that only one protocol should be used for the sake of simplicity, but it’s best to use the appropriate tool for each job.
Packet loss and high ping times are simply part of the reality of dealing with the Internet. You do your best to deal with these issues, but they’ll still cause you endless headaches as routers over which you have no control go down throughout the country. Many online games come with a little utility that does a trace on the route the packets take between a player’s machine and the servers. The information that the utility returns can help the player and his or her ISP determine where the bad connection is along that route. Developers should be aware that while they cannot fix the Internet infrastructure, it’s important to understand its limitations and deal with them as best they can.
4. Server spaghetti. Fireteam is a very complicated project with many processes running on both the client and the server. Add in the complication of the Internet, and you can get one confusing mess (Figure 1 shows just how complicated the Fireteam architecture is). We tried to break our server components down into smaller, more manageable pieces, each with its own function. We hired some experts in various disciplines to help us better understand parts of the server technology that were new to us. Our mistake was in thinking that these experts could just come in and solve our problems. As we busied ourselves with other parts of the project, it was easy for us to say to ourselves, "They know what they’re doing." In the end, however, the development team needs to understand the whole picture and how the pieces really fit together. One of Fireteam’s unique properties is that its server-side components run remotely at an ISP’s facilities. In order to debug something as complicated as our server architecture remotely, our key programmers — not just the client/server experts —needed to understand the whole system.
Figure 1. Fireteam' s technical architecture
One or two weeks spent planning and discussing the entire project with everyone involved will save you months down the road. The process of actually finishing and shipping a game is the hardest part of the development cycle; not many people actually know how to ship a game. During the final stage of the project, it’s essential that the entire team understand all the pieces of the puzzle.
5. Coping with the community. As I mentioned previously, when you create an online game, you need to embrace the community. At the same time, a direct connection with a community of testers who aren’t 100 percent aware of your objectives is something that needs to be managed very carefully. The testers will always want something different. When is the last time you played a game and said, "This is perfect"? I’ve often said that even my favorite game would be better if it had feature X. Most beta testers are young people who have a lot of time on their hands; that’s great for finding bugs, but it can also be a problem because some of them lack perspective. All players have an equal voice in the Fireteam lobby, so we had to watch over the lobby constantly because a few testers could ruin the fun for others, even to the point of instigating a mini online riot.
The home page for the Fireteam community web pages. Players can access a wealth of information about their statistics or other players’ statistics.
From what I can tell, some online game companies simply ignore their testers’ constant demands. After the experience of developing Fireteam, I must admit that this is a possible solution, though not an optimal one. Many of us on the development team spent many hours justifying our design decisions in order to educate the testers on why we were doing things a certain way. While this education does make them better testers, it takes up a lot of time. And it’s a dangerous black hole that you can be sucked into if you’re not careful. I believe that the true balance is to pay attention to your community, but sometimes to sacrifice the battle in order to win the war. You should involve your intended community in the evolution of your game, but don’t let it take over your design process or time.
Evolving Right Along
In building Fireteam, we as developers accomplished our goal of providing a complete online gaming experience with true team play, innovative voice technology, and extensive community building tools. The Internet offers brand new gaming experiences; game players can compete in ladders such as Battle.net or tournaments such as the PGL. Also, an online game lets players meet new friends with whom they can share true social gaming experiences.
However, the Internet introduces a lot of negatives to the gaming experience. Instead of lightning-fast LAN connections, players must now tolerate latency. Instead of a small group of friends, a player’s opponents may be complete strangers who aren’t polite and may even be cheaters. Because to the newness of this market, Fireteam may be ahead of its time. Or it may not have exactly hit the sweet spot that online multiplayer gaming should be. But, Fireteam has helped online game evolution along by demonstrating that voice technology does work and that team play and community are compelling elements that don’t have to be accidental.