its probably due to your installed package.
Ill post the DBP document here in english but next time reinstall it hey, oh and dont get grumpy, good people will just ignore you as a grump.
Multiplayer Tutorial
by S. B., aka SF (and SFSW), aka Vice (that StarWraith guy)
_______________________________________________________________
Welcome to the DarkBasic multiplayer tutorial. This document and the associated source code are intended
to be compatible with both DarkBasic Version 1.X and DarkBasic Professional. The intent of this information
is to help you design a multiplayer system for your games, including full use of the command set for
real-time games, such as first person shooters and flight simulations. This tutorial also focuses on
peer-to-peer connections, as this is generally the preferred method for gaming on a wide variety of
systems and connection speeds (it's also the mode that I've found offers the most stability and
functionality). While this tutorial covers one possible way to use multiplayer, there are numerous options to
perform the same function. And even though this is fairly basic in concept, a solid working knowledge of
the DarkBasic programming environment is strongly recommended before attempting to implement the
routines shown here. The last few sections in this tutorial cover some fairly advanced concepts for packet
exchanges and player movement prediction, but it's what some of the big name game maker's use, so it's
important information to cover. I've tried to make this tutorial as easy to understand as possible, but I'm
dealing with a complex subject. Multiplayer is a relatively advanced concept in programming, even with the
easy-to-use DarkBasic command set. So if you find yourself not knowing how to accomplish some of what
is discussed in this tutorial, you may want to review the help examples that come with DarkBasic as they
are the best way to learn the language and concepts better. Also, there are much more complex ways of
doing the tasks described here which add to accuracy and gameplay, but this will give you a basic model
of techniques to use for good results.
Section 1: The Basics
The multiplayer commands found in DarkBasic allow you to exchange data (packets) over an internet
connection, local area network (LAN), or other cable connection (for this tutorial, we will focus on just
using the internet and LAN options). You can use this data to exchange scene information between
players. Scene data can include player position/direction, weapon state, and other miscellaneous
information. Your goal as the game designer will be to calibrate a scene so it is accurate for every player in
the game. The speed of each player's connection will determine just how accurate the scene will be for
that player.
Here are some basic concepts for designing a multiplayer system:
- Establish Connection Types
- Select Desired Connection and IP Address
- Decide Whether User is Host or Client
- If Host, Find Game, if Client, Join Game
- Exchange Name/Gamestate Data as Players Joins
- Keep a Running List of Current Players
- Continually Run Receiving Routine for New Packets
- Proceed with Desired Game Progression
- Check for Lost/Disconnected Players
- Check for Latency (Lag), Adjust as Needed
Now, let's go over some of these concepts in detail and how they will work with your game's structure and
concept. Keep in mind that these elements can be moved around, looped as needed, and modified to adapt
to any pattern you desire.
Section 2: Getting Started
Once you have a basic working engine for your game, it is best to continue development with multiplayer
gameplay in mind. To do this, you will want to make sure all scene data is in easy to manage variables, is
not randomly generated, and has a set speed (frame rate, model movement, etc) that makes movement
prediction easier (which we'll review later on).
Once you're ready to introduce multiplayer gameplay, you will want to design the multiplayer setup menu
for your game. This allows the player to select the connection and IP address they want to use. As
mentioned earlier, this tutorial will focus on internet and LAN gameplay, so the sample code below will set
the connection for this gameplay by default. But you can let the player select the connection method
themself, if desired. DarkBasic comes with a good example to show you how to do this using the SET NET
CONNECTION command. For our example, we will set the connection type to use the TCP/IP option for
DirectPlay (which can be used for internet or LAN gameplay). Here is some sample code on how to do this:
rem sample code to setup a net connection
perform checklist for net connections
sleep 50
nettotal=checklist quantity()
for a = 1 to nettotal
rem find the connection for TCP/IP internet
if checklist string$(a)="Internet TCP/IP Connection For DirectPlay" then netsel=a
next a
So we have found the Internet TCP/IP option and set the "netsel" variable to the numerical value of that
connection. The next step is to set the IP address for the connection. An IP address is like a phone
number that allows multiple computers to talk to each other through a single connection. The HOST must
be the first player to set the connection through their own IP address. Other players must then connect to
the HOST through the same IP address.
If you attempt to set a connection without specifying an IP address, the user will be prompted to enter an
address in a pop-up dialogue box (which may cause problems on some systems if you are not running your
program in a windowed mode). It is generally best to use your own routine to prompt the user for an IP
address. If you would like to automatically detect the active IP address for the HOST, I recommend using
the DLL LagMaster (www.lagmaster.co.uk) offers. I suggest only using the DLL to enter the IP in initially,
but let the players alter it themselves since the detected IP may not be the one they wish to use
(especially if they are a player trying to join someone else's game or use a router). Once the player has
entered the IP address correctly, you will set the net connection using the following command (for this
example, add$ represents the IP address):
rem add$ is the IP address, example "127.0.0.7"
set net connection netsel,add$
Once this is done, the connection has been established. The next step is to decide whether the player is
the HOST or a CLIENT. It's a good idea to scan for active games on the IP address at this point first, since
the exact time the HOST starts a game may be unknown. For our example here, we will limit the IP address
to just one game. But you can run multiple games on one IP. To search for an active game, you can use a
routine such as this:
rem check for active games on the IP address the player just connected to
perform checklist for net sessions
if checklist quantity()1 then game$="None":goto nogame
game$=checklist string$(1)
nogame:
So using this routine, if a game is detected, the "game$" variable is given the name. If no game is
detected, the "game$" variable is set to "None" and moves on. If "game$" equals "None" you can prompt
the player to be the HOST if they want to. Or they can re-check the list periodically if they want to wait
for a game to be started (just run the routine again for each time they want to search for games). If the
player chooses to be the HOST, it's time to create the game, so run a command such as this:
create net game "My Game's Name Here","Host's Name Here",8,1
The 8 is the maximum number of players allowed, 1 is for the peer-to-peer mode. If you plan to offer
gameplay over an internet connection, 8 is a good standard as it can be managed acceptably by most
systems and connection types. Remember, when you run your game in a multiplayer mode over an internet
connection, you are expecting the player's computer to run your game, the internet service provider
software they use, and the DirectPlay interface, all at once. This takes a lot more resources from the
player's computer then just running your game in a single player mode. Many players still use 56K modems
which may not be friendly to rapid packet exchanges with a lot of players. AOL users are forced to
connect through a slow network, which further harms gameplay speed. It is best to offer wide compatibility
and stability rather then risking a collapse of the connection or extremely "laggy" gameplay. If your game is
more of a turn based system where packets might be sent every few seconds instead of several packets
per second, you can probably bump up the total player count substantially (there is a maximum of 256).
You can also allow more players if everyone uses a high-speed connection or is connected through a LAN.
The choice is up to you as the designer, just remember that it means fewer people will be e-mailing you
with technical support problems if more people can play effectively.
For CLIENTS, the game should be listed in the "game$" variable before they are able to join. Once a player
is ready to join, use a command such as this:
join net game 1,"My Player's Name Here"
1 is the game's number. Once joined, you can now begin to exchange data. It might be a good idea to
have a chatroom routine setup once the game is started by the HOST, this way players can talk to each
other before starting the game session. Various game settings can be exchanged at this point along with a
check of player names. You can list the names of players in one part of the screen as they join. To do
this, continually run a list check of players like this:
rem get a list of all players
perform checklist for net players
for i = 1 to checklist quantity()
name$=checklist string$(i)
text 10,10+(i*20),name$
next i
This routine will give you an up-to-date listing of all players and will stay current with the list as players
join or leave. If the HOST ever leaves, it is usually a good idea to close the game since the connection
may eventually be lost when the HOST leaves. So it's also a good idea to notify the other players by a
short message when the HOST quits, the game can then close for each player.
Section 3: Exchanging Packets
Now that you've configured your connection and started a game session, it's time to exchange information.
For this example, I will stick to exchanging strings only to keep it simple, but you can exchange many data
types. When a player joins the game, it might be a good idea to send a greeting automatically by using:
send net message string 0,"[My Player's Name Here] has joined the game!"
0 is used to transmit the message to every other player in the game. When the other players receive the
message, you can simply display it on the screen. To check for new messages, use a routine such as this:
rem search for new messages
get net message
message$=net message string$()
The GET NET MESSAGE command sets the starting point of getting net messages at the oldest message
not received. If "message$" equals anything other then "", you can then choose to display the information
on the screen. It's also a good idea to loop the routine a few times if more then one message is available,
that way there isn't a backup of information that might cause lag or stuttering gameplay. To do this, the
routine can look like:
rem search for new messages
keepgoing:
get net message
message$=net message string$()
rem ENTER WHATEVER YOU WANT TO DO WITH THE MESSAGE$ VARIABLE HERE
rem for this example, I'll just paste it to the screen
if message$>"" then gotmessage$=message$
text 10,100,gotmessage$
rem then check for any remaining messages
if net message exists()=1 then goto keepgoing
Remember to use whatever system settings and SYNC rates you want and adjust the routine and command
placements as needed. You can also use scrolling text for chatrooms to enhance the exchange. Use this
concept to exchange game parameters or any other data you want. Once everything is ready to go, it's
time to move into the gameplay.
Section 4: Time For Gaming!
Using the methods above, it's pretty easy to see how information can be exchanged for turn-based
gameplay, or chat exchanges, but what about fast paced real time games where the action is immediate
and accuracy critical? This is where some careful designing needs to be done. There are some limitations
and problems that can arise, and there is never a guarantee that severe bugs or crashes won't occur. This
is especially true when players connect using all kinds of different internet connections ranging from 28K
speeds to Cable modems. When in doubt, slow everything down for everyone until stability is reached.
First, there is no automatic exchange monitoring in DarkBasic. You will need to establish an integrity
checking system yourself. Integrity checking can help prevent pauses and crashes. Your game will crash or
pause for long periods if you try to send too many packets which can't be processed quickly enough
because of various connection speeds. Even over a LAN, more then about 15 packets per second can
cause lag problems if there are more then just a few players. Internet gaming might lag if more then 4
packets are sent per second. Lag is simply a hesitation in gameplay caused by more information being
transmitted faster then the connection can handle it. Here are some general rules to follow to help prevent
crashes and lag:
- Never insert a SLEEP command in your main gaming routine. Pausing
like this means your receiving routine can't check for incoming packets,
causing a backlog. It also means a packet may get lost as they are
discarded by DirectPlay if delayed.
- Never transmit more packets then you receive from any one player.
- Always check the time it takes for packets to arrive from other players.
When in doubt, never transmit packets at a rate faster then you receive
packets from the slowest player.
- Always check for incoming messages in your main game loop, even
when in menus.
- Never attempt to send more then one packet per SYNC. You can't do it
anyway and should never need to since all data should be contained in a
single string packet (for our example).
You can monitor the speed everyone is broadcasting at by checking the "ping." Ping is simply the time it
takes for you to transmit a packet and receive a reply. It is measured in MS, or milli-seconds. You can
check the ping a number of ways. One way is to transmit a time stamp from the HOST. To do this, simply
use the following routine on the HOST's machine:
rem get HOST's timer
mytime=timer()
rem since ping should never be over 9,999 anyway, just get the last 4 digits of the timer
rem to minimize packet size
mytimer$=right$(str$(mytime),4)
rem PC is for ping check, the receiving routine should indentify this
send net message string 0,"PC="+mytimer$
Then the receiving computer can return the information:
rem remember message$ equals receiving information
gottime$=""
if left$(message$,3)="PC=" then gottime$=right$(message$,len(message$)-3)
if gottime$>"" then send net message string 0,"RPC="+"My Player's Name Here"
When the HOST machine receives the "RPC=" label, it should know it received a reply from a specific player
indentified by their name. You can also use number values to indentify each player (since some players
might use the same name), if you wish. When the reply is received by the HOST system, it can compare
the time it originally transmitted the ping check with the current time to get the ping exchange time for
that specific player (current timer() minus original send timer() will equal the ping for that player). You can
then store the ping rates for each player in an array. You can now transmit data packets at an average
ping rate of all players (which I've had pretty good success with), or select the slowest ping rate and
transmit at that rate (safer, but slows the game for all players).
This is the basic concept for speed checking. As the HOST, you can send out ping checks every few
seconds to always maintain a running tab of the connection quality you have with each player. The
connection quality will change, so you always need to be checking. If one player doesn't reply or slows
down considerably, you will need to slow the exchange rate or stop it altogether for a second or two until
quality improves (simply revert to sending test pings every 1-2 seconds or so until you get acceptable
results and can resume the exchange). Don't hammer your routine with chronic ping checks. Remember,
every time you send a ping packet, you lose the opportunity to send a data packet. I recommend checking
ping rates like this ONLY in a menu or other area of your game where interactive gameplay is not involved.
And any time a packet is transmitted, you run the risk of losing a packet sent from another player at about
the same time. It's similar to two people trying to talk over the phone at the same time. So to help prevent
lost packets, you may want to send each packet 2 or 3 times to verify delivery (space each duplicate
packet tranmission by about 400ms or more for internet connections).
Another option is to time stamp the end of all packets from the HOST. This way, you never have to miss a
data packet to check ping. The drawback is packet sizes will increase. But in my opinion, the tradeoff is
well worth it. Simply use the last 4 digits of every packet for the last 4 digits of the timer() as illustrated
above. This way, the host automatically receives the player ID data in addition to the time stamp, without
having to transmit two seperate packets (one for the ping check and one for data).
Such speed checks need to control exchange rates for all players. When the host sends a packet, the
other players can reply. When the HOST stops transmitting, players don't reply. This way, there is never a
time when packets start to overload what the connections can handle. See the next section for detecting
and managing lag. Another way to handle speed control is to simply put a ceiling of about 500ms for a
maximum time delay between transmitted packets. That is, if 500ms has been reached and no reply has
occured, send a packet anyway as a test. Since packets are frequently lost, especially over an internet
connection, it is a good idea to setup a maximum time delay.
If you don't want to have the hassle of dealing with the complexities of integrity checking, here are a few
guidlines to keep in mind when designing your system:
- For internet gameplay with players using a variety of connection
speeds, keep packet exchanges at around 4 per second (250ms) with 4-6
players or less.
- For high speed internet connections (all players), you can generally use
an exchange rate of about 5-8 packets per second.
- For LAN connections, 8-15 packets per second generally works well.
- Adding more players generally means reducing the packets per second.
Section 5: Packet Design and Gameplay Control
Designing your packets is critical to effective multiplayer. The basic concept is to keep the packet size as
small as possible and only transmit the information that is important. It's a good idea to keep this concept:
SAMPLE PACKET TEMPLATE:
player's id information + player's X position + player's Y position + player's Z position
+ player's X direction + player's Y direction + player's Z direction + player's speed +
weapon data + timestamp data for HOST
So the player sending their data would have a packet string that looks like this (using "*" as a divider
between each value):
packet$=playername$+"*"+str$(camera position x())+"*"+str$(camera position y())+"*"+str$(camera position z())+"*"+str$(camera angle x())+"*"+str$(camera angle y())+"*"+str$(camera angle z())+"*"+speed$+"*"+fireweapon$+"*"+ping$
The receiving player would then see something like this in the received string when the packet is detected:
"Bill10424*543.1122*58.2311*801.8790*44.3250*172.0093*94.2210*15*0*2480"
The received string can then be broken down within the program using the "*" dividers and assign the
values to the needed variables. This can be done by getting each digit using the mid$() command until the
value equals "*", then advance to the next needed value.
Keeping this information in a single packet will help optimize accuracy while reducing lag or jittering
gameplay. You can seperate the various bits of information with a marker, such as "," or "*" and then the
receiving computer can break it down and use the variables as needed. It is ALWAYS faster to breakdown
a single packet within the program then it is to try and send multiple packets for various gamestate
parameters. The timestamp at the end can be returned to the HOST in the same form, then the HOST
machine can use the playerid and timestamp value to quickly establish an accurate ping.
Sending seperate packet types for weapon data and player data will mean longer delays between updates
for various aspects of gameplay. It's best to keep as much information as possible in a single packet.
For chat exchanges during gameplay, you can simply use a format like this:
send net message string 0,"M=[Enter Message Data Here]"
Then all receiving computers can detect the message and display it as needed.
You will lose packets. Over any connection (including LAN) packets will be lost. DarkBasic offers a packet
guarantee option for some data types, which would be a good idea to use for message exchanges to make
sure the message arrives. It is not recommended you use packet guarantees for game data packets as it
adds considerable delay to the exchange rate (in some cases, as much as a 300 MS additional delay or
more). If you choose to just use regular packet exchanges, consider sending two or three copies of the
same message to help insure its arrival. Make sure your program accounts for lost packets and can adjust
a scene accordingly.
Your game will need to predict movement between packets for each player. This is critical in first person
shooters and flight simulations. To do this, create a routine that compares the rate of movement (rotation
and direction) between received packets for each player. For direction movement, simply move the player
at the previously received speed (that's the easy part). For rotation movement, divide the total rate of
movement between the last two received packets by the number of frames counted between those two
received packet, or use the ping rate divided by the time between each frame, example: 30
frames-per-second equates to about 33 MS per frame, so if the ping is 300, the movement rate would be
TOTALXMOVE/(300/33). This way, you now how far to continue rotating the player for each frame of
gameplay. This is why it is important to standardize your framerate for every player, or at least have a set
rate of motion for the scene, regardless of framerate. You will need to fine tune the routine to get it the
way you want. And you may want to add a 0.9 or so multiplication factor to the movement speeds to
gradually slow it down, this will help prevent jerky movement when packets are finally received.
Sound a bit tricky? Let's try an example just using the Y axis of rotation. Remember, first person shooters
typically use Euler angles (the ROTATE OBJECT command set) while flight simulations typically use
Quaternion angles (the TURN/ROLL/PITCH command set). You will need to adapt your rotation set with the
multiplayer routine. For this example, we will use the Y angle of rotation, commonly used for turning left or
right in many first person shooter games. First we will assume we've received a packet from the other
player giving us the initial Y angle for the object that represents the other player. Let's set this value to
the variable OLDY (remember to use an array for more then one other player, so it might read OLDY(I)). In
your routine, you will continually set OLDY to the last received Y angle from each player, then set the
variable NEWY to the Y angle you just received. So in our example, OLDY now represents the original Y
angle we received from the first packet, and we've just received a second packet, which we set the Y
angle value to NEWY. Let's say OLDY has a value of 34.5 and NEWY has a value of 42.0. It's obvious that
the player has turned right, since going the other direction would mean they turned 352.5 degrees in a
very short time, which should be an impossibility in your first person shooter. So we now know the
direction they turned without having to receive any extra data to find out. The total distance travelled
was 7.5 degrees (42.0-34.5), which means we know that the player made a controlled movement of 7.5
degrees to the right in the time it took to receive two packets. We have the distance, now we just need
the time. Hopefully, you've been tracking the ping rate for the player also, as this will help you predict the
future movement of the player. In our example, the ping rate for this player was 288, just over 1/4 of a
second. Our game's frame rate is 30, which means each frame takes 33.33 ms of time. Using our formula
above, we know that at 33.33 ms for each frame, our moving player took nearly 9 frames of gameplay to
turn 7.5 degrees to the right (288 divided by 33.33). So if we want to predict this player's future
movement, we can guess they will likely continue turning right. We then take the 7.5 degrees of motion
and divide it by the number of frames it took to get there, 9. Our result is 0.83333. So for the next 9
frames we can continue to turn this player's object in our scene by 0.83333 degrees each frame. Then if
we get the next packet in about the same time, 288 ms, and the player continues to turn at the same
rate, it will appear that the player smoothly turned in that direction, instead of suddenly jerking 7.5
degrees to the right. This means movement will be smoother, aim will be more accurate, and gameplay
more enjoyable.
You will likely need to fine tune this concept to control twitching, so slowly reducing the automated
movement might be a good idea. You will also need to account for the 360 degree barrier. That is, when an
object rotates from a Y angle of 5 to 355, the distance is only 10 degrees to the left, not 350 degrees to
the right. Use the wrapvalue option and "y>180 then y=y-360" formulas to adjust as needed.
L A G
The scurge of multiplayer gaming. One of the things you will have to contend with is lag, also known at
latency. This problem is caused by overloading the gameplay with too many packets. When it happens,
your game will pause until the packet backlog is processed. This may take 1/10 of a second, or it may take
5 seconds, depending on how many packets you've tried to send. Your job as the designer is to detect
when this happens and respond by haulting packet broadcasting. One way to detect lag is to keep track of
the time between frames. Keep in mind, some people's machines will be able to run your game at a higher
FPS (frames per second) then others, so you'll want to only detect a frame delay of say 150-250 ms.
Here's a quick routine to check the time between frames. Remember, we are using a framerate of 30 in our
example, so this routine is designed to detect a frame delay of roughly 200 ms.
rem LAG CHECKER
lag=0
oldtimerms=timerms
timerms=timer()
rem if more then a 200 ms delay between frames, hault packet sending
if timerms-oldtimerms>200 then text 10,10,"LAG OCCURING":lag=1
rem then when the lag variable equals 1, don't transmit packets for 1000 ms or so
When the LAG variable equals 1, stop sending packets for about 1 second or more. Continue running your
GET NET MESSAGE routine to clear out the remaining packets that caused the lag. 1 second is usually
enough time to clear the packets with 4 or fewer players. Then as the signal quality improves, you will be
able to resume sending packets. If the signal quality continues to be poor, the routine will repeat itself
until the signal is clean again.
Final Notes:
By using the concepts in this tutorial, you will be able to create a basic multiplayer system that works with
a real-time game. The design and fine-tuning is up to you. The key to creating a solid multiplayer system is
finding the balance between sending too much information and not sending enough. Sending too much
means your game will lag, send too little and the gameplay will be jerky. It's best to always check the
speed that messages are travelling at, since the signal quality will go up and down for each player. Also
remember to use commands such as NET GAME NOW HOSTING and NET GAME LOST to continually check if
the session assigns a new host or is lost entirely. If a new host is assigned, then the host has left or lost
connection and it's usually best to close the game and return the players to a chatroom.
If you'd like to see how I've implemented some of these concepts in a game I created, check out Star
Wraith 3 at www.starwraith.com and you will see the basic outline illustrated here. The game starts by
setting up the connection and establishing a game session. It then moves into a scrolling chatroom
sequence, a menu mode, then gameplay. In every area of the game, there is a chatbox or chat option for
players to talk to each other, which is very important.
That's all for now, good luck with your projects
fall down seven times, stand up eight
