Yes, and besides that, you have a point about the extent of possible context Plamzi. But then the hint system could allow the player to select a message, and it might limit the aid shown to that which is related to the specific context of the given message. It's never going to be perfect, but it's surely going to have a lot more promise than what you painted in a previous post:

I agree. And to me, having Maestro say: "You've just entered a room where your torch isn't needed. Do you want it to be automatically turned on and off as necessary to save battery? Do options auto_torch_use = on" or whatever seems like a good way to go. But there's no reason that the lack of this, at this time, can't be simply because Epitaph is still polishing in it's post release phase. Suggest it to Drakkos or whoever.

Hmm, a help system that's better than my sarcastic description is a very low bar to set. The question is, would it be better than some very real solutions already out there.

You say you don't want to discuss graphics, but even graphics may be a smaller time & value investment than a system that attempts to keep track of state in a game where multiple actors can change the state of an object.

Adding clickable elements is much easier, and has the enormous advantage that pretty much everyone knows how to click on a link, while in your case you'd still have to figure out how to convey to people that they can type 'hint torch'. It would be a bit paradoxical to ask them to research the "hint" command in order to not have to research commands.

It's not that bad. The worst case scenario is just tracking the *current* state, for example

>k something
"Who do you want to kill? [dog, man, pig]"

player thinks for a long time, and before he puts in a command the pig was already butchered by the man.

>pig
He types "pig" and then the game simply says "The pig is already dead."

It also doesn't have to account for the changing state beyond querying it that way. For example, it's good enough that your system wouldn't allow this to happen:

>k something
"Who do you want to kill? [man, pig]" And then a rabbit hops into the room.
>rabbit
"Do what to the rabbit? [look, kill, whatever]"

The state didn't have to update the command parser as it was changed. It simply responded to what it knew and what it didn't know since the last query.

Anyways, I implemented something similar to this in CoralMud along with context based error messages that are fully generated based on type of the parameters and the various ways to use it, vs what the player tried to do. I think it was very worth it as I added more and more commands.

I think we're talking past each other. You propose what seems to me like solutions that don't even solve a small subset of the problems, then dismiss my solution with imagined problems that don't exist.

Clickable links and graphics are solutions, and good ones. But they do not in any way solve the things I'd like solved. You can't put a clickable link for every action the player might want to do, and just putting links for the ones you think they'll want to do merely leaves them as confused as before if their action is not linked. To have links that do more, and are flexible enough to solve the problem, you need that same context the theoretical hint command would use. Similarly, you can't display a graphic for every action or whatever the player might want. It's exactly the same level of unsuitable solution, but I expect alongside the text window rather than within it.

How do players find out about the hint command? The tutorial mode already tells them - them learning to use it is a non-issue. Go onto Epitaph and experience it if you need concrete proof. And I imagine that Kavir's MUD and it's tutorial mode which I've never tried has to do the same thing, slowly introduce core useful commands. It's a non problem.

I'm still yet to discern past a more noisy environment, how the IF style parser would be unusable in a multiplayer game compared to the singleplayer IF case.

Let me reframe: If you know that you can do something with an object, but don't know how to do it, and it's not linked in any text you've seen or specifically covered by a graphic, what are your options given what I've already addressed in previous posts? It's not what the text you've seen (perhaps about the torch) suggests and links, but something else you know is possible and more suited to what _you_ want to do that validly addresses whatever is at hand.

Since Epitaph has been the centre of some of this, I'll outline my views on it. I know the topic is about a larger issue, but it's only the Epitaph perspective I'm going to address here because I am a very self obsessed man. :-P

Some of the issues outlined are simply down to familiarity. Some are down to preference. Some are down to rough edges in a game that is not *underdeveloped* as such but rather under*exposed*. Issues like these are cracks in a sidewalk - you only find out the cracks are there if people are walking the routes. The route I take is fine, I only know about your problems when I'm told about them. Those kind of issues will gradually be smoothed away over time - we've already got five patches down that have gone a way towards that, and this time next week/month/year more patches will have knocked off more of the edges, and likely added more in the process. The players we have now are helping with that to a remarkable extent, in a way that would have been impossible without their perspectives. You can alpha/beta test as much as you like, but unless people are playing 'in anger' they're not going to be invested to truly report the issues.

Anyway, for the first - we all have a natural affinity for the command sets we're most used to. Almost by definition, the commands that we're most familiar with are the most intuitive. To take an example of that, if i had a hundred guesses 'recharge 2.torch' wouldn't be how I'd try to do it. Even knowing what it's supposed to be, I don't know what that means. Why is that 2 there? Who 'charges' a torch, much less recharges it? I honestly don't know. For some people, with different backgrounds in different games, that'll be so obvious it hurts. To me, from a different background and codebase, it looks like the syntactic equivalent of a war crime. That, as an issue, is largely impossible to solve. You just need to hope that people will make the time to learn a new syntax. If they don't, well - that's okay. Expect an attrition rate, but you gain nothing by worrying about it unless you plan on supporting every possible syntax form with all the inconsistency, incongruity and incompatibility that implies. People will be shaped by the first MUD they truly grow experienced with. 'Deprogramming' that is likely futile. I certainly have hope that people from other MUDs will be willing to give us a try for the long haul, and certainly early initial experience suggests that's true and I'm thankful for it. But if someone is instantly put off by an unfamiliar environment, I don't think it's the best use of our time to try and coax them our way against their first impressions and expectations. I've seen a lot of MUDs do that, but I see very few of them with the player numbers that would objectively validate their efforts.

For those coming at it fresh, intuitive syntax is valuable but intuitive means different things to different people. We can provide synonyms when we can, but if you're trying to 'displace the spigot' rather than 'turn the tap', you need to help us by reporting that. Likewise if I expect you to 'obviate the pachyderm' rather than 'dodge the elephant', our differing mental models need some kind of bridge. Like a bug report. Those bug-reports that come from the perspective of genuine newbie puzzlement are valuable. Those that come from the perspective of 'this isn't how I'm used to it' aren't really. That's as true for me in your game as it is for you in ours. My syntactic preferences are nothing for you to get wound up about.

For the second, well - preferences are by nature subjective. Flashlights emit *more* light when held but don't have to held at all. I very much dislike games that try to be simulations. I'm all about the *game*. If I want a simulation I'll go play one, but for me Epitaph is first and foremost a game and 'inventory management' adds nothing to that for me. Realism, by itself, is never going to be a reason for anything on Epitaph to change. Other people will have different views - I respect that, but again you gain nothing by adopting to the preferences of other people over your own. You have to, first and foremost, make the game that *you* want to play. Similarly with automatically turning flashlights on and off - I don't like game options that play the game for you, no matter how little that playing might be. It also works against the thematics of the game - I want people to have the danger of making mistakes and leaving themselves screwed as a result. You can't simultaneously be 'survival horror' and 'hand holding'. You might disagree, and again that's fine. But that's a clash of preferences and there are plenty other games out there where the development team *don't* have strong views on these kind of things.

For the last, well - every game *can* do better. But - the medium of text requires people to meet the interface half way. There's only so much you can do if people aren't willing to read the information that is given to them. Our newbie area for example tells you exactly the commands you have to type to get through it. Occasionally though, I still see people asking 'how do I do this thing', despite the fact that it was said and then likely later repeated. That's not to say there aren't things we can improve there - just that the things we *can* improve *won't* be improved for someone who won't read.

If text is getting lost for whatever reason we can do what we can to minimise that, reduce the cost of missing it and so forth. There is virtually nothing however that can be done if people won't *read* in a text game. Maybe there's too much reading, and that's something I can certainly sympathise with and specific examples can be addressed. You can't though hold people down and force information into them. Likewise, you can't force every piece of information that they might use into a tutorial/hint or guidance system. Ambiguous parsing such as between 'boots', 'yellow boots' and 'combat boots' are all things you can resolve with the game options and familiarity with the parse. 'help parser'[1] outlines some of the matching tools you have available. That's not content for a new player, really. There's no place, in my view, that information can legitimately go in a tutorial system other than in a helpfile. We can do more to point people to that helpfile of course[1] when the time is right, but MUDs are games for *literate* people. They're for people who enjoying reading. I don't think it's necessary to cater to those who *won't* make use of the tools provided and outlined in the context sensitive help. Epitaph is also a game where you need to pay attention to where you're going and what you're doing. It's almost certainly in everyone's best interest that people who aren't willing to do that are disincentivised from playing before they waste any of their time on what is certainly going to be a frustrating experience. There are, again, plenty of games where you don't have to do any of this, and I won't begrudge anyone who decides they are more appropriate for the kind of experience they want with their free time.

Some of this reply I know probably comes across as 'If you don't like it move to Russia', and I guess in a large part it's hard to deny that's what it is, although I hope I've put it at least constructively and in context, and I wouldn't have done even that if I didn't feel as if Epitaph was, at least to some extent, being 'called out' here. We'll fix the things we can for the audience we're looking to build, and they'll be the ones who help us do that. But that's a long term, ongoing process to be shaped by those players active *within* Epitaph rather than what you might think of as 'tourists' from other MUDs who have come for a nosy. :-D

Drakkos

[1] I'm not sure we do at the moment, and as such it's fair to say that it's very easy to miss if you don't browse the helpfiles either in the game, or on the web. That's a thing we can fix. What we can't (or perhaps, *won't*) try to fix is people not reading that if it's pointed out to them in an appropriate time and place.

I feel the exact same way, only in reverse :)

Let's revisit:



This solution exists in some games I looked at recently. It's easy to add in plain text (all you need is to convey the right handle, which your game already knows), it teaches a principle by example, it can be easily expanded to include several smartly-selected choices, it requires no state-keeping. It solves the problem you stated in the OP of not making people have to research a command.



Your objection to the above two: they list only one choice.

Well, duh, they don't have to. You can list 10 options (if you want to confuse the player more than to help them). You can use MXP to build a multi-select dropdown with 50 options if you feel they are all equally likely to be what the player wants. The point is that they address the problem in a way that many people, including non-mudders, will find easy-to-follow (clear verbatim instructions) and/or familiar (click on a link, select from dropdown).



You didn't address this solution. It's a variant of the multiselect, that can list many choices. The difference is that the dialog is modal, which forces the user to pay attention and take action before they can proceed with other actions. This simplifies your state-keeping, if you want to do any. This is a real solution I'm using in my iOS app, though not for in-game actions because of (real) real-time complications.



Your comment: It solves the issue but I don't want to talk about it because it takes too much time and effort.

I would add, this not only solves the issue, but it does so in the international language of the image. Is this an imaginary solution to an imaginary problem? Let's ask this differently: How many Chinese players are playing MUDs in English vs. games with even the most basic graphical UI?

Now on to your suggestion:



My comments:

1. How does the player know to type "hint torch"? This doesn't seem to solve the problem posed in the OP. If someone is ready to sit through a tutorial to learn about "hint", why wouldn't they be ready to read conventional help files about other commands as well?

2. A lot of things can happen to the torch between player input. How do you make sure the suggestions stay smart and relevant without an overly complicated system of keeping track of states? If you simplify in the way Runter suggests, how is that better than instant MXP-enabled prompts, e. g., which are easier?

To this, I would add:

3. If you feel that your solution is real, and mine are imaginary, do you have a game with active players where I can see your system successfully converting new players?

I'm not sure called out is really what is, it just happens to be something of immediate familiarity at this moment in time.

I didn't know that the flashlight had any different level of light (besides maybe flickering out), for one. I would have expected (rationally) for no light to escape it being in bag or pocket.

With respect to the flashlight, it's not so much that I am looking to automate the game as it is that there are certain aspects of behavior which are almost automatic to begin with. To force the manual adjustment of that is a nuisance. Who leaves a flashlight on in a lit area? Maybe if everywhere in a immediate tight radius was dark, but when dark places are distinct locations that you could avoid, having to switch off the light manually when you return from them is somewhat counter intuitive. Yes, it has to happen, but for the purposes of fun and games why does the player have to do it manually? (If you read all of what I said, you must have noticed that I made the point that automatically turning it -on- in the dark might be overdoing it given the game mechanic. Turning it off automatically in the light presents no such difficulty. Perhaps it would add a particular kind of tedium in turning it back on, but we wouldn't waste the battery without thinking which would be more consistent with rational behavior.)

I think it's worth noting that all players are "tourists" at first. Most people who play MUDs of any kind have played or do play other MUDs and new players are internet tourists so to speak. Since some of what determines whether they become active is whether they like the game in the first place, and aside from theme, what attracts is mechanics playability etc that means that these players *within* of yours aren't really about being active persay as they are about putting up with the attitudes of the dev team. I don't mean to offend, but for games in development the attitude and behavior of the dev team if and when they interact with players has an effect on whether those players stay.

In any case, I digress. This is getting a bit off topic…

Just wondering…
I didn't get past character creation on your mud.
Notes delimited with <——————

Welcome to MUSHclient version 4.84!
Written by Nick Gammon.

Compiled: Sep 30 2012.
Using: Lua 5.1.4, PCRE 8.31, PNG 1.5.12, SQLite3 3.7.14, Zlib 1.2.5

For information and assistance about MUSHclient visit our forum at:
   http://www.gammon.com.au/forum/
Can you trust your plugins?  See: http://www.gammon.com.au/security

— Connected on Wednesday, September 04, 2013, 3:29 PM —

     .                             .   .              .
     $                            .$   $'                           .
     $$                           $$  $$            .               .  
   + $$$ ====================== $$$$  $$ ==================. ====== $ =+
     $$$$        $$$$$$         $$$$ $$$       $$$$$$$$.  $$       $$
     $$$$$$$$.  $$$   $$   $$$$$$$$$ $$$       $$   $$$$  $$$     $$$
     $$$$   $$$ $$$   $$  $$$   $$$$ $$$        `   $$$$  $$$     $$$
     $$$$   $$$ $$$$$$$$  $$$   $$$$ $$$            $$$$  $$$$   $$$$
     $$$$   $$$ $$$$$$$   $$$   $$$$ $$$       ,$$$$$$$$  $$$$   $$$$
     $$$$   $$$ $$$$   $$ $$$   $$$$ $$$    $$ $$$  $$$$  $$$$$$$$$$$
     $$$$   $$$ $$$$  $$$ $$$   $$$$ $$$    $$ $$$  $$$$  $$$$ $  $$$ 
     $$$$$$$$'   $$$$$$$$  $$$$$$$$$ $$$$$$$$$ $$$$$$$$$  $$$$    $$$ 
     $$   .       `$$$$      `$$$$$$ $$$$$$$$$  `$$$$$$$$ $$$      $$
     $  .                    .                            $$       `
   +=   =========== == ============= =====================$$ ===   ===+
                                                          $  
           [ mud.playbedlam.com 23|9000 ] Bedlam  …. 
Bedlam v1.0 based on Another World by Mattias Larsson & Eric Helvey
  Based on Circle 3.0 (by Jeremy Elson), a derivative of DikuMUD (GAMMA 0.0)
    Created by H.H. Staerfeldt, K. Nyboe, T. Madsen, M. Seifert, S. Hammer

Note: A new user account system is in place. Create an account first,
then you will see an option to add your existing characters to it.

Enter new or existing username: 
xxxxxxxxx
Username exists. Enter password, or nothing to try another username.
Password: 

Your friend invite code is: xxxxxxxx           <————- what is this?

To claim, create, or play existing, enter a character name.
By what name would you like to be known? 
xxxxxxxxx
Did I get that right, xxxxxxxxx (Y/N)? 
y
New character.
What is your sex ([M]ale/[F]emale)? 
m

Select a class (press 'h' for help):

  [ 1] Crusader
  [ 2] Healer
  [ 3] Rogue
  [ 4] Assassin*
  [ 5] Ronin
  [ 6] Knight
  [ 7] Berzerker
  [ 8] Psion
  [ 9] Sorcerer
  [10] Necromancer*
  [11] Enchanter
  [12] Ranger*
  * solo class, cannot group with others

Class: 
h

CLASSES  [feature]
 
NOTE: The Bedlam Class system will be changing pending an update soon! Look for
even more variance and fun coming soon.

 Bedlam has 4 base and 14 special classes. They are strongly
differentiated and completely transform the way in which you experience the game
content. There are many good reasons to try them all.
 
 When your character reaches level 10, he or she is able to specialize more
narrowly within their base class (warrior, thief, cleric, wizard). To
specialize, your character must visit the guildmaster before he or she reaches
level 11. Staying the same class is also considered a kind of specialization,
with impact documented in the help file for the base class. App users can tap on
the icon  and others can type 'specialize' followed by the name of a special
class:
 
 Warrior:
 Warrior, Knight, Ranger, Berzerker
 
 

Select a class (press 'h' for help):

  [ 1] Crusader
  [ 2] Healer
  [ 3] Rogue
  [ 4] Assassin*
  [ 5] Ronin
  [ 6] Knight
  [ 7] Berzerker
  [ 8] Psion
  [ 9] Sorcerer
  [10] Necromancer*
  [11] Enchanter
  [12] Ranger*
  * solo class, cannot group with others
h knight                   <——————————  I read the help.  It says I choose one of the 4 base classes and specialize at level 10
                              <——————————- But the base classes aren't listed!
                              
Valid commands while paging are RETURN, Q, R, B, or a numeric value.  <—— How the heck did I know I was in paging mode?  I feel stupid for entering 'h knight'.
                               <——— And why can't I get help on any of the classes?!  Like "help knight" as above?

 Thief:
 Thief, Rogue, Assassin
 
 Cleric:
 Cleric, Healer, Crusader
 
 Wizard:
 Wizard, Sorcerer, Necromancer, Enchanter

                                  <———- above seems to be what was unpaged.

That's not a valid class.  <——— I think I hit enter here because I was told above I was in paging mode.
Class: 
1

xxxxxxxx is a Crusader.                  

Select a background (press 'h' for help):

  [1] Scholarly
  [2] Martial
  [3] Spiritual
  [4] Criminal


Background: 
h

Coming soon to a Bedlam near you! Backgrounds…   <———- that's helpful

Select a background (press 'h' for help):

  [1] Scholarly
  [2] Martial
  [3] Spiritual
  [4] Criminal

3
Alias added and saved.         <————-  what's this?  I didn't create aliases
Alias added and saved.
Alias added and saved.
Alias added and saved.
Alias added and saved.
Alias added and saved.

xxxxxxxxx has a Spiritual background.  


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                 B       E       D       L       A       M 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

   Please remember to vote daily via http://www.playbedlam.com - Thanks!

           -=[        News last updated 05/01/2013         ]=-

              Please use the 'bug' and 'idea' commands - thanks!

              For each friend you refer successfully, you get:
                     10 million gold, 20 quest points

                       Play nice, enjoy your stay!

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



*** PRESS RETURN: 


Welcome to Bedlam!
0) Exit from Bedlam.
1) Enter the game.
2) Enter description.
3) Read the background story.
4) Change account password.
5) Delete this character.
6) Login another character.

   Make your choice: 


That's not a menu choice!

Welcome to Bedlam!
0) Exit from Bedlam.
1) Enter the game.
2) Enter description.
3) Read the background story.
4) Change account password.
5) Delete this character.
6) Login another character.

   Make your choice:    Make your choice:

Quit.
Thought I'd try the web app.
Do you really want to hear what I think about it?

Sorry, we're out of troll fodder for the day.

There's a reason I did *not* point to my game as a shining example of doing a good job of hand-holding in simple telnet and MXP. Instead, I specifically mentioned SlothMUD. End of Time and Ansalon also seem pretty good at it.

My own efforts have been focused almost exclusively on custom clients; any help for people on generic MUD clients has been added by other coders, and is sorely lacking–I'll be the first one to agree.

I did, however, mention the Bedlam iOS app, which you are welcome to try. Oh, but you've already decided what you think about everything I do, haven't you?

Or do you want to surprise me by addressing the substance of my posts?


@donky:

I actually think it's totally fine that we've been talking past each other. Mostly, I've been playing the devil's advocate in order to make some of our audience think outside the box a little bit. I'm trying to get people to think beyond capturing the 5 remaining MUD vets that are looking for a new game. There's absolutely no reason (except our own recalcitrance) why we shouldn't try to grab the attention of a wider audience.

I've never bothered to even begin to review a mud before. Obviously I picked the wrong one.



Perhaps you might want to focus on the server. It's been pretty clear in this thread that the server itself has to provide the parsing, provide the clues and provide the context in order for the client, any client, whether telnet, MXP, or graphical to aid the user. That is to say… A turd wrapped in fancy graphics is still a turd.



I don't own any iDevices, so how could I decide anything? Should I assume that the iOS client somehow provides help to users in order for them to create their characters on your mud, in a way that neither your web app nor a typical telnet client can? Or maybe it logs into a different mud? I don't know.



The claim that typical users are unable to get 'help' or 'hints' by typing 'help' or 'hint' when specifically instructed to type 'help' or 'hint' makes the substance of what you write a joke. Sorry it just ain't so. Even millions of "idiot" cell phone users have shown themselves capable of "texting 'help' to 98217" upon instruction.

At what point did you determine that developers on this forum weren't aware of MXP or Pueblo, and needed to think outside the box?

At the risk of beating a dead horse, I will remark that certain mud server's libraries do support contextual help and commands because they are locally attached to objects, and are inherited from
other objects in their hierarchy.

For example:
@commands torch would show all the commands you can issue on torches and ancestors of torches.
Including if you want the actual matching templates that are used.
For instance…
take|get <thing> (from|out of) <any> <– inherited
light|ignite * (with) <any> <– on object
douse *

@help torch would also display any help attached to that object.

Take the elevator object created in the "Dynamic doors" thread for example.

Also the same library implements both contextual and modal commands.
See @build and @dig for example.

Context is saved, including the last command issued, the last thing manipulated, the last user spoken to.
So one can issue:
> to Bob say What's up?
Tyche (to Bob) asks, "What's up?"
> to him say I'm fine thank you.
Tyche (to Bob) says, "I'm fine thank you."

> get torch
You get the torch
> light it
You light the torch. It glows brightly.

Anyway I'm certain these ideas can easily be implemented in LPC or anything else.

Perhaps you should tend to your garden. I'm pretty sure that I've done more just on the server side in the past 3 years than you have. Plus, say, a dozen other projects. And if I need vague patronizing advice, I can always post some details on MudBytes!



That's exactly what I meant when I said that you already had your mind made up. Don't let lack of information (or apparent lack of any experience in designing UI's) stop you.



You *could* assume that. You could also be aware that a well-designed graphical UI (of which there are many) doesn't need to make users read help files just to complete a set of simple tasks. You could, as a game designer, be open to improving your understanding of how to ease the learning curve, even on a type of game that you seem to think you already know everything about. But, doing any of the above may shake your entire universe in which you seem to be the clear center.



The 'typical users' I'm interested in are not even going to be able to find or connect to your game. If on some odd chance they do, they are going to want to do something exciting almost immediately. They will be perplexed to no end if you ask them to type anything that is not related to game chat. They'll have a point. If you can have a "help" button opening up an easily navigable panel of topics, or pertinent contextual help when someone hovers on a discreet "help" icon attached to a "new" event, why are you making people travel back in time to MS-DOS?



I haven't determined anything. But now I know of at least one developer who thinks I'm talking about MXP and Pueblo, when what I'm really talking about is designing UX's to get us some players who didn't convert in the 90's.

Uhm, this is kind of funny. I just remembered that you posted a log in which you created a character in Bedlam over telnet. In it, you were prompted 5-6 times to press "h" for help, but you never did.

Just to be clear, in my understanding of how UX works, this is completely normal. Your own opinion, however, seems to differ.

Line 70 I typed 'h'
Line 109 I tried something more specific, 'h knight'.
BTW it would not have mattered what I typed, because you put me in some sort of paging mode, yet you sent me a menu prompt. I went back and tried it.
Line 121 I typed '1' selecting Crusader not knowing anything about what a Crusader was.
Line 141 I typed 'h'
Line 152 I typed '3' selecting Spiritual background not knowing anything about what I was selecting.



I believe you called it troll fodder.

I apologise for the delay in replying. Given our different directions, I decided that I needed to go away and start coding. But I think the replies I give below should help clarify why your solutions are not ones that suit me or the game I wish to make.


My objection is not that only one choice is listed, it's that you can never cover every case, and I am interested in implementing my system to make it easier for the player to work out what to do when it's their case that isn't covered. I think that given that, we are otherwise in complete agreement that this would be the simplest solution. How I would have to do it, would be to process all existing verbs/commands and list every single one of them that can take the object as one of it's arguments.


I didn't address it, because I didn't think it was a realistic solution. We both acknowledge that it isn't a practical solution for in-game actions. Also see my next answer in this post.


If a GUI allows you to select an object, and to see what verbs work with it through the presented action icons, then yes it does solve the command discovery issue. Or for that matter conversely, if you selected an action icon and then could see filtered lists of suitable objects that could be used with it. But it is only a suitable solution if the developer is developing the game in a way that suits it. For you, this is obviously the case.

What I need to make clear, is that I am not making a game with GUI. To adopt a GUI-based solution, is to change direction of what I am doing. This is primarily where you and I differ, with regard to our respective projects, and acceptable solutions for problems like this.


I really don't have any additional answers on this for you. Learning about hint in a tutorial is an aside, it isn't a major chore. Epitaph demonstrates this very well. I was happy to read as many help files as needed to work out how to do what I wanted to, but was unable to find any leads. And I'm confident that this can be a problem on any MUD, after all help files are a human effort amongst other more interesting human efforts and developers have never treated them as a professional endeavour.

With regard to relevance and state, this is something I need to go away and experiment with. With regard to MXP, for me what Runter shows isn't better, it's just more relevant for the type of game I wish to make.


I hope my answers above clarify that you and I are making different types of games (GUI-based vs. non-GUI-based), and your solutions do not fit with the type of game I am making. My game is not going to be active for many years yet.

Yes, but integrating into an existing system is not likely to be as easy.

Take for example the MudOS driver parser. This has a mudlib generally place filtering of suitable objects and matching actions into a set of functions defined on specific objects which have to be named in a dynamically constructed way based on how resolution of the most suitable command is to be approached. This places part of the filtering/matching into the function naming, and the rest into the logic within those functions. So any given mudlib that has a custom implementation of driver parsing support likely has the logic which would be needed to implement these ideas in a fixed placement not really suitable to use by other systems. Whether a mudlib with a pure-LPC based custom parser is much better off, would depend on the implementation of their parser and whether they inherited it or implemented it themselves.

I'd expect that most LP MUDs that wanted to do this wouldn't bother, whether because the change was too much work or simply too complicated for the level of coding skill they have at hand.

So, it sounds like, if somewhere in the help files Epitaph covered your scenario, you would not consider having to read many of them just to recharge your torch to be a usability issue? I would still think that, at the very minimum, the error message should provide a keyword that points the player to the right help file. We can't excuse everything by saying that we're not building a game with a GUI :)

I understand perfectly why you'd want to build help logic that tries to explain commands more comprehensively than a manually updated help system. Usually, this kind of documentation pays off in the long run for very complex and fast-changing systems. Unfortunately, all the examples in MUDs I can think of fall into the realm of the "syntax" command you mentioned in your OP. Creating a system that is context-aware and doesn't come across as horribly tech-y will be a great challenge, I think. Best of luck with it.

I wrote a longer reply countering each point, but it really came back to me saying something which Tyche has already said. It doesn't matter if it is possible to solve it with UI, if you can't do it in the text on the server to begin with, then the UI doesn't have the capabilities to do it anyway.



Case in point, if the UI is to provide the graphical buttons which the Chinese or English player are to share, they need to be the ones which apply to the selected object. If the UI is to get that list of valid and possible actions, then the server has to be able to do it anyway. And if the server can do it, then it is equally solved for text players and graphical players. But it is still solved for text players, even if there is no UI.

I would add that I've already given good reason why the error message can't give all the possible keywords. This is simply a rewording of the error message providing action links, whether by MXP, or simply showing the actual commands.

That's exactly what I was saying.

For example, when I drag a particular chain shirt from my inventory and drop it on my paper doll image of my character, I'm essentially sending the server the command 'wear second shirt'. That command may or may not succeed. The server might respond, "You put on the chain shirt." or perhaps, "The chain shirt is too small for you. It appears to be hobbit-sized." or maybe other errors due to strength or capacity. Or perhaps it's successful but with warnings… "You put on the chain shirt, but it chafes against your bare skin." It all goes back to the server understanding (parsing) and verifying every action (context) performed by the client. This is irrespective of whatever sort of UI you use.

Of course, the above, literally that is, makes quite a brittle interface. It's essentially screen-scraping. Instead some of us have developed protocols.

Like you, I want to preserve the text interface. However, I'm extending (mirroring) it through distributed GUI components. It's a bit off-topic here, but I'll just add that in doing certain GUI components, I've also discovered new ways to extend the text interface for my particular game. For instance, the act of arranging and moving equipment around in the GUI led to text commands to do the same thing.