Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > MUD Players and General Discussion > Tavern of the Blue Hand
Click here to Register

Reply
 
Thread Tools
Old 03-07-2011, 08:27 AM   #1
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
The inevitability of GUIs in text-based mudding

I know Newworlds and I have disagreed on this issue in the past, but a recent post brought it to mind again, and I think it'd make a good point of discussion.

Quote:
Originally Posted by Newworlds View Post
This is a bit of a derail, but notice how many people text or twitter now adays. You don't graphically text on your phone nor is twitter a big movie or image plug. Both are hugely text no sound. What are MUDs? Text baby.
Last week one of your players released a few more graphical MUSHclient plugins specifically tailored to your mud. I think we're seeing a gradual shift towards graphical interfaces, much like we did towards ANSI colour many years ago - you can either embrace it or ignore it, but you really can't stop it, because sound and graphics are handled by the client. And mud clients are becoming more and more powerful.

A game is far more than just an interface though, and personally I think that even a hardcore roleplaying mud could benefit greatly from an attractive GUI. If you really want to stress the text-based nature of the game you could design the GUI to look like an open book, with a parchment-coloured background and an old-fashioned font. Perhaps the players could even flick through the pages to view an annotated map, or check their score (designed to look like a traditional pen&paper RPG character sheet), and so on, with all of the OOC information being kept out of the main "page" of what would effectively become an interactive novel.

But I don't think you can escape it. Remember those roleplaying muds that refused to add colour (because "books aren't written in multicoloured text")? Well these days their players just set the colour in the client. It's nothing more than an inconvenience, another hoop for new players to jump through. A decade from now, perhaps players will have the same attitude towards muds that don't offer a GUI.
KaVir is offline   Reply With Quote
Old 03-07-2011, 11:43 AM   #2
Orrin
Member
 
Orrin's Avatar
 
Join Date: Jul 2008
Name: Matt
Posts: 141
Orrin is on a distinguished road
Re: The inevitability of GUIs in text-based mudding

As far as the text vs. graphics debate goes, you can make a distinction between the representation of the virtual world and the interface. A text world doesn't have to have a purely textual interface.

Yes people use text all the time, whether it's twitter or sms or participating in forums and blogs on the web. What they don't do is interact with these applications solely by issuing typed commands and the text as presented isn't usually white on black in a fixed width font.
Orrin is offline   Reply With Quote
Old 03-07-2011, 04:38 PM   #3
RP Kris
New Member
 
Join Date: Mar 2008
Posts: 20
RP Kris is on a distinguished road
Re: The inevitability of GUIs in text-based mudding

I've used some GUI interfaces for MUDs, but I don't prefer them and I certainly don't want to HAVE to use one. I think a GUI can be nice as a supplement experience for players, but that the game itself should stand alone well without using one. There are a couple of groups of players that wouldn't want to use a GUI.

One obvious group is blind players. Blind mudders compose a relatively significant percentage of the mud community at large. Most GUI's aren't going to make the gaming experience easier for them but more difficult.

Another group is those who want to play discretely. Some people MUD because it is a game they can discretely do from a variety of places - home, work, school. The more it looks like a game, the harder it is to conceal.

Beyond the community at large, personally I have no interest in a graphical interface for a MUD. If I wanted a graphical experience I would play a graphical game. Maybe I'm missing something here, but I don't see how it would enhance my experience.
RP Kris is offline   Reply With Quote
Old 03-07-2011, 05:10 PM   #4
plamzi
Senior Member
 
plamzi's Avatar
 
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

Quote:
Originally Posted by KaVir View Post
I think we're seeing a gradual shift towards graphical interfaces, much like we did towards ANSI colour many years ago - you can either embrace it or ignore it, but you really can't stop it, because sound and graphics are handled by the client. And mud clients are becoming more and more powerful.
I agree that MUD clients are evolving, but it seems to me that the evolution is rather slow, due to multiple factors, the most important probably being the vast number of servers most clients aim to support, the multiple protocols many servers do and don't implement, etc.

I also feel that, in many ways, the GUI shift has already happened (as implied by RP Kris's post). I learned from you, KaVir, that DikuMUD inspired and informed the devs of games like Everquest and WoW. The graphical MMORPG's had to shed a lot of complexity and flexibility for the sake of ever-more-detailed eye candy but, as we developers would guess, the server code is probably not that much different from that of a MUD.

I do see the trend you're talking about, but I think it's more of a different approach to GUI's. Let's say full GUI's that support one game server have already been around for quite a while. But GUI's that would support multiple servers of the same (loosely speaking) family, and GUI's that don't severely restrict the ability of the server to add content and features have not been done, or not done well enough yet.

I agree that the trend towards such GUI's is inevitable. But whether such a thing will ever succeed at striking an almost impossible balance and finding a strong player base, that doesn't seem all that inevitable, or even likely.

Quote:
Originally Posted by Orrin View Post
Yes people use text all the time, whether it's twitter or sms or participating in forums and blogs on the web. What they don't do is interact with these applications solely by issuing typed commands and the text as presented isn't usually white on black in a fixed width font.
We should be cautious in assuming that the current fad of twitting and FB posting would benefit text-based games (I wish).

A twit-based RPG game will probably be able to attract a strong following for a while, because millions addicted to twitting would be looking for something to do while waiting for the next twit from a friend. But a MUD would have to make tons of sacrifices to support a simple twit UI, not the least of which is the real-time component. In the end, one is likely to re-invent the browser-based game server, which is basically a snoozefest as far as most mudders are concerned.

Also, one is likely to discover that Twitter is not eternally destined to be fashionable, and all the games riding on top of it may fade just as rapidly as they flourished. Same goes for Facebook apps.

What would undoubtedly benefit MUDs is greater cohesion in the developer community and more commercial projects that can spend on advertising and take stabs at advanced GUI's for feature-rich MUD's (rather than simple MUD servers for 3D engines, which has been done). All other corners of the computer game market have muscle to advertise and attract new generations of players. With MUD's, it's always been a game of hide and seek.
plamzi is offline   Reply With Quote
Old 03-07-2011, 07:55 PM   #5
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

Quote:
Originally Posted by RP Kris View Post
I've used some GUI interfaces for MUDs, but I don't prefer them and I certainly don't want to HAVE to use one. I think a GUI can be nice as a supplement experience for players, but that the game itself should stand alone well without using one. There are a couple of groups of players that wouldn't want to use a GUI.
Sure, but I'm not saying the GUI should be at the expense of gameplay, nor that it should be a requirement for playing the mud.

Quote:
Originally Posted by RP Kris View Post
Beyond the community at large, personally I have no interest in a graphical interface for a MUD. If I wanted a graphical experience I would play a graphical game. Maybe I'm missing something here, but I don't see how it would enhance my experience.
There does seem to be a common misconception that only graphical muds should have graphics. In fact text-based muds have been using graphics for a long time - but initially they were limited by the clients. So their "graphics" consisted of ASCII maps with ANSI colour, VT100 energy bars, dashes and bars (and other ASCII art) for the score layout, and so on.

But clients have progressed a lot since then, and for many players it does enhance the experience to have true graphical maps instead of ASCII ones, to have graphical energy bars, to have buttons and icons, etc.

And while it may not appeal to everyone, what I'm seeing on mud client forums is more and more players designing GUIs for their favourite muds. There is a demand, whether you like it or not.


Quote:
Originally Posted by plamzi View Post
I agree that MUD clients are evolving, but it seems to me that the evolution is rather slow, due to multiple factors, the most important probably being the vast number of servers most clients aim to support, the multiple protocols many servers do and don't implement, etc.
The major clients already support most standard protocols, and allow considerable customisation through scripting. It's the muds that need to catch up.

Quote:
Originally Posted by plamzi View Post
I also feel that, in many ways, the GUI shift has already happened (as implied by RP Kris's post). I learned from you, KaVir, that DikuMUD inspired and informed the devs of games like Everquest and WoW. The graphical MMORPG's had to shed a lot of complexity and flexibility for the sake of ever-more-detailed eye candy but, as we developers would guess, the server code is probably not that much different from that of a MUD.
Agreed, but I'm not suggesting that text-based muds will turn into fully graphical muds. What I'm suggesting is that we'll see more and more people replacing ASCII graphics with proper graphics, replacing their prompts with energy bars and icons, that sort of thing.

Quote:
Originally Posted by plamzi View Post
I do see the trend you're talking about, but I think it's more of a different approach to GUI's. Let's say full GUI's that support one game server have already been around for quite a while. But GUI's that would support multiple servers of the same (loosely speaking) family, and GUI's that don't severely restrict the ability of the server to add content and features have not been done, or not done well enough yet.
Several muds have developed custom clients for their own GUIs over the years. But what we're seeing now are general mud clients like MUSHclient and Mudlet that allow you to quickly and easily design your own GUI through scripting, and IMO this is what's really changing things - because creating your own custom GUI is no longer a major job requiring a specialised skillset. It's now something you can do in a few hours, with just a little scripting knowledge. And we're seeing more and more players getting in on the action.

Quote:
Originally Posted by plamzi View Post
I agree that the trend towards such GUI's is inevitable. But whether such a thing will ever succeed at striking an almost impossible balance and finding a strong player base, that doesn't seem all that inevitable, or even likely.
As I clarified earlier, I'm not suggesting that such a GUI should be a requirement. However it is already an option, because this functionality exists in modern clients and is being used by players. Newworlds has said in the past that he dislikes GUIs, yet his players are still creating them and he can't really do anything about it. The same is true for other muds. You can choose whether or not to ride the wave, but you can't stop it.
KaVir is offline   Reply With Quote
Old 03-07-2011, 11:14 PM   #6
Throttle
Member
 
Join Date: Aug 2007
Posts: 31
Throttle is on a distinguished road
Re: The inevitability of GUIs in text-based mudding

Depending on the extensiveness of the GUI, I think it can turn a game into something other than a MUD. Some of the more modern ones look and play more like online roguelikes, and while the terminology does not specifically state that "text-based" is a requirment, that property is what everyone identifies a MUD by. If a game has an online client on their website that allows you to play their MUD with a more tidy visualization for stats and such, but is still fully playable with no disadvantages on a traditional telnet-based client, I don't think it loses any of its "MUD qualifications". If, however, it must be played through such a client and features things like a graphical playing field, a map, sound effects that are crucial to gameplay or anything of the sort, I think it stops being a MUD. The acronym stopped meaning "online game" once online games with graphics came out, and has meant "text-based game" ever since.
Throttle is offline   Reply With Quote
Old 03-07-2011, 11:32 PM   #7
scandum
Senior Member
 
scandum's Avatar
 
Join Date: Jun 2004
Posts: 309
scandum will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

One important aspect to consider is that a graphical interface is often a tactical interface. A tactical interface gives a player a huge advantage, so the question is not so much if the players use a tactical interface because they really want it, or because they feel forced (or tempted) to use it in order to compete.

I should point out that a skilled scripter can create a powerful tactical interface for any mud, the most obvious, easiest, and (arguably) most advantageous, fully client side tactical interface would be zmud's automapper.

I think MUDs could benefit from non tactical graphical interfaces, though I question the advantage of tactical interfaces as it increases the gap between blind and sighted players.

I think better physics handling and dynamic description generation are areas where MUDs can outperform graphical games, while all the interfaces I've seen are poor imitations of the graphical genre.
scandum is offline   Reply With Quote
Old 03-08-2011, 12:16 AM   #8
Newworlds
Legend
 
Newworlds's Avatar
 
Join Date: Aug 2007
Name: NewWorlds
Home MUD: New Worlds
Posts: 1,384
Newworlds will become famous soon enoughNewworlds will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

Quote:
Originally Posted by KaVir View Post
I know Newworlds and I have disagreed on this issue in the past, but a recent post brought it to mind again, and I think it'd make a good point of discussion.

Last week one of your players released a few more graphical MUSHclient plugins specifically tailored to your mud.
Hey, I'm not even knowlegdeable about that, how'd you know? Spy!? I'm going to have to ban that player.
Quote:
Originally Posted by KaVir View Post
I think we're seeing a gradual shift towards graphical interfaces, much like we did towards ANSI colour many years ago - you can either embrace it or ignore it, but you really can't stop it, because sound and graphics are handled by the client. And mud clients are becoming more and more powerful.

A game is far more than just an interface though, and personally I think that even a hardcore roleplaying mud could benefit greatly from an attractive GUI.
Unfortunately, I will continue to disagree with this. The leaning toward GUI clients and addons and the advent of hybrid MUD/Graphic games is a step away from the beauty that is the book and a vain attempt to become an MMORPS. Why "try" to be runescape, just "be" runescape. It reminds me of people who buy a high end digital camera and try to be a professional photographer just because they have hi res images, but they lack any images that are even close to what a professional can do.

Quote:
Originally Posted by KaVir View Post
But I don't think you can escape it. Remember those roleplaying muds that refused to add colour (because "books aren't written in multicoloured text")?
We still limit color far more than the rainbow effect in 99% of the MUDs nowadays and the reason is simple: it clutters the roleplay feel and intensity.

I used to be a graphic game programmer. I know exactly what the reason for the images, sound, and color are for. I know also what the textual properties of roleplay are for and I still lean back toward the Book and away from the Movie. For NWA nothing has changed.

It is like cheating on the game. Yes, people can use scripts, macros, automapping, image clients, etc. Yes, you can't stop this, but it does pull away from the rp and intensity of the game and in the end these types of players end up quitting for lack of ability to roleplay.

Let me finally say that my position isn't held by and shouldn't be held by all MUDs. We are a genre that is only one niche of many in the MUD universe. If you want graphics, rainbow colors, skype, music, explosive interactive sound, and video feeds, go for it, NWA doesn't.
Newworlds is offline   Reply With Quote
Old 03-08-2011, 02:43 AM   #9
plamzi
Senior Member
 
plamzi's Avatar
 
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

Quote:
Originally Posted by KaVir View Post
But clients have progressed a lot since then, and for many players it does enhance the experience to have true graphical maps instead of ASCII ones, to have graphical energy bars, to have buttons and icons, etc.
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.

Quote:
Originally Posted by KaVir View Post
Several muds have developed custom clients for their own GUIs over the years. But what we're seeing now are general mud clients like MUSHclient and Mudlet that allow you to quickly and easily design your own GUI through scripting, and IMO this is what's really changing things - because creating your own custom GUI is no longer a major job requiring a specialised skillset. It's now something you can do in a few hours, with just a little scripting knowledge. And we're seeing more and more players getting in on the action.
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.

Quote:
Originally Posted by KaVir View Post
The major clients already support most standard protocols, and allow considerable customisation through scripting. It's the muds that need to catch up.
"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.

Quote:
Originally Posted by KaVir View Post
Agreed, but I'm not suggesting that text-based muds will turn into fully graphical muds. What I'm suggesting is that we'll see more and more people replacing ASCII graphics with proper graphics, replacing their prompts with energy bars and icons, that sort of thing.
...
Newworlds has said in the past that he dislikes GUIs, yet his players are still creating them and he can't really do anything about it. The same is true for other muds. You can choose whether or not to ride the wave, but you can't stop it.
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
Old 03-08-2011, 06:31 AM   #10
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

Quote:
Originally Posted by Throttle View Post
Depending on the extensiveness of the GUI, I think it can turn a game into something other than a MUD.
The problem with that argument is that the GUI is handled at the client end. In theory a player could even create a fully graphical interface without the mud owner's knowledge - and in practice, many players are adding graphical elements to their clients.

If one of your players creates an extensive GUI for your game, does that turn it into something other than a mud? What if they do it without your knowledge or permission?

Quote:
Originally Posted by scandum View Post
One important aspect to consider is that a graphical interface is often a tactical interface. A tactical interface gives a player a huge advantage, so the question is not so much if the players use a tactical interface because they really want it, or because they feel forced (or tempted) to use it in order to compete.
But the same argument could be applied to many client features. Aliases, triggers, highlighting, hotkeys, timers, scripting, etc, etc, etc - even things we take for granted such as echo, scrollback, linewrap and ANSI colour can give the player a big advantage. So where do you draw the line? At what point do you say "stop, that's too much of an advantage"? How can you stop players from using powerful clients to improve their playing experience...and would you really want to do that?

Quote:
Originally Posted by Newworlds View Post
Hey, I'm not even knowlegdeable about that, how'd you know? Spy!?
It was posted on the MUSHclient forums. I think it's well worth keeping an eye on the client forums, they can provide you with some valuable insight into the "other half" of our hobby.

Quote:
Originally Posted by Newworlds View Post
Unfortunately, I will continue to disagree with this. The leaning toward GUI clients and addons and the advent of hybrid MUD/Graphic games is a step away from the beauty that is the book and a vain attempt to become an MMORPS.
I disagree with the implication that MMORPGs have some sort of monopoly on graphics - as I've said before, MUDs have been using (ASCII) graphics for a long time. Muds aren't books, but if they were they'd be the sort of fantasy novel that has a big map on the first couple of pages. Can you imagine buying such a novel and seeing that the map had been drawn with ASCII graphics?

As unfair as it may sound, people do judge a book by its cover, just as they judge a mud by its presentation. If you had written a novel, you wouldn't use ASCII artwork for the front cover, would you?

Similarly with your website - you make extensive use of artwork, links, colour, etc. You've put a lot of effort into the presentation, and it makes the website easier to use. Of course you could instead have provided the same information in a single text file, using ASCII artwork, but I suspect the reaction from visitors would be less positive.

Quote:
Originally Posted by plamzi View Post
This is what I meant when I said clients are evolving slowly. 20 years to get to graphical maps and energy bars.
Those were just a couple of examples. MUSHclient offers extensive support for graphics, you could in theory create a fully graphical interface for it using scripts (in fact I've already seen two such GUIs for MUSHclient - one was an isometric view, the other was 3D). Mudlet's graphical support isn't as extensive, but you could still do much the same sort of thing.

Quote:
Originally Posted by plamzi View Post
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.
Initially, yes. But an increasing number of players are starting to distribute their work to other players.

Quote:
Originally Posted by plamzi View Post
"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).
I've found the opposite - they're flexible enough to be used for pretty much anything, you could even create a fully graphical (MMORPG-like) interface driven by existing mud protocols if you wished.

Quote:
Originally Posted by plamzi View Post
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.
That's already possible through existing protocols, you'd just need to write a script for the client.

Quote:
Originally Posted by plamzi View Post
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.
Well there is - thus this thread. However the response from many mud owners tends to be fairly negative, with some (particularly old school) being quite strongly opposed to any sort of non-ASCII graphics. Even the positive responses tend to be lukewarm at best.

So while I believe that we're going to see a gradual shift towards graphical interfaces, I suspect it's going to be driven primarily by players rather than mud owners, with players developing and releasing their own "mods".

Quote:
Originally Posted by plamzi View Post
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.
Clients don't need to "stick" to anything. The use of protocols allows them to cater to all muds while at the same time offering additional features to those that support them. Likewise, the use of scripting allows people to design their own GUIs with whatever features they want, without needing to modify the client itself.

Obviously there are certain limits based on the individual mud, and you can see on the client forums that players frequently struggle when trying to add GUI elements if their mud has no (or poor) protocol support. The majority of GUIs I've seen were for muds with strong protocol support.
KaVir is offline   Reply With Quote
Old 03-08-2011, 12:48 PM   #11
scandum
Senior Member
 
scandum's Avatar
 
Join Date: Jun 2004
Posts: 309
scandum will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

Quote:
Originally Posted by KaVir View Post
But the same argument could be applied to many client features. Aliases, triggers, highlighting, hotkeys, timers, scripting, etc, etc, etc - even things we take for granted such as echo, scrollback, linewrap and ANSI colour can give the player a big advantage. So where do you draw the line? At what point do you say "stop, that's too much of an advantage"? How can you stop players from using powerful clients to improve their playing experience...and would you really want to do that?
Many players will feel compelled to use a client that supports auto mapping. I don't think it improves their playing experience, it only improves their competitiveness, which can avalanche to a degree as seen in IRE muds where players are forced to use complex script, often purchased from other players, in order to win pvp fights.

Which I guess means that if you make combat too complex (typically convergent rather than divergent complexity) players will automate it. Most devs will avoid divergent complexity as they're afraid to lose control over game behavior. So to answer your question, add divergent complexity opposed to convergent complexity. This is typically accomplished by allowing various game elements to interact, rather than having them behave as separate entities with separate interfaces.

Regardless, providing data access through MSDP or GMCP is fairly easy and gives the playerbase something to do. The big question to me is if it's worth spending time building a UI for a text game that could be spend on something else, and I personally don't think so, especially as it's something that can be developed by players. IRE is probably the best example when it comes to encouraging player side client development as they've clearly documented their data interface.
scandum is offline   Reply With Quote
Old 03-08-2011, 12:49 PM   #12
plamzi
Senior Member
 
plamzi's Avatar
 
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

Quote:
Originally Posted by KaVir View Post
I've found the opposite - they're flexible enough to be used for pretty much anything, you could even create a fully graphical (MMORPG-like) interface driven by existing mud protocols if you wished.

That's already possible through existing protocols, you'd just need to write a script for the client.
I'd like to build a 2D MUSHClient GUI for Bedlam. I'd like it to begin by showing a progress indicator of my choice while connecting, set against a splash background of specific dimensions. When connected, I'd like it to fade in two text input fields, labeled Character: and Password:. I'd like it to obscure the password entered in the second field.

Once logged in, I'd like the UI to slide a picture of the entry room in from the left. On top of the picture, in the bottom half of it, I'd like it to load the character's avatar.

When the user double-clicks their avatar, I'd like a rounded-border semi-transparent dialog positioned over the avatar to flash the message "You look at yourself" and I'd like this action to load a horizontally scrollable menu of worn items with specified dimensions and with icons I provide via URLs.

If the player drags and drops an item on themselves from worn menu, I'd like move the item to their inventory menu, creating and showing the inventory menu if it doesn't already exist.

If the player double-clicks an inventory item, and if that item is readable, I'd like to open a parchment dialog (at such and such coordinates) with a title in the font and size I specify and the readable contents of the item.

If the player tripple-clicks on an item, I'd like to open up a different dialog with detailed description of the item. If the item is a wand, and the player drags and drops it on an NPC (in a different menu), I'd like them to use the wand on this exact NPC.

If the spell succeeds, I'd like to overlay an animated gif of a lightning bolt, and if the mob is dead as a result, I'd like them removed from the NPC menu by sliding their icon downward and, while sliding it, replacing it with a small icon of a corpse.

I'd like the script for the above basic interactions to be significantly easier than writing the same thing in javascript using something like jQuery UI (which would get me a web GUI that anyone can use without installing anything).

Is this currently possible?
plamzi is offline   Reply With Quote
Old 03-08-2011, 01:30 PM   #13
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

Many players will feel compelled to use a client that supports auto mapping. I don't think it improves their playing experience, it only improves their competitiveness...

Seriously, I am not too clear on how having something draw a map for me is "worse" than having to have a whole bloody binder full of maps, so I know where the hell I am going. One disadvantage of text is, with the exception of playing a long time, it takes rare talent to "remember" where the hell you are, and not get lost in such a world. Its literally like being the guy my brother talked about, who went around the wrong tree while hunting, and couldn't figure out where he was any more.
shadowfyr is offline   Reply With Quote
Old 03-08-2011, 01:33 PM   #14
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

Quote:
Originally Posted by plamzi View Post
Is this currently possible?
Everything except the two input fields on the login screen. You could perhaps fake it, but better control over the input field is definitely something I'd like to see in a future version of MUSHclient.
KaVir is offline   Reply With Quote
Old 03-08-2011, 02:59 PM   #15
plamzi
Senior Member
 
plamzi's Avatar
 
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

Quote:
Originally Posted by KaVir View Post
Everything except the two input fields on the login screen. You could perhaps fake it, but better control over the input field is definitely something I'd like to see in a future version of MUSHclient.
I went through the list of MUSHClient script functions posted at MUSHclient script functions list. Some things I could not locate:

* draggable / droppable images (only whole windows are draggable, it seems. droppable nowhere to be found)

* click event listener for images, with multi-click detection

* animated transitions/changes (Could not find even fade. I see WindowTransformImage, but I don't see an option to animate image transformations from this to this state, in this amount of time, etc.)

Am I missing something? Or is it that it's possible but not straightforward?

P. S. All of the above are available in jQuery UI.
plamzi is offline   Reply With Quote
Old 03-08-2011, 04:09 PM   #16
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

For drag and drop, and mouseclick events, you need to use hotspots: Miniwindows - Hotspots

For information on animation, see here: MUSHclient : Miniwindows : animation techniques
KaVir is offline   Reply With Quote
Old 03-08-2011, 04:57 PM   #17
plamzi
Senior Member
 
plamzi's Avatar
 
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

Quote:
Originally Posted by KaVir View Post
For drag and drop, and mouseclick events, you need to use hotspots: Miniwindows - Hotspots

For information on animation, see here: MUSHclient : Miniwindows : animation techniques
Gracias. I'll dig in.

Noticed that these documents date back to 2008. Do you know of any MUD UI's that make use of animations and hotspots?
plamzi is offline   Reply With Quote
Old 03-08-2011, 05:41 PM   #18
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: The inevitability of GUIs in text-based mudding

As far as I'm aware, Aardwolf and I are the only muds that offer any sort of official MUSHclient plugin - so far, at least. We both use hotspots, and I have a few animated icons. Other graphical plugins I've seen were either experimental, or private.

I wouldn't suggest trying to duplicate a MMORPG like EQ or WoW using MUSHclient - it's still really a text-based client.

But for people who wish to have a GUI comparable with Archons of Avenshar, BatMUD, Maiden Desmodus, Primordiax, etc, clients like MUSHclient and Mudlet offer a way to very quickly and easily produce a custom interface, while still benefiting from the range of features that mudders expect from a powerful modern client.

Developing your own custom client from scratch is a major project. But creating a custom GUI for MUSHclient or Mudlet is something you can do in a matter of days, and you could have the basics in place in just a few hours. And that's why I feel things are going to change - the entry barrier has dropped so low that anyone who actually wants a custom GUI can now create one extremely quickly.
KaVir is offline   Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 07:16 AM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014