Amiga Format CD 42/Amiga Format AFCD42 (Issue 126, Aug 1999).iso/-serious-/programming/basic/udpchat/lag problems in net games

Text File | 1999-05-14 | 21.7 KB | 457 lines

On 11-Apr-98, Paul Burkey wrote:
>Hi Dave,

>> Now that's all fine, I can do most of the TCP/IP stuff pretty
>> easily, but I have some other problems. Does anyone know of the best
>way
>> to do 8 seperate players playing on the same game over the internet.
>Like
>> how would you linkup 8 players...all to one player, or all in a
chain.

>With more than 4 players I'd avoid the chain idea. That is unless you
>can deal with large amounts of lag and you don't need to be fully
>synchronised. The 1 server many clients idea is the safest and easiest
>system to deal with but ALWAYS the best way.

   First check out Paul's netpage:
  <http://www.sneech.demon.co.uk/netlink.html>

   It's got some links to pages with the problems you're likely to come
up against. I've been researching this for the last 6 or so months (with
some help from Paul), because I want to put multiplayer internet support
into a similar type of game as yours- a fast reaction arcade game. The
big problem as far as I can see is the lag you get from when one
computer sends a move, and the other machine receives it. This is worse
on a 2D game because you'll see if something's a few pixels out- on a 3D
game you'll never really notice anything is out, unless the lag is
terrible. You have to do everything to cut down the lag time

>> it depends on how much data I'm gonna have to send to every player.
>> And that's the second problem, do I just send co-ordinates of
>> every player, and say ever players bullets, and any objects
>> they pick up, or do I send just the players action, and work out the
>> outcome of that action and then reply with a message to say that it
>worked
>> okay.

>As always it's not easy to give any firm directions with this kind of
>stuff. You may have good reasons why you need to keep things
>synchronised
>or you may have a design that can cope with large amounts of lag. It
>depends on the gameplay really. I'd probably suggest using the I/O
>method where instead of sending coordinates or players, bullets
>and whatever else. You just send the players inputs. So if player 1
>moves forwards you send this. If he doesn't move anywhere then you
>don't send anything.

   Yes, I think this is the only way you could have it work for lots of
players- otherwise you'd physically run out of bandwidth (you wouldn't
be able to get enough information through the modem in a given time).
Instead of sending out each new pixel position of an object, you just
send out differences in speed, acceleration and direction with a
time-stamp. As all machines are time-synced at the start you can then
adjust the Avatar (copy of your player etc on another machine) to the
exact position the original is on-screen (using simple physics), because
you know what speed and direction it was traveling at a certain point in
time. Your characters actually are in sync more than the position method
which would always be behind by whatever the lag was. This is how
Quake/XWing etc do it.
  So if a monsta is traveling down a corridor, you can ignore it until
it goes down a different angled corridor, then you send this info out to
the other machines. You just have to have one machine only, responsible
for each object onscreen- so I was thinking of using the Server to say
which machine is responsible for which monsta etc (even though I'm using
peer-to-peer, I've got a Server to log in to), and other objects like
bombs, doors, etc could be controlled this way as well. This solves your
problem about having two players in one space, as only one machine makes
the decisions for each object. You might get visual glitches like
shooting a player and it misses them when it should have hit, because
the actual player was really a few pixels off, but if the lag times can
be kept down this shouldn't be much of a problem.

   A point raised on one of the web pages, was the problem that could be
caused by lag. Say for example, a monsta has AI that makes it chase a
player on line-of-sight. If a player changes direction just before an
intersection say, and a monsta is in line-of-sight of that intersection
eg:

-------------+-+--------------
            P->                           P- player
-------------+ +--------------
             | |
             | |
-------------+ +--------------
              M->                         M- monsta
-------------+-+--------------


  If the lag to one machine is greater than another, you could get the
situation of the monsta going in two different directions on the two
machines. On the machine with the faster connection the Avatar has
turned back (as the human player has), so the monsta carries on along
the way it was going; on the machine with the slightly slower connection
the Avatar goes a few pixels into the corridor before turning back, and
the monsta sees it and changes direction and chases it down the
corridor. Once the monsta changes course on one machine, the courses of
the two monstas will continue to diverge :-/  (sort of like that old (I
think it was H.G Wells') sci-fi story about the guy who goes back in
time and accidentally kills a butterfly :)
  If you have the one machine only making decisions for an object, it
solves this problem.

>> Like if 4 players each tried to enter the same square, and only 1
>> could...which one would it be, and how would I tell all the others
>which
>> one it was. I hope that hasn't confused everyone...cos it's confused
>me.

>This is where the 'one server many clients' idea can make life very
>easy. The following is just a rough plan, I'm making most of it up
>as I go along so feel free to pick the ideas appart until we can
>agree on a solution. Also lets understand that this idea would work
>for some gams and not for others...

>Lets imagine you have 20 players. Each player would have a unique
>number eg 1,2,3..20. Now imagine that each player has to send
>commands to the server and wait for the command to arive back before
>the command can be executed. A command may be something like 'shoot',
>'move forwards', 'move backwards' or whatever. Any commands player
>1 sends to the server will be mirrored to all other players as well
>as himself. Now lets imagine that the server is setup so that it
>will take incomming commands for 1/10 of a second and then send
>them all out. If no commands are taken then the server will send a
>'no commands' message to everyone. The game would be setup to
>gather these commands and sort them into order. So all player 1
>commands would be executed first, then player 2 and so on. A better
>solution would be for the server to attach a timestamp to each
>command as it arives. Then a batch of commands are sent out and
>these can then be sorted into the same order as thy arived on
>the server.

>Some extra error checking should be used in this example but theres
>no need to go into too much detail here.

>To get back to your question.. Each player would move towards
>this same square at the same time. So the 'move to square'
>command is sent to the server and then the server sends these
>commands to the players. All players will attempt to execute
>the commands in the same order so player 1 will be first and
>then player 2. Player 2 can't move into the square because
>player 1 beat him to it.

   This is ok as long as it runs fast enough for your game- for an
arcade type game I think it might run too slow (as you have to send the
message to the Server and then back to the Client (which could double
lag times). I'm using Peer-to-Peer (every machine sends its messages to
all machines), which by-passes the Server.
   In Quake, I think they have a max of 8 players peer-to-peer, and up
to 16 going through a dedicated Server (as in Paul's way, but only to
pass messages on, not to do any logic). But these Servers are rather
powerful with a fast direct net connections.

   This is all theory at the moment as I haven't had time to put the
code into a small test game to see what works :-/

   Also am using UDP instead of TCP which is much faster but has no
error checking. I've done a little chat program using UDP which checks
wether packets have arrived at their target or not, and has a basic
log-in Server- but all messages are still sent direct to all machines,
that are logged on.
    I'll put it on Aminet, but I need to tidy up the docs first- I can
send it to you if you want.


On 14-Apr-98, Dave Newton wrote:

>>>With more than 4 players I'd avoid the chain idea. That is unless you
>>>can deal with large amounts of lag and you don't need to be fully
>>>synchronised. The 1 server many clients idea is the safest and
easiest
>>>system to deal with but ALWAYS the best way.

>> I've been researching this for the last 6 or so months (with
>>some help from Paul), because I want to put multiplayer internet
>support
>>into a similar type of game as yours- a fast reaction arcade game. The
>>big problem as far as I can see is the lag you get from when one
>>computer sends a move, and the other machine receives it. This is
worse
>>on a 2D game because you'll see if something's a few pixels out- on a
>3D
>>game you'll never really notice anything is out, unless the lag is
>>terrible. You have to do everything to cut down the lag time

> Well, I had almost made my mind up on server->clients way of doing it.
>Let
>me explain more about the game, so you know why I thought this would
>work
>for me. Basically, it's a blockbased game, you move from one square to
>another, and it takes so many frames to get to the new block. All I
>really
>need (or atleast all I think I need) is someway of keeping track of all
>the players. I need to make sure they don't walk into eachothers
>squares,
>and make sure that I know who's picked up what object, and whether they
>have fired there gun. Now, I'm thinking for the monsters, that if I
keep
>all the players in sync, then each machine will be able to use the same
>monster routine to keep all the monsters in the correct place, without
>sending any messages about them. Because I keep track of the players,
>then
>say monster1 will always attack the closest player, and if they need to
>do
>any random stuff, I'm going to generate a seed, and send it to all
>players
>before the game starts, so when you do rnd(10) on everyones machine,
>everyone gets the same number back :).

  The problem is with this, is that if the delays (lags) from the Server
to the  players are different, the commands will end up being executed
at different times and that means that the monstas could react
differently on different machines, as in the diagram in my last post.
One way around this could be to put on a delay for when the move is to
be executed- if this delay is less than the max allowed lag, say one or
two seconds, then everything will run as above. It sounds like your game
might be able to handle a delay like that- only playtesting would tell
you.

> I think the limit for this game is 8 players, and all I need to do is
>send
>a single byte for each player to the server from each client, then wait
>for a 8 byte answer, which includes my next move, and all the other 7
>players next move. Now because it's square based (ie, there not roaming
>free on the game), I don't need to send stuff every frame, as say it
>takes
>8 frames to get from one square to another, then I'd have about 8
frames
>to
>use for the wait (lag - both ways).....correct?? Though this may seem a
>lil
>slow to the player, as he may have to wait 8 frames before his
character
>moves on the screen.

  This might make the game horrible to play- you'd have to do some
testing to see.

> Now, assumming that works...I have some other queries. If I'm on a pal
>screen, and my opponent is on a ntsc screen, I'll have to do some fancy
>sync
>keeping/checking, so that my oppenent isn't ahead of me, as if it takes
>8 frames for my character to move, he'll see me at the square I'm
moving
>too before I get there. I was thinking, If I wait for the server to
>reply
>everytime, before doing anything else, then I supposed the sync could
>be the server return, as then everyone would move about, and then send
>their
>next move, and wait for the server to send the new moves. This would
>mean
>that ntsc users wait longer than pal users....but I don't mind that :).

   You could just drop frames in your NTSC game (10 every second), or
have a timer and drop frames, and sync everthing from that timer- I was
going to do that for my game, as I haven't got any CIA timings working.
I worked out you drop your counter (50 per second), one number every 6
frames= 10 frames dropped every second, and then your PAL just runs one
count per frame- I was going to use the vertical blank interupt, instead
of just a counter in the main loop in case the game slowed down (say by
another program multi-tasking), so every game always was synced.
Although if some-one changed from NTSC to PAl in the middle of the game
it would stuff up though- so a CIA timer would be preferable.

> Now what's the best way of getting people to find other players??? I
>assume you would need a server that registers people who have this game
>and are currently online, and you can request a list, to see who's on,
>then ask them if they want a game. Now to register, you would have to
>run a special program that puts your hostname into a database, and
>then when you disconnect from the net, you'd have to send a offline
>message
>to this database. The server would need to be on 24hrs so I was
>wondering
>if you could say write a cgi script, then use a specially written
>program
>to act like a web browser and pass your information on to the cgi kept
>database...or would you have to beg someone with a permanent connection
>to
>run a script or daemon for you.

  There's a program on Aminet called AmiComSysMUI.lha, which does just
that- it has a permanent Server, and when you go online it logs into the
Server- you can put whatever message you like on the Server- ie: hosting
such-and-such game. You can start programs from AmiComSys and send them
arguments like the IP address of the person acting as game Server, so to
join a game you just click on a button in AmiComSys. You could do it by
sending the IP address to your game through Arexx as well if you wanted.
Also you can chat to others online with an external program that comes
with it.
   Another similar program is QamiTrax which does a similar thing, but
can't launch programs yet. Also look out for the port of ICQ (some
people are attempting to do it- but having a bit of problem with the
original authors). It is a very sophisticated program currently on the
PC/MAC.

> Now the other thing is that would be
>fine
>for just two player games, but not for 8 player games, as how would you
>know when to start, how long would you wait for players to join?? Well,
>you could fix a time limit, and when you connect to the data base, it
>just
>time stamps it, and when someone access the list, it'll tell you how
>long
>before the next game starts (unless you've missed it). In this way,
it'd
>mean that you don't go need to register when you log onto the net, you
>only need to register once, when your ready to play the game in 10
>minutes,
>and the database will delete entries that have already started. After
>that you could have a daemon on your computer that when someone has
>found
>you from the server database, it asks you if you want them to join in,
>and
>adds the host and alias to the game connect list, and then when the
>timer
>has run out, the game starts and connects to all the people on the
list.
>Good idea????

  Yes indeed :-) If you want ideas, check out the way Quake on the
PC/MAC does things, and also the game-launcher/chat program Kali (also
on PC/MAC). They do some of your ideas above. A simple way to start off
is what I've done, is just have one machine as log-in Server, and each
player logs into that. The level, environment etc is set by the Server
(ie: the person hosting the game). A group of people chat together on
IRC, or AmiComSys and agree to join together in a game, then they log
into the Server and the Server auto-starts the game when they all have
logged in, or maybe the person running the game starts it manually if
someone doesn't log in.
  Another way is like Descent, and the game is started by the Server,
and people can join in at any time- but your game has to be set up to
allow this.
   The Server needs to put it's IP address out for people to
log into as it usually changes every time you log in- I've written a
little procedure to get this on your own machine.

> I don't suppose theres some way of 'broadcasting' to all clients just
>using
>a single port...I assume the server has to have a port to each client,
>and
>then send the same 8 bytes to all the ports....(correct???). And how
>much
>better is UDP???

  Well, you can with UDP, as each UDP packet you send out has it's own
address, so you only need one port (you can send out, and receive
everthing from this one port). With TCP you have one port for every
player, you can do this with UDP if you wanted.
   There is `IP MultiCasting' for large numbers of players, but I don't
know a lot about it- some of those pages mention it.
  UDP is better for speed (much smaller lag times)- Quake etc use it.
But TCP is much easier to use- I'd try it first and see if it works for
your game.

> I have already started writing a test for my square based tcp/ip game,
>and I may have a go at a non square based tcp/ip game just to see if
>it's
>possible. If I do, I'll upload the test source for that somewhere, and
>let
>everyone know :).

  I've got a small game I wrote, that uses Paul's TCP Client-Server
routines, if you want an example.


On 16-Apr-98, Paul Burkey scribbled:

>>   If your game can handle a slight lag, you could put out a timestamp
>> with your commands, and all the commands are delayed a couple of
>> seconds, to make sure that they all get executed at exactly the same
>> frame on each machine- then you could have the AI being executed on
>each
>> machine. But with a fast action game this wouldn't be practical.

>okay, heres the "closer to original" idea... The server would gather up
>the commands for 10th of a second or whatever delay you wanted to use.
>The server may have 10 commands from different players. It would post
>these commands to all of the players and the players would read them
in,
>sort them and excecute them. The players would also get an extra packet
>telling them how many commands they should expect. In this case 10. So
>they stay in a loop until all 10 commands have arived. This would force
>some kind of "time sync" every 10th second where all players will
accept
>incomming commands and execute them. This means the environment is
>kept in perfect sync so even the cpu AI will be using the same data
>on each machine. This verion has the drawback of forcing a delay until
>the packets have arived but with carefull choice of 'delay time' the
>lag could be beaten.  While I recomended the server would be running
>with some kind of time delay (10th of a second or whatever) the games
>would be running in "frames" so if a game is running at 20fps it
>would read incomming commands every 2 frames. Carefull thought would
>be needed to avoid the case where the server and the games are running
>at the wrong speeds :)

   Hmm, yes that would work. The only problem I see here is with your
monstas running around- if the delays from the server are different they
might change direction at different times on different machines, as the
frame might get executed at different times on the different machines.
The internal AI is executed the same, as all the commands are executed
in same frame in each machine. As long as it doesn't really matter to
the gameplay, and they're just a visual clue, it should work ok,
- especially as you have many peasants wandering around, there normally
should be enough to get the idea across.
  Also, more importantly, I assume all their movements are
pre-calculated (ie: go to point x,y) in each frame so they'd all wander
around identically.
  Your system is then synced by frame, rather than by all running the
same synced time. As your system has some time between frames, it would
allow your computer to `catch up' so to speak with the other machines,
if your machine got behind because of a slow lag time time, or being
slowed by multi-tasking (assuming that the multi-tasking wasn't taking
too much CPU time for too long :-/
   The 1/10th of a second delay of the Server (100ms) would be too much
of an overhead for a speed game I would think, but wouldn't
be noticed in your game :-)

 On 18-Apr-98, Paul Burkey wrote:

>> - especially as you have many peasants wandering around, there
>normally
>> should be enough to get the idea across.
>>   Also, more importantly, I assume all their movements are
>> pre-calculated (ie: go to point x,y) in each frame so they'd all
>wander
>> around identically.

>No, the people calculate their routes as they walk. This avoids the
>case where a building is placed in the middle of a pre-calculated path
>causing him to walk through it. It also allows him to escape or
>attack any enemy characters who could also cross his path. Then maybe
>he is following another character who is moving about. These are
>just a few simple reasons why the routes should be caulculated in
>real-time. This doesn't affect the TCP commands system because of the
>way it is synced up on a 'frame by frame' basis.

   Yes, all commands are started at the same frame on each machine, so
any characters would start off on a journey (say) on the same frame, and
would wander around the same way, as the AI is being executed
identically on each machine.

>>    The 1/10th of a second delay of the Server (100ms) would be too
>much
>> of an overhead for a speed game I would think, but wouldn't be
noticed
>> in your game :-)

>The time lag only affects the "control" of the game. So the time when
>you'd notice a large amount of lag would be when you issue a command
>and it doesn't actually take effect for a second or two.

   Yeah, that's what I meant, not actual CPU time :)

---------

        Anton Reinauer <[e-mail]>