[plamzi]

That the game logic of most MMORPG's is near-identical to some MUDs is not an assumption but an observation, one that is kind of obvious to anyone who has played a hack'n'slash MUD and then NWN, Diablo 2, 3 etc. That MMORPG's are historically and technically the same thing as "graphical MUDs" doesn't need proving so much as some basic research on your part.

As a matter of fact, I have been testing the truth of this for four years now. I have a pretty typical DikuMUD driving a mobile MMO UI that is quite indistinguishable from any other mobile MMO (except it's better ). Based on my experience, I have no trouble believing that a server like KaViR's, which has a co-ordinate based world, would be able to drive a 2D or 3D client with no or very little change in the game logic.

You are right that just because two games use a database doesn't mean they are at all similar. However, that supports my argument and not yours Now, picture two games that both have character properties and advancement, items granting character boosts, mobiles granting items, etc. Because their game logic is similar, chances are that their db schemas will also have structural similarities. And so will their server code, which handles the state changes in these entities. It doesn't matter whether one is written in C++ and the other in Patagonian, that one uses MySQL and the other some proprietary RDB especially designed to make this kind of storage easier.

[Achon]

Small, perhaps, but not insignificant. The protocol in many of these cases,
HTTP, TELNET, FTP, SMTP, IMAP, etc, etc, IS the very minimal definition of how
the software needs to behave in order to be considered compliant with that
particular version of the standard. It defines the server (and often clients)
basic functionality.

While you might be able to coerce an HTTP server into implementing
bidirectional TELNET-like functionality or vice versa, this does not change the
essential fact that they (by definition) are not the same, nor are they likely
to be implemented the same.

You might say there are conventionally fewer restrictions on how an MMORPG
implements its protocol, otherwise you risk blurring the lines between MUD and
MMORPG, which could lead to some rather foolish arguments.

It is however these "different approaches" regardless of whether they are MUDs
or MMORPGs, which leads us back to the original point. Different approaches can
lead to different outcomes, and it would be an mistake to assume otherwise.

I contend that the choice of protocols could significantly alter both client
and server design, in addition to the potentially vast dissimilarity created by
the game logic itself.

Generalizing a simple observation often produces an assumption.

How could two separate games have "near-identical" game logic? That makes
little sense. What would motivate people to spend their money on such similar
products? I know for certain if I purchased Diablo 3, and it sucked as much as
Diablo 2, I would demand a full refund!

I don't doubt that. Now, will KaVir's server maintain some geometrical scene
representation (shared with the client), and detect collisions with arbitrary
3D planes? Or would both client and server need to be upgraded before we get
to experience these features?

Okay ... It's late, I'll get back to ya on that one.

[KaVir]

There aren't fewer restrictions, nor is there a "line" (at least in any technical sense), that's the point. You can play Second Life with a text-based client, or a Diku with a 3D graphical client, should you so wish. There is also nothing stopping you from mixing text and graphics in varying degrees, and indeed most MUDs/MMORPGs do exactly that.

Obviously, but I never claimed that every server is identical. What I said is that there's very little inherent difference between server development for a MUD, and server development for a MMORPG. The issues you're bringing up are not specific to MUDs or MMORPGs, they're general issues related to server design.

Only if the server is extremely badly designed. And even then, you'd have the same problem regardless of whether it was a MUD or MMORPG.

Now you're talking about specific implementations - you're making those assumptions again. Do you think all MMORPGs have collision detection? Do you think MUDs can never have collision detection? This comes back to my earlier point: when you design your game you need to decide whether or not you want collision detection, and you need to make that decision whether you're developing a MUD or an MMORPG.

[meae]

Wow, didn't expect to start such a lengthy discussion, but I'd be happy to contribute.. from the outset, I've been taking notes on developing both applications. I knew a little bit from reading development guides but mostly I've been banging my head into my keyboard.

Position updates taught me the most major lessons.

First, detecting when a client has tried to move out of bounds in a 2d plane without any obstacles is trivial. Accounting for solid objects on the terrain, and a third coordinate? Not so much.

Second, client software loops very quickly. Many hundreds or even thousands of times per second. Attuning the rate of motion to prevent rubberbanding is a challenge all to itself, and with the client looping that often, you need a substantial amount of packet updates to see entities other than those your client is positioning move smoothly. This amounts to about 15 position updates per second for my client, which also uses prediction to account for momentum. Another 5 are used to provide minimal state information on things that can be affected, like mobs. At the moment, that includes everything that moves.

-This raises even more sub-problems of its own. In the textual version, I didn't have to send everyone a mass of packets every second. In the graphical version I'm having to be far more specific when designing objects, to avoid bandwidth waste, and shorten data in general, since n20 space separated strings per second per player is a gigantic cost.


That's not to say its been all difficult, though. Learning to code for the mud client standards was a serious pain in the ass. Detecting client types, disabling or enabling feature sets, and applying compatibility filters is a lot of work. On top of this, analyzing input was extremely tedious, having to account for many variations of commands and document all of it.
Having control over the client's side of things doesn't mean i can discount the golden rule (never trust the client), but it means i can make a lot more assumptions about the structure of input data and state of the client, and don't have to provide verbose error messages to the client when something is improperly formatted.

I'm having fun expanding my horizons, and though much of the functionality and story are changed, it's infinitely entertaining either way to try and build your own little world from scratch.

[Achon]

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.

[KaVir]

The word you're looking for is "marketing". Early MMORPGs were simply called graphical MUDs.

This appears to be the crux of your misunderstanding. You're comparing two specific implementations that were never intended to work together. As I've , clients "can't pull the data they need out of thin air - they need some way to extract it from the mud". This sort of thing needs to be factored into the design.

A DikuMUD could be played as a fully graphical game, but it won't look like Quake. World of Warcraft could in theory be played as a text-based game, but it wouldn't look like DikuMUD.

However in this particular case the poster is designing his own server, and therefore has full control over what data it passes to the client. He could create a game server that is playable as both a text-based MUD and a full 3D graphical MMORPG if he wished, depending on which client the player uses.

[meae]

After switching to UDP, and before I fully realized it, I started trying to re-create TCP's features in the payload. Which is silly, so I've decided to "go against the grain" with this and use TCP.

This is my central implementation of the "alternate worlds" theme, and both the client and server are coded to handle different interaction paradigms. The primary challenges in this seem to be designing so that objects can be used in more than one paradigm and trying to maintain balance.

[Achon]

TCP is probably your best bet. I'm not even sure how fashionable it is to use
UDP these days, there's been some pretty major bandwidth improvements over the
years. Though I'm sure it still sees some use. TCP offers a lot of convenience,
which UDP can help you appreciate. In a situation where you find yourself
reimplementing TCPs features, then yea, it's probably best just to settle for
TCP. In fact, using UDP may be more accurately described as, "going against
the grain," for most common purposes.

UDP is unreliable, which may not matter so much in cases where you are sending
lots of small packets containing data that is not so critical, like movement
deltas, where a few losses won't mean the end of the world.

Wikipedia States,

[Newworlds]

Two things: Thing one, this is just the beginning of your "primary challenges". If you are truly trying to go Graphical MMORPG, your real challenge will be getting a studio, sound engineers, recording, graphic designers, artists, rendering, and doing it all on little or no budget. Unless of course, you happen to have a million or 2 stashed away.

Thing two: On the argument of there being no difference between an MMORPG and a MUD. I think you are all talking about the data stream and not the definition of MMORPG which is MASSIVELY (key word) Multiplayer Online Role Playing Game. That means folks, 1000's to Milions of players, not single digit to a few hundred. Let's not kid ourselves, MUDs are not anything like MMORPGs in the sense of the term which was created by Ultima Online's developer which had over a million players and he wanted to differentiate it from a simple multiplayer online game. Don't lose faith though, one day they might be, afterall "The Hobbit" the book sold more copies that the movie ever will.

[meae]

A little update (and one that makes me feel quite flaky!)

I successfully cobbled together a graphical game engine, client and server. I used freely available assets from numerous indie resources and actually managed to get a coherent theme, somewhat pleasing UI, balanced gameplay and stable, low requirement threaded system.

I hated it. I lamented the loss of creative freedom and inability to precisely impart the theme I'm trying for, the increased difficulty in implementing user generated content and the suddenly flat and direct gameplay.

So I've decided to go back to making a mud, where the only obstacle in my way is focus.

tl;dr i'm making a mud after all, how flaky!