I believe Hunter, In Darkness uses relative left/right/forward/back directions.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.)
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.
Note: I am of (subjectively) sound mind and knowingly reviving this thread.
Something for consideration on the visual GUI side of non-compass direction navigation was the classic Shadowgate (and the other games that used that engine: Deja Vu, Uninvited, etc). It was a graphic adventure, but the navigation square made a mental footprint into the playerâs mind. Even if you didnât remember how things were arranged on the world map. Notice how the navigation square is nuanced with where the destinations are located.
Might not be of use for a text adventure game, but I found that Shadowgate was easier to navigate (see what I did there ) because there was uniqueness to each roomâs available paths. You saw where you came from (uniquely displayed) and possible new destinations (uniquely displayed). Seeing something thatâs just a little towards the upper left doesnât feel like the same north of another roomâs north. In fact, I never really thought of the paths as compass directions at all. I just thought: up, down, left, right⌠and even then, I didnât even need to associate the directions with words. It was all visually described.
For text adventures, I think giving major landmarks a compass direction in the prose would help with cardinally challenged folk. For example, Iâve noticed that I donât immediately know compass directions while driving in a city. However, if I associate a cardinal direction with a major landmark, like a mall or car dealership, I then know if someone says, âHead north to the grocery store.â I know to travel towards the north mall, and that the south dealership is in the opposite direction. Iâll find my way eventually without the nagging feeling of being completely unsure. If you associate a game map region with a general direction, it might help players navigate easier.
Food for thought.
And if Iâm remembering correctly, Shadowgate-style navigation could more, for lack of abetter term, elegantly handle having multiple exits on the same wall of a given room.
Though, this thread makes my mind wander to places that completely break the 8-way compass and up/down based mapping. Such as a world built on a hex grid, a circular room with say, 7, 9, 12, or 13 equally spaced doors along itâs circumference, a 3-d map built on a rhombic dodecahedral honeycommb, a tower where there is a lot of vertical movement, often with multiple paths up/down, or navigating the branches of a great tree. And the above example of defining turnward/withershins/hubward/rimward has me wondering about navigating a layered spherical map(such as a spherical space station built as concentric shells)
@Mewtamer Thatâs correct. Good memory! It even allowed for exits anywhere within the middle area of the navigation square, sometimes denoting vertical exits on the floor or ceiling.
I think your idea of a space station with concentric shells would make navigation an interesting mechanic in and of itself!