Thread: RE: [GD-General] Online Gaming

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

AFAIK SOCOM is a classic client/server model, with centralised servers,=

while TMB online is P2P, although only in that one of the clients also =
acts
as a server. Another client can become the server, if the host-client d=
rops
out (AKA host migration), I believe that this means that each client is=

running full physics and logic, but discarding results upon receipt of =
data
from the server.

I think the more direct client interaction a game recquires, the worse =
the
network experience generally is. Both of those games suffer on that fro=
nt,
but it could be worse. I once worked on an online 1-on-1 fighting game.=

Lag's kinda fatal in that environment...

Cheers,
Phil

                                                                       =
                                                                  =20
                    "Mick West" <mi...@ne...>                   =
                                                                  =20
                    Sent by:                                     To:   =
  <gam...@li...>                    =20
                    gam...@li...urc       cc:   =
                                                                  =20
                    eforge.net                                   Fax to=
:                                                                 =20
                                                                 Subjec=
t:     RE: [GD-General] Online Gaming                             =20
                                                                       =
                                                                  =20
                    01/23/2003 03:25 PM                                =
                                                                  =20
                    Please respond to gamedevlists-general             =
                                                                  =20
                                                                       =
                                                                  =20
                                                                       =
                                                                  =20

c)  it's not really P2P. Clients are deterministic, and ignore what's
happening on  other clients.=A0 One "client" is also a "server", which
arbitrates scoring  and collision between clients.=A0 The server tells =
the
clients when they have  been hit, and they fall over.=A0=A0 The clients=
 tell
the server where they  are and what they look like, and the server rela=
y
this to the other clients, who  just display the other skaters at a few=

frames before their last known good  position, extrapolating only if da=
ta
fails to arrive in good  time.

It only works because there is very little interaction  between clients=

(they don't shoot each other, and most of=A0our online games  don't rel=
y
on=A0skater-skater interactions).=A0 Also there are no moving  objects =
in
mutli-player games, so we dont have to worry about crates or  vehicles.=

It's pretty specific to our type of game, and is probably not  what the=
y
use in SOCOM.

MIck

=A0-----Original Message-----
From:  gam...@li...
[mailto:gam...@li...] On Behalf Of
Andrew Sharpe
Sent: Thursday, January 23, 2003 1:43  PM
To: gam...@li...
Subject:  [GD-General] Online Gaming

After getting my PS2 network adaptor I've been playing SOCOM online for=

the past few days. Today though I put on a copy of Tony Hawk4 and was
pretty  surprised with how it played online.

Even on what I'd consider to be laggy servers (200-250 ping) the game
seemed remarkably fluent and consistent, i.e no warping players. Althou=
gh
I've  played lots of FPS games which usually use a client/server
architecture I'd  never really played a fast-paced peer-to-peer game an=
d
always assumed that on  anything other than LAN or fast broadband the g=
ame
would suffer.

Although I'm familiar with how C/S architectures work and how the effec=
ts
of latency can be compensated for, I've never really given P2P much tho=
ught
before in terms of how games can achieve a smooth playing experience, o=
r
even  how their network update is structured.

Possibilities I can think of for fast action games using P2P:

a) Clients are fully deterministic and perform a lock-stepped update  b=
ased
on inputs from all clients. For instance all clients perform their  phy=
sics
update based on inputs from clients during frame 180 and obtain  identi=
cal
results. Problems: this means that there's a delay between input  &
response, even on the local client, of around half the ping time to the=

slowest machine. Not too good I'd imagine on a slow connection.

b) All clients send their essential information (position, orientation,=

etc) and run their physics based on the last, or extrapolated details o=
f
other  players. Problems: clients may come up with slightly different
results due to  extrapolated data for other players (e.g the client
coliding with another  vehicle). There's also the problem of non-player=

entities in the world, for  instance a crate, which may end up with
different positions on different  machines if some form of correction i=
s
not performed to remove errors due to  the above problem.

There's probably other problems or solutions  I've not thought of thoug=
h!
I'd be very interested in comments from people  who've implemented P2P
solutions in games aimed at the online market though,  especially to do=

with how they handled gameworld physics and physical  non-player entiti=
es.
Very fascinating subject.

Thanks,

Andrew

With Yahoo! Mail you can get a bigger mailbox -- choose a  size that fi=
ts
your needs

=