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 network packets.
- Changes session state such as which players are in the session and who is currently talking.
- Raises managed events for any significant state changes.
- Returns 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, allowing 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 first creating a session, a game must specify the maxium 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
- 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 will return an AvailableNetworkSessionCollection containing a maximum of 25 AvailableNetworkSession objects, containing the following data about each session:
- Gamertag of the host.
- Number of players in the network session.
- Number of free public (between 2 and 31) and private slots.
- Quality of service information. This information is filled in over time, so search results will initially be returned 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 when:
- when a player connects or disconnects using GamerJoined and GamerLeft.
- when the game has changed state between lobby, gameplay, and post-gameplay modes using GameStarted, GameEnded, and SessionEnded
- when 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 and provides events to notify titles when the state changes. While in the lobby, each player can use IsReady to signal that they are ready to move from the lobby and into the game. The host will can check IsEveryoneReady to determine whether 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.