Summary
I’ve been tracking DreamMaster’s efforts integrating GLK into ScummVM and noted Andrew Plotkin’s (Zarf’s) own remarks on GLK’s portability limits. Rather than continue squeezing every interpreter into GLK’s C API, I propose a lightweight, message-based protocol: engines emit JSON-style requests detailing content, styling, and input, and hosts reply with explicitly supported capabilities. This approach would let each platform—web, desktop, mobile—leverage its native strengths, avoid undefined behaviors (e.g., MCGA color mishaps in Zork Zero), and foster a community-driven spec maintained by implementers.
Background: GLK’s One-Size-Fits-All Shortcomings
DreamMaster’s recent ScummVM Glk integration highlighted persistent rendering issues—particularly with Z-code color in Zork Zero—which mirror the broader architectural limitations of GLK’s “maximally portable” C API (Wikipedia). Plotkin himself has since acknowledged that the universal interface model can lead to “impedance mismatches” when engines request features hosts simply can’t provide (Wikipedia).
In practice, implementers continuously patch around GLK’s lowest common denominator. DreamMaster reported ongoing struggles getting true VGA/MCGA colors and advanced text effects working in ScummVM’s Glk layer (The Interactive Fiction Community Forum). Likewise, Gargoyle, Spatterlight, and Lectrote developers have each built their own workarounds, combining GLK calls with platform-specific hacks (Wikipedia).
A Message-Based, Negotiable Protocol
Core Idea
- Structured Requests: Engines send JSON messages like:
{
"content": "red text",
"styling": { "zcode_color": "red", "fallback": "emphasis" }
}
Hosts parse these, render true red if supported, or fall back to italics—no guessing, no crashes (Wikipedia).
- Explicit Capabilities: On startup, hosts could advertise support:
{
"capabilities": ["ansi_color", "true_type_fonts", "touch_input"]
}
Engines then tailor requests accordingly, avoiding “unknown attribute” errors (Wikipedia).
Platform-Specific Benefits
- Web Clients: Map directly to CSS classes or canvas APIs—no GLK-to-DOM shim (Wikipedia).
- Mobile Apps: Declare gestures and fonts; native frameworks handle UI widgets.
- Desktop GUIs: Talk Qt, GTK, or Cocoa directly for rich typography and windowing.
By letting each front-end “negotiate” features at runtime, we embrace platform diversity instead of enforcing uniform behavior (Wikipedia).
Community-Driven Specification
Rather than Zarf alone defining GLK’s trajectory, a working group of implementers (DreamMaster, Spatterlight, Gargoyle, Lectrote, Parchment, ScummVM devs, etc) could:
- Draft a Core Spec for text, graphics, and input messages.
- Define Optional Modules (sound, animation, touch gestures).
- Iterate Openly on GitHub or a dedicated forum thread.
- Publish Versioned Releases with clear migration paths from GLK.
This collaborative model ensures real-world use cases drive the spec, not purely theoretical portability goals (Wikipedia).
Questions for IF Developers
- DreamMaster: Would explicit capability negotiation have eased your color woes in Zork Zero? Were there deeper Z-machine attribute semantics issues that a JSON protocol couldn’t solve?
- Spatterlight & Gargoyle Devs: Could you map your existing rendering layers to a message-based front end, and what stumbling blocks do you foresee?
- Zarf (Andrew Plotkin): Given your reflections on GLK’s portability limits, would you back a successor spec built on capability negotiation over a static C API?
Your insights will shape whether we refine GLK or chart a new path that truly leverages each platform’s strengths and preserves our MCGA Infocom classics in all their intended glory (The Interactive Fiction Community Forum).
References
- DreamMaster’s announcement and discussion of ScummVM’s Glk integration and its limitations (The Interactive Fiction Community Forum)
- GLK API overview, portability goals, and Plotkin’s remarks on its limits (Wikipedia) (Wikipedia)