Look and Feel

[KaVir]

Some of what has been done is good, Kavir's ui is a good step in the right direction. But there is a long way to go to hook the people that muds need to survive long term.

There was quite an interesting blog post on this subject recently - I'll quote part of my response there, as I feel it also applies to this thread:

The real problem, in my opinion, is the lack of communication between server developers and client developers. Some clients may offer decent support for designing custom GUIs, but you can't expect them to build a GUI tailored to each and every mud - that responsibility belongs to the individual mud owners.

Likewise, many of these features require support for certain protocols, which need to be implemented in both client AND server. The major clients usually support most of these protocols, or at least allow you to easily add them through scripting - but most muds don't, and that limits what the client can do.

I've made the code for my GUI freely available, I've created basic versions for a couple of other muds, I've even had discussions with other developers about a generic GUI that can be controlled by the mud (i.e., the mud sends instructions telling the client what and where to draw various components).

Although I don't allow all of my graphics to be used by other muds, I have put together a package of public domain avatars, and provided links to websites where more public domain images can be obtained, customised, or even created.

I understand your view on this subject, it's actually very similar to my own (thus my recent work on GUI related stuff) - but trust me, you're talking to the wrong people. Mudlet can already do what you're after, and it offers to shake hands with any server that asks. The bottleneck is at the server end; very few muds can be bothered to reach out and clasp that offered hand. And the only people who can address that are the mud owners themselves.

My own players have created several of their own GUIs. But other mud owners? The reception has been lukewarm at best, and without support from the mud there are some pretty hefty limitations on what the GUI can do.

I actually started writing a mud snippet that would at least cover the essentials, although I keep getting sidetracked and haven't yet finished it. But even if I can get that finished, I don't expect it to suddenly revolutionise mudding - at best, my hope is that a handful of mud owners will decide to use it. Most, sadly, are pretty apathetic to the whole thing.

[larnen]

Absolutely agree with the above post. Maybe my problem here was misidentifying who the readership was on the Mudlet forum. I was working on the basis that it was a solid cross section of client developers, power users and mud administrators. If the representation from mud administrators is very low then clearly the sort of thing Im interested in cannot be achieved alone by the other two groups.

As a mud owner myself I would be more than happy to rewrite parts my mud to integrate with what Mudlet can offer. I have no issue doing that whatsoever, and MSP, MXP, GMCP etc support would be well worth adding irrespective of what client people are using. The difficulty is when as a single individual you are trying to rework the backend, AND write/implement/change the client scripts AND design the actual ui. I know my limitations (im an infrastructure/networks guy more than a professional coder) which was very much the thrust of wondering if there were graphic artists who could spin off a project to design something very modern looking, which then individual muds could rework to their own requirements.

The idea about the mud instructing the client how to place/update ui elements is an extremely interesting one btw. That sounds like one of those ideas that could snowball into something very very significant indeed especially if those updates can be done live and not just during an initial handshake.

Taking a step back for a second, my question would be - is it worth us making a subforum somewhere to focus on UI development, or even separating it from mudlet into an independent discussion. Im concious that some people have misinterpreted what I was saying as an attack on mudlet, which was never my intention and perhaps that would be solved by spinning it off into a dedicated space.

Either way thank you for the detailed replies. Im glad to see that im not out of step with what other mud administrators are interested in (those who have the enthusiasm to update their games to a post 1995 world!), and I will be watching development here keenly. If I manage to hunt down any graphic artists in my playerbase I'll see if we can help push this forward.

Larnen

[KaVir]

Maybe my problem here was misidentifying who the readership was on the Mudlet forum. I was working on the basis that it was a solid cross section of client developers, power users and mud administrators. If the representation from mud administrators is very low then clearly the sort of thing Im interested in cannot be achieved alone by the other two groups.

I believe that most of the posters here are players (or Mudlet developers), with custom scripts generally being written for personal use by a specific player, or for multiple muds rather than just one. I don't know if there are any other mud owners here - but if there are, now is their chance to speak up!

As a mud owner myself I would be more than happy to rewrite parts my mud to integrate with what Mudlet can offer. I have no issue doing that whatsoever, and MSP, MXP, GMCP etc support would be well worth adding irrespective of what client people are using. The difficulty is when as a single individual you are trying to rework the backend, AND write/implement/change the client scripts AND design the actual ui.

Yes, it's awkward. There needs to be some way to retrieve the data from the mud before anyone can use it in their scripts - but how do you know what data to offer if there's nobody telling you what their script needs? It's a bit of a "chicken or the egg" scenario, so I found the best solution was to do both myself.

I know my limitations (im an infrastructure/networks guy more than a professional coder) which was very much the thrust of wondering if there were graphic artists who could spin off a project to design something very modern looking, which then individual muds could rework to their own requirements.

Once I'd released the first version of my GUI, it wasn't long before players started modifying it and even designing their own. One of my players is quite artistic, and he provided me with some extra icons - if you produce something fairly basic to start with, you may well get lucky and find that one or more of your players is able to offer you better graphics.

The idea about the mud instructing the client how to place/update ui elements is an extremely interesting one btw. That sounds like one of those ideas that could snowball into something very very significant indeed especially if those updates can be done live and not just during an initial handshake.

Updating the display on the fly would be easy enough, my concern is more with downloading large amounts of data on the fly (from both a technical and security perspective) - for things like script updates, new graphics, sounds, etc - as well as achieving the right balance between flexibility and complexity (people will want to customise the interface for their game, but the more options they have the more complex the process, until eventually you reach the point where they'd be better off just creating their own custom GUI).

As an aside, I don't think it's a good idea to have one standard graphical theme applied to all muds. Aside from the major technical differences between many muds, giving them all the exact same interface would end up producing a "stock mud" look-and-feel. Thus as well as the option to create and position components, I think a generic GUI should provide a way to download skins for individual games.

Taking a step back for a second, my question would be - is it worth us making a subforum somewhere to focus on UI development, or even separating it from mudlet into an independent discussion.

I don't think there are enough mud developers working on GUIs to make a subforum viable, but if you went this route I'd suggest keeping it separate from the Mudlet forums (because with so few people interested in GUIs anyway, I wouldn't want to exclude development of GUIs for other clients).

[KaVir]

Just one of the other points I'd like to briefly respond to:

The only real solution here would be for the Mud creators to go ahead and provide GUI scripts for various clients, in order to attract customers. But that's difficult, with the different, constantly changing clients out there, so many go the simpler route of just creating a client of their own (Batclient, Nexus, whatever).

A few years ago, sure, if you wanted a customised interface you were pretty much required to create your own client, and that can involve a lot of work, even if you just want basic functionality. But modern clients have progressed considerably, and it's now much simpler just to take something like Mudlet and design your own GUI for it.

I wanted a custom GUI for a long time, but always dismissed it as something outside my area of expertise - I figured it would be a major project, requiring a large investment of time and effort. I've spoken to a number of other mud developers who still hold to that view, but it simply isn't the case, and I think dispelling that myth could really help encourage more muds to take the plunge.

In particular, if I can motivate myself to finish and release my protocols snippet and Mudlet GUI, mud owners should be able to get a fully-functional custom GUI working with no more than a few hours work.

[Vadi]

I hope that effort will pick up. I'll do my part by documenting some strategies for GUI's in the manual.

[KaVir]

I've now got a friend testing my protocol snippet on his own mud, and a couple of other mud owners I know have expressed an interest in using it once it's finalised. I'm also working on an example GUI for Realms of Despair (with their permission), so I'm hoping they'll get in on the action as well.

But more often than not, the responses I'm getting are pretty negative. "If we wanted graphics, we'd play MMORPGs" is a fairly common retort. Or "it won't be a mud any more", or "it gives an unfair advantage against older clients", etc. To quote larnen's original post:

Feeback welcome, but please dont just respond with 'there is more to muds than graphics'. Trust me, I was waving that banner in 1993 when my own one was new, but action bars, non-ascii maps, decent graphical buff displays, party frames etc - all have been in Batclient for years, and every single non mudder I have canvassed has said theyd be 10 times more likely to play using that than anything else they have seen.

I've come to realise that a large number of mud owners are still "waving that banner". The Mudlet developers have added fairly decent graphical support, and a number of players on these forums have put effort into designing Mudlet GUIs for their favourite muds, but many mud owners simply aren't interested (or are even outright opposed to the idea).

I'm sure we're going to see a gradual increase in the use of graphics over the next few years, but I think most of the pressure to add support to muds will come from the players of those muds. The more demand there is from the players, the more likely the muds are to listen.

[Vadi]

Seems like an accurate sentiment. Oh well, to each their own pace.

[tsuujin]

The problem is the old "slippery slope" argument. Hardcore mudders and mud developers do not generally want to see graphics added by anyone but themselves, because they're afraid that the induction of server-side graphics will eventually move the genre away from text and into the world of graphics... and frankly the very reason many people play is because text allows for so much more depth than graphics for many things. I, for one, am a PvPer. I love that a text-based system allows for combat mechanics that are simply impossible when you have to take graphical display into consideration.

While the addition of a HUD may not conflict directly with the notion of text gaming, there will always be a part of the playerbase that is afraid that HUDs will begin the trek into a direction they do not want to go. I, for one, love the idea of a HUD... tailored exactly to my own specifications. So for me sever-side mandatory graphics are hindering. I also fear for what might happen to huge Lusternian style raids when the bandwidth is bogged down by sending graphics to a client even optionally. This is why I'll always be a fan of player made, client side HUDs.

[KaVir]

I agree that mandatory graphics would be a bad idea - not because of bandwidth (you don't send the actual graphics from the mud during play) but for accessability reasons. Many players already have a favourite client and are loath to change. Others are restricted in their use of client, perhaps because they play from work or school, or because they're blind.

The nice thing about adding this support through protocols is that it doesn't force people to use a specific client, or a predefined GUI. You can play through a basic telnet client if you wish, just as you can design your own GUI from scratch if you don't like the official one.

It's really more of a toolset than anything, and any official GUI is just a recommendation. Looks good for promotional screenshots though, and it's definitely nice for newbies.

[tsuujin]

With any GUI, though, you'd have to dedicate a channel to send update information to clients. For every graphical update (changing the value of stat bars, rewriting information to a window, sending widget placement coords) you'd have to tunnel packets to the client somehow. I'd be afraid that in the most extreme situations (fifty person enormous two hour long lusternian raids) you'd increase the packet load enough to see performance lag. Even if only half of the people were configured to receive such information you'd still end up with a lot of overhead.

Trust me when I say that I love the idea of a client sending me graphical "hints". I work it over in my mind and I do believe that there is a ton of potential for the idea to make some badass displays with loads of useful information (That I would no longer have to calculate myself with client-side hack jobs). I just don't see how you could do it and preserve the integrity of certain games. That said, I suppose if you had no intention of combat reaching that scale in your MUD it wouldn't be an issue.