Using DirectPlay

Implement DirectPlay in your application using the following steps:

1Request that the user of your application select a communication medium for the game.

You can identify the service providers installed on a personal computer by using the DirectPlayEnumerate function.

2Create a DirectPlay object based on the selected provider by calling the DirectPlayCreate function and specifying the appropriate service provider GUID.

Calling the DirectPlayCreate function causes DirectPlay to load the library for the service provider selected.

3Request game information, including preferences, from the user. You can store this information in the dwUser member of the DPSESSIONDESC structure.

If the user wants to start a new game, skip to step six.

4Enumerate existing sessions (existing games that a user can join) by using the IDirectPlay::EnumSessions method.

5If the user wants to join a game enumerated by the IDirectPlay::EnumSessions method, connect to that game by using the IDirectPlay::Open method and specify the DPOPEN_OPENSESSION flag.

6If the user wants to start a new game, create a game by using the IDirectPlay::Open method and specifying the DPOPEN_CREATESESSION flag.

7Create a player or players.

A player's communication capabilities can be determined using the IDirectPlay::GetCaps and IDirectPlay::GetPlayerCaps methods. Other players can be discovered by using the IDirectPlay::EnumPlayers method.

8Exchange messages among players, including the name server (player ID 0), by using the IDirectPlay::Send and IDirectPlay::Receive methods.

Each player is associated with a friendly name and a formal name that the game can use for tasks such as error reporting and scoring. The game can exchange messages among players by using the unique player ID that is created with the player. The service provider, not DirectPlay, limits the number of players that can participate in a gaming session. In the current implementation, the number of players ranges from 16 for a modem connection to 256 for a network connection.

When using DirectPlay, you are able to define most messages in order to address the particular needs of the game. However, some system messages are defined by DirectPlay. For example, when a player quits or joins a game, that game receives a system message that provides the player's name and the status change that has just occurred. System messages are always sent by the name server, a virtual player whose player ID is 0. System messages start with a 32-bit value that identifies the type of message. Constants that represent system messages begin with 'DPSYS_', and have a corresponding message structure that must be used to interpret them.

Broadcasting a message to all players in the game is simply a matter of sending a message to the name server (that is, to player ID 0). Players receiving a message broadcast in this way see the message as having come from the player who sent it, not from the name server.

DirectPlay does not attempt to provide a general approach for game synchronization; to do so would necessarily impose limitations on the game-playing paradigm. However, the system includes some services that are designed to help you with these tasks. For example, you can specify a notification event when your application creates a player, then use the Microsoft Win32 function WaitForSingleObject to find out whether there is a message pending for that player.