VΘXΔM: a Z-Machine, Glulx, and Å-machine interpreter in Python

[dfabulich (Dan Fabulich)]

@Jeff_Nyman

I mean, really, this is kind of a solved problem, in a way. What a mapper needs from an interpreter is tiny: a stream of structured events. {“moved”: {“from”: 42, “to”: 57, “name”: “Round Room”, “command”: “east”}}, plus maybe room-seen text. That’s it. So the contribution worth making isn’t even an app, it’s a little protocol: JSON lines, written by any interpreter in any language, read by any mapper. Think LSP, but for game geography. Basically, structured data instead of text heuristics, which is what fixes the identical-name maze problem.

In the other thread, I raised that approach, but folks didn’t care for it, because the API would be too confining/specific.

@dfabulich

But what if the game wants to control more stuff?

• Room shapes: octagons, triangles, ovals, rounding corners, etc.
• Room border styles (dotted, wavy, colors, no border)
• Line thickness
• Fonts
• Putting more text in the room (subtitles, object lists)
• “You are here” symbol appearance (icon vs. color)
• Link port labels (“trapdoor”)
• Other overlays:
  • @ShardWorkX wanted to put little dots representing various NPCs on the map
  • Having several room colors, to depict different types of rooms (does the game decide? What about if the user prefers a dark mode UI vs. light mode?)
  • Putting rooms into containers (with background colors, titles)
  • Arbitrary non-room text on the map

Every individual thing on this list would require more API.

My current approach supports either a SVG map that the terp builds based on seen/unseen rooms as a string, or a rasterized JPG/PNG map, with overlays (e.g. “you are here”).

In Glk, there’s a constant push-pull tension between letting the author control what the UI should look like (making the UI less customizable), vs. describing the UI semantically, letting the Glk application and/or the user decide what it looks like.