23 Jun, 2010, KaVir wrote in the 1st comment:
Votes: 0
Idealiad said:
MD is a very good game oriented around players doing things, with unfortunately not enough players IMO.

I tried out the Primordiax client and was kind of disappointed. They went through all the trouble of making a Flash client but then the actual text window they drop you into looks like barebones telnet. I didn't see a way to customize things either, but I wasn't too interested in the game within the first few minutes, so admittedly I didn't give it much time to find out if customization of the appearance was possible.

There have been browser-based telnet clients for years, and I feel that it's not enough to simply put telnet in your browser anymore. The text styling and how you interact with it should be better than straight telnet if you're going to go to the trouble, IMO.

/rant.

I've been thinking about ways to improve my MUSHclient plugin, in particular the use of buttons (waring with my fear of getting carried away and making the interface overly complex). It brought to mind comments by some of my players about how MXP allowed them to play most of the newbie phase with just their mouse. And that brought to mind the above quoted text, which raised the question…

At what point does a text-based game become a graphical game, or even a hybrid game?

The answer is obviously subjective. But with MXP and buttons you could very reasonably create a graphical interface that made a mud fully playable without the keyboard - you'd still need the keyboard for communication of course, but it would be possible to play purely with your mouse.

For me, personally, this is a very important distinction. When I think of a "text-based game" I don't just think about the output (pretty pictures, bars, maps, etc), but also the input. Imagine a game that had a graphical display exactly like WoW or EQ - except you couldn't use your mouse. Instead, there was a command line at the bottom of the screen, and you had to type in every command. I know this is fairly common for some options (such as communication, emotes, etc), but I think it would feel pretty wierd to use it for all commands, and (for me at least) it would give the game something of a text-based feel.

The problem is that muds tend to have a very large command set, and creating hundreds of buttons is probably not desirable. But if you were talking about a hybrid game - a game designed to be played with either text or graphics - I think you could do it by giving the graphical interface a more simplified set of options.

I know the Maiden Desmodus client has buttons and supports MXP, but I don't know if it takes it this far, and it's only available for one mud. It's an interesting example to talk about, but it's not something that other muds can use. A plugin, however, could be used for any mud that supported the necessary protocols - and it could be created with (relatively) little effort.

Who else is interested in pushing their muds in this direction? Not necessarily replacing the text interface, but designing and developing an alternative graphical interface, so that players can choose between them.
23 Jun, 2010, Kaz wrote in the 2nd comment:
Votes: 0
I've been looking into this sort of thing a lot over the years. I'm still working on the details. But I did notice just recently that a number of normal terminal clients (e.g. xterm, PuTTY) do have bits of the protocol in place that will send you the location of mouse clicks. I have no idea if your standard mud client does this, however. I doubt it's the most commonly requested feature.
23 Jun, 2010, 3squire wrote in the 3rd comment:
Votes: 0
Well, one problem that you find in designing graphical elements for text games is that text games are oriented toward exchanging information via text. Creating input commands via buttons is of course a simple matter, but getting data out of a mud and making it interoperable through a client is a challenge that is unique. For instance, MUDs have the massive benefit of requiring the player to query the map for position location, unlike a 3D game for instance which is sending positional tokens to the client every second. The investment in a text-agnostic client is such that it is more feasible (in my opinion) to drop Telnet support altogether and let the client deal with the output. (Or, alternatively, to make two completely distinct modes that can intercommunicate, but are not employing the same data pipeline)

Of course, if clients even used a simple markup language like HTML for streaming output, it would be possible to send updates that could still be parsed like Telnet, and the game could still be played like telnet or could be seamlessly upgraded to a graphical experience, but again, the game is then built for the graphics and "downgradeable" to Telnet, not vice-versa, which means your going to a lot of effort if 80% of players are not going to bother with obtaining the benefits associated with the graphics.
23 Jun, 2010, Orrin wrote in the 4th comment:
Votes: 0
If you look back at the earlier graphical MMOs (original UO sticks in my mind for this) they made much greater use of text commands than WoW and more recent games tend to do. I guess this was a throwback to their MUD roots and it's interesting to see how GUIs have evolved.

I think there's a lot you can do to make things easier on the input side just by using MXP on the server. While far from perfect, MXP is supported by the two biggest clients so it's a solid choice if you want to make it accessible to your players. Input buttons should be relatively easy to do using plugins and again mushclient and z/cmud have their own systems to do this. I've seen examples for individual games, but I'm not aware of any kind of generic community efforts in this regard. I wonder if it's something codebase maintainers would be interested in doing; I could imagine a smaug plugin for mushclient for example with buttons for commonly used commands as well as a map window, energy bars etc.

One thing I had to put in on our server was a targeting system so that you could use a button which was just <verb> to replace the typed command of <verb> <target>. This was easy enough and works well with MXP so you can click a mob to target them and then click a button to perform some action.
23 Jun, 2010, KaVir wrote in the 5th comment:
Votes: 0
3squire said:
Well, one problem that you find in designing graphical elements for text games is that text games are oriented toward exchanging information via text. Creating input commands via buttons is of course a simple matter, but getting data out of a mud and making it interoperable through a client is a challenge that is unique.

It's actually pretty easy to get the data if your client supports an appropriate protocol, the question is really how far you're willing to take it. I already use MUSHclient to display energy bars and maps, so you can watch monsters and other players moving around in real time, but there are still some things I would prefer to show in text - such as combat messages.

However I think it would be viable to have an interface that made it possible to play purely with a mouse, perhaps even without the need to read the text window at all. In this way you could choose any combination of mouse and keyboard for input, and any combination of text and graphics for output.

That, in my mind, would be a true "hybrid" text/graphical game.

Orrin said:
I think there's a lot you can do to make things easier on the input side just by using MXP on the server. While far from perfect, MXP is supported by the two biggest clients so it's a solid choice if you want to make it accessible to your players.

Yeah it's pretty nice - it's already used by more than half of my active players.

Orrin said:
One thing I had to put in on our server was a targeting system so that you could use a button which was just <verb> to replace the typed command of <verb> <target>. This was easy enough and works well with MXP so you can click a mob to target them and then click a button to perform some action.

I already support the targeting part, I just don't have any buttons yet ;) I know one of my players has added buttons to his own plugin though, and it's something I'm likely to do in the near future.
23 Jun, 2010, David Haley wrote in the 6th comment:
Votes: 0
Quote
The problem is that muds tend to have a very large command set, and creating hundreds of buttons is probably not desirable.

Well, more information is available contextually with graphics, and you can create commands by stringing together several sub-commands (which might not be explicit clicks on buttons, but dragging from here to there, or whatever). So you wouldn't necessarily need hundreds of buttons to reproduce a large command set.

Furthermore, many MUD commands are about getting information; a lot of those become superfluous when the information is displayed right in front of you.
23 Jun, 2010, Zadious wrote in the 7th comment:
Votes: 0
This may be irrelevant to the discussion as most of your seem to be speaking of protocols. Reading this thread did however remind me of how Dutch-Pipe works.

http://dutchpipe.org/dpclient.php?locati...

You can click certain areas of the picture to take you n,s,e,w, and you can click on objects and a small menu with commands will appear allowing you to manipulate certain objects. Try clicking on the shop or the bar door and then clicking on the shopkeeper/barkeeper and you will get a small menu with available options/interactions.

As I said, this may be irrelevant as half of this discussion is still outside my comprehension but I thought sharing might spark an idea.
*shrugs*
0.0/7