This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: my two cents on networked games


Jan Jona Javorsek wrote:
> 
> On Fri, 25 Aug 2000, Jim Kingdon wrote:
> 
> > Speed is not a big consideration either way as far as I know - either
> > X or the remote protocol is likely to be too slow to play over a
> > 28.8kbps or similar modem.  More of a hunch than a careful analysis,
> > though....
> 
> If Xconq is to be a widely played and accepted game, not only the network
> code issues, but speed issues too have to be resolved. If I can play Quake
> 3 and Total Annihilation (a good but memory hogging *real time* game which
> uses a completely dumb network approach and is basicaly sending chunks of
> memory up and down, with up to 500 animated units per player) over a 28800
> modem and Xconq can't handle the same connection, that means something is
> wrong with Xconq.

Right now Xconq has lots of extra packets going back and forth for
syncing and debugging purposes, and at the start the entire game
definition gets downloaded, which takes a while.  My original plan
was to debug it all first before trying to optimize...

Games like Quake and TA take a different approach, which is that
they use very minimal packets over UDP, and they rely a lot on
dead reckoning to handle packet errors.  That's why network lag
matters to players - when the network is slow, your view of reality
is seriously out of sync.  Eventually the server prevails, and
your program adjusts itself to reflect the server's state.  Quake
also does TCP packets, for the rarer cases when it's critical
that the packet be received and handled, such as when a new player
comes into the game.

Xconq could be doing more of that.  Right now it requires that
the programs run perfectly in tandem, to the point that the
random number state has to be retransmitted continuously (because
interfaces and AIs might be asking for random numbers also).
Of course, Xconq's internal state is more complex than what
Quake or TA has, when you consider the different kinds of
objects, the number of properties for each, and the relationships,
so if you get *too* casual about syncing up, you may find that
the game you're playing bears no resemblance to your opponents'
games!

Also, I think networking is at the edge of what can be done with
just a two-person team.  Between engine, AI, interfaces, game
designs, and graphics, there is already a lot to do, and either
other parts of Xconq need to be scaled back, or more people need
to work on the code.  I follow Freeciv development, and must
confess to bouts of envy at the number of developers adding to it,
even though the code is somewhat crufty C, and the architecture
is thoroughly wired to Civ emulation.  No matter, every week one
or another limitation is being removed.  Oh yeah, and the networking
works...

Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]