Member Discussions

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.

Kavir,

Thanks a lot. This is a great resource. The only problem I
see is trying to not stop work on my current project so I can
try this out right away.

Sombalance

Okay, that is just cool.

Are mudlet or the snippet usuable by players on any mud or does it have to be something the mud owner/coder installs and then the players can use?

Does it work as a client itself? or do you use it with another client? (sorry-still early here)

Kitkat - would love to see where her character is in real time -

> Are mudlet or the snippet usuable by players on any mud
> or does it have to be something the mud owner/coder
> installs and then the players can use?

Mudlet is an open source mud client, it works for any mud, and allows graphics to be drawn using Lua scripts. However it needs to know what and when to draw, and that's where the snippet comes in. The snippet needs to be added to the mud by the owner/coder.

It is also possible to create a GUI without the snippet, using regular expressions - there are many examples of energy bars that update using information from your prompt, for example. However these require you to have a specific prompt pattern, and they only refresh when you hit enter. With the snippet they can update in real-time, without anything being displayed in the text window, and this becomes particularly important for things like maps.

> Does it work as a client itself? or do you use it with
> another client? (sorry-still early here)

You need a client with decent scripting support, such as MUSHclient, Mudlet or TinTin++. This handles the display, the sound, etc, via a script. Such scripts are generally pretty easy to create, but they can't pull the data they need out of thin air - they need some way to extract it from the mud. Many players already create such scripts for their favourite muds, but they're limited to what they can reliably capture from the text window.

The snippet provides a simple and reliable interface for such scripts, allowing players to directly request whatever data they need (although of course the mud still gets to control exactly what data is available).

Other features, such as clickable links, extended colour and unicode characters, can be added to messages and help files much like those two-letter ANSI colour codes many muds already use. Like those codes, they're automatically enabled or disabled by the snippet depending on whether the client supports them.

KaVir,

This is really nice code -- thank you! Do you plan to finish
up the How-To for implementing into TBA -- or at least tell us
where you left off and what we should do to complete the
implementation?

> This is really nice code -- thank you! Do you plan to
> finish up the How-To for implementing into TBA -- or at
> least tell us where you left off and what we should do to
> complete the implementation?

The INSTALL_GENERIC.TXT file has general (codebase-independent) instructions, but I can have another look at TBA as well.

... april 1st? Not a very nice choice for this sort of announcement, is it? I'll look at it tomorrow ;)

well i can tell you its not an april fools! Unlike last year when KaVir posted that everyone must speak german on his MUD by law.. :P

Yeah. I can confirm this is not an April Fools joke. He's been working on it off and on for a couple months at least. I've been working on something similar (or rather, my minion has been) in parallel.

I installed it last night, and it wasn't hard at all.

There were a few Rom / Merc differences, such as needing to make a GET_AC_TOT(ch) macro, but on the whole I'd say the instructions are pretty clear.

Thank you, KaVir!

> Yeah. I can confirm this is not an April Fools joke. He's
> been working on it off and on for a couple months at least.
> I've been working on something similar (or rather, my minion
> has been) in parallel.

Yeah I offered to let him use an early version of the snippet for The 7th Plane, but your MSDP implementation was already too far along.

The snippet includes other stuff as well though, you may still find it worth checking out.

Any possibilities to have something similar to zMUD or CMUD?

(Comment added by IFamiINIe on Sun Apr 3 10:32:51 2011)

Ahh, I see now after re-reading some of the responses in more depth. This should allow client-based scripts to receive data in real-time rather than hooks based on text patterns. However, when it comes to drawing GUI elements, certain clients may have limitations based on what they can basically piece together from the data received from this script server-side (MUD)?

If I'm understanding this correctly. Different clients will be able to utilize this based on their own limitations.

> Ahh, I see now after re-reading some of the responses in
> more depth. This should allow client-based scripts to
> receive data in real-time rather than hooks based on text
> patterns. However, when it comes to drawing GUI elements,
> certain clients may have limitations based on what they
> can basically piece together from the data received from
> this script server-side (MUD)?

Yes, the actual drawing is handled by the client. MUSHclient and Mudlet both have powerful scripting capabilities, and they're free, which makes them ideal candidates for creating a custom GUI. You could even bundle up the client with the script and images and offer players a single preconfigured download.

Obviously if your players insist on using windows telnet, GMud, or some other basic client, then they're not going to benefit from the snippet.

CMUD/zMUD supports some of the features, but I don't know if its scripting capabilities are powerful enough to create a full GUI. However IMO one of the big advantages of a custom GUI is for bringing in new players - but if they find they have to pay $30 for the client they may decide not to bother.

Thought this might be worth mentioning.

I installed the generic plugin for MUSHClient
4.61 and instead
of the gray gravelly type background, I got the
gold color.
To fix this, I edited the Generic_GUI.xml file
and changed the
setbackground call to

check (SetBackgroundImage(GetInfo (66) ..
"Generic/layout/outer_background.png", 13))


GetInfo (66) returns the home directory of
MushClient.

The command is supposed to be on one line, but
Chrome likes to break it up for me.

Sombalance

Mudlet is an open source mud client, it works for any mud, and allows graphics to be drawn using Lua scripts. However it needs to know what and when to draw, and that's where the snippet comes in. The snippet needs to be added to the mud by the owner/coder.

Ah, okay. I think I may give mudlet a try even if I can't get all the stuff it and the snippet would provide.

Thanks and sorry I didn't reply sooner. Busy, busy week.

> GetInfo (66) returns the home directory of MushClient.

Ah good point, thanks - actually the plugin was pretty hastily thrown together at the last minute, it was really just intended to help get people started. It could definitely be written better, and I'm hoping we'll see a lot more activity in this direction in the near future.

What I'm really promoting here is the snippet, because once that's installed anyone can create their own GUIs if they want to.

But people tend to react much more enthusiastically towards sexy screenshots than clever code, and I wanted to grab people's attention ;)

Thanks for releasing this kaVir! I've been following your posts on MUD Bytes on this and was getting super excited. I can't wait to take a stab and putting this in my MUD. Thanks for taking the time to snippet-ize this!

So, I've been porting this snippet over to java and when I was testing it, I noticed that mushclient was sending NAWS info around 20+ times (compared to less than 5 for putty, telnet and mudlet). MUSHClient seemed to behave the same way regardless of having plugins installed.

I was wondering if anyone else noticed that.


Sombalance

> So, I've been porting this snippet over to java and when
> I was testing it, I noticed that mushclient was sending
> NAWS info around 20+ times (compared to less than 5 for
> putty, telnet and mudlet). MUSHClient seemed to behave
> the same way regardless of having plugins installed.
>
> I was wondering if anyone else noticed that.

It should send NAWS every time the screen size changes. Were you changing the window size at the time?

Hey, do you mind sharing your Java port?

(Comment added by MECHFrost on Thu Apr 7 6:22:16 2011)

Edit: talking to Somnolance.

Nope, I wasn't changing the window size.

I'll play around with it more today. The only reason I
noticed it was that the first time I connect with a plugin,
there is a noticeable delay in sending/receiving text to the
screen. After about three or four commands, the delay is gone
and doesn't appear again unless I completely close MushClient
before attempting to login again. I thought I might have been
spamming a negotiation sequence. That doesn't seem to be the
case though, although I haven't ruled out something goofy in
my stuff.

Sombalance

Nope, I don't mind sharing it, but you should be aware I've
only been programming in Java for about 3 weeks now. I got
the urge to learn Java and decided that a simple hello world
tutorial wouldn't cut it. I'll post it somewhere this weekend
with an appropriate "use at own risk" type warning. I am
still testing it out to see that I haven't wrecked it.

Sombalance

> Nope, I wasn't changing the window size.

Was the value different each time, or was it always the same? If it's changing then it sounds like a MUSHclient issue - what version are you using?

If it's not changing, check whether it does the same in my snippet or just in your ported version. If the latter, it could be you're not clearing the buffer after receiving the sequence.

The delay with the plugin is probably because it's redrawing everything each time it receives new data. It should ideally be changed to only redraw the things that change, and not draw anything initially until all of the data has arrived. As I said before, the plugin could really do with a rewrite.

Hey,

Using the plugin on tbaMUD I am getting the below crash
every time a zmud 4.62 client connects...

Program received signal SIGSEGV, Segmentation fault.
0x080a3639 in process_input (local_mother_desc=5) at
comm.c:1922
1922 *(read_point + bytes_read) = '\0'; /* terminate
the string */
(gdb) bt
#0 0x080a3639 in process_input (local_mother_desc=5) at
comm.c:1922
#1 game_loop (local_mother_desc=5) at comm.c:820
#2 0x080a4878 in init_game (argc=2, argv=0xbffff7e4) at
comm.c:512
#3 main (argc=2, argv=0xbffff7e4) at comm.c:353
(gdb)

any ideas or ways I can go about debugging this. It has
happened once before when I just connected with putty. It
never has issues with wintin or MUSHClient.

What are the lines in the earlier frames? What does the input string it crashes on look like?

Also, do I understand you correctly that you've had this happen to you once before you had the snippet installed?