| |
|
|
||||
![]() |
||||||
| |
|
|||||
|
Using Groupings for Networked Gaming
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.
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. ________________________________________________________ |
|
|