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.
@Dizzydonut You have a good idea there! This also overlaps with the problem of word completion, which also needs to be context specific.
Iâm going to have a go at implementing this. However, it might be done as part of word completion. For example by showing you (somewhere) the word it thinks youâre typing. so GO K would show the word kitchen somewhere, so you know youâve typed enough. Pressing return would finalise the completion.
It could do something similar for other verbs too.
1 Like
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.
3 Likes