[KaVir]

I've been working on improving the interface for God Wars II for nearly a year now, making it easier to navigate through a mixture of graphics, sound, and enhancements to the text. The following screenshots demonstrate my GUI using MUSHclient and Mudlet:

• MUSHclient: Opening the large map while standing in Glyphstone Village.

• Mudlet: Exploring an undead-ridden crypt.

For the past few weeks I've been working on a snippet that adds the same feature support to other muds, and it's now pretty much complete. The snippet is relatively self-contained, and is designed to be easy to install and easy to use - I've added it to a few codebases already, and it generally takes me around 5-10 minutes (at least once I've worked out where the hooks need to go).

The underlying concept isn't new - muds like BatMUD, Maiden Desmodus, Primordiax, Archons of Avenshar, etc, have been offering graphical interfaces for a while. But those are handled through private clients and closed protocols. What makes this different is that it operates on existing open source clients, using an open protocol (MSDP) that allows owners and players alike to quickly and easily design custom GUIs for their favourite muds. You can see some of the interfaces my players have created for MUSHclient and TinTin++ here, here and here.

A handful of other muds have also made progress in this direction - for example the Aardwolf MUSHclient plugin and the IRE Mudlet interface both work in a similar way. But implementing full server-side support is a non-trivial job, and many mud owners still view graphical interfaces as some sort of mysterious black magic that requires a huge investment of time and skill. While it's certainly possible to invest a lot of time into GUI work, even a simple interface can be a huge improvement, and it's something that can be achieved extremely quickly.

Here are a couple of simple proof-of-concept "themed" demo GUIs I created for other muds - they took me about 1-2 hours each:

• SlothMUD (click here for screenshot): Now click here to view their website and compare the style.

• Tir na nOg (click here for screenshot): The map in this case is hand-drawn rather than generated, but this is also a viable approach.

Here's a slightly more fleshed-out GUI I created and then adapted - it took around 2-3 hours of tweaking to create the first one, the other two took only a few minutes each once I'd found suitable images:

• Realms of Despair (click here for screenshot): Also demonstrates some of the other features offered by the snippet.

• The Realm of War (click here for screenshot): Tijer has already implemented the snippet, so I wanted to give him a working demo.

• Generic GUI (click here for screenshot): A generic GUI for others to download and use. You can get it from here.

In layman's terms, the snippet provides the following features:

• Transmits data invisibly between server and client, allowing you to update your energy bars, maps, icons, buttons, etc, in real-time, without needing to capture anything from the text window.

• Extends your old 16-colour ANSI to 256 colours (or even 16 million if you really want them).

• Identifies which clients your players use, their screen size, and other useful details.

• Allows you to embed clickable links into messages, descriptions and help files, so that players can navigate with their mouse. Graphics can also be embedded in this way if you wish.

• Allows you to display unicode characters, such as the runic alphabet, alchemy symbols, gender symbols, weather symbols, linedraw characters, chess pieces, etc.

• Provides extensive information about your mud to any websites that wish to use it. This can be used to automatically generate and maintain detailed mud listings, saving you the hassle of updating them manually.

• Can be used to play background music, as well as sounds for combat, weather, movement, mudsex, communication, eating, sleeping, etc.

In more technical terms, it adds support for TTYPE, NAWS, MSDP, ATCP, MSSP, MSP and MXP, as well as UTF-8 (using CHARSET) and XTerm 256 colors. The plugin is a Lua script bundled with some public domain images to get you started.

The Realm of War has already installed the snippet, while several other muds are currently in the process of adapting it to their needs, including Realms of Despair, SlothMUD and 4Dimensions.

If you're interested in using it as well, or just want to read more, you can grab the snippet from here. Even if you hate graphics, you may still find some of the other features useful.

[melopene]

KaVir, I could so kiss you right now. This is something I've been wanting to see available for the non-commercial muds for at least 10 years. I am definitely putting this as a major point on my to-do list.

[lothoemas]

KaViR, this snippet is amazing. I got it working on our development port within about 15 minutes and haven't been able to stop myself from messing around with it since. I've been following your thread over on MudBytes and had been hoping that you would eventually release something like this. If you are interested I can keep you up to date on how we end up using this on Ansalon.

[KaVir]

Glad to hear people are finding it useful. I'd definitely be interested to see what you do with it - perhaps you could even post some screenshots once you've got a GUI?

[Threshold]

Wow. This is really awesome stuff.

Just from the screenshots and the description it sounds great.

[jcp80212]

Just wondering is it still possible to extract data from the incoming stream ie my game has a hp ticker would it be possible to make that into a hp graphic bar.

[KaVir]

Originally Posted by jcp80212 Just wondering is it still possible to extract data from the incoming stream ie my game has a hp ticker would it be possible to make that into a hp graphic bar.

Yes, you could also extract the data from the in-band stream using a regular expression. For example you could use the hp from your prompt to draw the energy bar, but that means that (1) you'd need to have a specific prompt pattern which included your hp, and (2) the energy bar would only update when you received a new prompt.

However the snippet uses MSDP to transmit the data out-of-band. That means you don't need to capture anything from the in-band stream - you can literally sit there with a static text window and watch your energy bars slowly refill, or watch the landscape scrolling past as you walk across the map, etc.

[jcp80212]

That's awesome the way I have seen muds do graphics is using specific lines on text which the client reads and then never outputs that line to the output window which is what I've been attempting to do but have failed so far I'll definitely check out this and see if it will fit in with my plans I'll post up some screen shots if I get it implemented.

[KaVir]

Originally Posted by jcp80212 That's awesome the way I have seen muds do graphics is using specific lines on text which the client reads and then never outputs that line to the output window which is what I've been attempting to do but have failed so far I'll definitely check out this and see if it will fit in with my plans I'll post up some screen shots if I get it implemented.

Well you can gag the text, but you'll still get blank lines in most clients. In my mud you regenerate every second, so handling that in-band would be really spammy - it'd be like hitting enter once per second.

The only way you can really avoid that without going out-of-band is to send the data with something that should be displayed, like your prompt (this is also how MXP handles it). But then you've got the problem that the energy bars won't refresh unless the text window updates, and that feels pretty clunky - particularly when you're regenerating every second, and are waiting for your energy bars to refill before you carry on exploring an area.

This is an issue I struggled with for a while before settling on MSDP - I documented my experiences on a blog if you're interested. The snippet (which took lothoemas 15 minutes to add to Ansalon) allows other muds to use the same features I've spent the last year working on.

[plamzi]

Great post, KaVir, and thanks for sharing. Enhancing the player experience is my #1 priority and I'll be looking to use your snippet as a building block--one thing my server is missing is support for advanced desktop clients.

Just wanted to add a few more resources to the mix. If you're someone who is comfortable with HTML + JavaScript + PHP and who wants to extend the reach of your MUD to Facebook, or the web in general, with a custom web client for your game, take a look at these links:

Flash Telnet to JS API + Sample UI

Web-Based Automapper (can be standalone)
Automapper Screenshot

Live Facebook App (no login required, use IE9 or non-IE browser)

The app has the embedded automapper + a minimap, and the page code contains reusable functions for handling controls, etc. Feel free to rip the JS / HTML code from the Facebook app page as needed. Just plug your own art.

My FB app targets the non-mudder who wants to discover a new and more challenging game. While it doesn't have too many power user features, it supports such "pretty" stuff as player avatars with changing states, transparent overlay map, etc.

In my case, the server drives the app and minimap without using standard protocols, but you can easily change that. If you decide to give it a shot and need code snippets showing how the server feeds the app in my implementation, let me know.

[melopene]

I actually had a thought last night - how well will this scale to screens of various size and resolution? There's a big difference between my 22" widescreen on my desktop and the 10.1" netbook (which I don't typically MUD on because of screen size - in a busy room, just 'look' can fill my full screen). Will text size and the background graphics scale well, or will it create even more of a problem on the tiny screens?

[KaVir]

Originally Posted by melopene I actually had a thought last night - how well will this scale to screens of various size and resolution? There's a big difference between my 22" widescreen on my desktop and the 10.1" netbook (which I don't typically MUD on because of screen size - in a busy room, just 'look' can fill my full screen). Will text size and the background graphics scale well, or will it create even more of a problem on the tiny screens?

That's entirely up to the client and/or plugin. A small degree of scaling is quite easy to handle - for example my MUSHclient GUI shrinks and stretches the text window and energy bars to fit the screen. But resizing bitmaps (particularly small icons) can degrade their quality.

[scandum]

I've linked your snippet from the MSSP and MSDP specification pages.

The snippet doesn't have a name (that I can find) so I named it Kavir's MUD Protocol Handler, is that alright?

[KaVir]

Originally Posted by scandum I've linked your snippet from the MSSP and MSDP specification pages.

Excellent, thanks. You may want to link to the copy in the MudBytes code repository instead though, it's a more "neutral" download location.

Originally Posted by scandum The snippet doesn't have a name (that I can find) so I named it Kavir's MUD Protocol Handler, is that alright?

Sure. I didn't really name it.

[scandum]

I'll link MudBytes instead. Another issue I noticed the other night is that Realm of War's current MSSP initialization is rather poor.

MSSP Mud Crawler - Realm of War is at the bottom.

I'm not sure if some kind of sanity checking would be helpful / too much work. Adding some comments with suggested values might help. I've emailed the guy; I guess MSSP is going to be a mess until a mud listing (that people actually want to be on) forces people to fill it out properly.

[KaVir]

Originally Posted by scandum I'm not sure if some kind of sanity checking would be helpful / too much work. Adding some comments with suggested values might help.

Well I do actually have the following comment directly above the table:

   /* Before updating the following table, please read the MSSP specification:
    *
    * http://tintin.sourceforge.net/mssp/
    *
    * It's important that you use the correct format and spelling for the MSSP
    * variables, otherwise crawlers may reject the data as invalid.
    */

However I didn't want to clutter the table itself with too many comments. I considered including some default values, but figured some muds might leave them as-is rather than updating them, which would result in incorrect information - better to have less data than wrong data.

Originally Posted by scandum I've emailed the guy; I guess MSSP is going to be a mess until a mud listing (that people actually want to be on) forces people to fill it out properly.

You could perhaps provide a script linked from the MSSP page that generates a report of any issues. It wouldn't deal with deliberately false information, like The Isles reporting a random number for "PLAYERS" every time you send it an mssp-request, but it would at least ensure that the fields used the correct format.

It'd also be nice if your crawler indicated MSDP support, particularly now that more muds are starting to add it.

[scandum]

Hadn't thought about creating a debugging script for server developers, that's a good idea.

I'll have a look at the variables you're using and synchronize the spec where needed.

Also, are there any links for your Mushclient / Mudlet plugins? As far as I can tell you've only linked screenshots, but no links to the actual plugins.

[KaVir]

Originally Posted by scandum I'll have a look at the variables you're using and synchronize the spec where needed.

I've included the full set from the specification (including the extended variables), although all but the essentials are commented out by default.

Originally Posted by scandum Also, are there any links for your Mushclient / Mudlet plugins? As far as I can tell you've only linked screenshots, but no links to the actual plugins.

I did provide a link to the MUSHclient plugin for the generic GUI - you can get it from here. The others are tailored to a specific mud, and I've given copies directly to the owners of those muds. Nothing generic for Mudlet yet, but I can throw something together I guess...it's really the snippet that I'm promoting here though, the plugins are just a demo of what you can use it for.

[scandum]

I was wondering the other day, does your snippet's MSSP support work for a MUD crawler that doesn't respond to TTYPE?

[KaVir]

Originally Posted by scandum I was wondering the other day, does your snippet's MSSP support work for a MUD crawler that doesn't respond to TTYPE?

If the crawler responds with either WILL or WONT, then the snippet will attempt to negotiate MSSP. If the crawler ignores the IAC DO TTYPE, then its telnet implementation is broken, and the snippet won't attempt to negotiate further.

Your MSSP mudlist includes the Realm of War, which uses my snippet, so clearly your crawler has no problem with it.

[jcp80212]

Hey thanks for pointing me towards using mushclient, I was able to build a pretty simple window in not that long of time and used a trigger code to snag outstream data that only that client sees. It was also possible to remove the text without leaving a white space which was nice cause the hp ticker got very annoying after a while. I'd love to one day implement that snippet you wrote but for now this is working very nicely. Thanks a lot for all the help you threw out there.

[KaVir]

Originally Posted by jcp80212 Hey thanks for pointing me towards using mushclient, I was able to build a pretty simple window in not that long of time and used a trigger code to snag outstream data that only that client sees. It was also possible to remove the text without leaving a white space which was nice cause the hp ticker got very annoying after a while.

Using MUSHClient's omit_from_output feature, I assume? That only works for single-line triggers, and (because the text is actually drawn then removed) won't work for screen readers, and may cause flickering if you send a lot of data. If you want to omit multiple lines you'll need to look at something like Nick Gammon's omit blank lines plugin (although that'll strip all blank lines, making the display look a bit squashed). Other clients will require their own solutions.

Your plugin will also need some way to tell the mud what data it wishes to receive. You could try looking over some of the older threads on the MUSHclient forums for inspiration (particularly the Aardwolf ones from 2006-2008), as your approach is similar to the way the "old school" plugins worked, before the recent push towards out-of-band protocols.

The snippet lets you avoid all of these issues of course, using a generic solution that works on a range of clients, but that's not all it does - it also supports extended colour, client detection, clickable links, inline graphics, unicode characters, sound, etc. And it's public domain, so there are no licence restrictions.

Bryantos also uploaded a SocketMUD port of the snippet earlier today, if anyone's interested.

[KaVir]

For anyone wishing to use the snippet in a TBAmud derivative, I've now updated the version in the MudBytes code repository to include full TBA installation instructions - you can download it from here. I recommend using those instructions rather than the diff file in the TBA section, as the diff appears to have some issues.

I'm now aware of four operational muds using the snippet (not including my own), and at least two other muds using it on their test ports. If you support MSDP (either through the snippet or through your own solution), please contact Scandum so that he can add you to the MSDP protocol page.

[KaVir]

If anyone has used the Merc installation instructions, please be aware that I missed something - thanks go to Bryantos for pointing it out.

In read_from_description(), you need to replace this:

    /* Check for overflow. */
    iStart = strlen(d->inbuf);
    if ( iStart >= sizeof(d->inbuf) - 10 )

With this:

    /* Check for overflow. */
    iStart = 0;
    if ( strlen(d->inbuf) >= sizeof(d->inbuf) - 10 )

Without that change, spammed commands will be silently dropped, which can be rather annoying (particularly for movement).

[lothoemas]

Finally got this in and going, thanks to KaViR and Bryantos. We also just released the first version of our GUI, not far from KaViR's Generic Plugin but I have certainly learned a lot so far and plan on learning more as I hope to get a bitmap version of my ascii mapper going as well as a tracking of our three moons in the top/right corner.

Here is a link to our GUI's wiki page:
Ansalon GUI - Unofficial Ansalon Wiki

And a screenshot:

[KaVir]

I've updated the snippet to resolve a couple of issues that were recently brought to my attention. If you're already using the snippet, I recommend using diff first, so that you don't wipe over your MSSP variables.

The first issue is broken packets. If the client splits the data across multiple packets, the snippet can now handle it correctly. Thanks go to Tyche for pointing this out.

The second issue is a bit more tricky. RFC 1091 provides a mechanism for cycling through multiple terminal types, and the mud uses this standard to detect support for XTerm 256 colors. However when used with Windows telnet, the client is left in a terminal emulation mode that appears unable to communicate with the mud - and it refuses to return to the top of the list. Or to put it in simple terms: Windows telnet freezes when it connects to the mud.

My solution is a bit nasty, but it's simple and effective. If the first TTYPE is "ANSI", the mud won't request any further terminal types. This has no impact on dedicated mud clients such as WinTin++ and BlowTorch, as they identify themselves by name on the first TTYPE request.

There is an alternative approach using escape codes, which I may add in the future, but it comes with a different drawback; the mud would need to pause for a few seconds before displaying the login screen. However this approach would also allow you to avoid the automatic disabling of echo for Windows telnet users.

[KaVir]

I've updated the snippet again, primarily because the MSDP specification has undergone several changes since the snippet was released, but also to resolve a few issues I've encountered while helping other people install it.

• Added an AllocString() wrapper function, as strdup() isn't standard C.
• Added support for the new MSDP tables and arrays.
• Added support for the new UNREPORT and RESET MSDP commands.
• Added a new REPORTED_VARIABLES list, as described in the latest MSDP spec.
• Renamed VARIABLES to SENDABLE_VARIABLES as described in the latest MDSP spec.
• Cleaned up the code, adding consts and fixing -ansi and -pedantic warnings.
• Added support for the new Mudlet GUI autoinstaller.
• Added an MCCP flag to make integration with the snippet easier.
• Updated CopyoverGet() and CopyoverSet() to include TTYPE, MCCP and CHARSET.
• Added an MSDPFlush() function for variables that need to be sent immediately.
• ProtocolOutput() now lets you send tabs.
• The snippet now recognises that DecafMUD supports 256 colours.
• Updated the TBA instructions with a fix for strfrmt().
• Updated the installation instructions to use MSDP tables.

You can download the latest version from MudBytes here.

An updated version of the generic MUSHclient plugin can be downloaded from here.

The following muds are now using the snippet to offer their players cutting-edge protocol support:

• 4 Dimensions (only on the test port for now, but see here and here)
• Ansalon MUD (ansalonmud.net 8679)
• Arcane Nites (arcanenites.com 7000)
• ChaosMUD (chaosmud.com 1111)
• CyberASSAULT (cyberassault.org 11111)
• Dark Lair (tiopon.mudmagic.com 3500)
• Fallout: The Dirty South (falloutsouth.net 4000)
• God Wars II (godwars2.org 3000)
• GodWars: Rebirth of Apocalypse (apoc.godwars.net 6660)
• Land of Eternal Sun (simba.darknessmuds.co.uk 5645)
• Pict (omen.genesismuds.com 4200)
• Realms of Despair (realmsofdespair.com 4000)
• Storm Hunters (sh.ackmud.net 7000)
• The Builder Acadamy (tbamud.com 9091)
• The Realm of War (row.godwars.net 2000)
• Tir na nOg (66.212.25.125 6789)

If you've added the snippet but aren't on the above list, please let me know!

There are also a few other muds that have implemented their own MSDP solutions, including The 7th Plane (7thplane.net 8888), which has also incorporated a few of the other features from the snippet, ConQUEST (conquest.sdmud.com 5000), Elvenblade (elvenblade.ca 23), and Lowlands (lolamud.net 6969).

Meanwhile, I've seen a few more muds adding support for GMCP, which offers similar functionality to MSDP. Both protocols make it considerably easier to design graphical interfaces, so it's pretty exciting to see more and more muds taking the plunge.

EDIT: If you're using version 3, there's a bug in AllocString() - you need to replace malloc(Size) with malloc(Size+1), to take into account the NUL string terminator. The Mudbytes link now points to version 4, which includes the fix.

[scandum]

I wasn't sure whether to start a new thread for this, but figured to post this here as the subject is identical.

I finished work on MTH 1.4, a public domain telnet / protocol handling snippet this week and it's now available for download here.

MTH 1.3 (released April 6, 2009) added support for NAWS, TTYPE, NEW-ENVIRON, MCCP, and MSSP. The MCCP implementation might be of interest to some because it uses 32K of memory per player, instead of the 138K used by most MCCP implementations.

MTH 1.4 adds support for EOR, MSDP, MTTS, Arachnos, and xterm 256 colors.

MSDP follows specification and should work with KaVir's MUSHClient plugin. In addition the MTH snippet has a walkthrough for implementing the ROOM variable, which combined with this TinTin++ script provides you with a status bar and fully automatic automapping. screenshot Not a whole lot of eye candy, but it's very effective, and will work with any other client that can parse MSDP and has an OOB mapper.

MTTS is a standard I created to negotiate terminal capabilities to the server. It's currently only supported by TinTin++, and in MTH it's used to detect 256 color support, and can be used to detect ANSI, VT100, UTF-8, and SCREEN READER support as well. MTTS is very easy to add both client and server side, unlike other alternatives.

Arachnos is an MSDP based Intermud network. Arachnos is relatively easy to implement for any MSDP enabled MUD. Instead of the traditional Intermud systems where you connect your MUD to a central server, an Arachnos spider connects to your mud using the normal connection, then uses MSDP to receive and transmit chat messages. Intermud gaming spiders are a likely future addition as anyone can create and run a spider. More information is available in the spec.

xterm 256 colors MTH extends the classic 16 color ANSI color system to a 32 color system using xterm color codes. ANSI supports 6 primary, 6 secondary, and 4 gray-shade colors. MTH adds the 12 tertiary colors, and 4 gray-shade colors. A stand alone version of the color snippet and a screenshot is available here. The code also supports color code compression.

Enjoy.

[KaVir]

While helping Splork get the snippet working in SlothMUD, we came across an interesting problem - it seems that the MXP specification doesn't actually define whether the server should initiate negotiation with IAC WILL MXP or IAC DO MXP. While some clients therefore support both, others support only one or the other. I've therefore updated the snippet to support both (it attempts one if the other fails).

There was also a complaint from another user about the MSSP table being cumbersome to update for non-static fields such as players and uptime. I've therefore changed the table to use function pointers, which should make it much easier to update in future.

Scandum also asked me to change LIST to use an array, as per the latest specification, which I've done.

Other than that there were a couple of bugfixes, but nothing serious. Here's the list of changes:

• Added symbolic constants for MSDP_TABLE_OPEN/CLOSE and MSDP_ARRAY_OPEN/CLOSE.
• MSDPSetArray() was using table values rather than the array values. Fixed.
• Added MSDPSendList(), used for the MSDP LIST command (updated to an array in the spec).
• Doubled MAX_VARIABLE_LENGTH for the list variables.
• Some of the LISTs had no separators between values when sent using ATCP. Fixed.
• The MSSP table now uses function pointers, making it easier to update dynamic fields.
• Added support for both variants of MXP negotiation.

You can download version 5 from the usual place.

[KaVir]

Version 6 is now available from MudBytes, and contains the following minor changes:

• Removed a stray semicolon.
  
  The "if ( !pProtocol->bMSDP );" statement had a semicolon at the end, which should be removed. This bug has very little impact, as MSDP already overrides ATCP, but it does mean that if the user's client supports both MSDP and ATCP, they will be sent the SERVER_ID variable twice.
  
  
• Made it easier to add MCCP support.
  
  Quite a few muds already support MCCP, and had trouble getting it working with the snippet - particularly if they were using copyover as well. So I've improved the documentation and made it easier to integrate.
  
  
• Made several minor updates to the installation instructions.
  
  The INSTALL_MERC.TXT had actually been written for GodWars rather than Merc, and relied on a couple of GodWars-specific changes. It's been updated to work with both, and now also defines MSDP_CLASS. The INSTALL_TBA.TXT instructions now define MSDP_CLASS as well.
  
  
• Added an INSTALL_ROM.TXT.
  
  Although the ROM instructions are very similar to Merc, there are a few minor differences, and someone had trouble adding it to their ROM derivative. So I added another set of installation instructions.