Written: 12th July 2001
of this lesson
2. Connection types
3. Sending messages
4. Receiving messages
tutorials about DirectPlay will try to cover much
of this interesting Multiplayer API. Before I jump
into the coding part, I will explain some details
that might help creating your multiplayer game.
First you should know that multiplayer programming
is totally different to game programming. You'll
get a hard time finishing your multiplayer game,
with smooth animations by other player controlled
objects. It's often wise to build the game from
the ground up to be a multiplayer game instead
of making it single player, and simply adding
the multiplayer capabilities later. Instead of
DirectPlay you can also use the Winsock API (or
control). Winsock is more flexible but you have
to code everything yourself, like "message priorization",
"guaranteed messaging", and lots more things.
In DirectPlay you do not have to worry about the
protocol decision "TCP/IP", or "UDP". But I'd
like to give a small introduction what these two
This protocol is "connection less". You just sent
the data to a computer, and hopes it will listen.
UDP is also "non-guaranteed", this means that
what you sent does not have to arrive at
the original intended destination ("packet loss").
The advantage of this protocol is that it's 2-3
times faster than TCP/IP. It's widenly used for
action games like Unreal Tournament, Subspace,
protocol first needs to be connected to a remote
host. TCP/IP is a guaranteed protocol,
if you sent something it will arrive. TCP/IP is
more used for data streams. Like downloading
a file! But for turn-based/or slow RPG's this
protocol is great. For modem users this protocol
is also better, because the modem can apply "TCP/IP
header compression" to the data. If too much data
is sent, the protocol will buffer the data, increasing
the latency. TCP/IP packets will always take more
time to reach the destination! (not good for fast
DirectPlay you really don't have to worry about
this. Because you can easily send packets "guaranteed"
using an additional flag to the method that sends
There's just one thing I'd like to make a note
on: Players don't and won't understand latency!
Make your game work under bad "internet weather"!
you should worry about is the connection type. There
are three "practical" types, but since DirectPlay
gives us the ability to use two of them directly,
I will cover only those two.
Peer To Peer
Well, as you can see in the picture above, every
client sents packets to all other clients
This game is far more easier to develop and to
maintain. but there's one thing you should know
about this type of connection: Unless you're
going for a LAN(Network) game, don't use this
type of connection above 4 players! Yeah,
you might wonder why this is bold but you
really have to make sure you don't forget it.
If you start with Peer-Peer and find out that
it doesn't work you have to redesign everything
to support Client-Server.
Client-Server is the common type of connection
these days. Almost every online-game you're playing
is using this method. Games Like Quake, Unreal
Tournament, Subspace, Half-Life and whatever more,
uses this. the main reaons is that bandwith can
be more controlled. The server will make every
decision in the game (player dies, player hit,
etc); the server can decide if players need all
the data; use a database to keep track of player
stats;and much more thing which I won't explain
all. If you're going for an MMOG (Massive Multiplayer
Online Game) then this is the way to go.
main thing about multiplayer programming is that
you get data to other players. In DirectPlay we
use "messages" for this. You can also call them
"packets", it's the same anyway. I'm going to
explain the initalisation code in two other tutorials.
But sending and receiving packets is virtually
the same. So I'm going to explain the sending
a bit in advance. This does not really matter.
I think it's better to explain it in detail here
so I can use it directly in the other tutorials.
First we should be able to "choose" what type
of message we will send. If you're not using any
system to do this, you won't be able to discard
two messages from each other. I'm always using
constants for this. It's also possible to use
an "Enum" for it but the capitals won't stay capital
if you use it in your project. That's why I use
constants, so I can immediatly see that there's
an error somewhere. Note that I declare those
constants as byte. You could make them longs of
course, but that will only make the identification
of the packet type take 4 bytes. And with a byte
you can have 256 different packets, which should
be enough for you. (if not go for integer, Range:
-32678 To 32677... should be enough, =-P)
//Put this in the declaration section of a module, or form
Public Const MessageType1 As Byte = 1 '//1 will indentify messagetype1 in the receive part(we don't want a variant!)
Public Const MessageType2 As Byte = 2 '//2 will indentify messagetype2 in the receive part(we don't want a variant!)
Building up a message in DirectPlay8 is a lot
different from the way in DirectPlay7. But this
method is very efficient and allows you to control
the packet size very accurately. A message is
built up using a "byte buffer". This might sound
a bit complex but it ain't so hard at all. I recommend
that you create a sub for every type of message
you sent; your project will be much easier to
maintain this way.
Public Sub SendAMessage()
Dim bMSGBuffeR() as Byte '//Create a byte array, which will serve as a data holder.
Dim lngOffset() as Long '//This long will keep track of the bytes we have used (in total)
lngOffset = NewBuffer(bMSGBuffer) '//Create a new data buffer, and reset the offset number
'//Add the data to the buffer. You've got to get the length of the variable you're using, with "LenB"
'//You can't use "Len" because it will return the characters, not the bytes!
'//It will also increase the offset with the number of bytes returned by "LenB"
'//You can call this as much as you like... if you want to add something else, use the same line.
'//(but don't forget to change the variable "AValueorString")!)
'//If possible to specify the byte sze of the value to add directly, like in the 2nd method
AddDataToBuffer bMSGBuffer, MessageType1, LenB(MessageType1), lngOffset
AddDataToBuffer bMSGBuffer, MessageType2, SIZE_BYTE, lngOffset
'//Send the message. We are now assuming that this is a client. (from Client-Server! So no Playerid needed...)
'//"DPNSEND_NOLOOPBACK" is one of the many options you can use to sent the message.Be sure to check the sdk docs!
'//0 = The additional timeout value. I recommend that you leave this alone...
DirectPlayClient.Send bMSGBuffer, 0, DPNSEND_NOLOOPBACK
There are several flags you can use for sending
data. Here I'm using "DPNSEND_NOLOOPBACK". This
will make sure the message won't be sent to myself
again. If it did, recursion would follow on some
cases. For example, I receive a packet with an
ID of 1 it will forward it to a client, so a new
packet will be sent with ID = 1. The server will
receive it's own message, so this will happen
over and over, till you get an error "Out of stack
space". For some detailed flag description I recommend
reading the DirectX8 SDK docs.
I have to add a small notice that "Send" is used
for DirectPlayClient, and "SendTo" for DirectPlayPeer
and DirectPlayServer. The differences are minimal,
you've only got an extra option to specify a destination
player/group. With DirectPlayClient you can only
send packets to the server, and that is what will
happen in the code above.
Everything part of your multiplayer code needs
to be optimized to the max. for example, when
a player leaves the game, I could let the server
send "PlayerWithALongName left the game", but
I could also send the PlayerID to the client,
and let the client figure out who left the game!
They have the name already stored in an array!
Now, When we send data we also should let someone
receive it, so this brings me to...
important part of multiplayer programming that
you receive the data that has been sent by other
clients. After the data has been received, it
is ready to be processed in your multiplayer game.
It's recommended that you do this as fast as possible.
(The longer it takes, the more time difference
between the original sending time, and receiving
time) In DirectPlay7 you could receive messages
by "polling" the message count. If the message
count wasn't zero (0), there were messages in
the queue waiting to be processed. This method
was of course very inefficient. So that's why
we have the magical events in DirectPlay8!
The events are the same as the average form/ActiveX
events. But they won't trigger on mouseclicks,
they trigger on DirectPlay8 events. Now, just
to save you some trouble, DirectPlay8 for VB requires
you to add all events to your eventhandler
(Form, class). So you just can't simply add one
to receive. So just copy and paste it from the
DX8 SDK samples and remove everything unnecassary
you see. In the next sample, I'm not going to
paste all those events. I'll simply use Receive
only. (Unless Jack wants it different :o)
Private Sub DirectPlay8Event_Receive(dpnotify As DxVBLibA.DPNMSG_RECEIVE, fRejectMsg As Boolean)
'//If this event fires, we already have recieved something!
Dim lngOffset As Long '//Used to retrieve data from the received data buffer
Dim lngMsg As Byte '//Will contain the MSG Type we have received
'//In this sample I assume that we got a LONG! So in the code above it was a number, defined as long
Dim lngReceivedLong As Long
'//Get the first value (1 byte!). This will be our "header"
'//It will enable us to determine which message was sent!!
GetDataFromBuffer dpnotify.ReceivedData, lngMsg, SIZE_BYTE, lngOffset
'//Select the message we're dealing with :o)
'//Again, demonstrating the method's to get the byte size. I recommand the first method (SIZE_Long)
Select Case lMsg
'//You've received MessgeType1, lngReceivedLong contains the number
GetDataFromBuffer dpnotify.ReceivedData, lngReceivedLong, SIZE_LONG, lOffset
'//You've received MessgeType2, lngReceivedLong contains the received number
GetDataFromBuffer dpnotify.ReceivedData, lngReceivedLong, LenB(lngReceivedLong), lOffset
that is practically everything you should know
for multiplayer gaming. In my next tutorials I'm
going to show how to initialize DirectPlay8. Meanwhile
practice your Tic-Tac-Toe skills, because that's
gonna be the sample game!