Sorry your browser is not supported!

DB Classic Multiplayer Tutorial
By TDK_Man

Note: This tutorial was produced using DB Classic with the Enhancement Pack installed. It should apply equally to DB Professional, but definitely will not work if you are using Classic without the enhancements - a very good reason to upgrade your DB Classic!


Introduction

Before I saw a post on the forums asking for someone to do a tutorial on the Multiplayer commands, I hadn't even looked at them before. I have prior experience in Windows comms programming, having written a Windows-based mail client and a chat client (like Windows Messenger), so I knew what to expect.

I took a look at the commands in the help files for the first time and approximately three hours later I had two DB programs running on different machines on my network happily talking to each other.

The point I am making is that at first glance the subject looks very complicated, but when you understand the basics, it's really quite simple...

Basically, the Multiplayer commands give you the ability to write two types of program in DB. One which can act as a server - much like the one the DB forums are located on and the other a client which connects to that server - like your web browser connects to the server to access the forums.

Once the two are connected, you can send data back and forth from one to the other. So, you can write a game with a client section which connects to a server along with other users playing the same game, allowing you to all wander around the same location, fight each other and so on.

It's all a case of passing data around the machines so they all know what the other players are doing.

So, how does it all work?

The first thing to do is explain a bit of the techy terminology for the newcomers...


IP Addresses

When you are using a computer on a network, for it to talk to another one, they both have to be able to talk in the same 'language' as each other. On a network, the language used is called a 'protocol' of which IPX/SPX and TCP/IP are the most common. Most networks these days use TCP/IP and IPX is most often only present as an option on Novell Netware networks.

On a network with many computers, there needs to be a way to make sure that information sent from computer A to computer B goes to computer B - not computer D.

To do this, each computer is given a unique number on the network called an IP Address. This is an octet number - 4 numbers separated by full stops such as 192.168.1.11. Each of the individual numbers can be between 0 and 255, but normally, 0 and 255 are not used. That still leaves enough free for up to 254 computers on the network!

Your IP address when on the internet is normally 'dynamic' (allocated by your ISP each time you connect) unless you pay extra each month for a 'static' IP address which never changes.

On a Local Area Network (or LAN) at home, you would normally use the numbers 192.168,0,x for your machines as this is an 'official' subnet reserved for private use. So for each computer on the network to talk to each other, they must all have the same first three numbers and the last one (where the X is) must be unique.

The internet is just a bigger version of a home or office network but over a wider area, so it's called a WAN (Wide Area Network) rather than a LAN. But it works in the same way using IP addresses. Each computer has it's own IP address and no two machines can have the same numbers.

When you type http://www.thegamecreators.com into your browser, it doesn't know what or where that is. It needs an IP address, so the browser accesses another computer called a Domain Name Server (DNS) which takes the URL and returns the IP address 216.92.119.232 - in much the same way that directory enquiries tells you what auntie Vera's phone number is when you give her full name and address. Armed with the IP address, your browser can connect to http://www.thegamecreators.com.

So to summarize, the machine you are connecting to is the Server and you connect to a server with a Client. OK, so now we know how machines can find each other over networks. What's next?


Getting Started

When you write a DB program, you have the option of creating a separate program from the game (a server) which runs on a machine connected to your network (or the internet). Your game would then allow you to connect to this server which passes all the data round to all those connected to it. This is your basic 'Quake Server' option.

Alternatively, you can put the server side of things in the game program so one of the players decides to be host and all the others connect onto him or her, by adding that option into the game. For simplicity, we'll assume that we are going to be writing separate programs for server and client.

The first thing we need to do is create our server, so that's where we'll start.


Choose Your Connection

DB's Multiplayer options don't just work with TCP/IP through a router via the internet. You can also connect two machines via a serial cable, dial via a modem or run the server and client on the SAME machine. These are all different types of Connection and you have to choose which one you are going to use from those available. That's where Perform Checklist For Net Connections comes in.

This will return a numbered list of what connections are available on your machine. As with all of DB's Perform Checklist calls, the number of items found is stored in checklist quantity() and the actual items stored in Checklist String$(N) where N is the item number. So we add the following to our program:



For the purpose of this tutorial, Our game server only needs to support Internet and Local Area Network - both of which use the TCP/IP option. If you need to use one of the other options, I'm sure that this tutorial when completed will have given you enough knowledge to alter your own code to suit your needs.

Anyway, the above code checks for Net Connections and we use the variable NumConnections to store the number found.

On my machine, I get 3 options, the third of which is 'Internet TCP/IP Connection For DirectPlay'. The other two are for serial connection and modem.

So, in our program we run through a loop grabbing the first eight characters from the options returned and make them upper case. If the result is the word "INTERNET", then we know that N equals the number of the TCP/IP option, so we save the value of N in NetConNumber and jump out of the loop.

Using the value now stored in NetConNumber we can now try opening a connection to receive logins from other people. The only other thing it needs is an IP address. This same command is also used when opening an outgoing connection where the IP address of the machine you want to connect to has to be supplied. With a server application, it's an incoming connection we are establishing, so there is no remote IP address to supply. So we simply enter the IP address of the machine it's running on - in my case, 192.168.1.2.

If you use "" instead of an IP address the program will pop up a windows dialog asking you to enter the required IP address. You can enter the machine's IP address there or just press Enter to ignore it.

Providing there are no errors, we can safely assume that an open connection has been established so it's onto the next stage - creating a net game...


Create Net Game

At this point in coding our multiplayer program we have the option of creating Peer To Peer (P2P) links between all the players where all are connected to each other for transferring data, or a client/server system where users all log into the server and the server distributes the data around to all the players. We are going to be using the client/server option in this tutorial.

So I used the following code:



Create Net Game has four parameters. The first is the session name. This is what the user at the other end will see when they try to connect. The second is the 'owner' of the connection and is in effect your username which others will see in the game itself.

The next parameter (10) is the number of people you are allowing to connect to the server (the maximum number allowed to play the game). You can have up to 255 connections, but if you are using a machine at home, your net connection may well buckle under the strain, so this is where you relieve the pressure. You may even have a game where only four people can play, so in such a case you would use 4 for this parameter.

Also, don't forget that the server uses up one of those 10 slots...

The last number is a flag for the options I mentioned earlier. If you want P2P connections, put a 1 here. If you want a stand-alone game server, put a 2. In this example, we need a 2.

Net Game Exists() is simply a test to see if the game we just tried to start is actually running. If a 1 is returned, then it is. If a 0 (zero) is returned, then we can print a suitable message and end the program as nothing is going to work if this fails anyway.

Assuming all has gone to plan, we should now have a net game running and waiting for someone to connect!


Messages

Everything revolves around messages that are received from the players connected to the server and those that the server sends out to the players. Messages can be in a variety of formats.

You can send a number of message types, though the most commonly used ones are going to be string, integer and float variables.

For example, if six people are driving around a race track, the server is going to have to receive information from all the players - like each player's positions on the circuit and then send it all back out to all the other players so that all copies of the game draw the other players cars in the correct positions.

In it's simplest form, this could be done by sending just the X and Z position for each player's car, though you'll probably want to send other information too. And yes, you can even program the Function keys to send taunts to your opponents just before you blow their heads off!


Incoming Messages

Our server is mainly concerned with distribution of messages, so it needs to receive them first. This is done with Get Net Message.

Like with Net Game Exists(), there is also Net Message Exists() to test if there is a message in the queue waiting to be processed.

Each message received is best thought of as a 'package' which contains various bits of information. There is a command to extract each piece of information so you can process each message. These are:

Net Message Type() - This returns an integer and the three common message types have already been mentioned - Integer, real and string. There are other less commonly used types like Memblock, Bitmap, Image, Mesh and Sound, but they are outside the scope of this tutorial and you can look them up yourself in the help files if you need them.

The ones we are going to use are as follows:

Integer: Net Message Type() returns a 1. Actual integer value is stored in Net Message Integer().
Float : Net Message Type() returns a 2. Actual float value is stored in Net Message Float().
String : Net Message Type() returns a 3. Actual string value is stored in Net Message String$().

Other associated message commands are:

Net Message Player From()

This returns the player number the message was received from. The player who initiates the server is player 1 and is always part of the game, appearing on the list of players logged on.

Net Message Player To()

This is the same as Player From(), but returns the number of the player that the message was aimed at. For example, in a game, it's possible for a couple of players to team up and this option gives them the opportunity to send private messages between themselves.

So, having found that a message has arrived, these commands can be used to find out who the message is from, who it's being sent to and what sort of data is in the message. A simple Select..EndSelect structure can be used to decide how to process the message.



In this example, a string called Packet$ is built up with the information received in the message and can be printed to the screen if required.


When Did They Connect?

When someone does connect, a message event is triggered, and the fact that a new player has been created is recorded. So, somewhere in the While Net Message Exists()=1 loop, we need to check to see if the current message was raised because this has happened. (I've left a blank line in the block of code above to show you where it would be inserted). This is done with:



At this point, although we have the number of the new player, the program at the other end which has just connected to the server doesn't know what it is as it doesn't yet know how many other players are currently connected. So, what we do is send this number back to the user in a message. It could be something as simple as "Welcome! You are now player 3 connected to the Pong server.".

We'll cover that later though in the section on Outgoing Messages...


What If The Connection Is Lost?

Once again, a message event is fired and we need to have a little test to check if the current message is due to this happening. For this, we use Net Game Lost()...



This is not if the server loses contact with one of the players, this is when the server's net connection goes down and the server loses contact with everybody!


Where Did They Go?

If someone disappears, be it due to your carefully crafted game going belly up with a 'File Not Found' error, or someone's been given their last warning to get down those stairs and get their dinner before it goes cold, a player disappearing raises a message event. This is checked for with Net Player Destroyed():




Who's Currently Connected?

At any time, you can use Perform Checklist For Net Players to find out who's currently logged on:



This puts a list of names at the bottom of the screen in a similar way to how the list of members logged onto the forums appears at the bottom of the main DB forums page.

OK, that's about it for incoming messages, so now we'll take a look at how we get our server to send messages back to the players:


Outgoing Messages

First of all, it's assumed that you are connected and have a net game running for the following to work. Just thought I'd better point that out...

Sending a message is simply a case of calling the correct Send Net Message. Which one you use depends on the type of data packet you want to send. You have the following common data types:

Send Net Message Integer 3,Count

...Which would send the contents of the integer variable 'Count' to player number 3.


If you use 0 (zero) then the message is sent to all players, but not yourself naturally, so:

Send Net Message Float 0,Player1XPos#

...would send the contents of float variable Player1XPos# to ALL players.


Send Net Message String 2,Taunt1$

...would send the string Taunt1$ to player 2.

That's all there is to it.

When the message is received at the other end, the client program uses basically the same system as described above to decide what to do based on the messages it receives. The only difference being that whereas the server program has to receive and distribute messages that it receives to one or all of the clients, the client only has to talk to the server.

This tutorial only includes snippets of code taken from my rough but working server program - to explain what to do. When Tutorial 2 is complete, I will finish off the client and server programs, make them tidy and presentable and make the source code available to download.

Next, Part II - writing the client!

There are many more tutorials and example code snippets on TGPF - my game programming forums. Click on the link below - it's free to join and everyone's welcome!

Visit TGPF

TDK_Man August 2005

Brilliant. I appreciate your help alot. Do you need any help? E-mail me at rpgmakerx2@hotmail.com . Unless you make an online chat server

Good luck,
Me

Very in depth and very helpful, TDK. I'm sure that has already sparked off several ideas, and helped others along the first steps of multiplayer.

Great tutorial TDK. Somebody find a mod with some tape.

the BEST programmer:



Yes - like your programming! Lol.

I guess we'll both get there eventually...

TDK_Man

Great tutorial. The tutorials in the DB Programming Guide for Multiplayer is very limited and this helps out a lot. Great job TDK.

one thing not listed by TDK - telling your program to look on IP of 255.255.255.255 will make it search EVERY possible IP address (this is great if the server's IP can vary, and you want to avoid the user always having to get rid of the popup box asking them where it is )

Other than that, it is very Helpful -- probably one that should get stickied...

SimSmall:

Ummm - I don't think so!



This tutorial is about writing a server, so why would you want to search for anything? You just enter the IP of the machine it's going to run on.

Now if it was the writing a client tutorial...

TDK_Man

ah -- guess that makes us both guilty of not reading the normal size print

oops...

TDK_Man

The only problem with that, is that the player will have to wait a few years before the game is joined.

not for LAN games -- just internet... but as this is server programming...

Hey TDK, great tutorial! I have already learned from it. Do you think you could post your code for your client part of the thing. You don't have to write the Tutorial just yet unless you want to), I just want to see the code because I THINK I might understand it with out. Big thanks if you could,

David

I've got a client and a server written in DB Classic finished and working perfectly - but only on my network.

For some reason it just won't work over the internet.

I now know what port number the DirectPlay server is using and it should work but doesn't.

I'll be doing some futher tests this weekend with a mate in the UK, so if all goes well I can finish the second part of the multiplayer tutorial (writing a client) and post the code for both.

TDK_Man

when I tried multiplayer (I only tried a simple FPS since I have no interest in multiplayer) I had the same problem, it turned out the firewall was silently blocking the connection at the other end, if my mate turned off his firewall it worked, (this is strongly not recomended) but even with the application allowed in the firewall exceptions list it wouldn`t work if it was enabled, I don`t know if that was DB weirdness or the firewall to blame, he was running Tiny personal firewall btw (I think it`s now called Kerio personal firewall), but I havent played with the network commands in ages.

Now I'll need some help myself...

I've started off a chat program, and mostly works (well just about)...

problem is:
Player 1 hosts the session and is the only one in it (no problems)
Player 2 joins the session, and the two can talk hppily (no problem)
Player 3 joins the session, Player 3 can only see Player 1 and himself when using the perform checklist for net players command
Every subsequent player suffers the same problem of only seeing themself and Player 1...
Player 1 is the only player in the game who can see everyone who's connected

Can you think why? A classic mistake perhaps? or do I need to submit some code before someone can help?

Edit: NOOOOO! worse than I first thought
Player 3 joining causes players 2 and 3 to share Player 3's name
Player 4 joining causes Players 2, 3 and 4 to share Player 4's name
And so on...

I've got a chat server running fine with many clients and I too had problems with the names when connecting. Plus major problems with getting past my ADSL router!

They do have their own names, but it seems that the last to connect is always number one.

If you let me have your e-mail address, I'll send you my as yet unfinished but working dba files from the tutorials.

TDK_Man

Hey TDK, I was just reading my Beginners Guide to DarkBASIC Book and it said that when you make a game server, you don't need the IP address when connecting to the internet. If you do that means there is a gane already established and you are going there to join that game. T think you put a IP address in your tutorial. So with what I just found out, I'm going to test this out and see if it's true. Please correct me if I'm wrong.

You need some way of pointing the client side of your program to the machine which is running the 'server'. The server program can be set up as a client/server or as a P2P system, but without an IP address in the client there's nothing to connect to.

On a server, if you don't enter the IP address in the program, it will just ask you for one when you run the program.

So to stop this, you do enter an IP address, but only the LAN IP address of the machine it's running on. This can be hard-coded, read from the command line when you run it, or just left blank where like the client it asks you for the address when you run the program.

The MAJOR problem with this is that it doesn't seem to want to work over the internet if you are on ADSL and have a router. And I really don't know why. It's very strange...

It's using the DirectPlay server and on my system, it doesn't seem to use the same port each time you run the program.

In order to get past a router, you need to enter a fixed port number into the Network Address Translation (NAT) table of the router - which is impossible if the port is different every time you run the program.

TGC did not implement a port number parameter in the muiltiplayer commands, which in hindsight was a mistake. In effect, this would seem to suggest that the multiplayer side of things is going to be less and less useful, the more people get ADSL and routers.

If you are connected to an ADSL line through a USB modem or are on dial-up, you don't have the same problem as the machine itself is connected to the net - not the router.

If anyone has successfully managed to connect over the net via routers using the built-in DB multiplayer commands, I'd love to hear about how it was done.

Failing that, I'm looking into the possibility of writing a DLL to do it.

TDK_Man

Oh, whoops, I re-read it and it said you put "(space)". That tells DarkBasic that you're the host. Whoops, so it's not "" its " "

TDK, if you're still on in about 10 to 20 minutes, could you meet me on your Chat thing in your IDE? (If you're even on at all).

I'm on now, but it's nearly 3:30 am here and I can't stay too long...

TDK_Man

TDK: Was this to me?

if it was I can't do anything now coz I'm in college, but after about 17:00 GMT should be alright (I'm not in tomorrow), so I'll PM my E-mail (so say now if that wasn't to me)

We're trying it right now, and the anonymous feel certainly adds an entertaining touch

Yes.

I've written a fully working chat server and client which does what you are struggling with.

My code is for the Multiplayer tutorial and isn't finished yet - but it works. If you sign the usual non-disclosure agreement, I'll e-mail it to you...

Lol - just kidding! Just keep it to yourself.

You may be able to help with the Router problem...

The "I'm on now, but it's nearly 3:30 am here and I can't stay too long..." comment was to vgames master who wanted to test the chat option in the IDE I'm writing.

TDK_Man

Your router problem is likely caused by the protocol used being 'DirectPlay'

What I understood this to mean from a microsoft web page is that you must have a direct connection to each other to play

Some examples:
2 machines connected via a serial cable <Direct>
2 machines connected via a modem <Direct>
2 or more machines connected on a lan (both wired and wireless) <Direct>
2 ICS hosts connecting to each other <Direct>
an ICS client connecting to someone outside their own network <NOT Direct> (has to pass through an ICS host (in most cases a router) first) (connecting to ISP's servers don't seem to cause a problem, otherwise it'd be network only for every game out there...)

If the protocol was simply TCP/IP (not DirectPlay) I don't think these problems would occur

If this is wrong, I'll just hide somewhere until everyone forgets about it

Edit: hmm, PM -- I must be thinking of another forum...

Directplay uses TCP/IP rather than UDP - which is good.

A router requires a port to be forwarded for a TCP/IP connection via the internet and the DB commands don't actually implement a port parameter - which is bad!

I've been looking at the possibilty of a DBC dll to do it, but it looks like it might not be possible because the DirectPlay server uses a queuing system rather than a polling system - something which would be quite difficult to implement in a dll as some incoming messages would just be lost if you didn't poll the incoming port quick enough.

If you polled it quickly enough, that would then have an adverse effect on the performance of the game running. You might stand a chance if you had a dedicated server doing it though...

As I said before, my existing programs work perfectly over a LAN, but it's WAN playing the majority of DB users want - not LAN - and that's only possible if you have an ADSL modem rather than a router. And that would rule out a growing number of users.

TDK_Man

I'm pretty much just spitting into the wind here but,

Doesn't the router get an IP of like (example)
169.204.138.1
then the computer gets a number such as
169.204.138.2?
I'm sure the spit hit my face on this one , so yah.

The router's IP is normally assigned by the manufacturer, some routers will however let you change it

The machines that cannect are indeed assigned such numbers as you said if you choose the router's option of "auto-assign" (or whatever it's called in router's configuration page

If you tell you router to give you an IP of your choice, it will, but you need to give it more information than you'd normally give windows - certainly mine asked for 3 bits of info and I can never remember what the 3rd bit was -- First two were: IP, and subnet mask, which are easy to do/know anyway

This is the case for Linksys routers... I wouldn't expect other routers to be so different...

vgames master:

You are correct, but the problem is that a) a router does not connect traffic automatically between these two IP addresses (built-in Firewall) and b) when you connect with an IP address, you also connect to a port.

If I write comms software in Delphi - like the IDE chat option, I have to tell the software the IP address to connect to AND the port number.

In the router's setup I can then tell the router to allow any traffic arriving on port 'X' to pass it through to the machine with IP address x.x.x.x.

And that is the problem with DBC's multiplayer commands - there's nowhere to define what port you want to use. Without a port number I can't see of anyway to allow someone with a router to either connect to another machine, or be connected to by someone else.

I have e-mailed Lee about this, but as yet I've not received any reply.

TDK_Man

Hey TDK, your doing nice with this while I was busy. Good job!

HEY! That could be (one of the million) reasons why my mmultiplayer thing wouldn't work! the computer I use upstairs, has a wireless router (very fast one at that). That could explain alot for me.