Network Session Management
Any matchmaking scenario involves the creation of a network session. Network sessions give XNA Framework games access to profile data on all the gamers in a potential game.
- Sends the network packets.
- Changes the session state, such as which players are in the session and which player is talking currently.
- Raises the managed events for any significant state changes.
- Returns the incoming packet data.
This explicit update call allows the framework to synchronize the session so that packet-received and state-change events will never be raised asynchronously with the rest of the game code. This allows developers to program against the network session object without any threading concerns.
Session updates are kept separate from the gamer services system pumping for two reasons:
- To clarify when session events will be raised.
- To allow developers the option to update the session from a background worker thread, which allows these developers the option to run this in parallel with the main game update.
To play a networked game with other people, the game needs a way to publish an instance of the game for others to discover the instance and join the game. This matchmaking and peer discovery mechanism is available through the NetworkSession.Find and NetworkSession.BeginFind methods, which return a collection of AvailableNetworkSession instances. You may examine the properties of each AvailableNetworkSession, and pass a suitable AvailableNetworkSession to Join to join the session.
The NetworkSession object exposes a collection of player instances, along with events indicating when players join or leave the session. There are properties for querying which player is the host (NetworkSession.Host), and for determining which players are local players signed on to the same machine and physically located together (NetworkGamer.IsLocal).
The XNA Framework exposes basic functionality for programmatic friends list access:
When you first create a session, a game must specify the maximum number of local players that it supports (1, 2, 3, or 4). The framework will automatically add up to this number of profiles to the session, and keep this up to date if the sign-in state changes. If there are more signed-in profiles than the game wants, only the lower-numbered profiles will be added to the session. If extra players sign after the session is created the players will not be added. If the host player signs off, the session will either be torn down or a host migration will take place depending on whether the NetworkSession.AllowHostMigration option is enabled.
The XNA Framework supports four kinds of sessions:
- System link
- Xbox LIVE unranked session
- LIVE ranked session
The same matchmaking API is used for both LIVE and system link session types. The session type must be specified when creating or searching for sessions, and only sessions of an identical type will be returned by the query.
Local sessions are interesting for games that want to build both networking and local split-screen multiplayer on top of the same infrastructure. This allows this type of game to implement both online and offline game modes using the same framework session interfaces.
The XNA Framework provides a single fixed matchmaking query in the form of a NetworkSessionProperties collection that represents the desired session to match. This collection is passed to the NetworkSession.Find and NetworkSession.BeginFind static methods. These methods return an AvailableNetworkSessionCollection containing a maximum of 25 AvailableNetworkSession objects, which in turn contain the following data about each session:
- Gamertag of the host.
- Number of players in the network session.
- Number of free public and private slots. On Windows- and Xbox 360-based games, the supported range is between 2 and 31. On the Zune platform, the supported range is between 2 and 8.
- Quality of service information. This information is filled in over time, so search results will be returned initially without quality of service data, that will then become available at a later time.
One important task in writing a networked game is managing the session, or instance, of the game. The events on the NetworkSession object allow you to be aware of the following:
- A player connects or disconnects using GamerJoined and GamerLeft
- The game has changed state between lobby, gameplay, and post-gameplay modes using GameStarted, GameEnded, and SessionEnded
- The network machine hosting the session changes using HostChanged
The XNA Framework keeps track of whether the session is in the lobby or actually playing the game. It enables events to notify titles when the state changes. While in the lobby, each player can use IsReady to signal that he or she is ready to move from the lobby and into the game. The host can check IsEveryoneReady to see if all the players are ready to begin the game.
Each network session can use AllowJoinInProgress to specify whether the game supports join-in-progress. This is used in conjunction with the lobby versus play state to automatically update the session joinability status on the matchmaking servers.