On the idea of custom client/server pairs…. If you were to put up a new game, with a nice looking web page, and put a nice easy-to-find download link to a client (for Windows, Linux, and OS X perhaps), I really don't think anyone would think twice about using it UNLESS you call it a MUD. At that point, they will assume they can and should use whatever their current favorite MUD client is, and be annoyed if it doesn't work.

MCCP and a few other protocols were attempts to move the text game community forward (by allowing content to be tagged so a custom client can parse the data stream more effectively), but they all were only marginal successes, or outright failures, because they insist on maintaining compatiblity with raw text sockets (not even proper TELNET, most of the time).

The only problem I see with maintaining compatiblity with the lowest common denominator, is that it means all the extras you MIGHT be able to do, are things you can only use for show. You can't do anything clever with in-game content, because you don't know that all the clients can support it. I'm not one for rainbow ANSI displays, but if I had a custom client and knew I could have it play sounds, or set the font colors with full 24-bit color, I might well take advantage of that to give audible clues, or make an ANSI map that has one part just slightly highlighted. I would not, however, want to put a good amount of effort into something that only a small chunk of my audience can enjoy.

I don't know that a universal protocol is even the right direction to head. There are no existing MUD's that would really take advantage of such a thing right now, and anything that would is likely going to be designed with it in mind. So, if you think you want or need such abilities in your game, I would suggest writing a client that will work hand-in-glove with YOUR server and require that your players use it. If your game is good enough, you'll have enough people. If you document the protocol you end up implementing well, other games might even adopt it, thus leaning towards a new standard.

I think that's a better way to go than trying to cobble up a standard first, and then convince people to use it.

I agree,but it still entails that the owner of a codebase do *something*, what that something is is kind of trivial - whether its write a custom parser or learn\adopt a new protocol - they're going to do whichever is easier, or most beneficial.

A module-based approach, for instance, might require you to step outside of your language to whatever the application supports. In .NET you could do Python, Ruby, VB or C# without much work, for instance, but if you're a C\C++ guy you'd have to deal with new syntax. Ultimately this kind of approach would probably be the 'most powerful' in terms of fine-grain control over things, but it would also be more work for all parties involved in that you have to create an external module (potentially in a language outside of your comfort zone) and then go in and monkey with your code to take advantage of the module you just built. Blizzard's WoW client is an excellent example of a module based system, though, that works spectacularly well. I would still prefer, though, that module loading\installing be done solely via the server's request. (I'm a trigger\scripting hater, I'm afraid)

A protocol-based approach still requires you to monkey with your code to take advantage of it but at least (one assumes) you're familiar enough with your own code so that it isn't that big of a deal. the obvious downside here is that you're limited to the functionality the client-builder exposed. Still, if done right, you can get a lot of cool features for relatively little work. I.E. when you're going to display a store menu, if the X protocol is enabled, you shoot out a small bit of markup that gets turned into a dialog on the client side complete with a graphical skin (or some standard skin) downloaded from your site on the fly.

—
V

Absolutely 100% agreed with everything you said. I feel quite strongly that this is really one of those things you'd want to build with it in mind, rather than retro-fit something that already exists. That isn't to say that you can't\shouldn't retrofit an existing MUD to use a couple of bells and whistles, but a lot of our decisions when crafting the games are based on how much info we can or cannot display or throttling the level of detail to a system based on it being too complex to display\co-ordinate via text only.

Mostly, these posts are in the spirit of the Thread (I think) in terms of what would make an ideal MUD better. Keeping in mind that a large majority of MUD owners are not really programmers, or at least not savvy enough to build their own client or do more than tweak here and there on their codebase of choice, I think that starts to point towards an easy to implement protocol or something to that effect.

p.s. I don't mean to keep double posting but there's new posts after I post an answer to a previous post!

—
V

Well, my point was that you don't have to have a "universal" protocol in order to send out machine-readable data. I don't think that the server should be sending anything beyond data: in particular I don't think it should tell the client how to render that data. That is a client-side decision: it might want to render it as plain text, or it might want to send it to separate windows, etc. It's not clear to me if we're actually saying different things; you might be saying that we should just have one mark-up format (e.g. XML, never mind opinions on XML itself) rather than a whole protocol that dictates display. The term "protocol" carries a fair bit of weight for me, much more so than just a data format. I'm not sure why a data format is really all that hard. Again, though, I'm not sure we're actually saying different things in the end of the day…

Being a little brief here, am at work and have lots of stuff to do… :wink:

I'm in the camp that says it shouldn't BE a client-side decision.

Things that are designed to transmit information (like the world-wide-web, before it became a commercial nest of banner ads and flash sites), should provide the information and let the client decide how to render it. That's because the information is what's important. I don't care what font (as long as it's readable) my news headlines come in, as long as they display on whatever I'm using to read them. That means my iphone might want to render it differently than my desktop, since it has a smaller screen.

OTOH, a game isn't just a source of information. It's an artistic expression that is suppose to be immersive, engaging, and entertaining. If I make a room description with some particular word highlighted in red… there's a reason *I* chose red. I don't care if YOU don't like red, the color is part of the message I'm trying to get across.

I absolutely agree that you don't need much of a protocol to send out data that your client can parse and make decisions about how to render it. For existing games, adding a few tags to say "This is an ASCII map", or "This is a combat message" are more than enough, and you can easily suppress that for players using "dumb" clients.

I don't think that's the smart way to make a new game though. I'd rather know what the client/server capabilities are, so that I, the game designer, can present my vision and know that all my players will have equal footing, and see things as close to what I intend as my technology allows. Do I care if you want all the chat channels in a bigger font? No. But I do care that you get a chance to notice the slight boldface on one phrase of the scroll you were reading.

Sure, you don't need any of that to make an enjoyable text game. We've done fine without it for 20 years now. But every year there is less and less of a compelling reason to stay within those limits if you don't want to. The days of people playing from vt220 terminals in university labs are gone, and the termainl emulators most people use these days are emulating things most of them have never seen. Why not have a true-color text window where you can have more than the paltry VGA 16-color palette? Why not allow sounds as hints that things are nearby that you can't see yet? Well, because you have to bite the bullet and require a custom client.

Your only other option is to NOT make use of any of those technologies as an integral part of your game. Sure, things like MSP can allow you to play sounds… but you still have to make the non-audible versions for people who aren't using it. For that matter, you *SHOULD* make alternative ways to highlight things for people who don't use ANSI color. Because of this, most MUD's only add colors and sounds and such on as fluff. They look pretty, but they're not conveying anything essential to playing the game. I think that's a waste.

I think we're mostly saying the same thing, but not. For instance, a protocol should be written in some specific way (I.E. XML) but it should 'mean' something. Whether or not the client choses to honor that meaning is one thing, but if a Dialog command exists (just as a for instance) the client should render a dialog with it somehow. Therefore, a protocol (in the way I use it) doesn't have any intrinsic functionality but it does have an implied functionality. Again, I think we're saying the same thing here, a protocol is essentially a data format to me.

I am more or less in agreement with quixadhal on his point, as well, though I will say that colors and such need to be overidable for a variety of reasons such as eyestrain\eye conditions or color-blindness. I guess the bottom line, though, is that even though most programmers are not artists we can all at least understand the concept of widgets\doodads\panels for various things. Simply having certain information available and visible at all times is enough to make the difference between an overly complex battle system and a really cool battle system. I.E. if I have to type five different commands to check five different variables (such as my balance, my opponents balance, their position on a grid, etc) rather than just glance at X panel, then i'm probably not having fun.

—
V

It's dead easy to come up with a new protocol. I've already got a simple message-based protocol (not at all based on telnet, like ZMP) that is compatible with various existing and proposed "web socket" protocols, thus making it easy to add a web-based client.

I fully and whole-heartedly believe that a web-based client is the way forward. It's not about making a nice site with an easy download. It's about not even requiring a download. It's about opening up that site and hitting the Play button and having the game pop up and play right there. Damn easy, too, given the features modern browsers have. The only thing missing is an actual way to do networking, but that's easy to remedy if you don't mind using Flash or Java or Silverlight or an ugly HTTP-based protocol. (I'm waiting for the HTML5 JavaScript networking proposals to be implemented in browsers… although the current draft for WebSockets is pure idiocy.) I have a simple Flash applet that does the networking bits for aforementioned protocol and communicates with JavaScript on the page for all the UI. All I'm missing is a nice cross-browser HTML widget for simple terminal output – getting the scroll behavior and handling screen clears with scrollback is the hard part. Annoyingly hard. Solvable, I just haven't put the effort into it yet, in the hopes some other sucke^Wperson will do it first. ;)

The protocol design becomes kinda easier when you stipulate that it's intended to be used along with an (Open Source) client to be installed on the game's website. See, you're never going to design a protocol that will cover the needs of every MUD out there. Let's say you wanted to implement a paper doll feature, because you're trying to use a very detailed damage system that needs to easily communicate wounds to the player. You just can't make that universal. My MUD might want to just show red dots at certain locations to indicate "wounded." Another MUD might want to show gradients of color at each location to indicate degree of damage. Another might want to be able to completely remove parts to show severed limbs. Another MUD might need all of those features, as well as support a wide variety of non-humanoid body shapes. You can't rely on letting the MUD offer graphics downloads for the paper doll because client A might go with a totally different visual style than client B, and the graphics might match only one of (or neither of) the clients.

Simple protocol, simple Open Source client. Offer extensions to both the protocol and the client for implementing advanced or non-standard features that most MUDs don't need, like paper dolls. Then each MUD can customize the protocol and/or client however they need, and you aren't stuck worrying about whether some third-party client will support your extensions because you only officially support the modified client on your game's website.

You also can then much more easily brand your client, which can be pretty important if you're trying to run a commercial venture (not on most stock codebases, of course). Or even just for MUDs that (thankfully) have a strong theme element, which are often best served by a client that expresses a very specific visual experience.

It also gets rid of the platform issue. I haven't played a great many MUDs in years because jsut about every Linux-capable MUD client sucks donkey balls. The custom clients for games like Simutronics' only run on Windows, and the handful of "top tier" generic clients are also all Windows exclusive (with a possible Mac OS X). The Web is universal. Even when the user's platform isn't an issue, the availability of software may be. Public terminals often don't allow installing software, but they can all run a web browser (and almost always have Flash/Java installed). A web-based client will work for everyone, everywhere. They even make working around firewalls a lot easier, if you do decide to go with an HTTP-based protocol (which will be quite easier once the server-sent events stuff is more prevalent… for now you need to rely on XMLHttpRequest and "COMET" patterns).

Basically, instead of trying to create a ton of inter-operable software that is supposed to somehow magically support an unpredictable set of features, offer a set of tools by which game developers can build their server and client components to meet their specific game design requirements.

Sorry, need to be brief again.


And that is why I think the semantics are far more important than the formatting. You are trying to convey emphasis. OK, maybe for you, ideally emphasis means red text. But if I'm playing on a white background, that is sub-par. If you already "*SHOULD*" make alternative ways, why not only have one way – tagging the semantics of emphasis – and let the client decide how to render that most appropriately? What I do on my smart phone might be different from what I do on my desktop, which might yet again be different from what I do on my laptop, etc.


Oh, I see the difference now. Whereas what you describe can have actions, such as "display a dialog", I am talking about a purely descriptive format. That is, I see no functionality in the data description: it is merely a description. What you choose to do with it – render it to text, to a window, to colors, whatever – is up to the person seeing the data. (Where person can be a client, or even a layer in between the server and the client.)


Oh – sure, it's (usually) easy to design a protocol when you have very specific requirements and know exactly what the client and server in question are doing. The extremely hard part is getting everybody to adopt it. For instance, for us to agree to standardize, I would have to believe that your protocol will allow me to do whatever I want. And if Fred gets involved, he has to agree too. When you get the major server coders and client authors together, the problem is just compounded, because then you have to convince the client programs as well to support the protocol…

The paragraph that quote comes from describes the unpleasant alternative to having a client and server which were designed to work as a pair. Namely, if you know that some clients will not support some of the features you are using, you have to waste the productivity to try and create workarounds to get your message across in a sub-optimal way. I'm advocating NOT doing this, because if you control both sides of the equation, you aren't forced into that position. In my client/server model, you wouldn't BE playing on a white background. Sure, I'd lose some players that can't stand black backgrounds, or red text… but you can't please all the people, all the time.


Indeed. And for all the kinds of things smart phones, laptops, and desktops can do, it's good to have things that work well on each. Where is it written that I have to shoehorn my vision into a shape that will fit on your smart phone? Why is it a bad thing to put minimum requirements on your game, so that the user gets the experience you want them to have?

The fact that something CAN be done, doesn't imply that it's the right thing to do. I know you CAN play Quake on a vt220 terminal by compiling the game to use AALIB. From a technical standpoint, that's impressive. I don't think being able to do so means the player is getting the proper experience of the game, and I think Quake would have been a less impressive game if they'd limited themselves to what AALIB could render on a monochrome terminal with no mouse support.

As I said, existing MUD's won't gain anything, because they've all been designed to use mostly pure text, with any additional information being tossed in as a convenience factor. If I were to design a text game that used real-time combat where positioning mattered, targeting mattered, and I had enough stats that you had to pay attention to that reading all the text would take too long, you can bet I'd want to use color, and I'd probably want full screen control, and possibly seperate panels or windows. I might even want mouse support to reduce the amount of typing required.

I guess my major issue with all of this is that people already have the option of 'customizing' a client, it's called their programming language of choice. I mean, honestly, if you're using flash\silverlight for the networking components why not just use flash\silverlight for the entire display as well? 'Customizing' doesn't mean much if the only thing the base package provides is the networking code, that's the part that is usually the absolute least amount of work to begin with. Those codebase owners who have really fancy features, outside of the stock-mud featureset, are probably competent enough to do a little coding of their own (assuming they get an artist to work with).

That said, there are a lot of correlations between HTML and the way I would skin a customizeable GUI. For instance, paper-dolls could be handled via a graphics skin and an Image Map so that when you click on a section you tell the game either the co-ordinates or the name of the hotspot that was just clicked on and let it do it's thing. I'm assuming that your framework (Which is really the flash\silverlight component, at this point) would provide the means for the java-script to send a message to the game and the game to provide a message for the javascript. In effect then, the framework would be kind of like a message pump with the client defining the messages and their implementation in Javascript. I.E. the MUD sends a Key and a data blob and then the flash\silverlight message pump looks for an equivalent hook to match the key and passes it the data blob.

Google's Chrome, with their impressively fast new Javascript engine and the neat little application shortcut, comes to mind. They're planning to go completely multi-platform and I'm fairly sure betting on Google is a safe thing. Other than completely specializing in one browser you'll have to rely on frameworks like jQuery (and be very careful about your HTML\CSS)

I guess my question is "does that make it any easier to do it?" or is it just good ol' fashioned pioneering. I guess my initial approach is to be an enabler, so that even people who just grab a codebase and tweak it without strong programming knowledge can still cook up something decent. Javascript is not friendly =( (Sorry, I'm just bitter. I actually kind of enjoy working with Javascript again with jQuery)

I feel like I kind of just ran around in a huge circle, so I apologize for that. I have to say I'm a little intrigued by the idea though and i have to ask why we've not seen more flash clients.

—
V

Quix, it just seems to me at this point that you don't really want a MUD anymore. As soon as you require a given client, you're not really talking about a traditional MUD. There's nothing wrong with that per se – I think limiting yourself to telnet is a problem anyhow – but I think it's important to contextualize the discussion. I thought we were talking about enhancing MUDs by working in the existing framework; it seems that you're talking about going a whole lot further than that.


Well, frankly and only IMHO, I don't see much value added if all that's happening is a console in a browser. On my own computers, I have my own clients, and on other computers, I can ssh into my computer and use a text-only client. For a Flash etc. client to provide significant value, it needs to have been tailored to a game, but that means it's only really useful for that game. And finally, writing a client that rivals the competition in terms of features is just a lot of work, and most people who start writing a client probably realize that fairly quickly and do something else.

That's probably the truth, and it's a real shame, because presentation is extremely important in advancing any kind of game style over another. To contextualize things, like you said, I don't think we're really talking strictly about MUDs here anymore but a kind of hybrid between a contemporary MMO and a MUD as we know it. I personally think that that hybrid is the way to go for future 12-15 year olds to become addicted and continue this hobby of ours. I don't beleive that MUDs will ever wholly die, but I think they should change, there is no reason for them not to aside from completely stubbornness. Citing Multi-Platform issues for not 'bothering' to provide a client is becoming increasingly less of an excuse, as elanthis has pointed out, there are a large number of solutions coming to the fore that solve that problem. There are a lot of solutions that already exist, to tackle it as well.

Most, if not all, of the high-population MUDs have a custom client and a killer presentation via their website etc. That's not a coincidence. Now are these highly-populated MUDs the best "EVAR", well, they're not bad. The fact that, at their core, they're still using text to paint the world lets them do a lot of gameplay scenarios that MMOs cannot match.

So I guess my entire argument can be boiled down to: I wish more MUDs had a client pairing and focused more on presentation, it's important and can add tremendous value to your game. It's getting to be about time when ignoring it is just stubborn, and not based on any practical reasons. Even my debug clients (written in a handful of hours max once I had graphic assets) provided a better experience than, say, zMUD or mushClient.

"A lot of work", maybe if you try to emulate timers, aliases, scripts, etc as in mushClient. Yet, to me, I would never want someone using mushClient for my MUD. Maybe that's just me, but as i've said before, I don't think timers, scripts, and triggers are healthy. Aliases are helpful, some minor scripting associated with those would be fine - such as being able to highlight a name in some list and then use an alias to cast a command on said name - but triggers are definately just a wide open door to completely wreck a user's experience. Take WoW, for instance. Blizzard has openly admitted that they now design boss encounters in instances with the the top-mods in mind. Which means that if you don't use mods (i.e. triggers) you will have a much, much harder time of it. I saw a MUD once, I forget the name - but it was one of the 'popular' ones - that had a whole forum section dedicated to "must have" triggers for combat. If you need triggers for combat to be viable either your design is too convoluted, or you need to think of an alternative way to supply information about - and control - all the variables involved.

Edit: I should also add that those same popular MUDs are also hindering themselves by still supporting telnet clients. That cord needs to be cut. There is no T for Telnet in MUD, it's only a perceived association, so I don't pay much attention when someone tells me I'm not talking about a MUD anymore just because I want to ditch telnet. I am, in fact, still discussing a text based Multi-User-Dungeon.

—
V

MUSHclient provides a platform for supporting multiple windows via Nick's new miniwindows feature. I would really suggest that people check it out by looking at some of the demos on his site.

I have basically no interest in writing a whole MUD client from scratch, not because I don't think the game would benefit from one, but because if I'm going to get into the client-writing business I would write a 2d engine client of some sort. However, when you have a client like MUSHclient that becomes a platform for letting me add my own windows etc., things get very interesting very quickly. Now I can parse machine-readable data using scripting/trigger mechanisms that are already there, and do what I want with that for the windows. I can provide such a module (that is what I meant earlier) to players of my game, and now I have "my own client" except I had a whole lot less work to do.

I don't think that MUD-client pairs is the way to go for MUDding as a whole community. I agree that it would be a way to go for particular games, but I just don't see it being a good discussion for the whole community because people can't afford to spend so much time writing clients for their games. This is not to say that custom clients aren't good – it's just that, realistically, I simply don't see it happening for the community on average. (It's hard/time consuming enough to write just a server…)

Part of the beauty of MUDs is that with relatively simple clients, you have access to a huge range of games. From a server's perspective, you need only provide a text interface, and you have opened your doors to everybody. If you need a fancy custom client, the bar goes up many notches.

Wow, thanks for the link. When you say new you're not kidding.

This is more or less what I was alluding to in the first place and it looks like, as of the latest release, he's pretty much committed to it so I'm sure it will fully mature at some point in the future. What he's got is an excellent testing ground, and base. I think that, if widely used, it will be an excellent driver for more and more interactivity.

—
V

Yeah, this has drifted a few miles away from the original topic. Sorry 'bout that! :)

I guess it depends on what makes a MUD, a MUD. To me, a MUD is a Multi-User text game, and I see text as the primary means to describe what's happening and deliver the game content. I don't see it as the only means, nor do I think requiring some degree of graphical or audible feedback is enough to form a new genre. Maybe it is, but I'd still consider it a closer kin to a MUD than to a game that uses graphics as the main content delivery mechanic.

The use of TELNET (or any connection protocol like it) was simply the most expedient choice for people to use back when MUDs were developed. It means they didn't need to write a client, since EVERY computer on the internet back then had a TELNET client.

I guess I'm just saying that *IF* you wanted to write a text game from scratch today, and you knew you were going to want more control over how your UI functioned, at this point *I* would write a custom client that worked specifically with my own game. If the specs for that interaction are public, it's possible that other people might do something similar, and once a handful of such games existed, a common standard might emerge. Until that happens though, I don't think there's much point to trying to develop such a standard, because the game we'd be making the standard for doesn't exist yet. Thus, we don't know how well it would actually work.

As for MUSHclient, I'll check that out. I will say that if there's a way for the server to discover that the client on the other end is using MUSHclient with whatever plugin I've written, and I choose to disconnect anyone NOT using it, I've established a custom client/server pair – since I can then develop my content knowing the capabilities of the clients connecting.

YARRR! The keel be draggin' 'long the edge o' Off Topic Reef! Hard 'a port, three quarter sails!

Read the whole thing before commenting, please. The entire point is that you CAN'T do that, so don't bother trying.



And this only works if the client is tied to a particular game. A customized "generic" client is not particularly useless, unless you're talking about plugins. But who wants to write 10 plugins to support 10 different clients? Nobody does, and more importantly, nobody will. I can name a dozen clients that have extension capabilities, and aside from all of two or three extensions, nobody's ever actually written any plugins for them. They end up just being an overly complicated method of turning first-party features on and off.

So far as the Silverlight question, my reason would be to avoid using Silverlight (or Flash or Java) as much as possible. I'd want a 100% standards compliant going-to-work-fucking-everywhere client. The only reason I'd hook in Flash or Silverlight today is because it's necessary for the networking component. It's entirely possible to abstract that away though, and make it as easy as dropping in a new network.js file in your client to switch to a different networking method (or even allow runtime auto-selection of methods). It won't be much longer before things like Flash become entirely unnecessary – SVG, <canvas>, sickeningly fast JavaScript engines, <video>, and (hopefully before too long) a networking solution, and then it's just a matter of getting good tools like Flash MX that work directly with standard HTML/CSS/JS.



Hence the desire to have an Open Source and easily extensible web-based client. It can come choke-full with features that most games would use, but can be customized for games that want to break the mold without needing the game developer to start from scratch.

There's way too much "start from scratch" crap going on in the MUD community as is. Mostly due to backwards and retarded mentality regarding the importance of "innovation" in code. You know, some dipshit writes a new vehicle system for his MUD (the 1,387th vehicle system written) and thinks that code must be kept super-secret lest some other MUD gain vehicle support and devalue his innovation (because being the 1,387th MUD with a vehicle system is oh so valuable). It somehow doesn't dawn on said people that their one or two "custom" features not enough to keep their whopping 20 person player base in the wake of their total lack of any regular content expansion, a friendly environment, or a professional administration style.

I don't want to see people writing new Flash clients that are tied to their game. I want to see people using a freely available, featureful, and well known client for their game, customizing it as needed (if at all).

I don't care about generic "feature packed" clients like zMud or MUSHclient, nor do I care about supporting console clients. People who have a strong need to use such clients can keep playing archaic games that never plan on expanding past simple text output and ANSI colors. There is a gigantic swath of game territory that lies past classical MUD interfaces but which does not venture into the realm of graphical MMOs. Games that use text as their primary descriptive element but which needs to provide a large amount of raw information to the player that simply can NOT be expressed concisely enough as text.

There's a limit to what you can do with a generic client. Vassi mentioned using image maps for paper dolls, but seriously, that's not good enough for someone with standards (like me ~_^ ). How can you ensure that your paper dolls graphics mesh properly with the visual theme of the client you're sending them to? You can't. You need to have it all mesh together. Ugly clients are bad. It makes your game look unprofessional and cheap. It is at best no help towards immersion, and at worst actively breaks it. You want to present the user with a single visual identity that feels coordinated and well thought out. You can do that with a generic client, but only if you don't let the server over-ride your art.

I'm also going to agree with Vassi on the topic of whether a client actually _needs_ any really advanced features. Triggers, aliases, etc.? Those are overly complicated features that are implemented because either (a) the MUD you're playing is a piece of crap with a horrendous command interface, or (b) because the client isn't customized to the game and can't pull out relevant information without you scripting it to tell it how.

Options are almost always wrong. Most options in most applications are there only because the developer was incapable of writing his software correctly. You don't need options. Instead of making a user manually choose between two half-broken ways of solving a problem, give the user a universal solution that just works, always. Sometimes that will require cooperation between the server and the client. Classic MUDs and classic clients are forced to give you a ton of overly complex mechanisms just to work around problems that flat out wouldn't exist if the client and server were actually designed to work together.

A web client isn't mandatory for this. It'd also be quite possible with a conventional "download and hope it works" client. It just seems entirely pointless to me to bother with those. They're harder to modify/customize, they're locked to specific platforms, they're often blocked on a lot of public terminals and corporate machines… the web just works, everywhere. Flash works pretty much everywhere too (and hopefully won't even be necessary before too long). I'm fairly sure that half the reason we even have a bazillion conventional clients is because they're all locked into some specific setup (Windows only, OS X only, UNIX/X11 only, etc.). The other half the reason is that they're only customizable by the player, and not by the MUD developer.

An easily customizable and Open Source web-based client lets MUD developers get away from the limitations that even "super advanced" conventional clients like zMud enforce by their design, it lets developers brand the client as necessary to give their players a coherent visual interface, and it will just work for everyone.

Oh, don't get me wrong, I really like the idea of custom clients – if anything via Nick's recent MUSHclient miniwindows – because I think that features that make a game truly rich, such as positional information, are all but impossible to render and interact with in a pure text environment. So I'm definitely happy to talk about this, and I'm very happy to talk about how one could encapsulate the relevant information into some kind of data description format.

And I'm not sure the topic is really drifting, given that we are talking about "progressive" design after all. :wink:

(Soon, we'll be running into the inherent paucity of the forum format: although it is great for discussion, it is terrible for future reference. Anybody (including ourselves) wanting to go through and see the interesting points will have to sift through the whole thing, instead of having a "current status" view like you would have with a wiki. And of course, wikis suffer from something of the opposite problem: while the current status is easy to see, it is rather hard to manage discussions…)

Hmm, a post while I was posting…


Well, as I said, I had to be brief. I apologize for agreeing with your point! :wink:

And, err, not to be net-nanny, but if you could tone down your language a wee bit that'd be nice.

Sorry, didn't even realize I used anything offensive. Then again, I've been called a "sailor with Tourettes" so my idea of offensive may be a bit non-standard. ;)

There are one or two around. However, I think that for most MUDs there is just no value to them in developing a custom client. The main reason to provide such a client is to reach beyond your established user base to attract new players and I just don't think this is a priority for many MUDs. Given that most people run their MUDs as a hobby it's not surprising that they want to concentrate their efforts on shiny new game features to appeal to their existing playerbase.

There is a lot you can do with Flash or Java to produce a nice looking client with stuff like map display, separate windows, stat guages, buttons, mouse interaction etc. etc. and in most cases you can do this in the browser with no download or install required. It's easier if you design the server with this functionality in mind, but there is still a lot that can be done that works with existing codebases with minimal changes.