Inform 10 and FyreVM

This is a request for the Inform dev team. It would be nice if the team would consider migrating the FyreVM extension to the new platform. This would be an alternate IO for glulx using channels (key/value pairs) with a handful of default channels automatically inflated by the extension (location name, score, main description, etc) and author created channels for other content. The latest version of FyreVM even described channels with content types to help any client with text emitting.

Without this effort, FyreVM will become a footnote and I think that would be sad.

I’d even suggest the IFTF use its grant program to entice a developer to tackle this issue.

Off the top of my head, it seems to me like if this were to be pursued, it’d make more sense to think about changing Inform I/O to facilitate creating any number of things like FyreVM rather than to update FyreVM support per se. Something like (vague handwave-y 50,000 foot view)…

Everywhere there’s output today, it’s replaced with sending a message to a dispatcher. This message includes what function (or maybe more discrete than that for giants like Parser__parse) is originating the message, a code for why it’s occurring, and the text of the message. The default dispatcher would just pass it on to something that outputs it, but a FyreVM dispatcher could decide which FireVM channel is right for it and send it there. (And other people later could carve things up differently.)

OK, we wouldn’t want to literally be doing this on a per character basis in all the places where we’re looping through a buffer printing characters, so this would involve passing the buffer in those cases.

(I do think isolating the View component would be a big improvement.}

1 Like

As far as I understand the new constructs:

  1. Still need to report to Glulx when FyreVM is enabled
  2. Default emissions would go to MAIN/text
  3. Target specific emissions like location name, score, turn, etc would go to LOCATION/text, SCORE/number, TURN/number, etc.
  4. Allow authors to create new channels through Inform 10 syntax.

There are a ton of I6 replacement routines in the current extension and most are just trapping IO and deciding to handle text emitting accordingly. It’s this block of code that befuddles me.

What about inputs? What can be sent to the game other than game commands?

That’s just basic Inform functionality. Since FyreVM lets you control the UI, you could have it “ping” the game engine for data. You’d set up a meta command and channel, and when the UI wants it sends that command silently to the game engine, the command is executed which could do anything you want to game state or just retrieve information), then sends back whatever information you want back to the UI. How the UI displays that information is also entirely up to you. Maybe it doesn’t show anything. Maybe the silent command changes game state, but it’s not “visible” to the PC. Maybe your UI has a map and NPC locations are updated every few seconds.

That’s exactly what i was thinking. So there would need to be a metadata protocol.

Well you’d design what you need. You don’t need a standard. My Cloak example uses JSON and mostly the standard output. The only custom emission is the header data.

1 Like