[meae]

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.

[Lorana]

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

[Newworlds]

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

[meae]

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.

[draxen]

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

[meae]

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

[Lorana]

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

[meae]

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!

[KaVir]

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.

[plamzi]

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 .

[the_logos]

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.

[KaVir]

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."

[the_logos]

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.

[KaVir]

I prefer the analogy from :

[plamzi]

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.

[Achon]

Talk about making assumptions.

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.

[plamzi]

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.

[KaVir]

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"

[Achon]

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.)

[KaVir]

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".