Most MUDs have no physics and as such are static, much like a picture. This works really well with the traditional model where builders create a static room description. MMOs have the same issue, artists create 3d images, after placement they never change. Doors don't exist in mosts MMOs, and besides doors I don't know of any functional pseudo-physics existing in MUDs. Some MUDs have weather systems, but they're mostly cosmetic, like there won't be a flood, objects getting hit by lightning, a stretch of forest getting ripped apart by a tornado, etc.

A physics engine would provide various material types with a set of rules of how they interacting and subsequently transform. With transformation comes the need to describe the various transformations, which is where the dynamic description engine would come in.

The concept of a physics engine will likely be pretty straight forward, with a human edible list of materials, and probably a way to configure some generic characteristics of the physics engine. The dynamic description engine is likely to contain human edible prototypes. A tree could be defined, what materials it's made of, what variety exists such as height, shape of the trees, quality of the wood, etc. The engine in turn would handle how to display a burned down tree, a tree that has been cut down, or a tree with a bunch of monkeys hanging from its branches. The physics engine in turn could handle how a cut down tree blocks your path, while the dynamic description engine is likely to handle how the tree obscures your vision. As with LPMuds a variety of drivers and libraries are likely to evolve once someone lays the groundwork.

Needless to say it's incredibly complex, though a simplified physics model is possible. Something very practical could be created, like the ability to display a three or four leaf clover, and have that have an influence when brewing potions, someone who has an intelligence of 10 and can't count past three will have issues as all clovers will be multi-leaved clovers. Some special skills could be required to distinguish the blood of a whore from the blood of a virgin, so the skill would be tied into the dynamic description engine. A werewolf with knowledge of metallurgy would see that someone is wielding a silver sword instead of only being able to determine that it's made of a metal. That's the most obvious way to utilize dynamic descriptions to impact game play, besides describing various physical states that one would like to be aware of, like that the windows are barred, the door is locked, and smoke is billowing into the room from the kitchen.

What do you mean most MMOs don't have doors? How many MMOs have you actually played for more than a few minutes? They've got more than doors, and I hate to break it to you, they use physics engines anywhere they think they're needed. Like the kind that is relevant to more than opening and closing a door… not that I think that even has anything to do with physics. You seem to be spending a lot of time talking about physics as it applies to transforming the world, but why do you think a text based game would be any better at displaying such a transforming world? Honestly, this sounds nothing more than a pipe dream at best. I think text based games are far more suited to these types of "picturesque" models you're talking about, and fwiw, most modern MMOs have started doing environment transformations.

Yeeeeah… I'm really bad about updating my blog. :thinking:


Sorry, is this in response to me as well? "Next-gen" != "3D", in fact I'm not doing anything directly related to 3D. I'm just using the browser.

42

Of course not! My apologies, this was totally aimed at the nuts who previously brought 3D MMOs into this discussion. I'm very familiar with your project and what you meant by next-gen.. a MUD client that runs on an x-box 360/ps3, right? (JOKING!!!)

((You know who this is, right?))



You should or you and I should have a more immediate way of getting in touch. I've been sorely missing our brainstorming on creative client development ideas.

*racks brains* Uhhhhh yes, but your name completely eludes me. :( My memory sucks, I swear I either need more RAM or a better HDD.


I know, right? I have AIM, MSN, and email. Just send me a PM here (or on Achaea) and I'll send you my info.

It's appropriateness isn't dependent on the '3' in '3d mmo', but the the first 'm'.
The number of dimensions isn't relevant as a 1d, 2d, 4d, or 5d mmo probably wouldn't choose Telnet either. ;-)

I would imagine most MMOs use their own custom protocol anyways. The main draw of Telnet is that it starts with a very small feature set that can be augmented via options, but MMOs almost invariably are made to talk with a single, custom client, so the common interchange format is fairly useless.

For MUDs it's quite the opposite.

Not really. Not by choice.

Text MUDs started out using TELNET for one simple reason. In the 1980's, the target audience was college students who were playing on dumb terminals (vt100's and their ilk), via a connection to some kind of mainframe. Some people were using workstations, but the average undergrad didn't always have access to them. Personal computers were connected via dialup modems and acted as dumb terminals for the most part.

Because of this, the idea of a custom client was out of the question. Very few people would have the ability to compile and use such a thing, either because they lacked the skills needed or (more commonly), they didn't have permission or disk space to do so. However, since telnet was commonly used to log into remote systems, it seemed a reasonable choice for a game client as well.

Text MUD's in that time didn't have fancy ANSI colors, nor did they require any kind of "out-of-band" mechanics, because – again – the players were using a dumb terminal which couldn't *DO* anything with such features, even if they had existed. Many MUD's don't even bother to implement telnet because many dialup terminal programs either didn't really support the protocol properly, or the connection itself didn't (7-bit connections were not unheard of, and the transport would not be able to distinguish between 7F (DEL) and FF (IAC).

Now, fast forward. Most players today are not overly fond of plain old TELNET, and typically use some kind of mud client. These tend to be generic because MUD authors don't write their own clients very often. As a result, the effort of customzing the client to make it useful for a given MUD is left up to each and every player who cares. THEY have to fiddle with regexps, and try to decide which kind of thing goes in which kind of window. I don't think very many players really WANT to have to do that, but they have little choice.

So, I ask the following question.

Let's assume the average player (not the diehard old MUD player who clings to their 1995 client, but an average gamer who finds text mudding and decides to give them a try) would prefer to go to your MUD's web page and download a customized client, where it already recognizes various game elements and has a UI setup that directs them to appropriate windows or screen regions, and may already have ways to let the user customize colors/fonts/macro buttons/etc, but also comes with a reasonable default setup.

Given that likely assumption, what REAL difference does it make to the player, what method the client and server use to communicate? Would it not make more sense to use something that makes writing such a client simpler? That is why I'm arguing for a structured data stream, rather than this subnegotiation OOB band-aid solution. It simplifies the server, it simplifies the client, it allows for generic clients to be more easily customized, and it makes it far more likely that individual MUD admins could do that customization themselves, for their players.

To me, this seems like a step forward. Do I expect everyone to jump on board? Of course not. Back when MUD's started adding ANSI color, lots of us laughed and said it was pointless since half the players were on monochrome terminals and wouldn't see it anyways. Yet, here we are… with only a tiny handful of antique MUD's out there which do NOT support ANSI.

Everyone said graphical MMO's were a pipe dream too. There was no way you could have 3D graphics over a modem. Hardware would never be powerful enough to handle full motion video in real-time. The idea of having more than 30 television channels was absurd. A telephone, that fit in your pocket and let you talk from almost anywhere? LULZ!

That was a very well thought-out response. :smile: I admit that I was speaking mostly from the present, where the norm is players connecting with multiple different clients (usually their pet favorite).


I have to admit, that's a pretty tough situation for me to imagine. Not because I disbelieve you, but because I'm spoiled on modern technology. :wink: But from the RFCs I've read, the people who created the Telnet protocol seemed to be thinking things through pretty well, and the 8-bit clean issue seems like a really strange thing to take into account. Is this really true?

For that matter, don't TCP and IP themselves utilize the high bit? I personally have a server where its dotted-decimal IP address has at least two numbers above 127 (and maybe all four). Dotted-decimal is just a handy way to express raw byte sequences (according to Wiki, 0xFF0000 == 255.0.0), so this really confuses me.


I agree that it would be ideal. It would also break backwards compatibility; you'd be starting completely from scratch. There are a lot of ways to make that work, but there are ten times more ways to end in failure. As an example, I've heard a number of gripes about IPv6 (none of which I'm really familiar with), and the biggest issue I've heard is that it's not backwards compatible with IPv4. This means a lot of upgrades to firmware everywhere to support the new standard.

Of course, the MUD community is only a very tiny part of the world. Still, you would have no clients or servers to start with! If something like this was undertaken, all I can say is: do not build by committee. Things like this should be proven in the wild before being standardized - give people a reason to use it! Make them \e\e[32m from envy! ([/color]\e[0m…) Otherwise - as some of us saw at MUDStandards - every little detail will be fought over during the process of creation.

For my part, I'm building something a little different. I'm writing a web-based client (without Java or Flash), and my main goals are:

1) Let MUD admins build custom interfaces much more easily, using already well-known technology (HTML/CSS/Javascript)
2) Let users discover MUDs without the overhead of downloading a client (much less picking the right one). Owner-provided interfaces are the default.

I guess you could say I'm tackling a different problem. Still, to tie this in to the current topic, under my architecture it should be possible to support more than just Telnet. (In fact, I was thinking of finding a way to run single-player text adventures through the client. Thanks to the "Get Lamp" documentary for that idea.)

I've actually had a lot of support from people I've talked to about this. I've only brought it up to the community at large once or twice (and I've only given you the overview), so I'm not sure what to expect. (I'm already using it to play my home MUD though, and even as basic as it is, it's pretty enjoyable.)


Hmm… Let the flaming begin? :sad:


EDIT: In retrospect, it kind of sounds like you're talking about what I want Aspect (oh yeah, that's my client) to be. Just without the different protocol - after all, I want to play Achaea with this thing. But like you said, what's the difference to the player?

You want me to download something to get the best experience from your game? Absurd!

Please don't flame Twisol. His client is actually really nifty. :]

Any links ready to explore, Twisol? I recently built a quick web UI but it uses a small Flash object to handle the telnet connection (the UI itself is in HTML/JS). How are you doing server-client communication without either Java of Flash?

It's not public in any form yet, sorry! I'm proxying MUD connections through my web server using Socket.IO (a library that encapsulates persistent connections excellently). The alternative would be to rely on Flash or Java, or force MUDs to support HTTP-based connections.

Have you ever used Mibbit? It's an online IRC client that works very similarly to Aspect. The downside to proxying is that all connections to a MUD look like they're coming from the same place, which hurts MUDs that disallow multiplaying. I'm planning on approaching some MUD owners in the near future to work out an acceptable workaround, but until then I'm the only one who can use it. (Suggestions are more than welcome! :smile:)

I'd post screenshots, but it's really not much more than a page with a Connect button at the top, an input bar at the bottom, and a big black space in-between. I'm working on implementing ANSI color support right now.


In the long run, I'm sure I'll need to offload some extra features to Java or Flash (like playing sounds, which has horrible cross-browser support right now). But the core needs to be dependency-free.

I think anyone who is serious about enforcing multi-player restrictions would have to go by some user id such as an email address and not by IP address. If you could provide some kind of common authentication layer (user registration) that the MUD server can access easily to read/write chars belonging to this user id, that would be neat for servers that don't already handle that.



If I understand you correctly, you're writing the page/UI in HTML/JS. You can take a look at the basic ANSI color implementation inside this js for a quick start.



Good luck warding off the ghosts of Java and Flash! I'm sure that the longer you manage to do without them, the better the final product will be. Looking forward to it.

Well, the first thing I want to nail down is the IP address. That's the big issue that Aspect steps all over. Anything above that would be awesome, but it's not my first priority. I want to get Aspect at least functional and usable.


That's right. If you look at it in terms of the MVC design pattern, the user's browser is the View; the Aspect server is the Controller; and the MUD itself is the Model. At least to a point, anyways.

Thank you for the link! That'll be really helpful. It's interesting that you wrote the socket handling in Javascript, because UTF-8 (the encoding used for JS strings) disallows byte 255 (IAC). How did you handle that?


Well, so far it's worked pretty well. :) I mean, Socket.IO does support Flash sockets, but it's one of its many fallback mechanisms. Flash sockets are one of the most optimal ways to communicate (because it's basically just a raw socket), but it will fall back to AJAX long-polling, infinity-iframes, etc. if it needs to. So Flash can be used, but it's not required, so I call that a success.

And you know, Javascript/DOM scripting is pretty powerful. Sockets are the big hurdle, and everything else is just multimedia. Look at Grooveshark! Almost their entire interface is HTML-based. As far as I can tell, only the audio is powered by Flash, which is pretty cool.

I never encountered this issue because, as I mentioned before, the socket handling is in Flash (but everything else is in JS/HTML). Take a look at this package I recently uploaded into the repository. From the description:

"A small Flash object (33k) which enables JavaScript functions on the page to control a telnet connection. The JS can set all required parameters dynamically, open, close connections, receive, and send data.

This object can be used to build custom lightweight telnet interfaces in HTML & JavaScript. The attached HTML container page is an example of a basic telnet interface with rudimentary ANSI color support."

It would have been ideal to forego Flash altogether, but I hadn't heard of Socket.IO and node.js a few months ago.



That's exactly what I was going for with the simple Flash API. It's just an actionscript telnet socket handler that people can put in the core of a web-based client written primarily in JS. It has none of the finish of fmud but it's much faster, fully controllable, and fully customizable using JS.

I'm pretty sure your approach will beat my Flash object in terms of speed, but take a look if you think it might help you along.

Oh, I see. Sorry, I was looking specifically at the JS file and I made an assumption. :rolleyes:


Right, very cool! I'll definitely check it out; I'm trying something very different from past clients, so anything related is a big help.

You might want to take a look at how Cratylus modified anyterm to work around the IP address masking thing. I think the general idea is to pass the actual IP (which the server proxy knows) along as data, which the game server can then plug in instead of trying to query the peer address (which is the proxy).

I believe that a number of people here are either misunderstanding or simply not understanding. Nobody here is arguing that people should use telnet to connect a modern 3D mmo with a modern client. That would be silly, given that protocols for connecting these have had over a decade to mature and that telnet still is a text terminal connection protocol, no more no less. (The only thing that's possibly sillier than arguing that is imagining that someone has argued that so one can feel better about their own infinitely superior intelligence. One is bound to miss a lot of learning opportunities if one plays that kind of game with one's self.)

Instead, what I was talking about is what KaVir touched upon in this thread on MUSHClient's ability to add visualization plugins. Like I tried to argue before, there is absolutely no need to add another protocol on to an existing MUD server just so you can send over enough information for a client to draw up a faux-3D (as in "imitation") view of a "place" in the MUD world. The information one would need for that is not going to be true 3D coordinates–the client can exercise a lot of discretion in drawing the view based on the same information normally interpreted by the player.

As for the first "M" in MMO, Tyche, you may be surprised to learn that on a single day when my iPhone GUI (faux-2D) was free, my CircleMUD-based server saw 18,000 players without crashing once. The limit was set at 500 simultaneous connections. Maybe that's not much by comparison to the big players out there, but in my *experience*, it's definitely not telnet that's keeping MUDs from going massive.

Also, Runter, if you're adverse to games that make you download a client, you may wish to ponder the fact that the vast majority of humanity thinks the client *is* the game, and so in a very real sense MUD servers are losing (or have already lost) the status of games.

I believe that the goal of this thread was to make some of us wake up, smell the coffee, and go to work. Well, I think I'm awake and have already gone to work. Ever since I got back into mudding 20 months ago, it has been a mantra of mine that it's all about custom clients and now I have a track record to prove it. And if I have to fake 3D in 2012 just to get more players, then egads, I will, over whatever protocol it takes.