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.