Architect Your DirectPlay Application

Microsoft® DirectPlay® offers many choices about how you structure the networking for your game. So, before you start writing a DirectPlay application, you need to make some decisions about the architecture of your game. The following list details the main issues you'll want to consider before getting started.

• Peer-to-peer or client/server game. Peer-to-peer is simpler to set up and, once deployed, has limited overhead; but client/server works better for large-scale multiplayer games and may provide improved Network Address Translation (NAT) support. For more information, see Peer-to-Peer Topology and Client/Server Topology.
• Multithreading. DirectPlay provides the IDirectPlay8ThreadPool interface, which allows you to control the number of DirectPlay threads in your game. You can set the thread count to zero and call IDirectPlay8ThreadPool::DoWork to perform DirectPlay tasks. This allows you to avoid complex synchronization issues. However, a multithreaded DirectPlay game scales better. For more information, see DirectPlay Callback Functions and Multithreading Issues.
• Connection types, such as local area network (LAN), broadband, or modem. Supporting just one connection type allows you to expect consistency among the send and receive rates of your players and the amount of data they can handle. However, if you want to support different connections, you'll need to include adjustments to keep the maximum send rate at the rate of the slowest connection and control the size of the data packets, or expect significantly higher latency and dropped packets for the slower connections. For more information, see Optimizing Network Usage.
• Reliable or unreliable messaging. Most applications will want to use unreliable messages, because they improve the speed of your game. You can specify certain messages to be reliable, for data that cannot be lost. For more information, see Message Categories.