MUDish approach to playing IF


What do you think about playing IF in MUD-style? I’m referring to the way it’s implemented in MUD clients: aliases, macros, triggers. Could it make your gameplay easier?
As for me, I often miss the opportunity to write a macro or shortcut for some long command or type the location name to move there (assuming that interpreter will enter necessary commands).
Would you like to see something similar in your interpreter? Or is it completely superfluous? Or are you already use it? If so, please share your experience. Thanks!


I have no clue what these mean. I know the words, but I’ve never looked at MUD clients’ source code.

Can you elaborate?


Instead of repeatedly typing in long commands you can create an unlimited number of aliases to shorten the commands and make typing them quicker. For example, instead of writing “buy ticket” to buy a ticket to board ship, you can create and alias and name it “bt” so every time you type “bt” you will send the “buy ticket” command to the game.

Triggers are commands that automatically fire depending on what happens in the game, without you having type anything at all. For example, you could create a trigger that automatically picks up all coins from a corpse after you have killed something.

Tired of manually walking the back and forth over long distances? That’s why there are paths that do the work for you. For example you might want to quickly move back and forth between the orc fortress where you’re hunting orcs and the Sparkle shop to sell your loot. This requires a little more work than the previous examples, but once it’s setup you’ll never have to do it again and can easily add new paths.

Genesis - Guide


I don’t like aliasas and triggers much. Maybe other players like them?

I think paths or similar is cool (but only for some games). You could also impleement direct movement: The player could enter “go to kitchen” and be transferred to the distant kitchen.

Only disadvantage: Let’s assume there’s something special assaulting the player character (imagine a bridge troll) or something positive is happening to the player (imagine a wise priest in a temple giving advice everytime the PC enters the temple).
Then you have to code some clever algorithm detecting that the movement goes through this special room.

Back in the early 90s I thought interpreter macros were a great idea. I put them in XZip and MaxZip. (Inspired by the somewhat clunky implementation in Zork Zero, I suppose.)

However, I never got the sense that anybody was using them. I never used them myself. So I dropped the idea.

The one interpreter convenience that (I think) everybody loves is the command history. Hit up-arrow, get the last command you typed. Keep hitting up-arrow to run back through previous commands. This winds up being 90% as useful as programmable macros, with much less work for both the developer and the player.


I think it can be easily solved. If the description of the room which you’re going through differs from its previous version, the macro will stop.

Well, there are automappers, shortcuts for common verbs (eXamine, Inventory, Look). I just thought, why not go further? E.g. bind n, e, s, w to arrow keys numpad.

Ah, I see. But IMO it would be more convenient for the player if the PC is “teleported” directly to the end location. But, yes, if the game is not in ‘verbose’’ mode a macro would be fine, too. (If verbose, then the player gets flooded with a lot of room descriptions.)

There are some early games that were designed around the use of macros. For example, the mainframe game Warp gives the player the ability to define macros—not just sequences of commands, but also if/then and repeat logic. Some of the annoyances in that game were designed under the assumption that you’d come up with fancy macros to deal with them (e.g. fast travel involves a bus that moves around the map every turn; instead of waiting for it, write a macro that repeatedly enters WAIT until the bus appears).

1 Like

I have a MUD server embedded in one of my regular servers. I dabble with it from time to time. I have thought it might be an interesting medium. Alas, the audience for MUDs these days is very small…

Aaron Reed had a very nice article on MUDs that was included in his recently published 50 Years of IF.


In Beyond Zork, you can program the function keys as simple one-line macros by typing “define” at the command prompt.


Yup, though the arrow keys defined don’t work now. It also is in Zork Zero, Arthur and Shōgun.

1 Like

Re: aliases, I like it when the author already puts the most useful aliases in their own game. This can be as basic as including short, obvious synonyms for long words.

If it’s something you do all the time (TALK TO) make it one letter (T) and throw in two as well for people whose brain works that way (TT). I usually have a bunch of undocumented aliases in my games, even for longer phrases. I felt if I documented them all, the volume of instructions would feel overwhelming, but if a two-word phrase is unique and has an obvious unique two-letter shortcut, I might have implemented it already.

Re: paths, I guess most modern games have less of those huge stretches of nwnnnwud…-type nav that was common in older games, and abounds on MUDs. Authors can implement GO TO at their end, as well.

Re: triggers, they were my bread and butter on the combat-heavy MUD I played. If I cast a spell and the attempt failed, the game would automatically re-enter the cast attempt (like an auto AGAIN). But these triggers were all geared for lightning responses to real time events in a huge scrolls of combat output. There’s not much of that kind of thing in most modern games.

Overall, what you got me thinking about is making my own aliases for games that don’t have them, because a legacy of RSI has left me with below average tolerance for unnecessary typing. You may think that sounds silly for an IF player, but I have a specific definition of unnecessary :slight_smile: Don’t make me type TALK a hundred times when I can type T a hundred times. And in hard puzzle games, I bounce off a lot sooner than I used to because there’s so much typing effort involved in making the exploratory attempts.



I think that there’s a few things that make these ideas more appealing on MUDS than in standard pieces of parser IF. I’ve never done more than dabble on MUDs, though, so take what I have to say with a grain of salt.

A lot of the issues boil down to the fact that each IF game is itself a “separate program” in some meaningful senses. Each bit of parser IF is also run on an interpreter, which is a program that pretends to be virtual computer to run programs that are written for that virtual computer. This has several implications. One is the question of where you’re handling these features: in each individual game? within the interpreter?

If you’re defining aliases, triggers, and paths within an individual game, OK, there are few problems from an implementation perspective: each author just writes some code to implement these features. (Well, “just” is massive bit of hand-waving, but …). You can get around some of these implementation issues by including standard definitions of these features in IF-focused domain-specific languages, or by developing libraries that authors of individual games can choose to include in their projects if they want to do so.

But there are additional problems from the user experience perspective with the “each game implements its own macro-type features”: once you’ve defined a macro for Earth and Sky, how do you use that same macro with Earth and Sky 2 and Earth and Sky 3? What if the game’s author didn’t include any macro capabilities in the first place? If you can move the macros from game to game, how do you handle macros that don’t make sense in the context of the game to which they’re being moved because the play mechanics or details of the underlying implementation are different?

You might theoretically get around some of these problems by building the macro-related functionality into the interpreters used to play the games, but you have massive problems here, too. The interpreter takes a low-level view of each game, not a high-level view. The 'terp, at its most basic, is a virtual machine that executes bytecode to read and write text from a terminal. So a program that is, say, written in Inform and compiled to Glulx requires a Glulx interpreter, and that interpreter pretends to be a virtual computer and executes the game code. But what the 'terp sees is not the overall structure of the game in the way that a human would, but just a series of very low-level instructions at the level of assembly language: move these two bytes from memory to a processor register; add them to the two bytes stored in this other process register; spit out a string version of that number to the console’s text stream; dump this string of text to the same text stream right after the number; compare these two numbers to see if they’re equal; if they’re equal, branch off and run this other routine; … . It is a huge distance away from the author writing something like Every turn (this is the People Seek Their Goals Rule): let L be a list of awake people who are not nowhere; repeat with P running through L; ... (for instance) in (for instance) Inform.

The problem with at least some of the macro-type functionality that you’re describing is that it would be difficult to impossible to implement at the interpreter level, because it requires a much higher-level view of the game than the game supplies to the interpreter. The interpreter doesn’t know what a particular game “is doing” in a general, human-intelligible sense at any particular time; it’s just following one low-level instruction after another.

On that scale, your example trigger is more or less impossible to implement at the interpreter level, at least under the current structure of how interpreters and individual games relate to each other. You can’t write a macro to pick up all coins from a corpse after you kill it, because the interpreter doesn’t know about corpses, which are a high-level representation presented to the player but not something that is consistently represented at the interpreter level. Many games do not implement combat or death; and when they do, that is something that happens narratively, in the player’s mind, as opposed to being something that each game implements in the same way, so that the interpreter understands “an object of the ‘corpse’ type has appeared in the room.” Each game that implements death, combat, corpses, or coins does so in its own way; and when the interpreter executes the commands that accomplish the goal of describing these fictional objects and narrative events to the player, it doesn’t realize that “that’s what it’s doing.” It’s just comparing numbers, dumping text to the screen, parsing input, launching off to subroutines, and doing all those things that it does at its own low level. It never has a high-level view of what the game’s large- or medium-scale goal is.

What you would need to be able to do these things is some way for the player to “hook into” higher-level representations of “what’s currently going on” in the game: the game would have to tell the interpreter that a death had occurred so that the player could write a macro triggered by that event, and the interpreter would have to understand the game’s “hey, a death happened” signal and support death-related macro-writing. Ditto for every other event type that you want the player to be able to write a macro for. Currently, to the best of my knowledge, there are zero interpreters that provide that functionality in the way you are thinking about; and part of the reason for this is that there are zero games that are trying to send death-related notification signals to the interpreter, as opposed to simply telling the player about it by writing a description to the screen. It’s the same “why don’t we ‘just’ redesign the email protocols to make them secure and reduce spam?” problem: because every email client would have to support the new standard at the same time for it to work. Similarly, good luck getting over the initial adoption hurdle of getting interpreters to do extra work to implement features that no games use while simultaneously trying to get game authors to implement high-level messaging features that don’t work on any interpreter.

MUDs get around this problem by not splitting the game-playing experience between game file and 'terp, so the entire thing is a single unitary software system, written by one group of people who collaborate directly and can design the single unitary system in any way they want, including by providing precisely these hooks for whatever event types they want to provide macro support for. This is a very different thing from game-writers implementing one half of a standard (via their specific programming language) and 'terp writers implementing the other half when neither half of the standard defines facilities for macro-type scripting by the player.

I think another big chunk of this problem is that people who want to define macros in MUDs are typically people who spend enough time in a MUD that the repetitive tasks become a severe annoyance; but these are people who are interacting with the exact same software stack for many many hours, perhaps even hundreds or thousands. It makes sense to automate repetitive tasks. But even if I’m playing a largish piece of parser IF, say Anchorhead, I’m usually still looking at just a few evenings for a playthrough; and the things I’d want to automate are specific to that particular game. Part of it, too, is that parser IF game design often de-emphasizes repetitive tasks: the dungeon crawl is not unknown, but neither is it all that common, and parser IF players, as a group, really hate having to trek back and forth to move objects around or perform boring repetitive tasks. There are of course exceptions, and entire games have been built purely to troll the user on exactly this issue, but repetitive long sequences of actions are decreasingly common in parser IF.

So it’s a combination of factors: technical difficulty of implementing, plus design that de-emphasizes situations where defining these macros is likely to pay off.

Sorry to write so much! I didn’t realize when I started how much I had to say.


But triggers and macros in MUDs are generally implemented at the client level, and clients are literally just telnet clients with a built-in terminal emulator and some convenience features tacked on. They just scan for patterns in text coming from the server, and can assign keystrokes or whatever to send longer commands that would take a while to type, especially under pressure. I’d argue that a Z-Machine interpreter has much greater insight into the structure of a game than a MUD client, even under the limitations you describe.

The bigger issue is that, as you pointed out, a MUD has highly repetitive gameplay where you have to perform long sequences of complex actions again and again, not least due to their gameplay revolving around RPG combat. Conversely, a text adventure ideally tries to minimize grind and repetition. So what would macros even help with?


Unfortunately, even today, there are still repetitions in IF.

I just finished “All hands abandon ship”. Nice game, but I’m more accustomed to using cardinal directions. It would be great if it was possible to reassign navigation commands in my interpreter.


Another example is a game from this IFcomp too. “Codename Obscura”. Great old-school bondiana. But having to constantly change clothes to get to different locations is tiring. This is not a complaint about the game. It’s beautiful. But what if I could do that:

> rec remove overalls,wear toga
Save macro
> toga

Short, but sweet :slight_smile:


I agree with Felix on this, but there are exceptions. For example you could examine every object in a room automatically when you enter it.

I think this strongly depends on how the game world is set up and if examining causes any side-effects.

If I tried “examine all” after entering a room in some games, I would be presented with a novel chapter of descriptions, because the author assumes that you are only going to incrementally investigate stuff that you want to know more about. I might be interested in everything, but seeing it all at once would be overwhelming.

And sure, some people would say that’s too many objects, but I personally prefer parser games with a lot to explore and it’s not as simple as “enter room and take all”. :woman_shrugging:


@inventor200 yes it can ruin the athmosphere, the tension and the plot in some games if anything is automatically examined. Depends on the game. In some game it’s simply part of the fun to manually X things. I’m not good at remembering game titles. That game where you try to get the map of Paris [edit: Curses], imagine there auto-examining: It would simply spoil all the fun.

1 Like

Well … sure.

But the text coming from a MUD is standardized: you can scan for a regex like “with a final shriek, \w*\w collapses to the floor” (or whatever might work for a particular MUD’s descriptions) to find a death. Again, it works because you’re interacting with the same software stack for hundreds of hours or more, and because the text is procedurally generated.

But every bit of parser IF is going to use different natural-language constructs to describe deaths, even in the case where those deaths have their description text procedurally generated. Many won’t: in the relatively small number of pieces of parser IF that describe multiple on-screen deaths, I would wager that most have a human-written description of each event, one that varies from death to death.

Scanning for patterns in text really only works well, without producing false positives, under certain controlled circumstances. It’s much harder to get it working for a large class of games whose text and code are both written by a large, non-homogeneous group of people.

Yes, and that’s why triggers+macros are always custom, tailor-made for each MUD. Then again you’re going to interact with the same MUD for a much longer time than with any given text adventure. That’s another important difference.