NetworkGamer.Id in XNA Game Studio 3.0

All network games need to send data from one machine to another. To make sense of this data, it is important to know which player it refers to.

For peer-to-peer games, this is trivial. When you call LocalNetworkGamer.ReceiveData, you get an output parameter telling you who the packet is from.

Client/server games do not have it so easy. When the server sends me a packet saying "Leto is dead, Paul is charging you with the shotgun, and Jessica is camping by the spawn point", he needs some way to refer to Leto, Paul, and Jessica, so we can both agree which players we are talking about.

The gamertag is not a good way to do this. For one thing, gamertags are strings, which are bulky to send over the network. For another, although LIVE gamertags are required to be unique, system link or Zune sessions can use local profiles, which may not have unique names.

In the 2.0 framework, the easiest solution was to send an index into the NetworkSession.AllGamers collection. The order of gamers is synchronized across machines, so these indices will always match up, except for one problem scenario:

  • Alice sends Bill a packet which refers to Charlie
  • While the packet is in flight, Charlie leaves the session
  • By the time the packet is delivered to Bill, the gamer indices are no longer the same as when it was sent

This situation is rare, but would cause a brief glitch any time it occurred.

Of course you can fix this by allocating your own unique identifiers and writing code to manually synchronize them over the network, but that is fiddly and a pain to implement.

In the 3.0 framework, we added a new NetworkGamer.Id property to solve this problem. This is a byte identifier, unique for every gamer, which is automatically synchronized across all machines in the session. Because it is an arbitrary ID rather than an index, it will not change as other people join or leave the session, so it can reliably identify one gamer to another.

Coming soon to a website near you: an updated version of our client/server sample that uses this new property.

Comments (2)

  1. BenS1 says:

    Excellent, that’ll help me simplify my network code quite a lot!

  2. Rim says:

    Somehow the image of Paul with a shotgun and the Lady Jessica camping is an afront to my fond geeky recollection of that tale, but in a good way 🙂

    Looks like the network library is shaping up very nicely, I’m looking forward to checking it out soon. From the sound of it, it should go a long way in detraumatizing me from my Managed DirectPlay experiences.

Skip to main content