I have a maze which is a small part of a larger WIP. The maze is a 8x8 grid. All 64 passages have a description. Some passages include items that can be picked up and used but are not required to solve the puzzle. I have labeled the columns A-H and the rows 0-7. The player starts at C7 or D7 and has to work their way up to the prize at H2.
As the player moves through the maze, each move is printed in the sidebar, ie. C7 C6 C5 etc. The player can only go forward, backward, left or right but there are some walls up so not every passage will have all those options.
At first, I labeled the possible moves with the passage name. Like B7 C7 C5 D5 but I felt this was very confusing. So I resorted to WSAD as navigation choices - but again, not every passage will have all 4 movements available due to walls.
I am finding this maze very difficult to navigate and I created it! At move 7, the player finds a note that has the shortest path to the prize like this: C7 C6 D6 D5, etc. But even after finding the note, I am finding it confusing and am certain most players will give up at this point.
So I am looking for advice on how to possibly simplify navigation but still challenge the player.
Also, the passages that lead to the prize include colors in the passage description. I am hoping that is a good hint.
I think labeling choices this way is likely to be confusing to anyone who isn’t familiar with the conventions of video game interfaces—there are a lot of people who are into IF and don’t play any other kind of game. Honestly, even though I am familiar with those conventions, I think I would struggle with it a bit because I’m not relating the keys to the letters in my mind when I’m using them for navigation in a game, if that makes sense. What about using compass directions?
Other than that, the navigation sounds about as simple as it can get (short of adding a map graphic that displays the rooms the player has been to and shows their current position, which would be much more complicated to implement). What are you finding confusing?
Compass directions might work. I think I might try arrows, too. I thought about including a map, which I still might do, but yeah, a lot to implement. I guess the most confusing part is just not having a visual to go along with the movements. I thought the breadcrumbs would help.
Having a visual can definitely be helpful, but not having one might be less of a problem than you think. A lot of IF players are used to mazes without visuals and will draw their own maps if need be.
Using forward, backward, left or right is an issue in parser IF, as the player has to mentally track not just position but also the direction she is looking. Going left means a change in position AND orientation, or so I guess, but perhaps just a change in one or the other? It is not intuitive and not familiar to IF players.
This is why parser games pretty much always use north, south, east and west.
If every passage has a unique description, it should be no more difficult to navigate than a parser game.
Having a mini-map displayed on the sidebar is also an option. Overlaying an “X” on top of the map image where the player is located. Granted, it won’t be very detailed given the large size, but would help with giving the player a general sense of where they are. It would take a lot of unique CSS classes to do that though (each giving the proper position offset for the X).
You could also do a map with two images, one for the maze, one the pointer, and set the position of the pointer using SVG or CSS via JavaScript, but any mapping solution will be quite difficult technically (relative to normal Twine stuff).
It’s also a massive pain to code. Players didn’t seem to find it confusing when I did it, probably mostly because it was in a house and once you’d seen a room, “there is a door on the left” would become “there is a door on the left leading to the kitchen” or what have you (also, it was a lot smaller than the maze being discussed here). But tracking where the player was coming from to provide the correct description of what was where and send the player to the right place when they moved again was much more work than using compass directions would have been, and it introduced a lot of room for human error, such that that section was the second-buggiest part of the game on release.
So yeah, I don’t recommend it. When I said arrows would be okay too, I was thinking of them as standing in for N/S/E/W rather than forward/back/left/right, but just naming the compass directions is less ambiguous, for sure.
“You are in a maze of twisty little passages, all different.”
In the past, finding one’s way in such a maze has been done manually by the player, drawing the map of interconnections (usually on paper) while navigating through them. As I recall, though, Colossal Cave’s mazes were quite a bit smaller. (12 rooms?).
Note that an eight x eight arrangement results in 64 rooms, not 48. (six x eight = 48). Is there a typo in the original post? The number of interconnections among the rooms would be larger, of course, especially if they’re actually arranged in 3 dimensions, not just 2.
One way to display the player’s location among the rooms would be to create 64 (or 48) unique images, one associated with each room that the user can be in. Then display the image associated with the current room. The coding for that should be relatively simple. Of course, if you want to show the path that the player has followed, that’s a different matter entirely.
A simplistic version of such image might look like
One common trick when implementing a Maze like that in Colossal Cave is to break the assumption that just because you went north to enter the next room means that you can return to the previous room by going south.
The connections between rooms normally looks like…
A D
| |
B---C---E
…which allows someone heading east from B to C, to return back to B by reversing the direction of travel. eg. by traveling west.
But a good maze can have connections between rooms like so…
.---.
| |
D |
A C--------.
| | |
.---B---. E---.
…which still allows moving from B to C by heading east, but this time to return to B they would have to head south instead.
This reminds me a bit of You May Not Escape! - Details (ifdb.org). A rectangular maze with a randomly generated layout. Navigation was the usual n s e w and I drew the map along the way. The advantage of knowing it has a rectangular layout is that players will quickly spot “holes” in the map and will quickly find where they did not go yet… I think the map drawing is kinda part of the fun of this kind of maze. Showing the position on screen makes me wonder though… how would that play out for people using screen readers? Would they get a long list of “square bracket open, square bracket closed” read out to them? If so it probably would make sense to make showing the map optional. Also, will the map show more than your current position? (e.g. the locations already visited?)
