X-UIDL: 1029613958.73463.edge4.edgenetwk.com,S=4183
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <kjs@lems.brown.edu>
Delivered-To: jonof@edgenetwk.com
Received: (qmail 73460 invoked from network); 17 Aug 2002 19:52:38 -0000
Received: from unknown (HELO advsys.advsys.net) (64.17.237.75)
  by 0 with SMTP; 17 Aug 2002 19:52:38 -0000
Received: from KJSP933 ([68.14.67.56]) by advsys.advsys.net with Microsoft SMTPSVC(5.0.2195.4905);
	 Sat, 17 Aug 2002 15:52:38 -0400
Message-ID: <002d01c24627$a6ee5020$0201a8c0@KJSP933>
From: "Ken Silverman" <kjs@lems.brown.edu>
To: "Jonathon Fowler" <jonof@edgenetwk.com>
References: <3D5E2565.3060606@edgenetwk.com>
Subject: Re: Build's networking
Date: Sat, 17 Aug 2002 15:52:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Return-Path: kjs@lems.brown.edu
X-OriginalArrivalTime: 17 Aug 2002 19:52:38.0678 (UTC) FILETIME=[A3DF3B60:01C24627]

> would I be right in saying netsend() broadcasts the signon packet to
everyone on the network?

If the destination index is -1, it's a broadcast. If 0 <= destination index
< numplayers, then it goes to a specific player. It's never a good idea to
use lots of broadcasts (it slows down everyone on the LAN), so I only use it
in the beginning of the game when finding other players on the network.

> ... it looks like the rest of the hosts ... etc...

I don't remember all the details, but your description of the connection
process sounds about right. The code is ugly, but it worked (most of the
time :).

> The two networking modes you describe are a tad hazy still but I think
I'll work them out in time.

Broadcast mode (n*(n-1) total packets per frame) is best for modem games
because each player only has to wait for the packet from the other computer
to arrive - so both computers basically have half the round-trip ping. This
method is bad for internet play for several reasons. If one computer goes
down, everyone's game stops.  Also, if n is high, it requires a lot more
packets than the other network modes.

Master/slave mode ((n-1)*2 total packets per frame) is best for the internet
play because the stability of the game requires only 1 computer to be active
at all times (the master). The lag on the master computer is 0, while the
lag on all other computers is the full round-trip speed because each
computer has to wait for their packets to go the master and return back (to
know which ones were accepted by the master). In this mode, the lag is twice
as bad.

I used client-side prediction in the Build engine (I may have been the
first, but I'm not sure.. all I know is I didn't get the idea from anyone
else). I used prediction only for movement and turning. This is the most
noticable thing when playing over a laggy connection. It makes a lagged game
feel the same as a single player game with no lag. The only time you feel
the lag during movement is when you interact with another player, such as
bumping into them or bullets spawned by them (see fakedomovethingscorrect())
When this happens, you view jumps around (because it's fixing the predicted
game state to be the actual synced (but lagged) game state.

> Looking at your docs, the games have to wait until each machine checks in
its game state before each can move to the next tic.

That's correct. My client side prediction hides a lot of this, however.

> how would Build react to the kind of lag present even on the snappiest of
Internet connections?

It should work just fine if you do it right. My Voxlap game uses a
synchronous protocol and works even over the crappiest of connections. To
make it work well over the internet, you need to use the UDP protocol and do
your own error handling. Packet resending is absolutely necessary for a
synchronous protocol like in Build and Duke Nukem 3D, or else the game will
go out of sync. If you send a lot of redundant information, packets will get
corrected immediately. For example, you could send all the packets that have
not yet been acknowledged. Since Build packets are small (approximately 5
bytes per player), keep in mind that it's not a problem to send something
like the last 10-50 game packets.

-Ken S.


