Hi, hey, hello
 

What's up?

I'm a 21 year old mud developer writing my own codebase and making a game in it. I like Dr. Pepper, hot pizza, anime, my former mud home lusternia, and hentai, all in excess. I'm not a particularly talented programmer but have forced myself to become proficient in lua.

..That's really about it. More information about my mud will follow when it's out of open alpha, but if you're brave and don't mind the open mess, you can connect to mobiuseor.com on port 23.

EDIT: windows telnet should work now. Didn't realize I'd have to do my own input buffering.

Re: Hi, hey, hello
 

Hey howdy hi, nice to see your intro! Good luck on your base, sounds like you're at least having fun with it!

Re: Hi, hey, hello
 

You had me at, "I like Dr. Pepper". Good luck and have fun!

Re: Hi, hey, hello
 

Thanks! Definitely having fun, and gaining a few grey hairs too. If nothing else, I'll be something else in terms of lua by the time I'm done.

Re: Hi, hey, hello
 

Hi there,

I tried to check out your mud. I was able to connect and saw the opening screen but the text appeared garbled (I'm using the Windows built in telnet client)
Anyway, I just thought you should know :)

Drax

Re: Hi, hey, hello
 

Aha, sorry about that. I've actually been trying to make windows telnet play nice with it, but haven't had any luck yet.

Re: Hi, hey, hello
 

Gray hairs are totally fashionable these days... at least that's the rumor I'm trying to get started ;-)

Re: Hi, hey, hello
 

A bit of an update: I've decided after much deliberation to make Mobius into a graphical mmo instead of a mud.
Given that this probably isn't the right place for it anymore.. it was nice meeting you all, and goodbye!

Re: Hi, hey, hello
 

From a server-development perspective they're pretty much the same thing, the main difference is that you'll need a graphical client as well.

Re: Hi, hey, hello
 

KaVir is absolutely right, although some people in this community may feel strongly otherwise.

Recently, I embarked on a project to help MUD servers develop better web UI's easier. This includes graphical interfaces. If your goal is a web-based game, take a look at . You can learn more about it and .

Re: Hi, hey, hello
 

It's only true from a very literal perspective. If you're building a very basic graphical MMO targeting a very small population, and using a downloadable client model, it's probably more or less true. At Sparkplay, my engineers built tech for predictively streaming 3d open world MMOs, and a couple of the issues that cropped up that I'd never had to deal with in text MUD servers before that come to mind (there are others, but these are the ones that immediately come to min):

* Scale. Large numbers of players compared to the tiny populations of MUDs make a huge difference in how you might engineer the server-side component, including sharding, enabling cross-shard interaction, and so on. MUDs don't have to deal with this because they don't target scaled up player populations (though some of us would love to have this problem!). The need to prepare for scale changes how one approaches a large range of server-side issues.

* Web-based or thin client with predictive streaming content to facilitate an open world with minimal downloads or waiting while running around the world. This is a very tricky issue that text MUD servers don't have to deal with.

* When you're running around in a client-server model in a 3d world, for instance, you typically have to have the client and server working pretty closely together to prevent 'skipping' around or jittery movement. Movement prediction is important, and something that our team spent a lot of time getting to feel right. Another issue that just doesn't come up in MUDs.

So while it is technically true that there doesn't need to be a big difference, in practice on the commercial side, there is a big difference, which I saw directly when tasking the same guy that had built the Iron Realms 'Rapture' server engine with architecting the MMO server engine for us, and despite having half a decade of extra experience by the time he did the latter, it took him far longer, and he spent far more time beating his head against his monitor (and he wasn't doing it alone in that case, whereas he did it alone in the case of Rapture).

As with everything, until you do it, you don't know what you don't know.

Re: Hi, hey, hello
 

For those who are interested in the subject, there's actually a very good article by Raph Koster (who has with both MUDs and MMORPGs) entitled "Are MUDs and MMORPGs the same thing?"

"This always comes up, and I often seem to be on the opposite side of the argument from many players. I’ve usually found that those who have worked on the implementation side of both tend to feel that they are the same thing, but that thsoe who haven’t see them as somehow categorically different.

So here’s my stab at explaining why I think both are really the same thing; in many ways, there are far larger differences between certain kinds of text muds than there are between graphical and text-based games."

Re: Hi, hey, hello
 

Yep, they are the same thing, but so is a bicycle and a Tesla - they're both forms of transportation. Building the two are vastly different propositions.

Re: Hi, hey, hello
 

I prefer the analogy from :

Re: Hi, hey, hello
 

While neither analogy is perfect, the horse and carriage one feels a lot closer. Why? Because I can build a GUI to a MUD server by modifying less than 50% of the code, and adding some on top. The end user experience will be vastly different, yet my server would just be pushing more math. The challenges you mentioned are not indicative of any anatomical differences. If you want to display player locations in any game, you'd be forced to overcome such issues.

Re: Hi, hey, hello
 

Talk about making assumptions. :rolleyes:

The server could implement its protocol in a totally unconventional manner. It
could end up utilizing different transport technologies, like udp, or
streaming media to clients. Who knows?

You mean the same as in, they both run on computers and communicate somehow
over a network? :)

There is nothing in "graphical mmo" that implies how it will be implemented.

Re: Hi, hey, hello
 

He means the same as in having very similar game logic. The character of a game is defined by its game logic and, to a lesser extent, by the exact mechanics of its gameplay.

The assumptions are all on your part, and the biggest one is that implementation has anything to do with the genre of a game. This is professedly untrue.

Simple example: Two games both use UDP to stream location data to their clients, use the exact same media streaming technology for audio and in-game video, are both written in the same script on top of the same middleware, use the same database. One is Mario Cart multiplayer mode for Nintendo Wii, the other, let's say, Tera Rising.

Re: Hi, hey, hello
 

It's you who's making assumptions. Those are decisions that have to be made regardless of whether you're developing a text-based MUD or a graphical MMORPG. In fact the network protocol will be a relatively tiny part of the overall project, unless you need to scale the game for exceptionally large numbers of players (which once again holds true regardless of whether or not you're going graphical).

As Raph Koster said in the link I posted earlier, "in many ways, there are far larger differences between certain kinds of text muds than there are between graphical and text-based games"

Re: Hi, hey, hello
 

That wasn't an assumption, on the contrary, it was the benefit of the doubt.

So then you admit to assuming the game will have similar logic, which is a far
more flagrant assumption. Even the number of ways to communicate over a network
(with standardized network protocols) is limited compared to the number of
ways to configure software logic and game mechanics.

Because both systems use databases or (might) require some level of persistence
does not automatically establish the overall solutions with be even vaguely
similar.

Your examples are insubstantial.

I enjoyed the article.

I think, Mr. Koster is speaking in a very abstract sense. In practice however,
how a protocol is implemented can affect both client and server operation
significantly. I think there are enough examples to safely conclude, this is a
fact. [Hint: take a peek at a few RFCs]

An example (inspired by one of Mr. Koster's comments) might be the difference
between, whether I chose to implement a turn-based MMO with an HTTP server
(without using websockets, AJAX, etc), or based it on (some vanilla derivation
of) DikuMUD.

Do they both manage and provide some representation of some abstract
simulation? Probably. Do they both offer some level of persistence? Possibly.

Is an HTTP server, which is designed to serve requests, the same as a TELNET
interface designed for bidirectional "text-oriented" communication?

Only if you decide to abstract everything into "datastreams" (with little
regard for time), which Mr. Koster appears to have done, and conclude that only
the clients representation of that data changes significantly.

I'm a Pepper too, btw. (For the record.) :cool:

Re: Hi, hey, hello
 

It can, although as I said it's a relatively small part of the MUD, the sort of thing that a well-designed server could change at a later date if it wished. [Hint: take a peek at my ].

However the point is that you have to factor network protocols into your design regardless of whether you're developing a MUD or an MMORPG, and two games might take the same (or different) approaches regardless of whether they're both MUDs, MMORPGs, or one of each. You can't just say "this protocol is for MUDs, and that protocol is for MMORPGs".

Re: Hi, hey, hello
 

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.

Re: Hi, hey, hello
 

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! :mad:

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 :confused: ... It's late, I'll get back to ya on that one.

Re: Hi, hey, hello
 

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.

Re: Hi, hey, hello
 

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.

Re: Hi, hey, hello
 

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! :rolleyes:

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.

Re: Hi, hey, hello
 

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.

Re: Hi, hey, hello
 

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.

Re: Hi, hey, hello
 

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,

Re: Hi, hey, hello
 

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. :p

Re: Hi, hey, hello
 

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!