I don’t see a problem with compass directions.
5 Likes
I’d like to note that those two things are completely separate. In, like…ADRIFT, where I think there’s usually an inbuilt map (though I’m not sure of that), so you have the traditional navigation directions but you don’t need to make the map. Unsure on if that actually helps out with a wide audience but it helps out me, at least.
I hate mapping, and can’t get through anything that requires it, so I set up an automapper, which is a huge bother if the game changes around room descriptions a bunch (Weight of a Soul specifically did a number on it). But if it were built into Inform that’d be swell and I’d love it forever.
I feel intuitively like the compass directions isn’t nearly as big a roadblock as the “argh I can’t remember how to get to the place with the shiny rock”. You run into the exact same roadblock if you have location names - “argh I can’t remember the name of the place with the shiny rock”. Pushing that memory into the system would be great.
Relative directions have been done, e.g. Battlestar, and were not very popular with players. You also have to make the room descriptions work for all supported player orientations.
1 Like
Well, I feel there are a couple of problems with the Blue Lacuna extensions themselves.
They’re very sensitive and notoriously bug-introducing for projects that aren’t Blue Lacuna. This one’s empirical.
The other one’s more conceptual. When you allow players to skip typing a verb (e.g. the go to function), you’re really altering the basic expectation of the parser, which is type an action, and maybe a noun. Skipping the action can work well for one game if that games teaches its rules, which is what Blue Lacuna does, but it’s not widely applicable enough to catch on because it’s too standard-breaking.
A good number of games now use GO TO as well as the compass, so GO TO has caught on, and the Approaching extension is a more general implementation of it.
-Wade
1 Like
For reference, there was a good discussion of this a while back. Here:
1 Like
Yes, absolutely. And it’s certainly possible to design a game that doesn’t need compass directions, but I think that’s a very specific kind of design. You need to build it in a way that it doesn’t matter how you get from one place to another, it doesn’t matter how the space is connected or what path you take, it only matters where you are. And certainly some games don’t want to fit in those design restrictions.
I think in a lot of cases you probably want compass/compassless to be options within the same game, if at all possible.
Yes, but as you also say, navigating more spatially helps a lot with re-routing. Especially if there’s branching or looping. And building a spatial layout when all you have is the chains and branches of connections is a hard computational problem. So I think if you leave out the directions you’re making it much worse for people who navigate spatially.
I’ve always been curious, if you think in terms of chains of locations, how do you build a feel for a bigger space (if you do)? Like, how did you navigate Eat Me, where the map sometimes changes as you play? How do you deal with, “oh no, this room (or connection) is destroyed and my route is blocked, now how do I get where I want to go?”
Or something like Sugarlawn, which has a lot of separate areas that are gated and looped together and there are often different ways to get to a particular place? I made an interactive graph of Sugarlawn’s locations and where the objects come from and go to, and even with color-coding for the regions, for me it’s nearly incomprehensible without dragging it into a shape that somewhat reflects the “physical” layout.
And on the “people’s heads are wired differently” subject, here’s a post from Chandler Groover in one of the most interesting old threads about compassless games. Lots of good points in that thread.
3 Likes
A lot of excellent points made in this thread, thanks to everyone for their input.
Just to reiterate, this isn’t about being against compass directions. Regardless of how the arrangement of locations is described to the player, there will inevitably be a layout, which constitutes a map and therefore places are going to be N,E,S,W of other places, and so compass directions should definitely work when used as input.
Here is what i understand from people’s responses:
-
Players want a map and the system should draw it.
-
You can click on map locations to move, possibly even for remote "go to"s.
-
For a given place, if it doesn’t describe adjacent locations using compass directions, then there needs to be an easy way to learn this, possibly made obvious by the map. This reflects the idea that some people think more spatially than others.
-
N,E,S,W,U,D, in and out, should work as input for games that need a map.
-
When compass directions are not made explicit in text, there should be another, less directional, navigational input form. Ideas are; keywords, GO completion, landmarks.
-
There could be a non-text-input, navigator “widget”. This could be a generalisation of the “compass rose” concept, but not necessarily be a compass. I don’t have a clear idea of what this might ideally look like, but obvious ideas are; a mini-map, a shortlist (popup?) of adjacent place names, or even a traditional compass rose with location names on it as well.
-
From an authoring perspective, some styles of games “work” with NESW and some don’t.
-
Some styles of game do not need a “map”, per se. or even directions! Particularly ones less object based and more situation based. These are often “hub” based, or an event flow. For example, when you play a choice game, you don’t (normally) start trying to figure out where things are spatially.
-
The style of games which benefit from spatial mapping is related to the “game mechanic”. Those that are object based, ie where challenges are built from using objects in various ways, are usually the ones that require a spatial model. Alternatively, games based on situational flow, often do not, or at least very little navigation is needed and often hub based. Example: Sherlock Holmes gets in a cab for each location. ie You don’t expressly need to know where Hackney is in relation to Shoreditch.
6 Likes
Surely it is not the case that the game layout necessarily implies compass directions.
Several of the solutions you suggested (visual map, clickable choices, compass rose) would not be accessible for visually impaired players such as myself.
The only way to make games which implement such systems accessible is to make compass directions available as well, which negates the point of creating the system in the first place.
2 Likes
Clickable choices can be made screen-reader compatible (in the same way that choice-based games in general can be made that way). However, care needs to be taken that a game consistently is screen-reader compatible. I could imagine a compass rose also being made screen-reader compatible. Visual maps, on the other hand, are very difficult to make screen-reader compatible.
Of course, the screen-read experience is different to the visual experience. However, that’s OK provided neither experience is made second-class to the other.
1 Like
Rubbish! Making “compass directions available as well” is not the only way!
What you’re saying is there needs to be an accessible method for the UI. I totally agree, but don’t insist that N,E,S,W are set in stone forever.
1 Like
Compass directions for navigation are historical for parser games, though many have tried other solutions like “go to the boardwalk”.
If you’re using Inform 7 I made an extension in the public library called “Easy Doors” which essentially allows authors to place a door in a room as an object without using a compass direction.
While easy doors by default work like regular doors that can open and close, you can also declare them “open and unopenable” so they are just a a passage - like a teleport. This means you can place a door and call it “a route to the boardwalk” so the player can type ENTER BOARDWALK, GO BOARDWALK, (any synonym for ENTER) or even just BOARDWALK and it will transport the player there. You could technically write an entire I7 game with no compass directions in this manner.
I’m not experienced with screen-readers, but the door descriptions should show up like usual in the game transcript and can be interacted with normally without the compass directions.
1 Like
“Goto” location is available in Dialog.
1 Like
I’m sorry if my earlier comment seemed a bit harsh. But, I’ve actually been thinking a lot about how to make modern games more accessible. The question is, how to evolve the UI whilst also improving accessibility.
Take a visual map, for example. This would be great for most people. They could
just click on adjacent locations or even remote ones as a form of GO TO. But how does this work with accessibility?
One idea is that it supports a kind-of “caret browsing mode”. This is a term from screen reader parlance that refers to being able to cursor about manually with the keyboard and have snippets read out via TTS.
@HanonO Your, extension for “Easy Doors” also helps this, by transforming directions into objects.
Anyway, aspects of accessibility is a whole new thread of conversation. But briefly, there’s a wider problem that technology is moving faster than screen readers can cope. More and more apps are no longer working with traditional readers. Even browser-based content. Since, as soon as you start making things graphically richer, fancy fonts, animating your text, more use of symbols and icons and so forth, supporting accessibility becomes part of the app rather than a screen-reader thing.
1 Like
What about Left (L), Right (R), Forward (F), Back (B) and up/down? This should be intuitive to most people, either to type or click on a compass rose. When someone asks you where the bathroom is, you say something like “Go BACK down the hall and then it’s on the LEFT.” And everybody gets that. You never say “Go north and then west.”.
1 Like
The problem with left/right is those are relative directions. People understand those directions in the physical world. Tank controls can work in a well-authored situation or with graphics - and they are common in slideshow explorers like the original MYST where you can see the movement. Also in Twine where there is no world model authors can make links: Take the [right door] or the [left door]? [Go to the bathroom.] [Go back down the hall and turn left…]
It can get extremely confusing in parser because left and right also needs to take into account the player’s current orientation and then model and describe that. “Go BACK down the hall and then it’s on the LEFT.” implies that the person is walking backwards and then are they turning left (or are they strafing (sliding) left?) Instead of going BACK then LEFT, can I go LEFT twice to turn 180 degrees and then go FORWARD…then is the bathroom still LEFT or is it now on the RIGHT since I’ve turned around? Then if there are diagonal hallways it gets even more difficult.
The reason map directions got standardized is they aren’t relative. NORTH always implies the same direction no matter the player’s imagined orientation.
4 Likes
Most blind people don’t use a mouse, and barring use of Windows OCR and NVDA commands to move the mouse, it would be difficult and virtually impossible to click links in parser games while running in native interpreters (think Glulxe or the TADS interpreter). The same applies to a compass rose, which whenever I’ve seen it used, is displayed in the status line, and requires the individual directions to be clicked on to move around, which as I mentioned, would be virtually impossible for blind people to click on in a native interpreter.
In a web environment like Vorple or Parchment, clickable links to travel would be fine; as my use of this site can attest to, 99% of screen reader users know how to activate links using a screen reader and the keyboard.
2 Likes
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.”
Thoughts?
(p.s. I’m sure anyone who’s looked at Dialog will see where most of this comes from.)
1 Like
Well, if you stated at the outset that the player will always be facing forward, I can’t see that being too confusing, although certainly a little artificial. But if someone wanted to make it work, I think it could be done.
1 Like
Many clickable links I’ve seen have been in games that can also be keyboard/keypad-driven (that is to say, the mouse is an option rather than a compulsory feature). Of course, if you’ve experienced quite a few games where that didn’t happen, or it got implemented badly, you’d have every reason to be sceptical of the technique as a panacea.
“I could imagine a compass rose being made screen-reader compatible” was intended to mean that a compass rose can be programmed in a way that a screen-reader could correctly interpret. This all goes to show that accessibility has to be laboured for and can never be assumed by a creator.