Oy! Don’t be mean about it. :)
(In the 80s, a computer lived on a desk covered with piles of paper so it was easy to take notes. That is no longer a universal truth. People are gaming on mobile devices, or sitting on the couch with a wireless keyboard.)
I don’t believe that’s true for parser games. Every time I play one on my phone, it has always been painful. If you’re talking about laptop devices, you can always open a mapping app in addition to the game.
I still sell a few copies of Hadean Lands for iPhone/iPad per month.
Not everybody uses those. If you tell people they ought to use them, they may reasonably respond “So why isn’t it built into the interpreter?”
I realize I’m in the position of saying “Interpreters should do mapping, and also it’s impossible for interpreters to do mapping.” Sorry! This is hard!
Something like this? (requires monospace font)
ABC
-D-
-E-
A: Forest
B: Junction
C: River
D: Bridge
E: City
Or this with “arrows”. I suppose I can use FJRBC, instead of ABCDE.
F-J-R
|
B
v
C
Edit: Added dash to the map, hoping screen readers will read it as dash D dash, dash E dash to represent empty places.
Edit: changes the second map symbols with directional exits.
\|/
-X-
/|\
^
<*>
v
That is why I am proposing a map-file in addition to the transcript. If the author had drawn the map you have just presented, he could export it as a map-file and the player’s map-display program would know exactly what the map should look like. And when the player has visited all locations, the map will be identical to the map the author made. Before visiting all locations, only visited locations should be visible in the map display.
There is already a map of ADVENT’s mazes here:
http://solutionarchive.com/file/id%2C22857/
So if the author supplies a map file with this information, the mazes can be drawn. However, the author could choose to make the maze locations or connections invisible as they may regard it as a puzzle the player has to solve unlike the rest of the game where mapping may not be regarded as a puzzle.
So, if I were thinking about interpreter-based automapping (for Inform games only), I would say:
Put two resources in the blorb. One is the map, as a text-based layout, roughly as Harry Hardjono described above. The other is a metadata file with a very simple format, on the order of:
493408
123450, wohouse, West of House
123670, kitchen, Kitchen
123750, troll, Troll Room
The first line indicates a VM memory address for the game’s location variable. The following lines describe values that can be in that variable. Each room has an identifier and a human-readable name. (You need both of these, because many rooms could be named “Maze”.)
Where do those magic numbers come from? From game.inform/Build/gameinfo.dbg, that’s where. That file is generated on every compile and it includes the memory addresses of all variables and objects. The author would have to extract this info from gameinfo.dbg and shove it into the map metadata.
This scheme would work for I6 and I7 games, Zcode and Glulx. (In Z-code the addresses would be 16-bit values rather than 32-bit, but that doesn’t affect the data format.)
Of course this scheme is very simple. There’s all sorts of stuff it doesn’t handle. (Rooms whose names change; multiple game locations implemented in a single Inform object; etc, etc.) But I would not go down the road of adding features to the format to support every possible game concept. Keep it simple.
Would this cater for directionality? My concept of maps is that passage between locations is directional and mutable. A tunnel may be blocked. You can get down to the Deep Pool by jumping off the Waterfall, but there’s no way back up, etc.
If I understand your proposal correctly, I think it will be too simple for most games. Perhaps those who made Trizbort could tell us about their experiences with auto-mapping. They might have an idea about which features are common and which are not.
A map-file does not have to be easily readable, as long as everyone has a map-viewer / creator some time in the future.
I do have a format that gives LocName, ExitDirs, Items, and Notes. However, it’s not screen reader friendly and too much work for a default, built-in map.
But yes, the maps shown above are simple by design, more of a mind map hints/hooks, so to speak. Good for small, simple games, less so for big, complicated ones.
Edit: Streamlined Description.
Yes, it is. An auto-mapper should - imo - only reveal what the payer has already discovered.
Personally, I would mark the map with an arrow between two locations with the verb that took the player there. Not just “north, south, etc”, but “Plugh, xyzzy, y2”.
I agree that if a bridge collapses behind you there is no way for the automapper to know that, but I would allow the user to edit the map or, at the very least, to add comments.
Personally, I would mark the connection with the verb that took the player there. It might be “starboard”, it might be “jump”, but that is how I would annotate the arrow.
Perhaps both North and South get me from the kitchen to the lounge. I would only annotate the one which the player used. If he later uses the second, I would add that too
This will be a player preference, whether you like it or not.
[quote=“mawg, post:30, topic:48090”]
An auto-mapper should - imo - only reveal what the payer has already discovered.
[/quote]
This will be a player preference, whether you like it or not.
Not if I code it, won’t. If coding an auto-mapper means revealing the entire map from move one then I will have no part of it.
This lóoks like it has great possibilities, thanks.
Is it only good for their interpreter? Do they have TADS and inform interpreters? I must read further after work, but it’s definitely the sort of universal system I would like to see.
Although, I am definitely not enamoured of their Lisp based programming language 
Not bad, but it seems to only support standard compass directions. It could be forked, but I dream of something more universal. Tha is for pointing it out, though
It’s people like you who make life “interesting” for people like me 
It works with any system that can send JSON messages.
For my interpreter I added functions to create JSON messages and a library that takes care of the JSON stuff.
For an impression you may look here (click) under the IFI-XVAN section.
Trying to restrict it is futile as players will either bypass whatever you do or others will specifically code a version that does what they want. Anyway, it’s no different than getting a complete map from the web or (back in the Infocom days) often included with the game itself.
I have partially implemented a z-machine specific design in my interpreter somewhat close to what you suggested.
Mine uses an author or community supplied image file and metadata file which can be stored in custom blorb chunks I created. It handles revealing rooms and connections as you play, including secret or one-way connections and can display the player’s current location and various other dynamic game info. It also supports revealing the whole map if the player desires. Support is pretty easy to code, and it uses a custom quetzal chunk I created to handle map state saving.
Maybe I should write something up.