[Aeran]

Originally Posted by ArchPrime Yeah, none of this discussion really explores a major problem. Its more a fact there is a desire amongst folks(including me) to see MUDs evolve a bit, especially in terms of the client. This is evidenced by the growing body of custom clients out there. And, maybe that's where it needs to end: with the custom client. *shrug* I just see huge opportunity for the MUD community to embrace a few more standards (yet to be defined?), which in turn will help developers on both the client and server sides work more with less effort. Depending on how far the standards would go, they should also increase usability of MUDs and help inject a lot more players into our shrinking/growing/whatever-your-metrics-tell-you playerbase.

Custom clients remind me a bit of custom web browsers. Years ago some websites actually recommended you what web browser you should use to be able to properly view them. Today that is very rare. You can use a range of different web browsers.

A very big benefit of supporting many MUD clients is that it makes it easier for the players. E.g with zMUD/cMUD you can play on many different MUDs and the software keeps track of them for you. A player also doesn't have to install multiple clients so they can focus to learn the features of one.

[KaVir]

Originally Posted by ArchPrime Yeah, none of this discussion really explores a major problem. Its more a fact there is a desire amongst folks(including me) to see MUDs evolve a bit, especially in terms of the client.

I share that desire, but I'm primarily a server developer, and my time is a finite resource. I would rather customise a popular, well-established and feature-rich client that's already had decades of hard work poured into it than create yet another mud client from scratch.

Originally Posted by ArchPrime This is evidenced by the growing body of custom clients out there.

And how many of those custom clients can match the features offered by the big clients?

Originally Posted by ArchPrime And, maybe that's where it needs to end: with the custom client.

Throwing away decades of feature development? That sounds like a step backwards to me.

[ArchPrime]

Originally Posted by KaVir I share that desire, but I'm primarily a server developer, and my time is a finite resource. I would rather customise a popular, well-established and feature-rich client that's already had decades of hard work poured into it than create yet another mud client from scratch. And how many of those custom clients can match the features offered by the big clients? Throwing away decades of feature development? That sounds like a step backwards to me.

Okay, lets back up the assumption wagon a bit, here. Who says "Throw away decades of feature development"? Actually, what are those decades of features you're not interested in throwing away? I have no idea how creating some new standards by which client developers and server developers should adhere to is a step backwards. Substitute "create" with "adopt" and it's still something else....an addition... an evolution. Which would you prefer? A standard way to display, skin, and control a status bar which would work in all clients that support the standard or come up with your own protocol, select a client, write a plugin for it, and call it a day? In the former, your game will provide the experience you want your players to feel, across all clients(hey! Minimal work for you as a server dev). In the later, your game will provide the experience you want your players to feel in only that one client, and only if they installed your *custom* plugin (Hey! Lots of work for you if you want broad client use).

I guess this does illustrate a major problem: coming up with standards and more importantly, getting client and server developers to implement/conform to said standards. I'm guessing its not gonna happen. That's why I said "that's where it needs to end:..." --- because the real standard is simply telnet. If you want to offer more, then you're free to with your own custom coding/client/plugin/control/mind bending technology/widgeting-ding-a-ling.

It would be cool to see what features are important to players --- and why. Same for developers. You might find that some of those current client features which represent decades of feature development become obsolete when replaced with standards and proper UI elements.

Whatever the case, I'm feeling like a broken record. There are blatant, obvious reasons MUD devs are creating custom clients for their games... and that reason is not hubris.

[Newworlds]

Originally Posted by KaVir No, the WGFriends client uses WebSockets, not Flash (although it does also offer a Flash fallback for browsers that don't support WebSockets). However Flash is so common that many people already have it installed - particularly if they play browser games. And even if they don't, they're not required to download something specific to your mud. I would speculate that most first-time mudders these days are more likely to have Flash than even a basic telnet client, and the former can provide a far prettier interface, as well as look more familiar than a terminal window to today's generation.

Perhaps, but when I dumbed down my IE it wouldn't run either of those clients within the browser. Still your point is taken that almost everyone has flash, but flash and java are not part of the install package and are seperate systems/patches.

[KaVir]

Originally Posted by ArchPrime Okay, lets back up the assumption wagon a bit, here. Who says "Throw away decades of feature development"?

See here:

Originally Posted by ArchPrime The best use of my time is certainly not trying to write plugins / scripts for the various clients out there so that users can experience my game as I intend. I believe there are a large number of folks that feel the same -- hence the use of custom Flash/Java clients on many MUDs.

If you're developing a custom client rather than customising an established one, then that means missing out on the decades of development and testing that have gone into those established clients.

Originally Posted by ArchPrime Actually, what are those decades of features you're not interested in throwing away?

Things like aliases, hotkeys, triggers, command-execution timing, variables, multi-session support, cross-platform support, ansi/256/24-bit colour, speed-walking, extensive scripting in multiple languages, macros, regex, toolbars, smooth scrolling, scrollback, logging, customisable fonts and colours, compression, chat, built-in text editor, configurable output buffer and text wrapping, debugging tools, text hyperlinks, spell checker, tab completion, configurable command window and input options, mapper, autosay, open protocol support, configurable sounds, NAWS, TTYPE, ECHO, fully customisable graphical skins (including buttons, energy bars, avatars, icons, mouse hotspots, etc), and so on and so forth. Not to mention the years of extensive testing by many, many users.

Originally Posted by ArchPrime I have no idea how creating some new standards by which client developers and server developers should adhere to is a step backwards.

Of course it wouldn't, why would you think that? My comment was a direct reply to this statement:

Originally Posted by ArchPrime Its more a fact there is a desire amongst folks(including me) to see MUDs evolve a bit, especially in terms of the client. This is evidenced by the growing body of custom clients out there. And, maybe that's where it needs to end: with the custom client.

If people decide that "the best use of [their] time is certainly not trying to write plugins / scripts for the various clients out there", but is instead to develop their own custom clients from scratch, then they're losing out on decades of development and testing. That is what I consider a step backwards.

I can understand people wanting to create their own client for legal reasons, or because they want it to run from a browser (not much available to reuse in terms of browser-based mud clients), or even just because they enjoy the challenge. But reinventing the wheel just for the sake of it? I can think of better things to do with my time.

Originally Posted by ArchPrime Which would you prefer? A standard way to display, skin, and control a status bar which would work in all clients that support the standard or come up with your own protocol, select a client, write a plugin for it, and call it a day?

Of course I'd prefer it if my plugin worked on multiple clients, but I can't realistically see that happening. What you could do is what I mentioned previously - design a standard for skinning, and create plugins for multiple clients that support the standard. Then any server that added support for the standard could indeed offer the same interface to multiple clients without the need to create any further plugins. No doubt some people would still prefer to design their own plugins, adding things that aren't covered by the generic plugin, but perhaps it would be useful as a backup option for clients you didn't explicitly support, or for muds that lack the skill or desire to do any work outside of the server itself.

Originally Posted by ArchPrime I guess this does illustrate a major problem: coming up with standards and more importantly, getting client and server developers to implement/conform to said standards.

Yes, getting client and server developers to agree on implementing a standard is very hard. However the plugin approach sidesteps the client developers entirely (anyone can create the plugins), and if you're already a server developer then you could use your own mud as the prototype for the standard, and/or release a snippet for other server developers to use.

Originally Posted by ArchPrime Whatever the case, I'm feeling like a broken record. There are blatant, obvious reasons MUD devs are creating custom clients for their games... and that reason is not hubris.

Actually I suspect hubris may be one of the reasons. Others include those I mentioned earlier - legal concerns (particularly for commercial muds), wanting it to run from a browser, or simply for the challenge. Or perhaps just an unawareness of what modern clients are capable of?

[shadowfyr]

Personally, when thinking about implimenting something for Mushclient, back before it got added, I had the thought of using markup to create the "layout" of the design you wanted, then either download that, or have the mud send it. The problem I ran into is that you have to create all custom controls. Why? Because MS doesn't even try to make it easy to use "design mode" for controls, outside their own IDE environments, and that assumes you are using controls that recognize it anyway. Worse, one reason to go with something like Lua, instead of tying the client to something in .NET, or COM, is to, at least in principle, allow someone to port it with a bit less insane recoding. Using Windows "native" system for controls kind of screws that, especially if you actually got design mode to work at all.

I have a vague sense how you could, but its... not documented in anything like a direct fashion. Its more like knowing that you can install front wheel drive, but having *never* seen how the whole system ties into the steering, or being able to find a manual showing how to do it right. Knowing the general idea of how it should isn't the same as actually being able to build it. I drove myself nuts for a while trying to find "anything" clearer than the vague hint buried in MS' own site (and their non-working link to a demo that supposedly used it), before giving up on the whole idea.

In any case, in general, the best solution is "likely" to take something that already has a huge set of features, and works fast, then try to work out how to correct some of its.. oddities. For example, ages ago you could find "fast" text clients for muds, which supported similar features, including scripting and triggers, but also supported text positioning, which Mushclient doesn't. Its not trivial, but not impossible either, everything in existence that is designed to do rich text *has to* be able to remap a document, if you delete internal tags, change the text, or page up/down. This isn't "much" different than what you need to adjust both the buffer display, and what is on the page. In the case of the old days, ones like Telemate, basically recorded the "final" state of a line, once it was no longer on a page, and treated pages just like page breaks in a document editor.

Point being, you could take an existing client, port it to something less platform dependant, as long as it was designed to start with to be that way, then just add the things that are missing. But, only for the open source ones.

Flash... Seriously, I watch movies via that, and used for that, it seems to *eventually* lag what ever it is in, until it either slows the whole system down, or crashes the browser. It has known problems. An interesting alternative seems to be PHP, with java, which, interestingly, has even been used to make things like EyeOS, which is an entire virtual desktop, which runs in the browser. However, Flash is so annoyingly ubiquitous that it even shows up there, for things where it is "easier". So is, imho, trying to use a skate board and a rope, tied to someone else's car, compared to actually having to drive one, but... lol

[KaVir]

Originally Posted by shadowfyr For example, ages ago you could find "fast" text clients for muds, which supported similar features, including scripting and triggers, but also supported text positioning, which Mushclient doesn't.

Couldn't you do it in MUSHclient by discarding the text window, and diverting the output to a miniwindow?

[shadowfyr]

Originally Posted by KaVir Couldn't you do it in MUSHclient by discarding the text window, and diverting the output to a miniwindow?

Not.. Efficiently. The mini-window isn't designed for it at all, and coding the extra stuff in script, to handle paging.. It would really have to be done more directly, in the main window, not via scripting, I think. Mind, not a lot of muds actually use the stuff anyway, its just a tiny few that do, and its often buried in the prompt systems (like changing the line of the prompt to update time, or something, without sending an entire new prompt), etc. Its not necessary to even have the feature, but its damned annoying for it to be missing, if you a) need it, or b) want to connect to something running an older game. An example might be trying to run TW2002, via a mud client, so you can take advantage of its scripting ability. It was written for dialup, it works, with some help, via Telnet, but almost nothing in existence supports **all** of the text control functions in ANSI, while also having any sort of complex script system, of any kind at all. FSM forbid someone got it into their head to do some of that stuff on a mud, and found that 99% of the clients either don't support it well (there is no protocol for asking, "Do you support all of ANSI, of just bits of it?", really, and certainly not color, but not cursor movement codes, since the former was added later than the "more critical" cursor controls...), or work poorly, or are almost feature non-existent, if they did.

[scandum]

Originally Posted by shadowfyr It was written for dialup, it works, with some help, via Telnet, but almost nothing in existence supports **all** of the text control functions in ANSI, while also having any sort of complex script system, of any kind at all.

TinTin++ supports full ANSI (typically called VT100), character mode, complex scripting, and runs on all major platforms.

[Newworlds]

Originally Posted by scandum TinTin++ supports full ANSI (typically called VT100), character mode, complex scripting, and runs on all major platforms.

Hmm, sounds like a winner and we're not even promoting TinTin on the NWA website with some other clients we promote. Send me a PM or email with download/contact info Scandum and perhaps we'll add it.

[shadowfyr]

My preference "tends" to be for non-custom script languages too, which have a fair range of language features. Most clients have... what could be called a "subset" of commands, that are useful, when specific to basic stuff you want to do with muds, but, at the same time, tend to be irritatingly limited, if you want to do something that isn't in the "standard" lexicon of things you are *expected* to want. Personally, I hate all of them. lol But, yeah, there are a few that provide fairly complex, if client specific, scripting, and support the full set of ANSI functions.

This just means that there is no rational purpose in not reworking ones that don't, and have a wider feature set to begin with.

[scandum]

Originally Posted by shadowfyr Most clients have... what could be called a "subset" of commands, that are useful, when specific to basic stuff you want to do with muds, but, at the same time, tend to be irritatingly limited, if you want to do something that isn't in the "standard" lexicon of things you are *expected* to want.

TinTin++ 2.0 has just in time compilation and is equal to C with the exception that low level string processing must be done with regular expressions. The language is typeless and provides associative arrays as well.

Another advancement is that scripts can be multi-lined and indented, in the past the typical tintin script was one long line of commands, making scripts so unreadable that any kind of serious programming was out of the question.

From my own experience most things are a breeze to script, low level string operations require some creativity with regex, and if push comes to shove you can use #script to use another scripting language.

Another cool feature that I don't believe any of the other mud clients offer is that you can run console programs like pine, lynx, ssh, and sftp within TinTin++ with full scripting capabilities.

[Fizban]

Originally Posted by Newworlds But I agree, Tintin and Vipmud aren't listed and they are both very popular.

Hmm, never even heard of VipMUD, not sure I could really class is as being very popular based on that. At least not in general, might be popular among players on your specific MUD, but out of the thousands of mudders I know none have ever mentioned using said client.

[Fizban]

Originally Posted by Fizban Hmm, never even heard of VipMUD, not sure I could really class is as being very popular based on that. At least not in general, might be popular among players on your specific MUD, but out of the thousands of mudders I know none have ever mentioned using said client.

Downloaded it, I quickly realized why I'd never heard of it. It's $30, essentially the same price as cMUD ($29.95), but doesn't look to even be in the same league. GUI is not user-friendly, and is almost non-existant, and its feature list is miniscule compared to cMUDs.

EDIT:

Originally Posted by Kavir They were players. But the point is they liked zMUD, and could no longer use it because of their operating system.

While zMUD is not officially supported on Windows Vista and Windows 7 it still works perfectly fine on both Operating Systems. It does require being ran as admin on them, but I hardly consider that trivial of task (especially since in properties you can set a program to always be ran as admin instead of having to select it every time you wish to run the program) to be a deal-breaker.

[KaVir]

Originally Posted by Fizban While zMUD is not officially supported on Windows Vista and Windows 7 it still works perfectly fine on both Operating Systems. It does require being ran as admin on them, but I hardly consider that trivial of task (especially since in properties you can set a program to always be ran as admin instead of having to select it every time you wish to run the program) to be a deal-breaker.

Are you sure that's all? Because Zugg has said that "Some people might be able to force zMUD to run on Vista and Windows 7, but it is not supported. Beyond just installation and running problems, there are other severe memory limits and other problems with zMUD on newer versions of Windows."

But either way, the fact still remains that I've had players switching from zMUD because they couldn't get it working.

[Newworlds]

Originally Posted by Fizban Hmm, never even heard of VipMUD, not sure I could really class is as being very popular based on that. At least not in general, might be popular among players on your specific MUD, but out of the thousands of mudders I know none have ever mentioned using said client.

It is a mud client specifically for blind players.

[Fizban]

Originally Posted by KaVir Are you sure that's all? Because Zugg has said that "Some people might be able to force zMUD to run on Vista and Windows 7, but it is not supported. Beyond just installation and running problems, there are other severe memory limits and other problems with zMUD on newer versions of Windows." But either way, the fact still remains that I've had players switching from zMUD because they couldn't get it working.

Yep, or at least that's all I've ever had to do, and I'm running the version of Windows which I'd expect it to have the most issues with (x86-64 Win 7).

[shadowfyr]

In almost all cases, if an application won't run unless its in "admin" mode, its usually due to it installing into "Program Files", and then attempting to write data to/from that location. Simply installing it to someplace else will tend to fix it. There are more than a few I use that still try to do that, and some of them, while they support adding additional locations for files instead of using the defaults, don't make setting that up exactly trivial. In some respects, it was stupid for them to be placing stuff in their own folders anyway imho, kind of like how 100% of all applications "insist" they need to be in the "main" trunk of the "Start" menu, even if it would be more logically to offer "media", or "games", or some sort of sub-subject as an option. Once people get the program working, more or less, and they are ready to package it, things like "Should be store user files here?", and "Are we an idiot for storing the link to the application in the same menu as all 800 other applications the user installed previously?", just never becomes something worth bothering with, or something.

Have to go in once a year and clean up their mess. lol

[Zen Clark]

I use wxMUD and Lyntin, depending on my needs at the moment. Both have nice and clean interfaces, and varying potentials for extending them. I've thought about creating a Lyntin module for the mud I'm working on as a break from the main server coding/building, which has some good potential. I've also messed around with Mudlet before but I don't think I will be switching over to it as my primary client.

wxMUD - a cross-platform graphical MUD client
The Lyntin Agent Framework: Main