Thanks Peter, for me it’s very intuitive because I have Trizbort open next to Windows Frotz with automapping on, so it’s very intuitive for me to look at the map and just ctrl+press the direction I want to go to without having to think about the compass directions, for some reason (English as a second language might be one) I usually have to think for a second whether left\right is east or west, and so the diagonal directions all have the same issue with me as they all contain a west\east component, for whatever reason I don’t have the same issue with north and south, go figure
Heh. GUEMap had a feature that maybe Trizbort could benefit from. Does anyone remember? You picked a starting room and a finishing room, and you got a series of commands (“n.e.e.s.se” style) that you could paste into your game to move to that room quicker.
A bit off topic, except that it’s still in the general subject of making it easier to navigate.
I always had a LOT of trouble on the E/W thing as well, and English is not my second language either! In Portugal, we have a funny trick to remember that: to the right of Portugal as seen on a map, i.e. to the east, we have Spain (Espanha - capital E) and to the left of Portugal (west) we have the Atlantic Ocean (Oceano Atlântico - O for “Oeste”, or “West”). I still use that trick a lot.
Another thing I use to remember is a stupid visual/sound pattern. In the game “The Muppet’s Treasure Island” there was an extremely simple “puzzle” that revolved around cardinal directions. I still hear the voice: “North, south, east and west; prepare the gold to find the rest”, or something (my English wasn’t as good back then - I was a kid!). And I remember the visual pattern that indicates - up, down, right and left.
When you consider all of this, it gets hard sometimes to explain to people exactly why cardinal directions are a good idea.
(when it comes to nautical navigation, though, forget it. If the game allows cardinal and nautical, I go full cardinal. If I’m stuck using aft/fore/port/starboard, I’m perpetually lost)
I think that modifying the interpreter would generally be a better idea though, rather than using AutoIt. Depending on the interpreter it may use a front-end and back-end (one example of such is JSZM), so just modifying the front-end will help with this.
Also, some games may use ship directions in some places, or perhaps something else. (TAVERN defines status-line types 10 to 13 for these purposes (and I intend to also add specification for menus, including a direction menu). Z-machine XZIP supports a “direction menu”, although the specification is unknown. Although, Z-machine XZIP and YZIP also support terminating character table which can be use for using number pad as directions.)
I encourage that we work to get a new API call for compass directions built in future Glk API so it’s a standard thing for multiple interpreters. As almost all Interactive Fiction interpreters have a concept of compass direction and room movement that I’ve seen. I know it would be nice to be able to use swipes on mobile phones / tablets with touch.
You could make command macros to send strings as input, but a standard API with a standard set of integer numbers can do a few other things: The game engine can tell the user interface which directions are valid on room exits with standard codes, the API can let the user interface know when they are valid (maybe it is at a YES/NO prompt and can’t accept them), and you deal with non-English language localization based on the standard codes, etc. My point is that Glk is specifically made for Interactive Fiction - and compass directions are pretty standard (and go back to the 1970’s original game, Colossal Cave Adventure). I would propose it would be an optional set of API functions like Glk defines optional features for sound and graphics on client apps.