It is extremely difficult to find any information on DirectPlay on the internet. There was one tutorial as one of the first Google hits but it was using DirectX5 which is very old http://www.cpp-home.com/tutorials/38_1.htm. The others aren't even worth being considered tutorials. I have found a bunch of DirectPlay stuff for VB6 but its also old and I wanna focus doing it on C++. There is a huge lack of a step by step guide, and the DirectX SDK's stopped supplying em since DirectX 8.1 SDK. And even then the samples weren't enough for me to grasp. Does anyone know where I can get more information on DirectPlay? Thanks in advance
Lack of Articles / Tutorials on DirectPlay
Why are you wanting to use it? The system has been deprecated and unsupported for years AFAIK.
Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]
I'm not sure you'll find very many.
Microsoft deprecated the library (said they would kill it) back in 2004, then removed the sources from the packages back in 2007.
The library had quite a few issues.
It was both too big and too small. It was too big because it offered a large amount of functionality, like migratory player groups, parallel sessions, voice chat, and various automatically negotiated partial mesh networks. In spite of all these big-game style parts, it was limited to 64 connections. The features are common in major AAA games but overkill for hobby games. The small games couldn't use it because it was too big and difficult to use well. The big games struggled with it because it was too small and did not scale at all.
Next was the multithreaded aspect. They designed it around a multithreaded system that required programmers to take care to avoid a lot of situations such as potential race conditions and memory barriers in callbacks. If you used the multithreaded version you either needed to completely wrap the DirectPlay code inside a thread safe intermediate library or face serious potential data corruption problems. But if you disabled the multithreaded parts the system became much less responsive, since the solution was to have each function block until all others were complete. Again, it was either too complex on the one hand or overly simplistic on the other.
Beyond the programmer problems, the system had some other issues with implementation.
DirectPlay needed two specific ports plus a range of 100 ports (2300-2400), and at the time they needed to be forwarded manually. This decision caused no end of grief.
At the time it was released few people had broadband and home-user NAT was not something consumers needed. Those with dialup didn't have many issues because they were generally directly connected with public IP addresses. Many people at the time used Window's Internet Connection Sharing system, but automatic port forwarding was hit-and-miss for home networks that used ICS. It worked great for some configurations, and would not work at all for others. Most corporate environments didn't mind that employees were blocked from playing the popular games like AofE.
For those who could get their home network to play the games, it didn't support many configurations. Many people wanted to play both on a local network and against remote players, and ICS doesn't support hairpin NAT, making one of the more popular configurations impossible. You could play an entirely local game, or you could play an entirely remote game. You could not have a mix of local and remote players.
Several of the 2300-2400 range was taken by other apps. Microsoft's own OLAP and SQL Server overlap on 2382. OpenVMS was/is a popular app with overlapping ports. Secure telnet overlaps (unsecure telnet was 23, secure was generally 2323). Compaq's built-in remote assistance conflicted. HP System Management tools overlapped. Seagate tools overlapped. And on and on and on...The conflict with major apps over such a huge range of ports caused a lot of problems.
Also there were some big worms and DDoS attacks that selected these ports. Google turns up a few viruses and trojans over the port range (Storm/Atma Xplorer, Studio 54, Portd, IRCContact, Doly, etc.) Many ISPs block the ports, and some leave them blocked to this day.
No, there are many good reasons that DirectPlay was killed. It should stay dead.
There are many good libraries out there, and some groups use them. Other groups program their own network libraries.
DirectPlay did have a lot of potential. Unfortunately they made a bunch of bad design and implementation choices. It was too complex for simple games, not complex enough for major games, had some poor choices like requiring 102 Internet ports, and so on. It was used on several games at the time such as Age of Empires, but it was fundamentally a bad fit for most game designs. If they had made better design choices and used safer implementation rules the library could have been excellent.
The quick answer is "you probably want to use RakNet, with eNet as a popular second choice."
The longer answer is "game networking is so integral to how the game and simulation works, that most games end up doing something at least semi-custom," followed by all the different ways you may want or need to go custom. Connecting using TCP and sending bytes back and forth is not very hard if you're a good systems programmer -- it's how those bytes are generated on one end, and parsed and acted on on the other end, which is the real challenge.
The #1 take-away is that your game loop and game simulation needs to be written with networking in mind for your game to work well as a networked game, so thinking about it early is key! Sounds like you're getting there, which is good.