We’ve just recently added several features to Tohm’s command line parser! Please share any opinions or ideas you have in this area so that we can make Tohm better.
I suspect this will be a feature that takes a great time to develop and then winds up being significantly underutilized.
There are reasons to enter multiple commands on a single text line in a turn-based environment. However, if you’re playing a MUD, every delay in your command entry is a delay experienced by everyone around you or (if applicable) a delay in combat. The faster you can enter commands, the better -
get sword
get shield
attack rat
produces a steadier stream of input and reaction, vs.
get the sword, get the shield, and attack the rat
which produces a delay followed by a flurry of action.
You invited suggestions as well, so here are three, all stolen fairly directly from GemStone IV and DragonRealms (by Simutronics Games).
Because time matters in a real-time environment, allow partial typing and match for solutions. If there’s a dragon present, “att dra” should resolve to “attack the dragon”. If there’s a broadsword on the ground, “lo bro” should finish to “look at the broadsword”.
1b) For extra showiness, make it contextual: “ki go” is more likely to be “kill golem” than “kiss golem”, but it’s more likely to be “kiss Gordon” than “kill Gordon”. (At least, unless you have a heavy PVP game.)
Implement the word “my” to mean “on my person”, such as “get my sword” taking only the one that’s mine instead of the one on the ground. Helps greatly with disambiguation.
As a standard of interactive fiction, items don’t have identical names, and when they do, they combine into piles. In a MUD, though, it’s virtually impossible to avoid identical names, and “Do you mean taking the steel broadsword or taking the steel broadsword?” will cause trouble - especially if it’s possible for the steel broadswords to have different stats while still handling with the same adjective/noun pair. Implement “second”, “third”, etc. to help sort out stacks like this. “Get the fourth blue dagger from the second gold chest in the roc’s nest” is ideally a workable command.
I like and welcome any improvements to the IF interface.
However, once you’ve improved it until perfection (where the player can type in “tkae” and the interface will take the latest mentioned and most likely thing, for instance) will you just be using it for MUDs?
It seems like a big waste, because the best interface for a MUD, is a point and click interface. Right now I’m watching a lot of Rim World, and would Rim World use a text interface, it would be a nightmare. The thing is that even complex MUDs are monotone by nature. The player isn’t expected to learn how to be a shirt salesman in one adventure, and a space pirate in another. He’s just supposed to fight monsters all day, and especially in combat, things get very monotonous. You can almost just replace the whole interface with just one “Fight” button.
…so regretfully, I think this interface and game type, might be a mismatch.
That’s a good analysis of 99.9% of muds, but from the OP other links on the wiki it seems like they’re trying to make their mud the .01% that is not actually monotonous.
Though that doesn’t rule out the possibility that even the .01% would be better off with point and click for most actions.
While I do see your first point, I think we’ve already mitigated it to a large extent. It’s not shown in the video because this video isn’t about the details of combat, but two pieces of information you don’t already have are relevant - first, combat is not real time, and second, the multiple-commands-per-line is disabled during combat because we don’t want players to shoot themselves in the feet by committing to the next turn before this one resolves (it’s our intent that each round should be very interesting - if players feel very confident about what will happen more than one round in advance, then we’ve made a mistake).
But I think your point holds merit, and I thank you for it. I agree that outside of combat, it might be better in some views to see a three-step inventory management play out gradually rather than all at once. Also, we don’t intend to spend a lot of time perfecting this feature - it will be enough that it works in many situations. I agree that it won’t be used by many or very frequently, but I think those unfamiliar with a command line interface will try it, so the major benefit is in being friendly to the uninitiated. So the strategy is “make it work for simple cases, then move on to more important areas of the game”.
Yep, partial matching works. All of the following work today:
p
pun
punch
p z
punch zombie
pun zo
Punch that zombie!
punch the zombie
Punch a zombie.
On the “my”, yep - the plan is 1) find a sword on your person. if not found, then 2) look for one on the ground that YOU put there.
“second”, “third”, “other”, etc are also on the to-do list for inventory management. It will also work for combat, but in combat, similar creatures will be guaranteed to have unique adjectives (“smelly zombie”, “short zombie”, “ugly zombie”, “fifth zombie”).
I think you’ve been unknowingly playing some of the worst MUDs, at least as far as combat goes. We will be working very hard to make every combat decision an interesting one with many attractive options for the player.
I would make just one recommendation: make the combat more intensive in the description. The technical terms like contusion, abrasion, etc., those are good, and would make sense if the character is a doctor, but are too technical for a fight simulation. I would recommend that after each hit you describe how an enemy staggers, how long it takes them to recover, and how damaged they are when they do. This can also play into the environment, if a creature staggers into an obstacle or other player. It would also make the combat more fast paced.
Yep, we’ll definitely make a lot more investment in adding flavor to the combat text. I don’t understand how the changes you describe would make combat more fast paced, though? Please explain.
If the combat had more weight to it, and each hit from the player had a bigger effect on creatures and the environment, the tension and adrenaline of the scene goes up. Abrasions and contusions are very small effects, and it would seem to take forever to bring anything down. It would also make me feel weak, as a player, that I’m only causing small effects with what is described to be full momentum, knock-out punches. If I were to stumble, or if my attack barely hit, then I could understand such a small effect. But if I put my whole weight behind a punch and connect solidly, I would expect more than an abrasion or contusion. In my mind, this would slow down combat. It would make it more like a bad dream, where my hits don’t count, my legs don’t move, etc. You want to make the player feel powerful – that’s how you make combat fast-paced, in my opinion.
If you’re going to be fighting horrific creatures like zombies, have zombies be able to wrestle you to the ground and crawl on top of you, and have you fight from that stance at a disability. Have taking wounds, or being exhausted, affect your ability too. That’s the one advantage that zombies have: They never tire and they don’t feel pain. If you can turn a simple life bar, into a “safety” bar instead, you’ll begin to see players actually fearing for their lives.
I like how this parser combines some of the convienience features of IF/text adventures (multiple commands in one line) with some of the convenience features of MUDs (abbreviating according to shortest disambiguity).
I’m curious about the emote system. As a former MUD roleplayer, let me suggest that players be able to reference other players and objects in the emotes at the very least. Ideally, players should also be able to place the character name/identifier after the beginning of the emoted sentence. Emotes that begin with an apostrophe should automatically get rid of the space between the character identifier and the emoted string – “Harry’s hand shoots up” instead of “Harry 's hand shoots up.”
It would also be good to allow players to set a “short description” or “pose” attribute – a sentence describing what the character is doing, appearing beneath the room description to other players. Example: “Harry is leaning against the brick wall.”
I apologize if you’ve already studied all this in depth, as seems likely. I recommend Argila – the RPI MUD engine developed in Shadows of Isildur – as an example of a codebase with excellent integration of user-created text with procedurally generated text. (Unfortunately, Argila doesn’t seem to have any significant web presence. I haven’t been following MUDs for a few years; I hope the whole RPI subgenre hasn’t died completely.) Argila did not have a particularly helpful parser, though.
Oh, I get it now. Yes, there are no weapons or skills yet - once we add weapons and allow players to become martial arts experts, zombies won’t take forever to kill and individual combat maneuvers will carry more weight. For now, it’s lackluster because you’re the average Joe trying to fend off a zombie (who’s tougher than you and bites) with your untrained bare hands. The only reason players are able to defeat zombies right now is because they’re crazy slow (one maneuver every other round) and don’t bother to dodge incoming attacks.
Yep, will add debuffs like being knocked down on the ground eventually. Right now the focus is on filling-out some other stuff, like the topic of this thread, the command line feature set.
Yep, you’ll see in the next video that we’re adding support for targeting other players and monsters with smart emotes (“smart” for us means it correct use of pronouns with respect to the player who’s reading the message). You’re the second to mention about emotes targeting objects, so that is also on the to-do list. We also have a freeform emote which can serve the latter fairly well (emote sits on a chair. => “Bainespal sits on a chair.”).
I haven’t encountered the “leaning on the wall” status messages before, let me think about how that can be accomplished without adding too much text to the room descriptions. Thanks for that!
@Bainespal, Argila hasn’t died, but it’s not that accessible. From what I understand the codebase is sort of available but it’s not in a good ready-to-run state.
But can you target objects with the freeform emote? If the chair is actually refered to as “a tall-backed wooden chair” by the parser, can I emote “Bainespal sits on a tall-backed wooden chair” without having to type out “a tall-backed wooden chair”? Maybe you don’t want to allow such verbositity and specificity for user-generated text if you’re not aiming to accomodate roleplaying, but it’s something to consider.
At any rate, single command emotes are very immersive, and I would probably agree that recognizing a lot of them is more important than being able to target objects and characters with the free-form emote. By this I mean, any time I can type a verb that is recognized by the game and output into the text window in a way that responds properly to any objects that I might specify, that aids immersion.
I guess that’s something, although there used to be an RPI community a few years ago that seems to have died out, along with several never-launched MUDs. At any rate, Argila has some very strong implementation that IF could learn from, especially in processesing player-written text strings and in realistic world simulation.
