IFI, Strand's Interactive Fiction Interface looks extremely interesting, but are there any TADS or Inform interpreters which support it?
3 Likes
Ideas like that have been raised several times before. @DavidC in particular is interested in separating the display layer from the interpreter backend.
The problem is you can’t easily do that in most IF formats. The memory of a storyfile is just a big blob of memory, and from the outside you don’t know what belongs where. So the storyfiles themselves would need to be programmed to send metadata explaining the state of the world. You can do this now, and occasional projects have then used it in custom interpreters, but it’s complex and not generalisable.
2 Likes
This was the fundamental reason in developing FyreVM. Its dynamic key/value pair messaging system allows the author to provide any kind of meta data they want to a client. Unfortunately, the IF community never embraced the concepts, favoring legacy Infocom models and that’s still true today outside of Twine development.
I’m still interested in separating IF concepts, but I’m driving into the base requirements like parser, world model, grammar, and output as distinct services in an event-driven architecture.
And I’ve abandoned interest in existing IF platforms since I believe they are all bolted to the past and have irredeemable flaws. Plus we’re at a point where creating IF systems on powerful platforms like C# has extensible advantages.
3 Likes
100%
2 Likes
Here’s a really old test using IFI + Inform to run PBP’s Bigfoot Bluff.
I added some pictures in as tests, with apologies to BPB for hacking his game.
x me for a pic.
1 Like
Yes indeed. In IFI the back-end game does no file IO because sometimes there is no filesystem.
For save/load it has to send a “blob” to the front end for saving and request one for restore. Also the front end can request such a blob from the game. For example when you click on a “save” menu.
However, this wouldnt really need changes to the story file. the game engine could “pretend” to save into a blob and use that.
1 Like
Creating a custom interpreter just for display seems like an over-engineering effort to me. I may be biased since I use Linux OS, but all my approaches so far use a custom display system.
Z data → Frotz ↔ IO system.
Where IO system can be
- Web server + Web browser
- Glk Interface program
- X Windows client/server framework
- Processing/Java custom IO program
- Javascript in a browser.
For #5, I was looking into a JS Z-machine interpreter, but it’s not like I have to create a whole new interpreter. Merely stream/pipe the output to a JS routine.
About the story, you just set up a flag variable that says optional graphic commands to be sent, such as
- (see pic 23)
- (star chart 190929)
- (sound of bell)
- (Floyd looks depressed)
etc.
Something that can pass as normal text as to refer to a picture book elsewhere, but actually something that the IO system can have access to and display appropriately.
The IO system doesn’t have to do anything other than pass user commands and format the output of Frotz appropriately. Even the save data blob is done by the Frotz program locally, wherever it is located.
No need to build a whole new windowing system into the story data, which is what the Strand IFI is doing, IMO.
2 Likes
I think the story should be able to control certain properties of the UI. This is an interesting area.
For example, should the story be able to suggest a font? Or maybe a font style? If the story can play sounds and emit pictures, what about icons? What about a handy list of things carried. The GUI can ignore this or use it.
So i see this as a “meta window system”. Where the story can pass information and the UI choose how to display it. Some things come under the rubric of hints to the UI. Maybe the style of font. Maybe some story UI preferences.
How about the map, for example?
2 Likes
Sounds like HTML to me. AFAIK, we’ve been fine with just text only. Leaving things to mostly IO will cleanly separate story and media, and leave it to the user how they want the map displayed, either by pictures, fixed width text, or audio cues.
1 Like
You guys REALLY need to look at fyrevm. Take a look at the Core extension and then some of the extensions adding on to that. None of this translates to the current version of Inform since the entire I6 subsystem was replaced. It’d be awesome if fyrevm was re-implemented, but that’s not on anyone’s radar at the moment, including mine.
fyrevmweb-react/extensions/David Cornelson at main · ChicagoDave/fyrevmweb-react (github.com)
4 Likes
Fyrevm looks as if you definitely need a web browser at the other end. I’m thinking customizing Parchment would be a more convenient way to go.
If you want HTML stylistic cues, Markdown is a good substitute.
1 Like
There’s a C# version of FyreVM ( ChicagoDave/fyrevm-dotnet: Glulx Virtual Machine in C# (github.com)), so theoreticlly one could build any type of client and with .NET Core (.NET 8 at this point) entirely cross-platform. The web version actually came second and was enabled by glulx-typescript, a library I had built by a third-party developer and also has a github repo.
3 Likes
Controversially, i think HTML is a really bad way to describe a UI. It’s awful at describing layouts.
The other day i tried to put some text on the left and a picture on the right in HTML. Like you might want in a game. And a caption under the picture. And i wanted it to be responsive when you size the view.
Yeah! about 4 hours later, i sort-of got it working.
2 Likes
That’s exactly what you don’t want to do. If you do that it will always be inferior to the displaying the map game specific.
However, I’m proposing the story controls the map display not the user. So there is an element of choice, but only for the author.
1 Like
HTML isn’t bad. It’s just one of many ways. The nice thing about html is you can make fluid text interfaces like Liza Daly’s Harmonia done in React: https://harmonia-game.com/
I’m on board with author control of the UI. Users should be focused on play. That said, there are ways of using meta data to enable some user choices.
1 Like
I don’t really want to argue between HTML or not. It would be a lot of people’s choice for UI layout. But personally not mine. Thanks for the game link. There are some nice touches there.
You mentioned fyrevm, I looked at the links but there were no docs on any overall concepts i could find. What was the deal there with how the game connected with the UI? And what kind of things could the game send and have the UI see?
If it could send things like the player inventory, location, exits, mapping, images, sound, preferences etc, then it was a great loss that this system wasn’t developed further and maintained.
2 Likes
I used to have a web page describing everything. FyreVM is an alternate IO subsystem within Glulx where the standard is GLK (a hard windowing system).
Instead of implementing windows within GLK and flipping how Glulx works (instead of the client containing the VM, the VM is a black box you send commands into and get a JSON response).
In the case of FyreVM, you get a list of JSON key/value pairs I called “channels”.
The Core extension enables basic channels from the default emissions within Inform 7’s logic. So out of the box, you get:
Section 0 - Dynamic new channels
To decide which number is the next channel id:
(- GetNextId() -).
A channel is a kind of thing. A channel has a number called id. A channel has some text called content name. A channel has some text called content type.
main-channel is a channel with id 1296124238 and content name "mainContent" and content type "text".
prompt-channel is a channel with id 1347571796 and content name "prompt" and content type "text".
location-channel is a channel with id 1280262990 and content name "locationName" and content type "text".
score-channel is a channel with id 1396920146 and content name "score" and content type "number".
time-channel is a channel with id 1414090053 and content name "time" and content type "text".
death-channel is a channel with id 1145389380 and content name "deathContent" and content type "text".
endgame-channel is a channel with id 1162757191 and content name "endGameContent" and content type "text".
turn-channel is a channel with id 1414877774 and content name "turn" and content type "number".
storyInfo-channel is a channel with id 1229866575 and content name "storyInfo" and content type "json".
scoreNotify-channel is a channel with id 1397641044 and content name "scoreNotify" and content type "text".
contentManagement-channel is a channel with id 1129138004 and content name "contentTypes" and content type "json".
ifid-channel is a channel with id 1229343044 and content name "ifid" and content type "text".
In your story, you’d “open” or “set” a channel with this code:
The author can add their own channel with one step:
my-channel is a channel with content name "myChannelContent" and content type "text".
2. To use your channel:
say "[on my-channel]This text will appear in your new channel.[end]";
3. Alternate use:
select my-channel;
say "This text will appear in your new channel.";
select main-channel.
Standard Channels:
main-channel - The main channel is meant to handle the regular text window output.
prompt-channel - The prompt channel defaults to the common ">" caret, but can be altered to be anything.
location-channel - The location channel contains the current location name.
score-channel - The score channel contains, if any is provided, the current score of the game.
time-channel - The time channel contains the current number of turns or the current time.
death-channel - The death channel contains any output that happens after the player dies. This is separated from the main text so that the UI can handle it contextually.
turn-channel - The turn channel has the turn count, regardless if time is the primary timekeeping method.
storyInfo-channel - The story info channel contains JSON with all of the banner and general story information.
scoreNotify-channel - When scoring is used and the score changes, the change value (up or down) will be posted to this channel.
To add something like an inventory channel would be simple and you could iterate carried items and emit them as a JSON object list within the channel. In your HTML, you’d be able to bind the JSON list directly to the DOM.
In the C# version, using wither JSON or XML is workable.
To see it in action, check out:
plover.net/~dave/cloakjs/
Open up the dev console and you can see the interactions with the VM.
{mainContent: `\n\n\n\n\n\nYou are standing in a spacious hall, splendi…f="#" onclick="sendCommand('west');">west</a>.\n\n\n`, contentTypes: '1296124238,text,mainContent;1347571796,text,prompt…t,themeContent;1515864388,json,statusLineContent;', storyInfo: {…}, themeContent: 'day', statusLineContent: {…}, …}
bannerContent
:
"Cloak of Darkness\nA basic IF demonstration using FyreVM by The IF Community\nCopyright © 2021\nRelease 1 / Serial number 210618 / Inform 7 Build 6M62 (I6 lib/v6.33 lib 6/12N )\n"
contentTypes
:
"1296124238,text,mainContent;1347571796,text,prompt;1280262990,text,locationName;1396920146,number,score;1414090053,text,time;1145389380,text,deathContent;1162757191,text,endGameContent;1414877774,number,turn;1229866575,json,storyInfo;1397641044,text,scoreNotify;1129138004,text,contentTypes;1515864385,text,bannerContent;1515864386,text,prologueContent;1515864387,text,themeContent;1515864388,json,statusLineContent;"
locationName
:
"Foyer of the Opera House"
mainContent
:
"\n\n\n\n\n\nYou are standing in a spacious hall, splendidly decorated in <em>red and gold</em>, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways <a href=\"#\" onclick=\"sendCommand('south');\">south</a> and <a href=\"#\" onclick=\"sendCommand('west');\">west</a>.\n\n\n"
prologueContent
:
"<span class=\"p-style\"><span style=\"color: green\">Hurrying through the rainswept November night, you're glad to see the bright lights of the Opera House. It's surprising that there aren't more people about but, hey, what do you expect in a cheap demo game...?</span></span>\n\n"
prompt
:
">"
score
:
0
statusLineContent
:
{showLocationName: true, showLocationAddendum: false, showStoryTime: true, showStoryScore: false, showStoryTurn: false}
storyInfo
:
{storyTitle: 'Cloak of Darkness', storyHeadline: 'A basic IF demonstration using FyreVM', storyAuthor: 'The IF Community', storyCreationYear: '2021', releaseNumber: '1', …}
themeContent
:
"day"
time
:
"540"
turn
:
1
The Cloak of Darkness source show its use of FyreVM.
3 Likes