Networked computer games present new data distribution challenges to the developer. With stand-alone games, all game information is available in one place, on one computer, all the time. When designing networked games, however, the developer has to consider what information the other players on the network need, when they need it, and how to deliver it to them. The easy way out is to broadcast everything you can think of to everyone on the network as often as possible. This keeps everyone synchronized, but quickly consumes all available bandwidth - not a good idea for groups of players dialed in to the Internet. The other extreme is to carefully consider each packet of data and to send it only to other players who really need it. This approach makes efficient use of bandwidth, but deciding who needs data and who doesn't chews up so many of the sender's CPU cycles that no processing power is left to play the game.

There is a middle ground, however, and it's called "grouping." Grouping allows networked games to route essential data among the players while making efficient use of both network and CPU resources. In some cases, underlying network service providers support an efficient way to distribute grouped data; this is called multicasting. In other cases, games may be limited to broadcast or point-to-point connections. Still, grouping can provide some efficiencies. Grouping can help a networked game scale up to include large numbers of players. This article covers logical ways to group data and the schemes used to implement grouped communications.

What Is a Grouping?

The first thing to consider is why you'd want to group data at all. If you're developing a one-on-one boxing game played on two computers, then chances are both players will need to know everything about one another; every move and every change will need to be exchanged. It's a very different situation, however, if you're building a large-scale space war scenario with lots of players. You may have a very high-performance spaceship and may be doing rolls in seven dimensions, but if I'm far away from the maneuvers, you just look like a dot to me. You're too far away for me to see your detailed maneuvers, so I don't need to know the details of your motion. Furthermore, if neither one of us can see the "cloaked" alien spaceship hovering nearby, then there's really no need for him to send us his position at all until he becomes visible. The bottom line is that if you think about various players' data requirements, you can save a lot of bandwidth, network interrupt overhead, and CPU processing by only sending information to the players who need it. The trick is to make routing decisions without spending more cycles than you stand to save.

How Is Grouped Data Transmitted?

Before we get into the mechanics of creating data groups, let's look at how grouped data can be distributed among computers on a network. Ordinarily, each sender can communicate with other players on the network using either broadcast, one-to-everyone communications such as UDP/IP or via one-to-one links such as TCP/IP. For computer games, what you really want is one-to-many or many-to-one communications. Multicast-capable networks implement this capability at the physical level, using addressing schemes that allow a single transmitted message to be routed to many receivers while being ignored by others, even others on the same LAN. Even in environments where multicasting is not available, or in server-based game environments, the server can still effectively implement multicasting. A single transmission is reflected (or "exploded") back to multiple receivers, albeit with added latency. Figure 1 shows multicast transmission and its server/exploder equivalent.

Figure 1. Multicast transmission vs. server message exploding.

The DirectPlay component of DirectX that provides an abstraction of one-to-many and many-to-one messaging is called, not surprisingly, group management. DirectPlay's group management methods provide the ability to define, join, leave, and send data to groups of players. To create a group in DirectPlay, any player within a session calls IDirectPlay3::CreateGroup. After a group is created, any of the other players in the session can join the group via the IDirectPlay3::AddPlayerToGroup method or leave via the IDirectPlay3::DeletePlayerFromGroup method. Any player can then send a message to all the other players in the group via a single call to IDirectPlay3::Send. Note that these interfaces don't change with the underlying communication mechanism of the service provider; rather, DirectPlay abstracts away whether a group is implemented as a physical multicast group, an exploder group, a broadcast that's filtered on the receiver end, or some other mechanism.