I can see the advantages in having a web-based client. But what are the advantage in running the mud server itself in this way? Couldn't someone just modify their existing codebase to take full advantage of the web-based client?

Do you still support telnet clients? There's already an established community of mudders, and many of them already have a preferred client (and some of these clients offer a huge range of features) - will players be able to stick with their existing clients if they don't like yours?

You see, a real game client does not use a request protocol like telnet, wherein the pushdown is only information I am able to see. A real game client transmits massive amounts of information that is useful to the game, but not useful to the user as a sentence in English.

For example, a person enters a room. In a MUD 1.0 Mud, the game broadcasts a message to the room "X entered" --

But what if I wanted to have a persistent pane that updated automatically as people entered and exited the room? Or a persistent "Who" window that updated and changed as people entered and exited and went invisible? Well then I would need to send data that had more information in it than just a string the user could see. It would need to have Meta Data, that stuff that Telnet just cannot provide.

But Browser's support meta data no problem, and they have for a long time. In this instance we are using JSON.

The problem is that you have to reconfigure how you conceptualize the MUD. Now when anything happens (a person enters/leaves the game, enters/leaves a room, changes position, changes a flag) you need to send anyone who could easily observe that state change data that the state has been changed, without explicitly forcing them to see a whole new copy of the "who" list. So the client has to do a lot of work too in this instance. The client has to interpret that Meta Data and decide how to display it. We have developed two clients thus far. One plays just like a regular Mud client, and looks the same, etc. The only difference is pictures. The other one has active panes and floating windows that update automatically as game state changes quietly in the background.

So this is behaving like a real, actual game client and not a mud client per se. Could current muds be altered? Yes, but they would have to take all of their observation commands and push them into the client and then go through their code and implement all the appropriate triggers to send the encapsulated data to the client when the data becomes relevant.

It's doable. But this solution is better. Not only that, having gone through Diku/(extensions of) extensively, I have to say that they did a good job with creating a game and a terrible job writing the code. It's just awful. Not extensible, not really properly scriptable, etc. I'm rewriting with a much more efficient, flexible framework that will massively increase Diku functionality. (If you wonder why I bring up Diku specifically, I was raised on Diku, all MMORPGs today play like Diku, etc. and so I want to get that feel. But the idea that "North" is "North" because an exit is in position 2 in an array is stifling. Especially because the benefits to an implementor/core code designer of using that system are almost negligible.)

So, there you go. I am hoping to get people onboard, because I would love to create a browser based mud that plays like a real MMO. I think it's a big opportunity.

You see, a real game client does not use a request protocol like telnet, wherein the pushdown is only information I am able to see. A real game client transmits massive amounts of information that is useful to the game, but not useful to the user as a sentence in English.

I would argue that dedicated mud clients are also "real game clients". Some of these clients do support graphics (sometimes even 3D graphics and real-time animation) and sound, and transmit data that isn't human-readable (such as telnet negotiation sequences and compressed data). A few of these mud clients are also browser-based, such as FMud.

3squire wrote:

For example, a person enters a room. In a MUD 1.0 Mud, the game broadcasts a message to the room "X entered" --

But what if I wanted to have a persistent pane that updated automatically as people entered and exited the room? Or a persistent "Who" window that updated and changed as people entered and exited and went invisible? Well then I would need to send data that had more information in it than just a string the user could see. It would need to have Meta Data, that stuff that Telnet just cannot provide.

The problem is that you have to reconfigure how you conceptualize the MUD. Now when anything happens (a person enters/leaves the game, enters/leaves a room, changes position, changes a flag) you need to send anyone who could easily observe that state change data that the state has been changed, without explicitly forcing them to see a whole new copy of the "who" list.

Many muds send this sort of information to the user anyway - an "info" message when someone logs on or quits, an arrival/departure message when someone moves into or out of sight, etc. Many mud clients also allow users to write their own custom plugins (usually supporting a variety of programming languages), gag specific string sequences and spawn additional windows, so this sort of thing could even be done without support from the mud (although it would be cleaner if the mud supported it explicitly).

3squire wrote:

So this is behaving like a real, actual game client and not a mud client per se. Could current muds be altered? Yes, but they would have to take all of their observation commands and push them into the client and then go through their code and implement all the appropriate triggers to send the encapsulated data to the client when the data becomes relevant.

To be honest that's pretty much exactly what I did when I added support for the MUD Sound Protocol (MSP), and that didn't require more than a few hours work. What you're describing here is really just another protocol, and I don't think many people would be willing to discard (in some cases) literally years of work just to have a game that supported an extra protocol.

The less restrictive MIT licence is nice, and IMO could provide a decent incentive for new mud owners who are looking to start out. But I suspect one of the first things people would do is add support for telnet-based mud clients, because without that you're going to lose a lot of potential players.

A browser-based client is definitely nice for pulling in new players, particularly if you target browser gamers, but I think it's going to be a pretty major hurdle for attracting veteran mudders.

The real difference between the MUDs of yore and the modern MMORPG client isn’t the sim on the backend; it’s the fact that the datastream is tokenized. When you connect to a MUD and it attempts to inform you of the presence of an object, say a chair, it actually sends the definition of that chair down: the words that make up its description. When you connect to a graphical MMORPG, instead you are sent an index number, a token that lets you look up on your local client install the description of that chair (which these days, is likely to be a 3d model). -- Raph Koster, http://www.raphkoster.com/2006/03/31/are-muds-and-mmorpgs-the-same-thing/

Well, I would argue a bunch of things, not the least of which is that from a programming perspective, this is far easier than developing a rigid client. The whole point is that the clients can be built custom and made to handle data differently. More importantly, the incredible extensibility of the data framework here vastly outclasses MXP.

The proof is in the pudding though. This is not meant to feel like a MUD, except for the good parts of mudding, and it really doesn't. I've been on a lot of the most popular MUDs out there, and they are still like the MUDs I played 10 years ago technologically. Which is to say, text with colors, sometimes there is sound, and ASCII graphics. It gets a little more sophisticated, but the emphasis is on "little".

What benefit does telnet provide? See that's a place where we are really going to disagree. Everyone who is on the internet has their browser open. Flipping between tabs in a browser and flipping between telnet or a specialized client and their browser are two pardigmically different activities.

As to "arrivel/departure messages" -- The whole point is that the client can handle incoming data any way that it wants to. I want to know who's online in real time, or what the price of Ore in the southern region is in real time, and this client can give me that information without flooding my screen with all the data it's transmitting to me. This isn't about "X sits down" messages, it's about someone going invis and disappearing automatically from the "Who" list.

Something I find so surprising about the number of years people have worked on their MUDs is the fact that 99% of a MUD is (should be) in the content-side, which is not so difficult to port anyway thanks to the fact that these games are text. One advantage of using PHP is that people will be able to script directly in PHP and edit in the Browser, both of which should massively improve the building experience for content creators.

Basically, I don't see this in the restrictive context of a MUD platform, but as something totally new that MUD players would be familiar with.

Well, I would argue a bunch of things, not the least of which is that from a programming perspective, this is far easier than developing a rigid client. The whole point is that the clients can be built custom and made to handle data differently. More importantly, the incredible extensibility of the data framework here vastly outclasses MXP.

The client certainly sounds intriguing, but if it's worth using I would add support to my existing mud. Losing support for telnet clients would cost me most of my players, and scrapping the actual game would cost me all of my players. I expect most mud owners are in the same boat here. Your codebase may well be of interest to those who are just starting out, but I imagine most established games would be far more interested in the client.

3squire wrote:

The proof is in the pudding though. This is not meant to feel like a MUD, except for the good parts of mudding, and it really doesn't. I've been on a lot of the most popular MUDs out there, and they are still like the MUDs I played 10 years ago technologically. Which is to say, text with colors, sometimes there is sound, and ASCII graphics. It gets a little more sophisticated, but the emphasis is on "little".

Graphics and sound are client features, not server features. Something like the Shattered World 3D telnet client could in theory be created for any mud - it's a separate application from the server.

The technology of muds has definitely progressed in the last decade though, and this may actually be another problem for your codebase if it's just a "better Diku". Diku is 20 years old, and its age really shows when you compare it to modern muds. Having a fancy graphical client is nice, but when both muds have that same client, people are going to start comparing the features, and those 20 years of extra development are going to show.

3squire wrote:

What benefit does telnet provide?

It's well-established and well-supported. I'm definitely not opposed to alternates, but I believe it would be a mistake to discard telnet support.

3squire wrote:

As to "arrivel/departure messages" -- The whole point is that the client can handle incoming data any way that it wants to. I want to know who's online in real time, or what the price of Ore in the southern region is in real time, and this client can give me that information without flooding my screen with all the data it's transmitting to me. This isn't about "X sits down" messages, it's about someone going invis and disappearing automatically from the "Who" list.

Right, but telnet mud clients can also do that if you want them to.

That's not to say your client doesn't have advantages - a web-based client means no downloads, making the game far more accessable (easier to use, can play from any computer without needing to install special software, etc). From what I understand, your client is also far more customisable than most, and it sounds like it has much better graphical support than most telnet clients. It seems like a very nice addition for a mud, but I don't think it's quite as far ahead of the telnet clients as you think.

3squire wrote:

Something I find so surprising about the number of years people have worked on their MUDs is the fact that 99% of a MUD is (should be) in the content-side, which is not so difficult to port anyway thanks to the fact that these games are text.

To be honest that really depends on how the game is designed, and what you consider "content" (eg LPMuds and similar already allow you to create the game from within the game). But unless your game has very simplistic gameplay, there's likely to be a lot of coded mechanics.

3squire wrote:

Basically, I don't see this in the restrictive context of a MUD platform, but as something totally new that MUD players would be familiar with.

KaVir, you have to understand that from my perspective, what you are saying is like someone telling me that EverQuest should have supported telnet.

I mean, look at the code. You are writing as if I don't know what I'm talking about, and a lot of your talking points actually do not make sense in this context.

A mud in a telnet client simply cannot support the kind of emergent gameplay elements this engine will support, period. It just cannot.

I understand the desire to "protect" one's game, since in many ways more than other games, individual muds are like works of art. But Shadowbane, for example, has opened, run its course, and closed in about a quarter of the lifetime (or less) of GodWars, because it wasn't technologically attractive anymore in it's context (graphics, etc.)

In the same way, this isn't a replacement for MUDs, but it also isn't a MUD as they are generally conceived and it will have it's own lifetime, context, etc. I do not think people will think of it as a mud. Maybe a MMOBG or something, I'm not sure.

At a lot of your claims about how it is not different come from clearly not having looked at the code at all. Since my desire is to get people to look at the code and see it for themselves, I'm not going to go into lengthy exposition about it. When the game is launched, you'll have an opportunity to play, and at that point you can revise your position as appropriate.

At a lot of your claims about how it is not different come from clearly not having looked at the code at all. Since my desire is to get people to look at the code and see it for themselves, I'm not going to go into lengthy exposition about it.

I'm sorry to hear that, but the clearly stated purpose of MudLab is to provide a medium for discussing muds and mud-related issues. If you don't feel your game is a mud, and you don't want to discuss it, then I'm not really sure why you posted.

I do find your view on browser-based clients interesting, as it provides a good counter-point to telnet client developers who express opinions like "...it’s a terrible misconception to try to present high quality MUDs that have been developed for more than a decade by legions of developers as a cheap little browser game that has been developed in a couple of weeks."

In my opinion both approaches have their pros and cons, and I don't see them as mutually exclusive. I've seen muds that offer browser-based clients (the Maiden Desmodus client is really nice, for example, with a graphical map that follows you around in real-time), but these clients are offered in addition to support for telnet clients, not instead. I've also seen a few graphical iPhone mud clients, and I think that would make a nice option too.

But I tend to view these as accessories - the meat of the game lies in the server. The client can involve a lot of work, and have a huge impact on the playing experience, but it's not a "game" in its own right. It's just a front-end. And a mud can support multiple front-ends.

Hey it's your forum, do what you like with it. You're the one who redefined MUD then when I said this codebase fell outside the definition told me if I didn't like your definition then I was welcome to find the door.

The fact is, MUDs as you conceive them are dying and will die out because it would take only a small investment to radically improve the games while retaining the core features. Like the shift from printed and bound books to e-readers, the book is the point. In the same way, in a MUD the action and the description and depth are the point, but they are mutually exclusive, yet presented together because you can only input data through a terminal interface and receive it the same way.

This is a traditional mud in that it does not rely primarily on graphics and retains as much of what's good in MUDs as possible while upgrading to something better. Again, don't take my word for it though. Clearly, you haven't been.

I can understand you wanting to defend your product, but please understand I've heard the whole line about revolutionising muds a hundred times before. Likewise, I used to collect quotes from people claiming that text muds were dead or dying - one per year, dating back to 1990.

Muds are always going to be a niche market, and I don't believe there is any one silver bullet that's going to magically change that. However I certainly agree that a good client can help attract players, and your client sounds like it has potential. I wish you the best of luck with it.

Although telnet is commonly associated with modern muds, the earliest muds weren't even run on the internet. The original MUD, for example, ran on JANET (a British academic network), while early commercial muds such as MUD2 and Gemstone were available through dial-in services like Wireplay and GEnie.

It's also worth noting the recent attempts to formalise protocol standards across mud clients. I think this is the right direction to go - making muds accessable to a wider range of clients.

Although telnet is commonly associated with modern muds, the earliest muds weren't even run on the internet. The original MUD, for example, ran on JANET (a British academic network), while early commercial muds such as MUD2 and Gemstone were available through dial-in services like Wireplay and GEnie.

It's also worth noting the recent attempts to formalise protocol standards across mud clients. I think this is the right direction to go - making muds accessable to a wider range of clients.

dialing a bbs to play legend of the red dragon....

so how does one control the burst ability for the meta-refresh in this client. i mean this client might work fine for small pool play. how does it handle quest groups and the like, or is that even supported for large group play. Im trying to picture the way the meta refresh works in a huge combat situation, and I see it coming up short. diku can put out as much spam as needed and be segment free and seamless, up until the buffer is overrun.

so how does one control the burst ability for the meta-refresh in this client. i mean this client might work fine for small pool play. how does it handle quest groups and the like, or is that even supported for large group play.

To be honest I don't think it's going to be much different. I know there's already a server that supports both protocols though, so it might be interesting to make a direct comparison.

In regard to telnet clients, Nick Gammon recently released a YouTube video showing some of the telnet negotiation concepts he's been working on - you can check it out here, it's pretty interesting stuff.

In regard to telnet clients, Nick Gammon recently released a YouTube video showing some of the telnet negotiation concepts he's been working on - you can check it out here, it's pretty interesting stuff.

Interestingly, the text part of his game is pretty much pointless within his demonstration. He may as well get rid of it, and have more fancy windows for the interactable aspects like attackable monsters.