Mega Code Archive

Functions of client server handling in multiplayer games PART II

Title: Functions of client-server handling in multiplayer-games PART II Question: About different service providers and message handling Answer: Release 2 last update: [06.05.2000] ---------------------------------------------------------- Functions of client-server handling in multiplayer-games ---------------------------------------------------------- --------------------------------------------- PART II: Performance of service providers --------------------------------------------- - Personal comments Maybe my english is bad, thats because I am german. I am using the information described in this article in my current game called FinalFighter which I am developing. Check out www.finalfighter.com. Feel free to message me about this article and/or my project. - Status This memo describes the functions of a client-server oriented communication in computer games. The technology described in this document is independent from any programming language. It's only an example how to build such an interface. This article is the successor of PART I, check it, before reading this one. - Introduction In the first part of this memo, we discussed general things about different server types and their communication. In this part of the memo we will get to know somthing about different service providers and how to prevent lagging in your game. - Service providers Before you can send something over a network you must choose a service provider like TCP/IP, IPX or any other protocol (modem or serial-port connection). The most known service provider today - also used for the internet and local area networks in enterprises - is TCP/IP. Another protocol which came from Netware is IPX, it's only used in local area networks. Modem and serial connections are used to connect only two PC's over a telephone line or by the PC's serial port. These two connection methods are outdated and uninteresting for our game programming project, so we won't go into further detail. The DirectPlay-protocol included in the DirectX runtime from Microsoft encapsulates all this service providers we already mentioned, so you can easily include this technologies in your game - when you programming a windows-game - without having any trouble with different protocols or hardware. - About TCP/IP TCP/IP is a service provider which is used all over the internet and also in all kinds of local area networks. Every machine using this protocol can have one or more IP-addresses which identify the computer globally. This addresses can only be modifyed by hardware-drivers and the operating system, not by your game. So it's not advisable to use the IP as global PlayerID in your game, because the client can run multiple instances of the game, or he can use one shared telephone line - by two or more computers - which causes that all machines using this connection had one and the same IP. The TCP/IP protocol uses ports through which the messages are transmitted to prevent mixing them up with messages from other applications. You can use any port between 1 and 65535 for your application. All client who wants to connect to the server must know the servers port to connect to. All messages send through this network can be send in two ways: guaranteed and unguaranteed. TCP/IP sends guaranteed with the help of TCP included in this protocol. Guaranteed messages are used to send important messages like game states or something else. This type of message-sending takes more time and the packets send are bigger than unguaranteed ones. Unguaranteed messages are send with the UDP-technology, they can be used to post less important things like the player's position or something like this. - Network performance and prevent lagging The largest problem when writing a network computer game is to minimize the amount of data sent, to prevent player-lagging in your game. Before writing the network message handling in your game you should consider different bandwidths which the end-user could use. Your game must be able to work less-lagging when for example four players playing on the average with a 6kb/sec connection (ISDN or 56K-Modem) and someone with a 2kb/s (28K-Modem) joins the game. This may cause that the 2kb-player unintentionally manipulates the gameplay because other players can't recognize him correctly because of the lag. There are not many solutions for this problem, the only good one is to keep the amount of data sent low. Another (bad) solution is to kick the lagging player or to test the performace of bandwidths for every player before the game starts. Another important thing we should also know is that the gamespeed isn't only depending on the bandwidth of the network, but also on the connections of the internet providers in different countries. The IRC network for example, has different general servers (general server: see PART I) which are connected together. Each server only allows a connection from a user who lives in a specific sector in the world. E.g: Only users living in europe can connect to a server in Paris. You can resolve the country where an user lives by the hostname (to get hostname - resolve the IP). But here we won't go into further detail. We should remember that all these problems refer to internet connections. We don't have these problems in local area networks because the LANs always have a bandwidth which is large enough to ensure a less-lagging gameplay. - About asynchronous sending It can be an good advantage, sending messages asynchronously because this prevents unnecessary blocking in your game. When using synchronous message sending, a thread which sends the message is called and it only ends, when the message was successfully or unsuccessfully transmitted to the receiver. In the time where the thread is active, no other messages can be send. This is very unsuitably for your multiplayer-game, because this blocks the complete game when it takes longer than normally to transmit a message. Windows' Winsocks from version 2.0 or DirectPlay support asynchronous message sending with TCP/IP, so it's recommended to use it. When you are unable to use it (e.g. the service provider doesn't support it) so you can write your own asynchronous-message-sending method by using a message-queue with multiple threads. These queues are often limited to 16 messages. And you should always use the complete bandwidth aviable. When you find that there is place for more messages in the message-queue, than you can complete it by sending more messages. But this must be automatically controlled by the game itself. Example: we have a game with two players currently playing using the complete bandwidth of our network. When someone joins the game, the sending of messages should be minimized, so that the game can be continued without lagging. --------------------------------------------------------------- End of PART II