Mail Archives: djgpp/1999/06/03/12:55:50
I can't claim to be an expert but I do have some idea of what you're
asking about. I'll try to answer your queries one by one.
On Tue, 01 Jun 1999 18:40:05 GMT, plogarithm AT yahoo DOT com (Plog) wrote:
>I basically need some C/C++ code tailored to modem-useage; a set of
>functions specifically for use in games would be best (I can't find
>any Allegro functions for this).
You know Doom? ID software released the source code for the serial/ipx
routines a while ago (and the rest of the source since). It can be
found at ftp://ftp.idsoftware.com I believe.
> Plus it'd be useful to have a good
>idea of what is actually involved in programming internet games...
>I've heard/read about stuff like IPX guff, sending 'packets' of data,
>pings (time to send data from A to B and back again??), but I don't
>know the details...
Information must be transmitted between computers to (at a bare
minimum) let each know what the other player is doing. Information is
sent in "packets" of data because this allows the implementation of
error checking protocols etc (a packet is just a lump of data of a
certain size).
>I'm assuming that within the game, the main thing is to send data
>updating things like player positions/actions; but how often do these
>updates have to be done? Every frame?? I imagine a top priority is in
>preventing 'divergence' of the games on the connected computers...
Possibly every frame; depends on the speed of comms and the frame rate
of the game. The main problem is the lag between a player at one end
initiating an action and the computer at the other end getting to know
about it. What if two players move into the same space before their
respective computers tell the other that the space is filled? This is
where the idea of a host comes in...
>This could be made difficult by data lost in communication, right? And
>exactly what is the role of the 'host'??
Yes, data being lost increases the lag. That is what "error
correction" is for. Depending on the reliability of the link I suppose
it could even be worth sending every packet twice. Not that the
general idea is:
computer 1: sends packet
computer 2: sends acknowledgment of packet recieved
So generally, computer 1 will continue to send the packet until it
recieved acknowledgement. In the case that it doesn't recieve ack for
a while, it may either disconnect from the game or refuse to allow the
player any action (and freeze the screen) until communication is
re-established.
Meanwhile, what if computer 2 doesn't recieve an expected packet? a
similar sort of situation may occur.
The role of a host is to make gameplay continuous, and avoid pauses
caused by occasionaly communication disruption (this is particular
important for games with many players), as well as maintaining
consistency across the machines. The host keeps track of where each
player (and all other objects) are, and their status (health etc). The
"clients" send information regarding what action the player has
initiated (eg "move forward"/"fire" etc) and the host returns
information regarding the new position and status of the player, as
well as all other objects (players, enemies etc) that have moved.
The particular advantage of this method is that no two machines
believe different things about the same object (eg, one computer
believing that a player's health just went to 5% after being hit by a
rocket, the other believing that the rocket missed entirely). The main
disadvantage is that most of the actual processing must be done by the
host, and nearly everything that happens must be transmitted to each
client (which could be expensive in terms of bandwidth).
Having a host is also the only feasible way to run a >2 player game,
as there must be some common communication medium between all
connected computers (unless each is going to broadcast to every
other).
The other alternative is to force a wait for packet every <n> frames.
That is, each computer *must* update its current status every <n>
frames (by sending packet & recieving ack), if not, the whole game
freezes or dies. Not a very good option: What if an "ack" is sent but
not recieved....? However some games seem to use a similar approach
(and yes, they do die every so often). Also, entities controlled not
by player must be moved identically on each machine to maintain
consistency.
Hope this helps,
Davin.
__________________________________________________________
*** davmac - sharkin'!! davmac AT iname DOT com ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/
- Raw text -