The original GodWars muds had a pretty sizable number of commands, covering the various abilities available to the different classes. As a result there were a lot of commands you could type which would give you some message about them not being available. Actually I've seen this in quite a few other muds as well, with commands like "kick" often saying something about only being available for warriors. But in my case it was worse, as there were so many commands, and it felt very cluttered and confusing. As a result, one of the early decisions I made when designing GW2 was that you'd only see commands you could actually use - in much the same way that imm commands are handled in the typical Diku, but extended to cover other factors.

However a problem I occasionally encounter is people trying to use commands that are mentioned in help files, only to find that the commands apparently don't exist - of course they do exist, they just haven't been unlocked. I do mention in the help files if a command is only available in specific situations, but then there's the age old problem of newbies not reading the help files properly. Perhaps using dynamic flags in the help file would improve this, displaying a big red message if the command isn't currently available?

If the command were always available, it could at least give feedback explaining why it can't currently be used - but then we'd be back to the problem of clutter. I guess it could be handled through a config option, but that seems rather counterproductive as well - it's only really newbies who have problems with unavailable commands, and the reduced clutter is intended to make the interface less intimidating to those same newbies. Another option might be to only lock commands that will never be available (such as those for other classes)...I guess this would be a sort of middle-ground.

Anyone have any thoughts or solutions for dealing with unavailable commands?

But in my case it was worse, as there were so many commands, and it felt very cluttered and confusing. As a result, one of the early decisions I made when designing GW2 was that you'd only see commands you could actually use - in much the same way that imm commands are handled in the typical Diku, but extended to cover other factors.

...

Anyone have any thoughts or solutions for dealing with unavailable commands?

I've played and developed on MUDs that take your current approach, and I found it frustrating and confusing. It made no sense to me that game commands, or "doing actions", did not exist until I was actually capable of performing them. I found it helped me as a player to see a relevant message that made it clear that it existed, and why I did not have the ability or skill to do it.

Immortal commands, yes, it would be frustrating and confusing to have those visible to players for whom they are not relevant.

I do not understand your post where you talk about the clutter you perceived and acted to rectify with your current approach. While it is entirely possible that it is relevant to the way your first game engine worked and unique to that and therefore irrelevant to engines I have used, it sounds to me like a personal viewpoint that was somewhat arbitrary.

I've played and developed on MUDs that take your current approach, and I found it frustrating and confusing. It made no sense to me that game commands, or "doing actions", did not exist until I was actually capable of performing them. I found it helped me as a player to see a relevant message that made it clear that it existed, and why I did not have the ability or skill to do it.

So it's "frustrating and confusing" to hide some commands you can't perform...

donky wrote:

Immortal commands, yes, it would be frustrating and confusing to have those visible to players for whom they are not relevant.

But it's also "frustrating and confusing" to show some commands you can't perform?

How do you decide when a command moves from one category to the other? Are you suggesting that immortal commands should be hidden on the basis that players won't ever have them? But what if they're promoted? Or what if some of those commands are unlocked at the top level (eg immtalk for hero-level characters)?

And how does that differ from class-specific commands that a player won't ever have, or other promotion-specific commands (such as commands that are only available to clan leaders)?

donky wrote:

I do not understand your post where you talk about the clutter you perceived and acted to rectify with your current approach. While it is entirely possible that it is relevant to the way your first game engine worked and unique to that and therefore irrelevant to engines I have used, it sounds to me like a personal viewpoint that was somewhat arbitrary.

The mud had a lot of commands, so typing 'commands' to list them all (which is often a useful tool) could be rather overwhelming and confusing. Because commands could be abbreviated, it also meant that shorter commands had a higher priority in the parser, and therefore typing an abbreviation for one of your abilities might instead execute a different ability - possibly one you didn't even have, and couldn't ever get - giving you a failure message and forcing you to retype your desired command in full.

This is actually a problem on a lot of muds I've played, although it was perhaps more noticable on my old mud (and those derived from it), because of the way I tended to assign many abilities their own commands.

My current approach reduces the number of commands presented to the player, making it easier for them to browse through those they've got available and reducing the frequency of naming conflicts. It also makes it easier to have multiple commands with the same name.

However it seems many players are used to muds where all the commands are accessable, even those which don't work. I think I could probably get away with hiding those that the player will never get access to (such as commands specific to other classes), but I may need to provide better feedback on others. Perhaps "not available right now" commands could still be hidden from the commands list, and have some sort of alternative (but equally generic) "command not found" response.

Deadsoul wrote:

that is a sure sign of a bored coder who has no choice but to nit pick command availability.

Don't underestimate the importance of a user-friendly interface - it can make or break a game.

How do you decide when a command moves from one category to the other? Are you suggesting that immortal commands should be hidden on the basis that players won't ever have them? But what if they're promoted? Or what if some of those commands are unlocked at the top level (eg immtalk for hero-level characters)?

And how does that differ from class-specific commands that a player won't ever have, or other promotion-specific commands (such as commands that are only available to clan leaders)?

Immortal commands are irrelevant to normal players. As are unlockable commands like "immtalk". To show them is confusing, because they are simply functional utilities that either help the performance of the immortal's job, or open up trusted actions to trusted players.

I see these being easily distinguishable from player commands, which are useful in the course of normal gameplay, perhaps after training and similar activities.

I simply show the latter, and the former are invisible and inaccessible. Of course, I am working on the roguelike interface to my MUD at this time, so... this is sitting fallow right now.

KaVir wrote:

The mud had a lot of commands, so typing 'commands' to list them all (which is often a useful tool) could be rather overwhelming and confusing. Because commands could be abbreviated, it also meant that shorter commands had a higher priority in the parser, and therefore typing an abbreviation for one of your abilities might instead execute a different ability - possibly one you didn't even have, and couldn't ever get - giving you a failure message and forcing you to retype your desired command in full.

If I were to implement a solution for this, it would be the following. The player would be unable to access non-game playing related commands, like immortal commands. And they would not be able to see them in the help.

All game related commands, would be accessible both as commands and in the help. However, I would filter the help information so that it only displayed commands that were relevant to the player, and I would put a trailing line on the output to indicate this like "[ Usable commands shown, type 'commands all' to see all commands including the unusable ones ]". But more clearly written than that. Maybe make the parser prioritise usable/effective commands, even abbreviated, over shorter ineffective commands with the same name.

When there are two effective commands that match, I would warn the player. This could be done at two points, point of usage, or the point in time at which a command becomes effective and it is detected as clashing with another command.

This is along the lines of the approach I would take. I think you've got a good point, now that I understand the problem. I think what I suggest is a little messy, but I also feel like there is a way forward in the direction I describe. If there were a wiki on MUD development that had a section on parsing, I would add your situation in there as a potential problem.

If I were to implement a solution for this, it would be the following. The player would be unable to access non-game playing related commands, like immortal commands. And they would not be able to see them in the help.

Just to throw a spanner in the works...I allow players access to a range of immortal-style commands (such as 'slay', 'restore', etc), but only while they're on their home planes. How would you deal with that?

donky wrote:

All game related commands, would be accessible both as commands and in the help. However, I would filter the help information so that it only displayed commands that were relevant to the player, and I would put a trailing line on the output to indicate this like "[ Usable commands shown, type 'commands all' to see all commands including the unusable ones ]". But more clearly written than that.

The difficulty there is in deciding which commands are relevant to the player. I might not be able to kick (because it's a warrior skill) but I still want to read the documentation so that I can see what it does. I can probably guess that it's some sort of attack, but if it has a chance of knockback, or stun, then I want to know about it before I get into a fight with a warrior. I think this sort of transparancy is particularly important for a highly competitive mud.

donky wrote:

Maybe make the parser prioritise usable/effective commands, even abbreviated, over shorter ineffective commands with the same name.

I did consider that, but I think it could actually be even more confusing - because some commands would give you the "Only warriors can do that" message, while others would still appear not to exist - particularly if I deem it necessary to make the appropriate help files available. Eg:

You feel the need for a smoke.

> kick the habit
Only warriors can kick.

> sneak a look around for any smoke alarms
Only thieves can sneak.

A hot girl walks into the room.

> help pun
Syntax: pun <person>
This Bardic skill allows you to tell someone a pun, increasing their mirth by 5 points. It's also a great way to impress hot girls.

> pun girl
You punch the hot girl in the face.

This reminds me of playing muds years ago where sometimes 'k' would be short for 'kiss', and other times it would be short for 'kill'. It always resulted in hilarity when a player from one mud tried the other.

donky wrote:

When there are two effective commands that match, I would warn the player. This could be done at two points, point of usage, or the point in time at which a command becomes effective and it is detected as clashing with another command.

I think point of usage could get annoying, unless it was a one-off warning. Informing the player when they unlock a new command is a nice idea, but I wonder if they'd really pay attention. In both cases though, players who have gotten into the habit of typing a particular abbreviation are going to be irritated when it changes (I've seen this happen when new commands are implemented as well).

One could generate shortest unique match tables to avoid the kill - kiss situation. And then k-ki would generate an ambiguous command message.
I'd prefer not to ever execute an ambiguous command outside of user aliasing. That is I'd process user aliases first, so the user could alias k to kill without any ambiguity.

One could generate shortest unique match tables to avoid the kill - kiss situation. And then k-ki would generate an ambiguous command message.
I'd prefer not to ever execute an ambiguous command outside of user aliasing. That is I'd process user aliases first, so the user could alias k to kill without any ambiguity.