UDP packets have less overhead, but don't provide the book keeping or
reliability offered by TCP. Many real-time servers use UDP and possibly some
form of compression.
Some servers might even use both TCP and UDP for different purposes.
Clearly if there is no distinction, one of those terms is superfluous.
I'll try to adhere to the most common definitions, for the sake of utility and
to facilitate communication.
I disagree, Diku would require significant modification to offer the
functionality of a Quake server, at which point it would probably look very
unfamiliar, in fact you might be better off trying to convert Quake into a mud.
You could provide a pseudo-3D graphical client atop Diku, but this is not 3D in
any contemporary sense, based on what modern users might expect if you tried to
convince them that it was. They would probably feel deceived (realizing they've
seen better 3D on their iPhone), and begin sending angry tweets. It could get
ugly.
Of course, we wouldn't want to burden the subject of server development with
issues related to server design.
What you said is,
To reference two well-known examples, not even Diku and LPMud are the same
thing, from a "server-development perspective." They are two very different
approaches to providing a virtual space. One is a hard-coded game server, the
other provides a virtual platform and language with which it is possible to
implement a game server, or something else entirely. So why would you assume
graphical mmos would be the same?
Differences in server design permeate not just the communication methods chosen
by the server, but in some cases, how the game itself is implemented along with
its various subsystems to what extent they exist, integrated or separately.
Add the complexity of managing complex 3D spatial relationships and the need to
frequently synchronize related constructs with the client, to determine
visibility/audibility, solve collisions, etc., and it could result in technical
differences that defy any reasonable attempt at comparison.
Indeed, this message forum might have more in common with text-based muds than
certain graphical mmos do. Should we include web servers and web forum
software into the mix as well? How about IRC chatrooms, certainly they manage
virtual space, and would even meet the "real-time" requirement of Mr. Trubshaws
definition. Many web technologies even offer some level of persistence, and
make use of concepts like "avatar."
Oh great! More assumption accusations. That's all we need!
You missed the point entirely, perhaps you've disregarded the context in which
the statement was made. The implication was that the client can only degrade
what information is provided by the server. It can take either take full
advantage of the information provided, or less. It cannot add information
where none exists. Adding a 3D interface to a game which is essentially 2D, or
not designed to fully utilize a 3D dataset creates a pseudo-3D game (similar to
UO's 3D client, as a generous estimate).
These "specific implementations," whether we like it or not, can have
consequences with regard to server design.