Matter of trust: in one case I trust one application.
With a brownser you have to trust not only the brownser, but every application it runs, that is way way more trust to give. (or give up)
And that is why those applications are indeed sandboxed, and so very limited in what they can do. WebGL is the first step to break the sandbox because it is so limited.
I would prefer to install my games, from the vendor I chose, instead of opening a backdoor to every malicious programmer…
The brownser is already definitely not safe enough as all the black hat are demonstrating year after year by clicking a single link in every pwn to own convention. I turned off noscript for mudbytes cause I give it a little trust, like I would to a program I would install. But on the contrary of an installed program mudbytes could get corrupted by a hacker one day, and start distributing malware. I do not control mubytes, but I control my computer. That is the main difference. If you don't think there is any difference good for you.

@plamzi: It's not whether it would be as performant as Mush (it absolutely would come nowhere close), but whether it would be performant enough to be usable. In other words, could it feasibly be a replacement for my normal client? Or would it be sluggish and frustrating to use? Everyone's definition of "satisfactory" is different, and I may be spoiled by years of using Mush, but I have yet to use a Flash, Java, etc. client that wasn't what I consider sluggish, and these are much more refined technologies than today's JS (though probably not for too much longer).

I see, so you're looking at it from the perspective of a veteran MUD player. There aren't too many of those left, and in five years, I venture that they'll be even fewer. I will also venture that they'll keep using their favorite MUD client even if a web browser app came along that is 100x faster and more advanced. I know someone who uses a client discontinued in 1995. He says he likes "the feel" of it and there really is no argument that will compel him to switch.

When you look at things from the point of view of someone who is making or promoting a MUD game, it's hard to compare a target audience of a few thousand (MUSHClient) with a target audience of a few billion (a web app). In my book, if a custom web app is even remotely playable and possible (it is), I'd worry about it first because it will dramatically improve the reach of my game. After all, I don't need to do anything about generic MUD clients like MUSHClient–I get those free as long as I support even basic telnet…

It sounds like you have your own pretend-way (no offense) to install a web-app. Given that you use noscript by default (basically disallowing the app to run), and can enable it selectively (effectively giving the your explicit trust), I think you've already covered the problem on your own.

That's what I've been saying all along. Having a custom client (however you choose to implement it) gives you the ability to present things in ways that can't be done via a plain old text stream. It also enabled the user to interact in ways beyond having to type commands and hit return for anything to happen.

Look at a trivial thing like nethack. Sure, you can play nethack over a telnet connection, but not without some pretty heavy trickery that involves having a seperate daemon to handle terminal I/O for it (dgamelaunch), and each nethack game is single-player, with no interaction between them. The fact is, nobody has yet made a multiplayer game that can properly and reliably use character mode with all the various plain TELNET clients out there, let alone looking at things like tinyfugue or mushclient.

And that's just one tiny baby-step of evolution. It's pretty plain that things like a builder's interface (OLC) would be much easier to work with if it had menus and (if on a graphical platfform) listboxes/droplists for known values. Can you do it in TELNET? Sure, provided you require the user to use only known clients that properly handle the transitions – oh, that's a custom client requirement except it isn't one YOU wrote.

Also, it's not about "can you do it", as much as it is about "can you do it easily"? If I'm writing a game and I want the user to be able to see the potential blast radius of a spell they can cast at a point on the ground, I'd like that radius to be highlighted as they're moving the target cursor around so they can see what the blast will hit before committing to casting the spell. Given a curses-like screen update library and lots of bandwidth/horsepower, you can certainly do that in a hex-grid map on a vt100 screen over TELNET. But, it's sooo much easier to just have the client ask the server for a map, and for the blast radius of the spell in question… and then let the client handle the display and input, sending the command packet to "cast spell x y" when they finally click. The server gets a nice formatted packet that it doesn't have to scan and parse, since "cast" is a known command and "spell" is a known value. All it has to do is verify x and y and off it goes.

No offense, but neither of you understand KaVir's point and you probably never will. While you go on and on about hypothetical custom clients and protocols and what's simply not possible using telnet, mud developers actually are implementing 'custom client' features without dropping telnet support.

You can astro-architect your custom client all you want, but at the end of the day it's far more likely that a better experience will come by iterating on prior work, not by laying transatlantic rare earth element cable for your quantum messaging protocol that underlies your supra-retinal display.

Look, even plamzi, who's doing more custom client work and non-mudder outreach than anyone here, started with DIKU.

Unless you have a really really old computer flash and Java client are not sluggish because of the technology, but because of the coders. They did angry bird in html 5….so just parsing text is not exactly rocket science.

DecafMUD is a pretty impressive web-client. It uses a Flash object for the connection (including MCCP), but everything else is done in Javascript. It's a lot further along than Aspect (mine) is, too, so you can actually see it perform.

I don't think that's a meaningful comparison at all.

Nick Gammon reported 56,438 downloads of MUSHclient over a 12 month period. What percent of people who download MUSHclient are likely to use it to play muds? A high number, I'd guess - it's a mud client, after all, so people are unlikely to download it if they're not planning to use it to play a mud.

There are apparently around 2 billion internet users, and I'd speculate that the majority of them have web browsers. But what percent of them are likely to use their browsers to play text-based muds?

I certainly believe that browser clients are a Good Idea, particularly for lowering the entry barrier for new players. But I view it as an extra notch on the belt, not a replacement for existing clients (unless you're creating a primarily graphical mud).


I prefer focusing my efforts on server-side protocol support. While I've already shown examples of what this lets you do with clients such as MUSHclient and Mudlet, that same support can also improve the experience for browser clients like DecafMUD, and smartphone clients like BlowTorch, because they also support some of the same protocols.

The next version of FMud will apparently support MXP, including images, gauges and menus. If client developers are supporting the same protocols as me, then I don't need to worry about developing my own browser client, or smartphone client, etc.

A comparison is difficult, agreed. I also agree that you don't necessarily gain more players by widening the net. But the arguments go both ways. 50K downloads is not 50K people. And how many people who downloaded MUSHClient did so to play *your* MUD vs. thousands of others? Does MUSHClient offer free advertising of your game to match a Google organic search? Does it offer options to integrate it into social sites like Facebook?

And, just to re-iterate, people who are not new to MUD's can *already* use MUSHClient to play my game. I'm interested in people who have no idea what it is. I'm also interested in ways to control and enhance the experience as I wish and not have to wait years for someone to add a feature to their generic MUD client that I've always wanted. I'm just not that patient.

At the end of the day, you decide who to cater to, of course. Personally, I feel that if a MUD vet dislikes any aspect of my gameplay, they will move on regardless of whether I support protocols or whether or not I have a custom skin for MUSHClient. I also feel that if I don't go after true new blood, the MUD community will continue dying its slow death, which is one of the things my project works against.



That's exactly how I see it, as lowering the entry barrier. To me that's not an extra notch in the belt–it's the whole belt. If I convert a person who has never played a MUD before, and if they find my GUI apps limiting at some point, they can go on to download MUSHclient or Mudlet. Some do, some don't. Most use the mobile app at least half the time because it offers a feature MUSHclient will never have, ahem, mobility. Some fire the web app via Facebook when they're not on their home computer. At this point in the game, it really doesn't matter to me which client they use, when, and why.



There are good reasons for your approach. In an ideal world, enough games will implement a server-side protocol sufficiently complex to enhance a player's experience in enough clients without any need for the end user to have a computer science degree. In the real world, you don't need me to tell you that it's an uphill battle. I don't have an elephant's patience. My web app does things that a MUD protocol + generic client may or may not support 10 years from now. I don't even feel the need to support common protocols via your magical snippet, because I feel that between my custom clients, and what MUSHclient or Mudlet can do OOB, I've got all bases covered.

Now, for a game that doesn't have any custom clients, I would totally back you up on recommending protocol support. The FMud development is very important because it opens the doors to better-looking Facebook apps for a whole slew of games. Looks are very important.

IMO it's generally the muds that need to catch up. Some of the more advanced modern clients support a wide range of powerful features, it's just that very few muds bother to support them.


There's a lot more to lowering the entry barrier for new players than just offering a browser client. There's things like a well-designed website, a detailed newbie guide, in-game tutorials, streamlined character creation, context-sensitive hints, easy-to-use help system, and so on.


Can you give an example?


The out-of-band stuff is handled through protocols such as MSDP, ATCP, ZMP, etc. Muds that support those (and other protocols) have got their bases covered, because they're using a standardised way to communicate with the client, and quite a few modern clients already support those features. Without such support, you won't be able to offer the same sort of experience to players who don't use your custom client.

I think what you're saying may be true for most MUDs. But I began my project by developing a mobile GUI that no generic MUD app (not desktop, and certainly not mobile) could possibly pull off for me. After that, you can say I got spoiled. I've seen your examples of what MUSHclient can do in terms of custom GUI, and to me it seems like a lot of hassle for an end result that just doesn't look streamlined. That's to be expected, since you're inserting graphical elements in an app's "workspace" rather than building an app. Even if I learn LUA and out-design myself, at the end I'd have a UI inside someone else's UI.


There's a lot more to lowering the entry barrier for new players than just offering a browser client. There's things like a well-designed website, a detailed newbie guide, in-game tutorials, streamlined character creation, context-sensitive hints, easy-to-use help system, and so on.

That's absolutely true and I recommend putting just as much effort into all of these. Even if you don't embark on making a custom client at all, these are some of the important ways in which you can try to attract fresh blood.



For one thing, I already have images and gauges aplenty, clickable elements. I've also done some things with hover on/off events. I have a real-time map which appears overlaid on top of the main text window, and when you click on a room, you see its contents (I suppose it's a kind of meta-data tooltip). I've only plucked the lowest-hanging fruit so far, but by controlling the client I can add stuff as I please: context menus shouldn't be hard since I already have a method for sending this kind of info. I'm also planning to show the player's inventory in icons, and I can leverage any one of a thousand JS carousels to make it look nice and interactive any way I want. If I were building a plugin, I'd be very limited there.

Now, I realize some of the above can be done in MUSHclient but I wanted a web app for reasons I've already shared. Also, the thought of learning a new scripting language that I probably won't get to use for anything else ever was a huge downside, I admit.



That's mostly true. I do have a standalone version of the real-time map (web-based) that a handful of people use next to their advanced MUD clients. If anyone ever asks, I can evolve that standalone view into a more full featured "info hub". It won't be integrated into their particular client, but at least I'll be re-using code, which to me is essential given that I'm flying solo.

If someone comes along one day and asks me to support a protocol so they can write a nice custom GUI for Mudlet or MUSHclient, I'll definitely seize the opportunity. In the meantime, I don't see how pouring hours into customizing these is going to lower any barriers for prospective players.

Hmm no, you can easily do all of that with a MUSHclient plugin (Mudlet is still lacking mouseover functionality, but it can do the rest).

However the important point here is that the protocols provide a standardised way of communicating the data to the client. I used them to create GUIs for MUSHclient and Mudlet, but that same data could also be utilised by smartphone clients (perhaps a future version of BlowTorch), browser clients (DecafMUD already supports MSDP), etc.


I transmit the data through MSDP, and let the client integrate the map into the GUI. I think that looks much better than having to open a separate web browser to view the map.


A more appealing and interactive interface can help lower the entry barrier for new players. The existing protocols provide a standardised mechanism for incorporating sound, graphics, gauges, buttons, clickable text, a wider range of colours, etc - not to mention providing other useful options such as automatic detection of client type and screen size, data compression, and so on.

This goes back to my earlier point about muds needing to catch up with modern clients. A lot of this functionality has been supported by various clients for a while now, but most muds simply don't use it.

When Stendec finalises and releases DecafMUD, I think we'll start seeing many more customised browser clients.

I'm sure there's a whole lot of unexplored potential in MUSHclient. I also think that (at least in my case) all that potential is under-explored for many good reasons. Suffice it to say that when I saw examples of some of the most talked-about MUSHclient plugins, I was not inspired to jump on the bandwagon.

I'm including two screenshots below. Let's set aside for a moment the fact that one has to be downloaded and installed, while the other is ready to go as soon as you load the page. Can you tell me which one you think is more likely to appeal to a person who has no prior knowledge of MUDs?

The problem is you're comparing aesthetics, not functionality. Other than the input field, your GUI could certainly be duplicated in MUSHclient.

I mean, I could take a screenshot of a basic browser client and post it along with a screenshot of my MUSHclient GUI, or even Runter's MUSHclient plugin, and ask which you thought would appeal the most to newbies.

Now if you want to compare your GUI with Aardwolf's GUI, and ask which is likely to attract the most players, then that's fair enough. But the fact that Aardwolf happened to build their GUI on MUSHclient, while you built yours into a browser client, is really beside the point as far as aesthetics are concerned (because you could just as easily have created either GUI on either client).

Just caught up on this thread, and I gotta say, many eyebrows were raised about web technology, security and so forth.

Oh, and there were a few nice strawmen too, like transatlantic quantum cabling.

I laughed.

I read over the thread, and the only thing I want to add is this rhetorical question. How am I going to offer the same sort of experience to players who don't use my custom client if no existing mud client supports the feature? If that's not even able to be granted, I think this really explains why some people in this thread will never agree wrt front end development for a mud.

My point is more that if clients already support the features you want, then using that same approach in your custom client means that (some) other clients will also be able to offer the same experience.

Take Primordiax for example. They offer a custom browser client which supports graphics and clickable text, but they do it through some sort of closed protocol. If they'd instead used an open protocol like ZMP, MSDP, or ATCP for the graphics, and used MXP for the clickable text, then their players could have duplicated the interface in MUSHclient, Mudlet, etc.

Furthermore, with browser clients like DecafMUD and FMud now supporting both MSDP and MXP, other muds should be able to design interfaces comparable with Primordiax without even needing to create their own custom client - as most of us have limited resources, this means less time taken away from server development.

Obviously if you want features that no existing client supports, then you'll have to create your own. But even then, if you create an open protocol for those features, you may find other client developers decide to support it as well.

That's all we needed to hear.