03 Sep, 2013, donky wrote in the 1st comment:
Votes: 0
This isn't about Epitaph, it's more about whether it's practical to take things to a more user friendly level.

I've been playing on Epitaph and one thing that struck me is how much "guess the verb" I play. I logged in, and got a message about the light from my torch waning, which was reasonable given that I left the batteries in. So I tried "turn flashlight off". Is this the right verb? "help turn" gives me information relating to directional facing. "help flashlight" tells me that it is a weapon. How do I know what verbs I have available for a given object?

Epitaph being based off the Discworld mudlib provides a "syntax" command, so I can go "syntax turn" to see how it can be used. And in fact, this is what every command used with incorrect syntax ends up informing the player. But I find it grueling. When I get a command wrong, surely there can be an easier way than forcing me to read a manual that doesn't always help.

Take for example the non-gameplay command bug. When a runtime exception happens when I use a command, I get a message saying use the bug command. So I do "bug when I try and 'some command' I got a runtime error" and get "USE 'syntax bug'" as a response. I understand that there's a system in which developers desire a player use to report bugs, where they specify which entity they are referring to, and the related object and it's code can be linked in. But the onus here is on the player, where perhaps there's a way to remove the cumbersome struggle to not just "guess the verb" but "guess the verb's arguments".

Some MUD-Dev mailing list posts referred to a set of interactive fiction games that had more intuitive and less cumbersome commands. "take the pen" might get the response "There are two pens here, a red and a blue one. Which pen?", and then the player could simply type "red" at the normal command prompt that followed and the red pen would be taken. And similarly, should a command result in a yes or no based output, then they could type "yes" or "no" and it would refer to the last command they did. I think that this is something worth looking at further.

In the base of the "bug" command, what should have happened? Perhaps I should get a message informing me that the bug command associates my message with the thing that caused the bug, and could I choose whether I am referring to a command, object, npc.. But really you could just give them a prompt and get them to enter a keyword, and then it could locate anything in all the known systems that match that keyword and just give a small multi-choice menu. "> bug unparseable text" -> "Were you using a command or an object or something else? Type it's name: " -> "… Type it's name: bug" -> "There are two possible matches, please select the one you are referring to: a) command: bug b) room object: cockroach …" -> "choice: a".

I think that's a big improvement, perhaps not as an exact approach, but as a direction. But then writing it, I pictured doing so using the interactive fiction method further above. To write the name of a command at the normal command prompt, rather than a custom one which isolates whatever is entered to whatever is wanting the input, is ambiguous. No idea of the best way to fix that. And additionally, there really isn't that much difference between the prompt-less and prompted input of additional information. In theory, you could switch between modes.
03 Sep, 2013, quixadhal wrote in the 2nd comment:
Votes: 0
This is what gave rise to the "verb" system, used in Nightmare based mudlibs, and used exclusively in the Lima mudlib.

With the verb system, you don't define add_action()'s on every object. Instead, you give every object a set of functions which the verb system calls to determine if a given verb can be applied to it. Typically, can_foo() and do_foo().

How's that different? It shifts the decision of what verbs apply to what objects up a level. Using add_action(), you might make a doorknob object and then make it so you can "turn doorknob". A different builder might make a doorknob but use "twist doorknob". Without a QA staff to verify that all doorknobs in the game are conssitent, it becomes annoying for the players to figure out what things respond to what verbs.

The verb system creates a verb which can have many aliases. So, perhaps you coded the "turn" verb, and then added "twist" as an alias to it (inside the verb system, not via player or client aliases). ALL objects that can be used that way are coded to have can_turn() and do_turn() functions. Now, the two different builders write their doorknobs, and they both respond to either "turn" or "twist" or even "rotate" and maybe "use"… because all those aliases in the verb parser call the can_turn() function.

That, of course, only addresses part of your question/complaint. Target ambiguity is another layer, as is context-aware usage messages. Part of the problem with comparing a MUD to an infocom game is that an infocom game is a single player system, developed with a langauge that was custom-built for the purpose (Z-machine code).

For a MUD to do something like:

> cast 'fireball' troll

Which troll, the green troll or the big blue troll?

> green

You cast a fireball at the green troll.

For that to happen, you need to have state information preserved between your command and the actual execution of the command. It can be done (LPMUD allows input_to()), but you also have to deal with players that will want to retype the whole command instead of answering the question, or just ignore it and move on to do something else.

In short, you need ALL your builders to be careful so any input that ends up in their input_to() catch function is analyzed… if it's a valid command that isn't a response, it needs to be redirected again to the normal parser, whereas if it's an invalid response, a help message needs to be shown and loop back to the local input_to().
03 Sep, 2013, donky wrote in the 3rd comment:
Votes: 0
I've used the MudOS parser, which I would expect Nightmare and Lima to be similar to, if not based on. I believe there is still the problem you can't go, show me all the verbs which can work on this object, so that I can try them.

I don't think you'd have to worry about input_to, with regard to where answers to the last failed command could be typed. You could have your general command system take care of it, first working out whether it's a valid command via can_foo() and secondly working out if it is an acceptable answer to the last failed command. I imagine if both could be polled for suitability without side effects, to determine if it is possibly ambiguous, you could ask for further clarification. Replace all calls to input_to, with a similar function that either prompts or takes input from the command system, and it should be achievable. The least easiest part of this, I think, would be dealing with the ambiguity handling if the systems did not support polling possible places the input could go.
03 Sep, 2013, quixadhal wrote in the 4th comment:
Votes: 0
It's a problem of state preservation, donky.

If I type "hit troll", the hit command has to disambiguate the target to know which troll I should try to perform the hit against. If there are multiple matches, you can either (a) attack the first one, (b) attack ALL of them, or © ask for confirmation of which target you meant.

Most MUDs do (a). Infocom games did ©.

To do ©, you have to preserve state between commands, because if you THEN type "the green troll", how does the command system know that's a response to a message from hit? Since no state got preserved between commands, it can't.

So, you have to somehow preserve that state info. You could do it via input_to(). You could also kludge some player variables that the command system would have to check for every single command typed. Even worse, you could kludge some state variable mapping into the command system itself.
03 Sep, 2013, Nathan wrote in the 5th comment:
Votes: 0
I think Epitaph is a good example (I've played it a little bit recently). Frankly there's a sort of related issue about how you construct item names. If you have a bunch of items that are all the same kind of thing (boots, swords, you name it) and then all these variants on it like color and kind, it starts to become a little unclear how to ensure that you are indicating the right one when using sell/take/etc. Personally, with respect to Epitaph I've had a little luck just sticking to the color/kind and then the type (ex 'boots'), but it takes a certain leap of understanding.

Example:
purple boots
yellow boots
yellow combat boots
purple combat boots
shiny purple cowboy boots
shiny cowboy boots.

When it's just two and you don't have duplicate items it's not as bad, but suppose with the above set, one types 'combat boots' or 'boots'. Which one do you get? The first one found? Typing out the whole thing might be okay if you're selling junk, but it gets a little crazy. Further, what if you have two pairs of the same thing, how on earth can you be sure to sell the more damaged pair (if your game records wear)?

This sort of falls under syntax and ordering of descriptors.



I think the obvious "answer" to syntax is to be as intuitive/easy to guess as possible, so for a command like 'get' you stick to syntax such as:

1) get <x>
2) get <x> <y>
3) get <x> from <y>

The last one is tedious, so some games support #2, which makes sense and of course #1 is the ordinary version. Commands should follow logical thought. Any idea of a case that doesn't follow this?

Other than that, there is the necessity of either sticking to a limited set of verbs or aliasing all logical verbs/syntax to the same "action", so long as the verbs are identical or nearly so. So, 'take', 'get', and maybe 'retrieve' should be equally viable and use the same syntax unless there's a good reason not to. On the other hand, you should never mix commands like 'wear' and 'wield' since they usually refer to clothing/items and weapons respectively.
03 Sep, 2013, plamzi wrote in the 6th comment:
Votes: 0
donky said:
I've been playing on Epitaph and one thing that struck me is how much "guess the verb" I play. I logged in, and got a message about the light from my torch waning, which was reasonable given that I left the batteries in. So I tried "turn flashlight off". Is this the right verb? "help turn" gives me information relating to directional facing. "help flashlight" tells me that it is a weapon. How do I know what verbs I have available for a given object?


Easiest solution:
"The light from your torch is waning. Maybe you should 'recharge 2.torch'."

Many solutions to the problem in general (if you think beyond the simple terminal window):

a. One line: "The light from your torch is waning: <a href="send('recharge 2.torch')">Recharge</a>."
b. Modal dialog: "The light from your torch is waning:<br> Recharge <br> Discard"
c: A picture of your torch in an inventory window has its battery picture waning. You get the bright idea that you can drag and drop a new battery on top of it.

I'm sure I'll catch hell for suggesting that some of the solutions don't require people to type or know any command syntax at all. I mean, isn't being a real MUD synonymous with puzzling newbies and making them research your command syntax structure before they can do even the simplest things?
03 Sep, 2013, Nathan wrote in the 7th comment:
Votes: 0
plamzi said:
donky said:
I've been playing on Epitaph and one thing that struck me is how much "guess the verb" I play. I logged in, and got a message about the light from my torch waning, which was reasonable given that I left the batteries in. So I tried "turn flashlight off". Is this the right verb? "help turn" gives me information relating to directional facing. "help flashlight" tells me that it is a weapon. How do I know what verbs I have available for a given object?


Easiest solution:
"The light from your torch is waning. Maybe you should 'recharge 2.torch'."

Many solutions to the problem in general (if you think beyond the simple terminal window):

a. One line: "The light from your torch is waning: <a href="send('recharge 2.torch')">Recharge</a>."
b. Modal dialog: "The light from your torch is waning:<br> Recharge <br> Discard"
c: A picture of your torch in an inventory window has its battery picture waning. You get the bright idea that you can drag and drop a new battery on top of it.

I'm sure I'll catch hell for suggesting that some of the solutions don't require people to type or know any command syntax at all. I mean, isn't being a real MUD synonymous with puzzling newbies and making them research your command syntax structure before they can do even the simplest things?


Typing 'help flashlight' really ought to explain how the flashlight works, unless it's meant to be a vast cosmic mystery. A better syntax than 'put <specific battery> in <specific flashlight>' would be good though. Since most muds still use text, it's worth talking about this issue. Once the game starts involving that point and click mechanism it starts to feel more like interactive fiction than a MUD, really. Doesn't make it so, but that's the way it feels. A very good question is how you know which torch is 2.torch. It's good that the computer knows, but you have to know too.

Not sure what it should be, but really context should be used to simplify this somehow. An abbreviated form of replacing the battery should always handle the one you're using.

What's really wonky about Epitaph, in my estimation, is that it is sufficient for the flashlight to be on and in your possession to have light. It seemed like you didn't even have to hold it which is immersion breaking in my mind.
03 Sep, 2013, plamzi wrote in the 8th comment:
Votes: 0
Nathan said:
Typing 'help flashlight' really ought to explain how the flashlight works, unless it's meant to be a vast cosmic mystery.


And what should the user type to find out how the help command works? What should they type to find out how and where to type commands?

Nathan said:
A very good question is how you know which torch is 2.torch. It's good that the computer knows, but you have to know too.


An even better question is, why should the user ever have to know (or care) which torch is which when the client and server can easily decide that between themselves with 0 chance of error. Raise your hands everyone here who thinks figuring out the right handle for objects is big fun.
03 Sep, 2013, Idealiad wrote in the 9th comment:
Votes: 0
I don't disagree that context-sensitive help, using MXP or even something like this is far preferable to guess-the-syntax. However the reality is that many mud players come in on their preferred client. If you want to hook them onto yourpreferred client do you want to have a confusing interface for their first few hours of play?
03 Sep, 2013, plamzi wrote in the 10th comment:
Votes: 0
Idealiad said:
I don't disagree that context-sensitive help, using MXP or even something like this is far preferable to guess-the-syntax. However the reality is that many mud players come in on their preferred client. If you want to hook them onto yourpreferred client do you want to have a confusing interface for their first few hours of play?


If you've built a confusing interface, I agree, you shouldn't force anyone to use it :)

The larger point here is you can provide visual cues (even in plain text) that would help someone you know may be a new player learn the ropes without having to read a help file.

On the general topic of "reality", if you're building a game that only targets veteran MUD players with preferred clients and preferred games, I'm not sure that any amount of visual aid would be enough. They can disqualify your game for any one of a million reasons, most of which are beyond your control.
03 Sep, 2013, Nathan wrote in the 11th comment:
Votes: 0
plamzi said:
Nathan said:
Typing 'help flashlight' really ought to explain how the flashlight works, unless it's meant to be a vast cosmic mystery.


And what should the user type to find out how the help command works? What should they type to find out how and where to type commands?

Nathan said:
A very good question is how you know which torch is 2.torch. It's good that the computer knows, but you have to know too.


An even better question is, why should the user ever have to know (or care) which torch is which when the client and server can easily decide that between themselves with 0 chance of error. Raise your hands everyone here who thinks figuring out the right handle for objects is big fun.


I think that help commands should be fairly universal, in the sense that you can get help on a command or on a topic. That way, there is no confusion. It is certainly possibly, and even likely that this will not always be the case. Some things are always going to take some initial figuring out, though. I'm just saying that if I can replace the flashlight batteries separately, I want to replace the one I meant to on the first try. I don't particularly enjoy having to figure out the right handle. Why don't you explain what you mean more thoroughly?
03 Sep, 2013, plamzi wrote in the 12th comment:
Votes: 0
Nathan said:
plamzi said:
Nathan said:
Typing 'help flashlight' really ought to explain how the flashlight works, unless it's meant to be a vast cosmic mystery.


And what should the user type to find out how the help command works? What should they type to find out how and where to type commands?

Nathan said:
A very good question is how you know which torch is 2.torch. It's good that the computer knows, but you have to know too.


An even better question is, why should the user ever have to know (or care) which torch is which when the client and server can easily decide that between themselves with 0 chance of error. Raise your hands everyone here who thinks figuring out the right handle for objects is big fun.


I think that help commands should be fairly universal, in the sense that you can get help on a command or on a topic. That way, there is no confusion… I don't particularly enjoy having to figure out the right handle. Why don't you explain what you mean more thoroughly?


I was just thinking that assuming a new player knows to type "help flashlight" in a text input field seems to disqualify the entire population of this planet except for, optimistically, 40-50,000 people.
03 Sep, 2013, donky wrote in the 13th comment:
Votes: 0
quixadhal said:
It's a problem of state preservation, donky.

If I type "hit troll", the hit command has to disambiguate the target to know which troll I should try to perform the hit against. If there are multiple matches, you can either (a) attack the first one, (b) attack ALL of them, or © ask for confirmation of which target you meant.

Most MUDs do (a). Infocom games did ©.

To do ©, you have to preserve state between commands, because if you THEN type "the green troll", how does the command system know that's a response to a message from hit? Since no state got preserved between commands, it can't.

I agree that the solution in general has to be state preservation. But this particular problem you highlight is not one I wanted to focus on. I'm more interested in the general concept of how a player can more easily know what they can do, and how they can do it with minimal complication. Like being able to ask what commands can be used to suit a given situation, or c) being usable to reduce typing in correction of choices unclear to the game.

quixadhal said:
So, you have to somehow preserve that state info. You could do it via input_to(). You could also kludge some player variables that the command system would have to check for every single command typed. Even worse, you could kludge some state variable mapping into the command system itself.

In your code base as it stands, you may have to kludge it in. But I think it's fair to say a code base could be cleanly refactored to fit it in as a natural concept.
03 Sep, 2013, donky wrote in the 14th comment:
Votes: 0
plamzi said:
donky said:
I've been playing on Epitaph and one thing that struck me is how much "guess the verb" I play. I logged in, and got a message about the light from my torch waning, which was reasonable given that I left the batteries in. So I tried "turn flashlight off". Is this the right verb? "help turn" gives me information relating to directional facing. "help flashlight" tells me that it is a weapon. How do I know what verbs I have available for a given object?


Easiest solution:
"The light from your torch is waning. Maybe you should 'recharge 2.torch'."

This is a good solution in the case where there is one obvious action that should be taken. But there isn't just one obvious action. I'm leaning towards all messages including context, and being linked into the a hint system like Epitaph has.

Quote
The light from your torch is waning.
> hint torch
hint: Do you want help with general commands, or the immediate problem of your batteries getting low?
> batteries
hint: Do you want to replace the batteries, or turn the torch off?
> off
hint: try "turn torch off" or "switch torch off"
> hint torch
hint: Do you want help with general commands, or the immediate problem of your batteries getting low?
> commands
1) turn torch on
2) turn torch off
3) take batteries [from] torch
4) put batteries [in] torch
5) swap torch batteries
> 5
executing command: swap torch batteries
You take the dead batteries from the torch.
You put live batteries in the torch.


I'm not against graphical approaches, like your image-based solution, but like others it's hard enough to make a MUD let alone make graphics. Discussing the graphical approach is not something I am willing to do in this particular topic.

plamzi said:
I mean, isn't being a real MUD synonymous with puzzling newbies and making them research your command syntax structure before they can do even the simplest things?

Yes and no. It's that way for a reason, and I don't think it's that way intentionally. If the code bases came with a better approach, one that was proven, then I suspect it would be less of a problem.
03 Sep, 2013, plamzi wrote in the 15th comment:
Votes: 0
donky said:
In your code base as it stands, you may have to kludge it in. But I think it's fair to say a code base could be cleanly refactored to fit it in as a natural concept.


Most of the challenges of state preservation do not stem from the fact that a certain codebase was not written with that in mind. They stem from the fact that a MUD is a (usually) real-time, always multiplayer game. Interactive fiction is not. This makes things infinitely simpler. A question is posed and user input is required to proceed. There is only one state at any given time.

Also, are you sure that the problem you described in your OP is not specific to young and/or underdeveloped MUDs? The ones I've seen lately do a pretty decent job of cluing a new player into what to type next. Of course, they all assume prior mudding experience, but still, a decent job.
03 Sep, 2013, donky wrote in the 16th comment:
Votes: 0
Nathan said:
What's really wonky about Epitaph, in my estimation, is that it is sufficient for the flashlight to be on and in your possession to have light. It seemed like you didn't even have to hold it which is immersion breaking in my mind.

I disagree. I get tired of holding cameras, let alone flashlights. If I can prop it out of my hands into the strap of my backpack or tie it to my headband, then that's a solution I can't expect Epitaph to model. Instead I can associate carrying the torch in general, as doing that, rather than carrying it in my hands simply because that's all the model gives me.
03 Sep, 2013, donky wrote in the 17th comment:
Votes: 0
plamzi said:
donky said:
In your code base as it stands, you may have to kludge it in. But I think it's fair to say a code base could be cleanly refactored to fit it in as a natural concept.


Most of the challenges of state preservation do not stem from the fact that a certain codebase was not written with that in mind. They stem from the fact that a MUD is a (usually) real-time, always multiplayer game. Interactive fiction is not. This makes things infinitely simpler. A question is posed and user input is required to proceed. There is only one state at any given time.

I disagree. Give an example situation if you can, but to me the implementation is the hard part, it should be an uncomplicated experience whether multi- or single-player.

plamzi said:
Also, are you sure that the problem you described in your OP is not specific to young and/or underdeveloped MUDs? The ones I've seen lately do a pretty decent job of cluing a new player into what to type next. Of course, they all assume prior mudding experience, but still, a decent job.

Give me the link to one, and I'll see how much better it is. You might be right. In Epitaph's case it has pretty much the same command system as Discworld, and MUDs don't get much older than that.
04 Sep, 2013, plamzi wrote in the 18th comment:
Votes: 0
donky said:
plamzi said:
donky said:
In your code base as it stands, you may have to kludge it in. But I think it's fair to say a code base could be cleanly refactored to fit it in as a natural concept.


Most of the challenges of state preservation do not stem from the fact that a certain codebase was not written with that in mind. They stem from the fact that a MUD is a (usually) real-time, always multiplayer game.

I disagree. Give an example situation if you can, but to me the implementation is the hard part, it should be an uncomplicated experience whether multi- or single-player.


I'm a bit worried that you're having trouble coming up with examples. Here's one:

The light from your torch is waning.

Benjamin walks in from the north.

With a series of deft maneuvers, Benjamin makes you drop your torch.

Benjamin drops a torch.

A great earthworm rises from the ground and consumes a torch.

You have been given a torch by Benjamin.

> hint torch

hint: Do you want help with general commands, or the immediate problem of your torch that was low on batteries, got punched out of you by Benjamin, dropped on the ground, and devoured by an earthworm? Or the other torch he gave you which doesn't have the low battery problem but otherwise is exactly the same as the one you lost?


donky said:
Give me the link to one, and I'll see how much better it is.


You can try some of the games that people recently listed on the MUD portal that have good MXP support. SlothMUD, for example.
04 Sep, 2013, Tyche wrote in the 19th comment:
Votes: 0
Is Benjamin an NPC in a single player game?
04 Sep, 2013, Nathan wrote in the 20th comment:
Votes: 0
donky said:
Nathan said:
What's really wonky about Epitaph, in my estimation, is that it is sufficient for the flashlight to be on and in your possession to have light. It seemed like you didn't even have to hold it which is immersion breaking in my mind.

I disagree. I get tired of holding cameras, let alone flashlights. If I can prop it out of my hands into the strap of my backpack or tie it to my headband, then that's a solution I can't expect Epitaph to model. Instead I can associate carrying the torch in general, as doing that, rather than carrying it in my hands simply because that's all the model gives me.


I can sympathize with that, but in this case I find the lack of reality jarring. I'd rather have an additional way of things being attached (maybe a general one), personally. It's also a bit easier to tell that it's still on, short of being in a dark area when you're holding it, I think. I seem to recall that when you look at your inventory, the flashlight (if you're holding it) has a state message attached about whether it's on or off.

It would be handy if it would turn itself on/off when you walked back and forth between light and dark or just turned off in the dark->light transition if having it on becomes a danger somewhere elsewhere in the world. Manually flicking it on/off is very annoying – and way TOO realistic at some level. Especially since the game seems to hint that the area outside the central streets where you start is more dangerous (I haven't gone farther than a street or two from the Winchester most of the time.
0.0/44