View Single Post
Old 03-08-2011, 01:43 AM   #9
plamzi
Senior Member
 
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
plamzi is on a distinguished road
Re: The inevitability of GUIs in text-based mudding

This is what I meant when I said clients are evolving slowly. 20 years to get to graphical maps and energy bars. I consider such elements to be part of a GUI hub, not the GUI itself. The "I" stands for interface, which suggests two-way communication. These elements merely communicate information one way. I'm sure I'm not the only one who finds these very much undeserving of the GUI moniker.

I'd argue that such features, when buried inside the super-hyper-advanced tabs of MUD clients, tend to affect very few people. Even though mudders are on average more advanced computer users, the majority are not proficient at scripting their client. My guess is that many of these MUD hubs are written by power users for their own use, and are only adopted by a few other souls.

A scenario with more impact is when the game dev bundles a custom hub and goes to some lengths to support it well and make it available for download/use. A good example are the BatMUD and Aardwolf clients, or the custom web UI's provided by some MUDs like the Two Towers and mine. But even the most polished custom UI's currently available are, in my view, "passive" GUI's at best--i. e. info hubs around text windows, allowing for no interaction with any graphical elements.

And even with two ready-to-rock custom clients, one of which is a lot more of a GUI, I find that 99% of my telnet players are just not interested. And it's not because they prefer to write their own MUSHClient hub. It's just that they're used to playing in a certain way, and man is a creature of habit.

"Considerable" is again a matter of perspective. I believe we've touched upon this topic in another thread, but basically I find MUD protocols quite rudimentary in terms of standardizing interaction (as opposed to passive graphics). Advanced MUD clients are likewise focused on drawing hubs, avoiding the great big challenge of interactive graphics.

It is possible to imagine a MUD client which goes a lot further. Let's say that it defines a very abstract UI template, and then lets the server populate different areas with elements. These elements would be conveyed bundled with multiple interaction options, defining not only what happens when the element is clicked (MXP) but also context menus, drag-drop effects, etc. The server can be allowed to specify a remote image to display and replace as needed. There will be options to display info in dialog windows, separate text windows, and other basic UI structures. The GUI may even let the server specify the structure of the UI template. In theory, this would be a 2D MUD GUI fully customizable by altering server output. No such beast exists.

With the above in mind, I think we can just as easily argue that the clients need to catch up, or at least do a better job of compelling attention. If there's such a client out there, offering extreme graphical customizeability, and it documented ways for it to be supported (could be its own protocol, or a protocol extension), it could compel more servers to add support. I'm a server dev, and the current capabilities of Mudlet and MUSHClient leave me cold. Consequently, I have 0 standard protocol support. But if one of these two could render an interactive 2D graphic space the way I tell them, I'd definitely consider implementing whatever protocols it asks of me.

The topic "The inevitability of GUIs in text-based mudding" got me to thinking of something a lot more graphical and interactive than a text window surrounded by energy bars, a minimap, and a smattering of icons. If clients unambitiously stick to what is universal across most MUD server and easy to visualize on the client side, then the wave you're describing will (sadly) all take place in a teacup.
plamzi is offline   Reply With Quote