Well, when outdoors, compass directions read naturally anyway:
Sandy cove is to the east, and Grimtown's
barely a smudge on the northern horizon.
So we ought to keep compass directions. It’s only indoors that they’re inelegant and artificial.
So I’d suggest that
> GO TO [NEIGHBORING ROOM]
become the default means of navigation. We can let the player abbreviate “GO” to G – g on its own still means again, but g followed by something else means “GO.” You only need to type enough of a rooms name so that it’s unambiguous. So “K” would get you to the kitchen from the living room, but if there’s a door from the lanai to the kitchen and also an (enterable) kennel in the lanai, then the player would have to type “G KI” or “G KE” etc. If the parser can’t work it out, you get disambiguated as usual.
Imagine we have a living room, with the kitchen to the west and the street (door) to the north, and the lanai to the south. This is the underlying geography of the game: the description’s something like:
living room (on the couch)
Sunlight ripples on the pool beyond the glass doors, and glows
on the red brick lanai. Off to your right, in the kitchen,
the coffee maker burbles. You're barely conscious of the
traffic sounds from the street.
If the parser sees
> G K[itchen]
it defaults to trying to match a neighboring room, or a synonym (see below.) If it can’t, then it tries to match a standard direction, if it can’t match one, then you get parserErrror “Huh?”
Rooms can have synonyms, so when the player is in the living room, “pool” is understood as a synonym for lanai.
If the player says
> G S
It’s understood as “GO STREET” because street is a neighboring room, and so has priority over SOUTH. (Remember, the compass directions are not displayed by default.)
Relative directions (like the burbling coffee maker) are taken care of under the hood by the player having a “facing” - but they’re purely cosmetic, for the purpose of modeling the relations between things. You can’t “go left” etc. so it doesn’t matter if the player skims over them in the description, or misremembers which hand they’re on when they come in from a different room.
When the parser matches a go-target, it turns the player to face the direction according to the underlying game geometry, and uses this facing to print any relative relations in the go-target’s room description. The author can override this on a case by case basis for e.g. if the connection between the rooms is not a straight line, or can use an if-switch on the facing to print variations on the room description.
Notice how the player isn’t told that the street is to the north, because it doesn’t matter. The player is just as likely to “GO OUT” anyway. Out won’t match to a room, but will match to the standard direction, which has (assuming due diligence on the author’s part) been remapped to NORTH.
We could have the option COMPASS ON for people who want to see compass directions instead of relative descriptions, and COMPASS DISABLED for those who find the fall-through from rooms to compass directions produces confusing results because they’re typing G[space]O or something. (hey, we’re not gonna get it right all the time.)
For cases like the street, above, cant-go would give the full list of exits, and with compass on would list the compass directions, either as well, or instead. It might thereby reveal the various geographical kludges used to e.g. have two doors side by side in the same wall, but hey - you want to peek behind the flats, you’re gonna see the stage machinery.
It would mean players moving purposefully rather than geographically (I mean GO CLOCK TOWER rather than GO WEST) which might actually be more immediate, rather than “I want to go to the clock tower so from here I must go west.”
(p.s. I’m sure anyone who’s looked at Dialog will see where most of this comes from.)