Michael Edwards
Microsoft Corporation
November 7, 1996
The folks on the DirectX team have been hard at work these last few months adding important new features to DirectPlay--features that have moved it light-years ahead of DirectPlay 2.0. If you don't particularly enjoy writing code that doesn't add core competency to your product, you owe it to yourself to take a look at DirectPlay: a good thing just got a whole lot better. In the coming months I'll be writing some in-depth articles designed to help you take advantage of DirectPlay. For now, let's take a shallow dive into the pool of new DirectPlay functionality--watch your head!
The coolest new feature of DirectPlay 3.0 has to be the game lobby. Anything that simplifies the black art of finding games sessions has to be a good thing. Of course, anyone who can actually figure out how to get online probably doesn't need much help, but that's another story altogether. DirectPlay 3.0 adds a brand-new COM interface that supports the concept of a game lobby. The game lobby consists of two parts--a server side and a client side.
The lobby-server software resides either with an online gaming service or simply runs on a host machine somewhere on the network. The lobby server's job is to track ongoing DirectPlay game sessions and the people playing them as well as those gamers on the sidelines looking for someone to frag.
The lobby-client software resides locally, on the user's machine, and manages communication between the user and the server. The user chooses and joins an online game using the client software; the software also manages other interactive features offered by the game provider, such as chatting between players who are gathering for a game or searching for a particular player or a team currently online. When the user chooses to play a particular DirectPlay-compatible game, the game must be installed on the user's machine and registered as "lobby-able." When the user selects a particular game session, the game asks the lobby client for the IDirectPlay 2.0 interface connected to that session.
The DirectPlay game-lobby architecture standardizes how games communicate with online game services. That means the game developer has to write the code to provide DirectPlay lobby compatibility only once. The lobby also encourages online game providers to continue competing in the areas of customer service and cool features. Of course, standardization doesn't prevent game developers from cutting exclusive deals with particular providers, but it does encourage the availability of more games with more providers, which makes everybody happier--especially the end user.
But a picture--even a shoot-'em-up picture--is worth a thousand words. If you're running an ActiveX-compatible browser, take a look at the Internet Gaming Zone , a free online game service using DirectPlay 3.0's game-lobby feature.
Augmenting its current lineup of service providers for IPX and modem play, the DirectPlay team added support for player matching via a direct serial linkup as well as via TCP/IP connections over the Internet. Support for Windows machines in close physical proximity as well as for those dispersed across the planet means that now more than ever the developer has to design around inconsistent and relatively long latencies when designing games for the Internet.
If you're among the many people who have complained about DirectPlay's lack of support for guaranteed messaging, good news: sending messages now comes with a guarantee because the built-in TCP/IP service provider supports the DPSEND_GUARANTEED flag. But be warned--this synchronous operation can take two to three times longer than a nonguaranteed operation.
Another friendly warning regarding guaranteed messaging: you may need to plan for the fact that future releases of DirectPlay will emulate guaranteed messaging on top of protocols such as IPX that do not have this feature built in, so guaranteed latencies will likely vary. Another important change in this area is that all messages are now checked for integrity, and nonguaranteed packets are ditched if they've been corrupted (therefore the DPSEND_TRYONCE flag is nuked for DirectPlay 3.0).
In redesigning DirectPlay 3.0's architecture, developers borrowed a great deal from DirectDraw and DirectSound in order to achieve trouble-free, network-independent communication. Testing emphasized heavy API stress testing (many tests were automated to run for days at a time) and use of the Internet service provider. Market research and developer feedback helped determine areas of focus.
Reducing the load on the network is the goal of multicasting, enabled by DirectPlay 3.0's service-provider architecture. Multicasting is not, however, currently supported with Winsock on Win95, so the built-in network providers do not include this ability. In the direct-access spirit of DirectX, you can inquire whether the service provider supports group messaging through multicasting by checking the DPCAPS_GROUPOPTIMIZED flag in the DPCAPS structure.
DirectPlay 3.0 added a feature to make replicating data to remote players a lot easier: your application can now associate data with players and groups of players and propagate that data automatically to all remote players. New DirectPlay APIs that set and get remote data also allow you to specify that the data be maintained only locally. DirectPlay 3.0 also allows the user to create friendly names for player groups, making it easier to track teams in a session.
Another much-requested feature has been added: the user can now get session properties in the middle of a game. And to make this even more interesting, DirectPlay 3.0 gives you several new session properties to play with. The real party animals will be glad to hear that the user can host multiple sessions with DirectPlay 3.0. Since host migration is a new session property, bailing out of a session won't be such a pain: new players and applications can continue to join the session the next time the host's kid yanks the power cord. If the game can do without tracking source and destination player ids for messages, a new session property eliminates them from all headers.
Another session property, the "keep-alive" option, removes remote players who become lost in the network noise and no longer respond to a game. "Lost" players are notified and removed from the session. By the way, the DirectX team members ran out of time before they could complete support for changing session capabilities after the session has begun. This means the DPSESSION_NEWPLAYERSDISABLED and DPSESSION_JOINDISABLED flags are not yet useful in preventing I_Don't_Race_Without_Crashing_Into_Somebody_Real_Often from joining a session. Of course, you can always limit the number of xlayers!
The scant documentation included with DirectPlay 2.0 has been much expanded in the current release and even includes some tutorials on the new features. A new sample in the DirectX 3 SDK, DPLAUNCH, shows developers creating a game lobby how to launch a DirectPlay game and connect it to an online session. The DUEL sample in the DirectX2 SDK has been updated to support multiple players via DirectPlay, and the update makes use of just about every DirectPlay function in the book. You'll also find it interesting to read about what it took to port a game that used to pit a single player against the computer to a multiplayer, network game. And as I mentioned before, you'll see more about DirectPlay on this site, including a new sample application that uses almost every DirectPlay 3.0 feature with a minimal of other stuff cluttering the landscape.
It's getting to the point where you can't ship a product without the marketing people just about going postal over foreign-language versions. Localization issues are especially critical for the lucrative Japanese and Far East market, so look for wide character (Unicode) string support in all the DirectPlay 3.0 APIs. Of course, ANSI versions are still available.
The DirectPlay team has one goal in mind--to make Windows the best multiplayer gaming platform in the world--and DirectPlay 3.0 marks substantial progress toward that goal. This step forward doesn't come without some pain for the developer--at a minimum, you will have to recompile and link your app. You may also have to make minimal changes to reflect changes in some of the interface and structure names; the library name is different too. (Note: Although the obsolete interfaces and structures are no longer included in the new DirectX 3 SDK Help file, documentation for the previous releases is in the \docs\archive subfolder of the DirectX 3 SDK.) Of course, you may want to actually use some of the new features available in DirectPlay 3.0, which will entail some changes as well. T