Electronic Design

Standard Takes Aim At Game Playing Over The Internet

Game players have progressed beyond the confines of a single PC and now use the Internet as a medium to play action and strategy games. But the Internet's unpredictability leaves gamers longing for improved real-time interaction. As a result of an informal conversation between gaming company Valve LLC of Kirkland, Wash.—creator of the popular game Half-Life—and Cisco Systems Inc. of San Jose, Calif., the two companies have crafted a preliminary proof-of-concept document that defines an approach to improving gaming and other interactive applications over the Internet.

The PowerPlay 1.0 "standard" deals with how routers, access concentrators, and real-world service provisioning impacts network performance. It also suggests methods for enhancing end-to-end behavior. The 1.0 version of the standard is a proof of concept to show the benefits that game developers, ISPs, and router/access concentrator providers can reap by closer cooperation. The real advance will come with version 2.0. This eventual update will build on the issues developed in the 1.0 version, which is being used to define open standards for quality of service (QoS) and the functionality necessary to make the Internet a better platform for consumer entertainment.

Other Companies Signing Up
Some of the issues the 2.0 version will examine include the integration of high-quality voice, the use of multicast IP for further network optimization, new lower-latency modem standards, and bandwidth reservation. Version 2.0 of the PowerPlay specification will be an open industry standard that will encompass a wide group of developers, service providers, and hardware manufacturers. Bioware (developer of Baldur's Gate), Ensemble Studios (creator of Age of Empires 1 and 2), Epic (developer of Unreal and Unreal Tournament), and many other companies will participate in the 2.0 development.

With PowerPlay 1.0, designers are focusing on latency and packet loss—as well as on their impact on the gamer's experience. Both are key issues when game clients connect to the game servers. Some of the aspects that Valve discovered in dealing with Cisco resulted in changes to its gaming software. Designers were able to tune the flow-control algorithms, decouple the server and client frames, aggressively perform bit-wise compression on the data, move some functionality to the client from the server, and thread the network queue. Cisco is currently preparing a white paper that will address in greater depth what can be done by the infrastructure companies to improve networking and service provisioning.

No two approaches to implementing games over the Internet are identical. But by detailing one approach, the creators of the PowerPlay standard hope to provide food for thought. The PowerPlay working group also will be able to start with a group of concepts that can serve as a catalyst for future discussions.

Meanwhile, flow control only matters if the communication scheme is employing user datagram protocol (UDP)—as opposed to transmission control protocol (TCP), which performs its own flow control and can be susceptible to lots of stalling. The critical issue with UDP is to compensate for header overhead when metering out bandwidth. This translates into a simple guideline: true packet size equals payload size plus UDP header size.

Once the packet is placed on the wire, compute how long the wait should be before the next packet can be placed on the wire. This should be done for the user's link speed (in bytes/s). For game servers, that may require going one step further. Instead of delaying up to a full maximum client update rate, the next packet is transmitted as soon as the previous packet is cleared. If a client receives 20 updates/s, there is a 50-ms delay. If the server is running at more than 20 frames/s, the user will get another packet as soon as possible from the server instead of waiting for that 50-ms period. Modem users with a point-to-point protocol (PPP) connection must also add the PPP header overhead and/or framing overhead to the true packet size when computing the next available send time.

Receive Queue Thread
Client rendering operations and complex server computations can degrade a game server's ability to appropriately timestamp incoming packets. This results in jerky object movements, degrading the user experience—especially in multiplayer games. To deal with this, the network receive queue can be placed in its own thread. When packets arrive at that thread, the timestamp for the received payload is more precisely marked with a high-precision clock. This is particularly important for player actions that come into a centralized server where the server frame rate dips below approximately 20 frames/s. This can occur if a user is running a nondedicated server on an underpowered computer.

To move game data faster, it should be compressed as aggressively as possible. Packet size, including the overhead bits, is very important to the QoS afforded a user. For modem-link players, it's absolutely vital. A bit-level data stream, then, is essential. Furthermore, coherent data (sending the same block of data to the client more than once per session) should be composed into a shorthand signal. On the client, data can be played back on demand by invoking the shorthand signal only. This can save a considerable amount of data movement, but it requires a fair amount of coordination between the server and client software.

These are just a few of the issues PowerPlay 1.0 is tackling. For a full copy of the working document, contact Gabe Newell, the managing director for Valve, at (425) 889-9642, ext. 101 or [email protected] Additional information can be found at www.powerplayinfo.com.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.