Usually, I find an EXITS command helpful (where you type EXITS, and the game lists which compass directions you can go), but I’m wondering if it makes sense for this situation, and whether to list blocked exits.
There’s a situation where there are (supposedly) exits in two directions, but you actually can’t use either of them at that point–one because it’s blocked, and the other because the character doesn’t want to. (That “exit” actually never works throughout the entire game.)
I’m not sure what would be a good response to “EXITS” in this situation. If there is a blocked exit, do you list that, or not? Something like “The way to the west is blocked” or “You don’t want to go east”?
Does EXITS make sense in a game like this? Most of the locations have only one or two exits, which are in the room description.
Unless it’s particularly obvious, in which case “West is blocked by a wooden door” is good, then you could have it open until you notice a danger, perhaps, from when on you can list the threat the direction gives. That’s my thoughts.
If you don’t want to spell it out initially, you could make the exits output conditional based on whether the player has already attempted the direction or not.
This is what I do (with customized “can’t go that way” messages)
If the output is English, it seems reasonable to say “A door to the south (closed and locked)”. (If the list looks like NORTH EAST WEST, as in the Scott Adams aesthetic, you could use parens or strikethrough if the style system allows it.)
“The character doesn’t want to” is an interesting angle. I might list it or not, depending on how it’s presented in the narrative. It might be a good way to cue the narrative: “To the south is the graveyard’s gate (but you just got here!)”
If you don’t plan on going the route of Full Information Disclosure to Players (which I personally favour reserving for beginner games), you could go the dodge of “potential exits are as follows:” and then issue the message “Oops, the West door seems to be locked” the moment the player tries one of the blocked exits, then afterwards remove it from the answer until the door has been unlocked. Requires a bit more programmatic effort but abides by the Law of Minimum Surprise.
Of course, I regard the disclaimer “Warning: this game may lie to you” and making the EXITS command unreliable perfectly OK. Now that I think of it, I played such a game, where the answers to some commands were deliberately misleading; made sense in context, but I don’t remember what was it.
Depends what kind of game it is and what the doors are normally like and whether the game plans to be tricky with the player or not, and what you want its map to do.
In my WIP, PCs are frequently not wanting to go ways. I list all exits that would be physically possible to go in, including those ways.
If the player has the graphic map on, an exit’s marked with a dashed line if the player tries it but the PC reacts by not wanting to go that way. But the exit’s still visible, and listed. And so are doors that are locked or closed, since I want the map to remind people of possibilities.
If there’s a direction the player will never be able to go for physical reasons, that’s when I (98% of the time) don’t list an exit, even if maybe it/is was a door, but is now petrified or superjammed or something. If it wasn’t apparent that it was blocked at first glance, I may initially make it an option. But if the player can see how useless it is at first glance, I just don’t offer it as a possible exit in the first place.
Why would you not list all exits, blocked or otherwise? What is the reason not to do this, other than to make the player’s life harder (which may be a goal for some games)?
I am always suspicious of games that don’t list their exits (available or not) prominently. Either in a room description paragraph separated from the main description, or with EXITS, etc. It makes me think the game is trying to fool me by obscuring things.
So I think it’s a user-friendly addition that takes some work to do, but it telegraphs that you’re working with the player instead of against them.
I was wondering if it would be annoying to players if they type EXITS to figure out where they can go, and then pick an exit from the list–or multiple exits–and find that they don’t work. Kind of like false advertising.
(The working exits are always included in the room description regardless. This EXITS command would be an extra thing for players who like to type EXITS.)
Not everyone will use EXITS, and if they are clearly listed together (instead of separated by lots of text between each exit) in the room description probably no one would use it. If you’ve clearly stated that the door is locked or that the force field prevents them, then that’s not false advertising. IF is full of locked doors. I assume you have a reason for the door that will never become available.
Why not also list non-working exits, though, with the information about why they are not available? Unless they are secret doors, why not say “There is a locked metal door to the west”? If it’s there at all, then surely the player needs to keep it in mind?
I do use EXITS, but only when the room description isn’t a reliable indicator of exits. A paragraph like this drives me nuts:
The hall of the mouse king is strewn with shredded newspaper, which piles up high around the tunnel to the north, rendering it nearly invisible. A cluster of well-dressed young murine courtiers play some kind of game with a marble by a door in the east wall as they sneer at each other’s fashion choices. The mouse king himself sits in a throne made of toothpicks next to a passage to the west, twirling his whiskers and laughing at the youngsters.
You have to read through it really carefully to note every exit and it can be easy to miss one. If the main description of the room (king, courtiers, etc) is first, followed by a paragraph break and then the exits listed, that’s preferable even to EXITS. Better is an updated list of exits, like I try the passage north to discover that the piles of shredded newspaper are too high, and then the description updates to “There’s a passage to the north that’s blocked.”.
I find it no worse than not mentioning SW as a potential exit and afterwards finding out that the grandfather clock in the corner can be moved and there’s a passage behind. Realistically, the player is not even supposed to guess there’s an exit there. Other contextual clues will point to that, maybe later on.
What’s important is to be consistent with your choice. The player will cotton on to your style quickly and be guided by that. A sudden inconsistency can throw people off and leaves a bad taste.
You might want to avoid Castle Blackstar then: all room descriptions there are of this sort.
in days of yore, bonking on walls and fences when under turn count limits (e.g. the dreaded “hunger daemon”) was really annoying, so having a list of exits was a very desirable feature.
modern parser IF generally don’t have turn count limits, and practically all modern IF languages has a contrib library implementing an exit lister in the status line, if not even implemented and default in the standard library/ies.
I feel that EXITS as metacommand is a bit unfriendly to left-handed player (the dominant hand tend to be faster than the other), so as coder, I favour the statusline exit lister.
(digressing a bit, perhaps ßtesters has a right to known the handness of the coder, this perhaps can ease the typo hunting…)
people whose played the pair of works of mine will surely have noted that I strive to describe or list the exits at the very end of the room description… which I think is good practice.
Due to a bug, the Z-machine version of my IFComp WIP didn’t list the exits in the status line (only in the EXITS command), so I had testers methodically trying every exit of every room for completeness.
@CMG had a nice bit on this sort of thing in his postmortem for Eat Me a few years back:
The rest of that section is a bunch of tricks to get players to pay attention to things in the text. It’s very smart!
Speaking personally, I don’t like this convention much either. As a reader, I don’t like it because one million identically-structured exits paragraphs are no fun to read; and as a writer, I don’t like the implication that the main description shouldn’t have any important stuff in it. (If it wasn’t important I wouldn’t have put it in at all, dang it!)
Of course, that’s just about room descriptions! exits commands and “you can’t go that way” messages are times that the player has specifically asked for that info, and it’s best to give it to them in a direct way. (My game was did a bad job of this bit, which I regret!) And the status-bar exit listing is a great idiom.
Personally I think just listing the things that would be obvious to the player-character is the way to go. If the room description mentions an exit, it should probably be in there somewhere; if the character has learned about a secret exit from an NPC or something, it can go in there too; if the character refuses to use an exit, it would be a kindness to mention that.
A bit like inventory, maybe? Not a great place to reveal info to the player for the first time, but a very good place to remind them of things in a clear and direct way.
If a text description or response contains a text that could be entered verbatim by a player, I format it differently. This is because reading for reading’s sake and scanning for information are two different activities. My thought is that I can only maximize the first by minimizing the latter.
You will have to *TAKE THE APPLE* first.
or
You hear an unpleasant gurgling emerge from the doorway to the *EAST*.
No *EXITS* command, then, but clarity regarding exits. This strategy would not work with a design that involves hiding details in dense passages, but that’s not something I’ve pursued.
(I expect to abandon this formatting tactic for full hyperlinks once Inform supports them natively.)
I likewise do a custom “going nowhere” response for every location. If a player discovered that a seemingly possible exit was impassable, I would customize the rule response once the discovery was made. I’d change the room description, too. I wouldn’t talk about invalid directions unless there was a reason to do so.
If the player can access the information without keying in special commands, that’s my preference.
(which isn’t to say that you shouldn’t do an exits command. If I did one, the output would match my “can’t go that way” message).
In my IFComp game “One King” I listed all exits which are seemingly available to the player. I use the Exit Lister extension by Eric Eve which conveniently lists exists on the status line and also includes the EXITS command.
I had to cover the following cases:
exits which are never available (e.g. going south from the Throne Room, which actually leads to the Dark Hole room where I hide my secrets.) Possibly it would have been better to exclude these from the exit list, I merely wanted to create the impression of choice (and the Throne Room only featuring an exit towards the Dining Room and Royal Bedroom would be kinda weird.)
exits which are not available because we roleplay as a Barbarian who never marches back (enforcing the always moving forward idea.)
exits which are not available because they are closed. I used Inform7 doors with some trickery to make them function as portals, i.e. they disappear when closed and are thus not mentioned in the list of available exits.
In my current WIP I use regular Inform7 doors and exits are listed even if doors are closed. I am not sure if excluding locked doors from the exit lister would make sense, to me it looks like the default behavior for this extension. At least I dropped the idea of including exits which are always impassable to the player, that is only a potential source of frustration for the player.
My current strategy—we’ll see if the testers like it or not—uses links. If there’s a normal passage north, an open door south, and a closed door east (locked or not), it’s presented like this.
north - south - east (the front door)
In other words, a direction is linked if clicking that link will take you that way without any intermediate steps, and otherwise the direction is unlinked and the obstacle is linked.