[MUD-Dev] Re: MUD-Dev digest, Vol 1 #443 - 12 msgs

Dr. Cat cat at realtime.net
Wed Oct 17 17:33:39 New Zealand Daylight Time 2001

> From: Brian Hook <bwh at wksoftware.com>

> You will never, ever attain the latency and bandwidth necessary
> for an MMORPG using TCP.  QuakeTest used TCP, and it was a
> disaster.  They switched to UDP.  I believe the original UO was
> also TCP, and it too was a disaster.

I have to respectfully disagree, and offer Furcadia as a
counterexample.  It's all 100% TCP, and it's been running just fine
since 1996, growing continuously, and I think we actually get less
complaints about lag now than we did a couple years ago.  (I'd guess
because the colocation site we're at now has better private peering
or is less overloaded on the pipes it has to various backbones.)
Our current peak usage is a little over 1200 users, but I don't see
any reason our TCP usage couldn't scale ten times as big or more,
and do so just as well as a UDP version would.

To me the tacit assumption here is what an MMORPG "is like" or "has
to be like".  You certainly can design games to require better
performance than TCP can give you.  But then you can design them to
require better performance than UDP can, or better performance than
the speed of light can give you.  One is well advised not to do so,
however.  :X)

And while some games may benefit by pushing their designs closer to
the "bleeding edge" of what's just barely practical with today's
technology, I would say it's an axiom of my system of game design
that most of the "solution space" of potentially interesting and
worthwhile games that could be made lies outside the realm of
designs that require technology to be pushed anywhere near its
limits.  I would add the further corrolaries that the "push the
technology" subset of interesting possibilities is over-served, with
large numbers of programmers and development teams focusing there,
and the remaining, much larger portion of the space is seriously
underdeveloped.  And that the portion of the space that falls into
the "must push technology to implement" is shrinking ever year as
computing technology advances.

My 1980s development philosophy at times led me to optimize code
literally to the theoretical maximum performance of a 1 MhZ 6502,
down to the last CPU cycle (measured in microseconds back then, not
nanoseconds!)  My pulse-width modulation sound effects code couldn't
get the carrier frequency up above the audible range without that
level of optimization.  Memory usage, bandwidth, and everything else
had to be similarly dealt with in miserly fashion.

Today the small minority of the code that really needs optimizing
has shrunken more and more, and a lot of it may fall within third
party libraries that you just license.  And that which you do
optimize generally doesn't need to be coded in assembly language or
perfected to squeeze every last machine cycle out of it.  Optimizing
is much more biased towards good algorithm design and protocol
design, and less towards little architectural details of the CPU or
the OS you're running under.  Which is good news, as far as I'm

I've heard stories in the past about horrendous inefficiencies in
the design of the communications protocols of some of the commercial
MMORPGs, sending far more information to the client far more often
and in a far more bulky data structure than was necessary.  Some of
the stuff I heard even sounded like it was n-squaredish, which I
would have hoped people would be too smart to do on one of the top
online games, but I guess I should be more cynical about that.

So while I do think a big part of the reason I can use TCP with
impunity is that I design games where an occasional 2-3 second pause
isn't going to kill you or even upset you anyway...  I have to
wonder if some of these big games aren't less able to deal with TCP
because they're much more apt to clog the pipe, because they don't
streamline what they send enough, and/or because they weren't
designed as well to scale to large numbers of players without
n-squared problems.  If they were better designed, would they see
the 2-3 second pauses a lot less often, the way I do?

I have heard points in favor of TCP over UDP, possibly on this list.
For many users, the biggest bandwidth bottleneck (at their modem)
will be running through a PPP link that gives them TCP header
compression, but no corresponding savings for UDP packets, so the
actual number of bytes of data sent through the slow modem may be
LESS with TCP.  And while it's certainly theoretically possible to
make a reliable UDP that's better tuned for your specific app than
reliable TCP, the argument that TCP has been fine-tuned for years
and is well implemented still carries weight with me, given that in
the real world many programmers will indeed fail to do a perfect
implementation of reliable delivery over UDP, and might end up with
something that performs more poorly than TCP would have.  And of
course the work is already done in TCP, I'd rather spend less coding
time and get a project done sooner, with fewer technology risks.

Ultimately, if I make a system that only utilizes 5% to 10% of the
capability of the hardware, by ignoring newer OS calls and APIs that
would keep the players with 5 year old machines out, or by not
optimizing my code 100%, or just plain by not being greedy enough
for system resources to even ASK for much of what the CPU can
deliver...  I'm still getting far, far more out of the machine than
the machines of the 1980s could deliver.  And I certainly never ran
out of creative possibilities on those machines, couldn't do that in
an entire lifetime.  I'd much rather be pushing the envelope on
creativity, game features, game design, interface design, community
management, etc.

That said, I do think really huge online games are an area where to
some extent, we still have some technology-pushing needed.  Making a
game that can handle a million simultaneous users smoothly is
non-trivial from a technology standpoint, and I do have a bet to win
about that.  But still I feel that a lot of the other games out
there may be "penny wise and pound foolish" on the technology
issues.  If I make my game design, protocol design, and algorithm
design scale extremely well, I think at the really huge sizes I'd
see some of these UDP engines floundering from one scaling problem
or another, while mine would continue to grow smoothly.  One could
hope so, anyway.  :X)

   Dr. Cat / Dragon's Eye Productions       ||       Free download!
*-------------------------------------------**   http://www.furcadia.com
  Supporting user-created graphical worlds. ||  Let your imagination soar!
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list