AJAX Mud Client

[York]

Javascript is one of the most widely used programming languages in the world owing to the number of installed browsers that support it. Therefore it only makes sense that an environment (HTML, CSS, XML, JS) designed roughly to support interfaces (documents if you want to be technical) should be used to develop network-enabled applications-- Which is what brought me to ajaxmud.net recently.

At anyrate check out this link for an ajax-based mud client.

We're one step closer to a web-enabled mud

[krem]

I think everything is in place to implement a feature-rich web-based UI for a MUD. It's only 1 solid proof-of-concept/implementation from actually becoming a reality. Someone needs to put all the little pieces together and show that it does work.

My biggest gripe with most implementations such as the one you provided is that it remains almost exactly like the telnet model of all text-based commands/responses. The next generation of mud clients need to be much more visual than the past. The clients need to take the original text-based interfaces and add to it: Maps, inventory lists, status bars, etc.

This is a paradigm shift in a way and would require a large amount of re-work in the existing MUDs. However all new MUDs should start out with this in mind.

[York]

I wholeheartedly agree that there is a need to move forward. Part of the reason MUDs are failing to attract new blood in any significant quantity is because of the archaic client interfaces and general difficulty of getting clients to work in the mildly security-aware environments of modern computing.

Telnet doesn't play friendly with firewalls, particular kinds of networks, and is difficult to secure from hacking. Most of all, the protocols available for supporting media (MXP, MSP) are rough and only partially supported.

A better solution is, as this whole site indicates, to move the client to the browser. The browser is an ideal platform, despite some of the incompatibilities between brands, because it provides a methods of scripting an interface (Javascript), languages for formatting content (HTML and CSS), is widely supported on nearly all commercial operating systems, and provides methods of serializing data/media and streaming it to the client (instead of having to design and develop all the client-side network code yourself).

More importantly tens of millions of people use browsers to access the internet each and every day. There is an advantage to be had when new potential clients don't have to install an application or plug-in, but can immediately access your software.

As for server-side solutions, yes, they are sadly lacking, even considering all the MUD codebases available. Most solutions don't scale, are outdated, poorly engineered, lack common media support, are insecure, and are difficult to customize without using kludge-like scripts or dropping down into hardcode. More importantly most codebase are lacking substantive documentation. Don't get me started on licensing (e.x. Diku).