Strategies to Eliminate Compass Directions from IF Narrative?

Authoring General Design Discussions
41

Do you mean making the Forward/Back/Left/Right directions absolute instead af relative? So Forward is always North, essentially? I’ve always thought that might be a nice system: more familiar directions than NSEW (although then is the command L a synonym for Look, or Left?). But relative directions are just confusing: I’ve played a few MUDs that used them in places where they were trying to make the player’s life deliberately difficult and it always works.

This has been tried various times: the trouble with this (to me) is that it tends to be significantly more typing (unless the author goes to extra work to make sure that every combination of adjacent rooms always have unique starting letters) and that it’s theoretically algorithmically a lot more work to decide what to type, especially on bigger more complex maps.

If you have directions, you can place things mentally in space, so you know that the (farther away) place that you’re trying to go is “over there”, and just go in that direction, and maybe you have to remember that there are some places where you have to detour due to the shape of the map. But if you just have the room names and their connections you have to essentially do a full graph search to find which rooms to visit, which is, even in theory, much more algorithmically complex.

As I said way back when in this same thread, look at my non-directional graph of Mike Spivey’s Sugarlawn: if I’m in the cane fields (one of the red dots) and want to get back to the foyer, with compass directions I know that I go north and then just go east the whole way, and might have to detour up over the balcony or around through the south courtyard if I don’t have the appropriate keys. I don’t have to care about the rooms in between or even think about them at all unless they present particular obstacles.

But with no directions, I have to remember (and figure out what to type for) Outside the Cabin, the Gazebo, the Back Porch, the Stairwell, and then the Foyer.

Or maybe, in the worst case, Outside the Cabin, the Gazebo, the Iris Bed, the South Courtyard, the South Passage, the Library, and then the Foyer. Which would you rather do? I know which I’d rather.

And of course Sugarlawn is a terrible example because it’s a path optimization game so you always care about every room, but it was the one that I had a non-directional map for.

GO TO [ROOM] can certainly work if it does path-finding like some games do. But GO TO [NEIGHBORING ROOM]? Yuck. You can offer at as an option and it may well be helpful for people who don’t think directionally (and we know they’re out there). But I’m never going to use it, and I’m probably just going to skip your game if you don’t offer absolute directions like NSEW or up/down/inwards/outwards or clockwise/counterclockwise/hubwards/rimwards. And if they don’t have single-character abbreviations I’m going to be very annoyed at you. Because it’s objectively algorithmically measurably worse for me.

2 Likes
42

I believe Hunter, In Darkness uses relative left/right/forward/back directions.

43

Yes indeed. That’s why i think this has to work with either a fancy completion UI or choices. In fact, all navigation and “look at” commands should either be links or choices, even in parser games. In addition to command input.

44

I think Dialog offers that sort of option - clickable links and type-in. I agree that in parser clickable links in the text would work really well for EXAMINE (give me more information about this thing mentioned). At least for people who are not visually impaired, but that’s why it’s good to give options and multiple interaction modes.

45

Okay, to respond to each of your points:

the trouble with this (to me) is that it tends to be significantly more typing

To me, this is not a problem. I’m a touch-typist playing on my PC. So to me, typing “GO LIBRARY” is less mental effort than re-reading the description to find out which direction the library is, and then typing “W”.

Plus, if we’re thinking about people playing on a touch sensitive surface, then touching a link is touching a link, irrespective of the number of letters in that link.

(unless the author goes to extra work to make sure that every combination of adjacent rooms always have unique starting letters)

Well, at the moment, authors have to go to extra effort to place the geographical relationships of things in terms of a compass rose, even when they don’t really fit. So I think it could be the same amount of effort, just in a different place.

Plus, the game world itself is being constrained by having eight horizontal directions, plus up/down and inside/outside. But if the author only has to think about each room having a max of twelve connections the added flexibility might allow descriptions to be more imaginative, natural and evocative.

It’s true that would move some of the structure of the game world from the room connections to the room description, but that wouldn’t matter to me because I have to re-read room descriptions to find my way around anyway.

that it’s theoretically algorithmically a lot more work to decide what to type, especially on bigger more complex maps

That’s why its “go to a neighboring room”, specifically not “go to any known room”. During play, all we need to do is loop over the exits from the current location, and add in any special cases. Sure, going to any known room would be nice for the player, but as you point out it’s computationally expensive.

If you have directions, you can place things mentally in space, so you know that the (farther away) place that you’re trying to go is “over there”,

Except that my mind doesn’t work that way. Unless I draw a map,* I always have to navigate one step at a time. It seems my mind works better with visual patterns.

*“So draw a map,” I hear people say. But this, I think ties into why IF continues to have only a small audience. Modern players expect games to be self contained. If you have to draw a map of a level to make sense of it, then that level is considered to be badly designed. Players expect to be able to read the screen.

But if you just have the room names and their connections you have to essentially do a full graph search to find which rooms to visit, which is, even in theory, much more algorithmically complex.

Yeah, agreed. See the remarks on neighboring room vs any known room above.

(sugarlawn graph thing) Oh, is that what it’s meant to be? I just didn’t understand how to read it, so that argument went right over my head. So much for me being good with visual patterns. :slight_smile:

You can offer at as an option and it may well be helpful for people who don’t think directionally (and we know they’re out there).

Yeah, I’m one of them. I’ve gotten lost in an elevator.* But that’s just the point - they’re out there, not in here playing IF with us, because the nav system, not working with the grain of their thought, seems like a lot of hard work to them.

(*Pressed the wrong button, got out into a hallway that initially looked the same, but the later corridors had a different layout. To be fair, alcohol may have been a factor.)

But I’m never going to use it, and I’m probably just going to skip your game if you don’t offer absolute directions like NSEW or up/down/inwards/outwards or clockwise/counterclockwise/hubwards/rimwards.

IOW, the NSEW system suits the way you think. Fair enough. That’s essentially the same reaction as all those other non IF playing people “out there.”

But in this case absolute direction players would use the option COMPASS ON. The game would then work the way you prefer, it just wouldn’t be the default.

The descriptions would likely regain their descriptive clunkiness, and where the game world didn’t fit “eight flat + 4 other” directions you’d have to be careful, but that’s the trade-off. At the moment, we’ve just gotten used to the ugly prose that describing a space in navigable prose with absolute directions requires.

I guess no navigation system is going to please everybody, but that’s not the title of the thread, thank god!

46

I’d like to point out that much of this discussion makes implicit assumptions about how IF systems work, or are implemented.

One of the reasons i like this idea @dizzydonut, whether it’s completion or abbreviations, is that the system i’m working would not have to start querying the map. or indeed possible verb/noun combinations.

Instead, i have a situation where, at every point, the system has precalculated a list of all things the player can do at any point. This is akin to a chess computer calculating all the opponent’s possible moves.

Whether you agree or not, i’ve always felt this a superior approach to IF, rather than just fling the parse at the verbs and hope for it to work.

Working with an exhaustive list of possibilities, this becomes the basis of both word completion and, in this case, resolving appropriate abbreviations. You can also see the same approach could be used for other verbs too.

47

Well, In choice based systems, like Twine and Squiffy, compass directions aren’t standard/mandatory anyway, so: job done.

My knowledge of IF parser systems is: I7 (a bit), I6 (a bit less), Dialog (less still.) Drowned in the T3 library, so nil. So my assumptions are based on a small amount of experience of writing code in those systems. So “parse ‘n’ hope” is the only way I know.

If you know a better way, great. Go for it.

If you make your system public, then I’ll enjoy shouting at your compiler too, LOL.

2 Likes
48

I’m working on a improved navigational system for my project (VIBAE by Kvella) that is designed to address this. There doesn’t seem to be any way around having absolute directions without adding a fair amount of complexity. My system doesn’t use a parser but the problems are the same when you want to use relative directions.

Say you have a room with three other rooms that link to it. With the absolute directions you might have each of the exits to the other rooms described by cardinal directions from the first room, but for a relative system you need a description of each exit that changes depending on which room the player previously entered from, ie; if the player had last entered from the West room, then the door to the North room would be described as being “to the player’s left” instead of being “to the North”, etc. I think this has already been touched upon earlier.

Depending on the scenario this can get a lot more complicated. If the setting is an environment that the player character is supposed to be familiar with then it might make sense to just to describe the exits in terms of where they lead, ie; “the door to your office”, etc.

In a scenario where the PC is supposed to be exploring an unfamiliar building or landscape it might be desirable to add another layer of complexity whereby the description of an exit depends on if the player has visited that room before or not. In that case a room with three exits might have up to 6 different descriptions for each exit, two for each direction the player can enter the room from with one of those being the ‘has visited’ state and one the ‘has not visited’ state.

1 Like
49

Kind of similar to the idea of [go to Adjacent Room] narratively I really like the idea of relying on [enter door/threshold]. As others have noted this does require more typing but I don’t actually think that’s a bad thing, as I feel one of the strengths of parser based IF, or at least one thing that drew me to it was how the act of typing increases the complicity or immersion of the player. Perhaps that’s just a me thing and typing to enter a certain door rather then typing N would just piss people off rather then engage them but my thought at least is that it builds the world in a way that is both narratively appealing (avoiding the clunk of NSEW and using natural connections between places) and builds familiarity with the map in the player.

So for example if you had a backyard room you might have a “door” called the forest entrance which takes you to the forest path, and a back door that the leads you into the house and a fence the player can even HOP over. I think this builds a better sense of location for the player because they’ll think of locations as relating to each other rather then relating to directions.

Personally I don’t play much parser IF or really much traditional IF at all but from the few parser games I have played I’d say I’m also not a fan of NSEW, mainly because it’s so easy for me to gloss over it and I’d almost never actually remember which room was north of what, and it made it really easy to just blow by rooms on my way to find somewhere specific. So while NSEW does make it faster to travel I just felt like it almost hurt since it meant I’d just skip over the places in between my destination.

2 Likes
50

Surprised that no one yet has mentioned shipboard directions (port/starboard/fore/aft). TADS supports them, and I would think Inform does as well.

Of course, they don’t make sense in scenarios not involving a ship, but an interesting alternative to using the compass rose.

1 Like
51

I think with TADS the shipboard directions are already in the library and just need to be enabled.

With Inform, they’re not in the standard library, but just need to be included via an extension. (It’s such a trivial couple of rules, that the “extension” may in fact be an example in the standard docs.)

In either case navigating by “go to neighboring room” sidesteps the issue since we no longer care if the wheelhouse is fore or aft of the cargo hold. (Unless we’re offering the COMPASS ON option, which I think would be courteous.)

52

You can actually specify your own non-standard directions of any kind in Inform 7:

New directions must always be created in opposing pairs, and each must be declared with a clear simple sentence of the form “X is a direction.” For instance:

Turnwise is a direction. The opposite of turnwise is widdershins.
Widdershins is a direction. The opposite of widdershins is turnwise.
Hubwards is a direction. The opposite of hubwards is rimwards.
Rimwards is a direction. The opposite of rimwards is hubwards.

They still operate just like compass directions with specific names though, so this may or may not not solve the problem. You could define “right” and “left” “forward” and “back” and use those, but they’d work just like NSEW. That could potentially make more sense depending on the game if it’s just the direction names confusing people.

They have to be made in opposition so “right” would likely be the opposite of “left” and you could say The Dining Room is left of the Living Room. which would imply without further text that The Living Room is right of the Dining Room.

I suppose that would work if you show the player a map and tutorialize that the player is always facing “forward”. It won’t account for players who assume they can do things like TURN AROUND or TURN LEFT nor update the direction names relative to player-facing.

2 Likes