In this reprint from the July 1997 issue of Game Developer magazine, id Software alum Ned Purdom reveals how Quake was first brought to the Total Entertainment Network in the late 1990s.
In this reprint from the July 1997 issue of Game Developer magazine, id Software alum Ned Purdom reveals how Quake was first brought to the Total Entertainment Network in the late 1990s. Whether played across LANs, the Internet, or on commercial gaming services, multiplayer gaming is hot. For the gamer, what better way to express competitive impulses than to establish Web-wide bragging rights? For the developer, online play offers a means of extending the life of a particular title, realizing royalty revenue, and enhancing retail box sales. As a result, many developers now offer titles with some level of online support. While the online capabilities provided by game developers are usually a sound basis for online play, game networks are able to optimize these games by taking advantage of rapidly changing networking infrastructure, technologies, and expertise. But this is a matter of focus as well as expertise; while game developers have their hands full dealing with the issues associated with title development, game networks tackle the technical and social challenges of creating the best online gaming experience. Porting a game to a commercial network isn't as simple as just installing the game onto a network server and turning it on. High-performance server hardware and proprietary network APIs are commonplace to game networks, and these present hurdles for game developers who are looking to host their game on a commercial service. In this case study, we'll look at how one game network, the San Francisco-based Total Entertainment Network (TEN), ported id's Quake to their network.
Many aspects of Quake make it compelling from a game play standpoint, and quite challenging from the perspective of a developer getting it ready for online play on a managed network service. The game itself is quite open, fostering continuous evolution. id Software spurred this evolution by providing their own programming language, QuakeC. While Quake is online-ready out-of-the-box, the developers at TEN felt that several enhancements were warranted. First, they wanted to accommodate a broad spectrum of online gamers -- those with relatively slow 14.4 baud modem connections through those fortunate enough to have high-speed T1 lines. Equally important, TEN wanted Quake players on their service to have a similarly consistent game-playing experience from wherever they happened to connect. As TEN began bringing the title online, it was apparent that the major areas of technical focus would be porting Quake to TEN's network infrastructure, optimizing gameplay performance, and providing value-added or unique elements to differentiate the TEN Quake experience from other online efforts. At the same time, the company knew that they had to make readily available those constantly evolving elements of Quake that the playing public demands.
Before actually porting Quake to its network infrastructure, the developers at TEN first had to determine what architecture would best support the game. After considerable deliberation, it was decided that a forked server approach would provide the best gaming experience. In this scenario, multiple arena servers are set up and a separate instance of the game is created within one of the arena servers when a new game is started. Once this architectural approach was decided, the process of moving Quake to the network proceeded. Developing a low-level network transport for Quake was the first requirement in the porting process. Since TEN requires Windows 95 on client machines, and Quake is a DOS application, a special interface had to be provided to transfer UDP data between the DOS application and Windows' WinSock. Quake uses the UDP Internet protocol as its networking backbone. A slightly older version of the commonly used TCP/IP protocol, UDP offers several advantages for game play. With UDP, each packet is transmitted one time, but there is some packet loss associated with the protocol. Conversely, TCP/IP retransmits packets to ensure reliability -- a key consideration in mission-critical networking. What UDP lacks in reliability, it gains in performance, which is certainly a major issue for gamers. With a lot of packet loss on the network, UDP is more effective for game play because it does not try to resend stale data. By using the TEN datagram library for DOS, the company was able to provide this data transfer using a virtual device driver and a hidden Windows application. The datagram library allows a DOS application to use the UDP networking protocol within Windows 95. The development of this special code was one of the first efforts undertaken. The code to implement this can be found on the Game Developer web site.
Providing enough server resources to accommodate peak playing loads was the next concern. TEN anticipated that up to 700 players would play Quake in a given day, with some 140- 150 playing simultaneously. This load was certain to tax Quake's DOS/Windows/NT server environment. The TEN service -- for all games -- is based on the Sun/Solaris operating system running on ultraSPARC servers. This platform was initially selected for its superior performance and because TEN felt it could provide better support if it only had to manage one operating system. Not only does the Solaris/SPARC platform offer the performance necessary to handle the anticipated load for Quake play, but equally important, it provides the scalability to accommodate growth in Quake play, as well as TEN's overall subscriber base. So the decision to port the DOS Quake server to Sun's Solaris operating system was an easy one to make. The process of readying Quake for TEN's network infrastructure and porting the game to the Solaris operating system was conducted by four of TEN's engineers. The total process required about three months. The first month was devoted to setting up a build environment similar to id's. Once the source code was obtained from id, the porting process, testing, and optimizing required another two months, and was conducted exclusively by TEN. Because of the inherent quality of Quake, including its modular architecture, network readiness and extremely clean code, the game engine itself was virtually unchanged as it became part of the TEN service. As a result, TEN developers focused primarily on optimizing data transfer to improve game performance, and adding features for enhancing network play. Once complete, TEN forwarded a CD of its game version to id. The executables were downloaded and id staffers played Quake on the TEN service. At this point, the game was approved by id. According to developers at TEN, id's role was limited to providing source code and approving the final game. However, they note that because Quake was such a good starting point and an Internet-ready title, TEN's role was one of integration and enhancement. TEN notes that in some cases, network capabilities must be added or code cleaned up so that a title is suitable for online play.
Once Quake was ported to the network infrastructure, TEN realized that attracting and keeping players was the next -- and ongoing -- technical challenge. Part of this challenge was providing a unique, inviting, and evolving environment for an extremely broad range of Quake players. An equally important challenge was optimizing Quake performance, player by player, during actual online play. This required striking a balance between the design and game playing elements specified by id Software -- logos and other art -- and those added for the TEN service. A major concern was making the service easy to use for the new player, while providing flexibility and extensibility for the more experienced Quake gamer. The opening game screen allows players to chat among themselves prior to establishing a game. When ready, even a game involving several mods can be started with a few mouse clicks, as opposed to command lines common to standard Internet play.
Inherent in online play is a desire among participants to play against others; a natural outfall from this competition is player rankings. Rather than simply construct a database ranking players by wins and losses, TEN extended the Quake server to gather a stream of data from each game. This information includes what weapons were used, who shot whom, percentage of success, and so forth. With these rankings, a Quake community grew, not unlike the communities associated with statistics-driven sports rotisserie leagues.
Game developers conduct quality assurance throughout the development process. While these tests address the stability issues associated with the game, TEN needed to get real-world insight on high-load, multiplayer gaming. Consequently, TEN enlisted hundreds of presubscribers to stress test the entire service, the user interface, and early versions of Quake and other titles. During early product testing, evaluators reported performance problems, especially at modem speeds below 28.8 baud. The company considered this a serious issue given the large number of gamers with 14.4 baud modems. Evaluators noted a "skating" feeling during play, where they did not have complete control. Other manifestations included sound dropping out, which prevented players from hearing each other's approach. The Quake server was continually broadcasting complete game updates to clients during play. It was apparent that there was simply too much data for slower modems to handle. TEN carefully studied bandwidth profiles during game play and determined that the only way to provide consistently good performance on slower modems was to fundamentally change the way that Quake sends data to players. The result was a new capability called Dynamic Attribute Reduction Technology (DART). With DART, the TEN Quake server keeps track of what each and every client knows at each point during a game. For instance, the server keeps track of whether a player has opened or closed a particular door, and avoids resending that information until the object has changed its state. DART filters out redundant (unchanged) data and permits the server to broadcast only changed information. In effect, DART optimizes the game for each particular player continuously throughout a game by reducing the information sent to players by up to 70%. Furthermore, DART allows TEN to manage server loads better and handle more players on the existing servers. See the code examples on the Game Developer web site, which show how DART is typically implemented. Moving forward with Quake and other online titles, it's clear that the major technical issues for service providers such as TEN are how best to maintain the original spirit of the game, maximize the online experience of each supported game, keep pace with the evolution of online games, and do so in a simple-to-use and reliable manner.
You May Also Like
