I’m starting to look at porting FyreVM to javascript. Actually the only thing that would need to be created is a glkote replacement for Zarf’s quixe interpreter to mimic the channel IO stuff I have in FyreVM.
Then you’d have the entire web development world connected to a javascript library that handles turn-based parser IF, but without any of the limitations of building your UI in Inform itself. All your output would be contextual, to be used in HTML as you see fit.
Then Zifmia would become something like Ionic, with built-in templates for IF.
Thanks for coming back, McTavish. I appreciate your willingness to stick around.
And since you’re here, may I ask you to explain this a bit more to someone who has basically no idea of what’s going on under the surface?
In particular what is “a business logic layer within a traditional web software stack”? And what’s the difference between what you’re proposing and interpreters that run in browsers?
For my money I would prefer to do my actual coding offline. As David said, browsers can slow down for reasons unrelated to what you’re currently doing, and fairly stress-heavy stuff like compiling seems like something I’d like to keep far away from my browser. In general, anything that encourages me to open more tabs can’t be good.
I’m pretty dissatisfied with the current state of offline interpreters (I may start a thread about this, called “Maladies of Interpreters”); Zoom isn’t maintained and Gargoyle’s scrollback handling makes it very difficult for me to use, though I need to stress test this to see exactly how difficult. So abandoning work on interpreters to me suggests essentially abandoning interpreters. And one good thing about virtual machine formats is that they’re easier to mass-port and mass-update AFAICT; I can play Nord and Bert or Ultima IV on my Mac because they can be emulated (I don’t really know what Ultima IV is doing under the hood, but I don’t think they recoded it), but I can’t play Jason Rohrer’s Passage because there’s no way to play PowerPC games on Intel Macs without a specific update. (Wait, it looks like Rohrer has updated it, but the point stands.) I guess Web architecture can be one way of accomplishing something that will stay updated but I’m worried about putting all our development eggs in one basket. (I’m not sure that’s not world salad.)
I would like to be able to simply, with a GUI, create an actor in Inform7.
I would like to simply, with a GUI, build out some logic around that actor (aka Scratch)
I would like to drag that actor into a Twine object (let’s say, a room) and completely manage the rich media experience - through a GUI.
I would like to be able to drag a ‘parser widget’ into that Twine object.
As a player, I want my experience to be delivered either through a web browser, or a mobile application.
Then, as a player, when I enter that ‘room’ in Twine, a parser box appears, and the actor appears in the text, and in addition to the CYOA elements, I can interact with that actor (i.e. speak to it) through fully typed sentences.
Thanks for that answer, McTavish! I see two different things here, the making side and the playing side.
This is all cool, but I would like that to be not the only way I have to interact with Inform7. For instance, I like to do a lot of things that aren’t particularly based around rooms or actors, or the default model for rooms or actors. What I really like is the rules, and though there are some things that I’d like to be able to do with a GUI (playing whack-a-mole with rule ordering is no fun and it might be nice to reorder them by dragging and dropping), I’m not sure how easy it would be to do all this with a GUI. Maybe there could be some things the GUI could do and some things to do with typing. (Like the Twine/Twee distinction, perhaps, but with an IDE for the text side.)
This sounds like a great idea. Could having Twine run a javascript interpreter accomplish some of this? Is the problem the way the interpreters talk to the surrounding code? Maybe FyreVM could help there (though I don’t usually understand what’s going on with FyreVM either.)
I’m still not really understanding how this is different from Parchment/Quixe/iFrotz or whatever.
So the Inform 7 logic is governing NPC behavior in Twines, basically as a conversation interface or something like this? That sounds very cool! It also does sound like a hybrid – there will be projects for which this is not suitable, I think.
Thanks for the suggestions! The I7-in-Twine thing sounds cool especially, and maybe not that far out of reach with what we already have, if it’s just a question of getting bits of Javascript to talk to each other (I don’t know if that’s a concept that even makes sense).
I ain’t saying this is the future, but I’m interested in a lot more kinds of autogenerated text. There are a lot of kinds of play loops that don’t work well in IF–and in tons of other kinds of game–because the text gets so repetitive. Who among us has read the text on a Fallen London card the tenth time we get it, or the flavor text of an FTL encounter? (In fact there’s one funny FTL encounter that essentially gives you a bonus for having read the flavor text.)
Now currently autogenerated text doesn’t add much to that kind of replayability, because it gets repetitive anyway; see for instance Begscape and the Hunter, In Darkness maze where part of the point is that what the PC is experiencing is all much of a muchness. (As Emily said about Begscape, you ignore the city descriptions and go straight to the price of lodging.) But part of that may be that we haven’t much explored what can be done with autogenerated text. Think about the amount of work that went into the 3D graphics we all take for granted now and imagine if some small fraction of that work went into autogenerating text.
As the original poster (I think) said, this is something that might be doable with text but would be hopeless with voice acting, though recombining graphic elements is a lot easier than recombining text.
Whenever I think if AI IF, I don’t imagine a game generated by an AI but rather a game where the responses are AI generated. Meaning you could type quite literally anything and the game would be able to understand you and process your commands. You’d finally be able to have complete newcomers to the scene pick up and play a game without them wondering what they have to type or how to word their commands.
That’s a fundamental limitation of text itself; grinding doesn’t work that well in tabletop RPGs either. You can try it yourself by writing and running a game of Parsely set in Fallen London memento-mori.com/parsely/ where you’ll improvise text as the players are grinding.
Even with a full human intelligence behind it, IMO, it just doesn’t work. I don’t know why, but watching and re-watching an animation is just mildly dull, but doing it in words is just terrible. (But maybe it’s just me; I’m kind of allergic to grinding in games.)
What I envision as AI in IF is an author-assistant app or widget that suggests rooms and items to include, help with coding various effects, and generates suggested text responses. It’s not part of the finished game at all, but just something to help make the author’s job easier. Sorta like Clippy (but hopefully much less obnoxious).
I’m not super interested in grinding myself, but I think there are lots of other things we might be able to do with generated text that we can’t necessarily do with hand-authored text. Think of a texty version of Proteus, maybe, or a version of the Battle of Walcott Keep that doesn’t produce an overwhelming amount of noise when lots of NPCs act.
And anyway “fundamental limitation of text itself” might mean “something we haven’t tried yet”; or at least we can’t tell fundamental limitations from things we haven’t tried if we don’t try them. The difference between graphics and text here, for me, is that it’s easier to get an interesting variety by recombining discrete graphic elements than it is to do something similar with text, where you’ll have to do a lot of work to get past the Mad Libs effect. But again, a lot of collective work has been put into generating graphics effects (all the 3d libraries and hardware and stuff) and very little into generating text, so we don’t know unless we try.
Also, watching the exact same animation over and over sounds like the worst! At least I can skim text. Is there any particular thing where you like that, or is it that it’s easier to put the same animation in different settings, or just that walking animations etc. are easier to watch over and over? For me walking animations are more like “Taken” or something; I don’t mind seeing them over and over again, because they’re just there, but they sure don’t provide enough to keep my attention. (LIMBO comes to mind as something where the walking animations really are captivating, though per Wikipedia someone worked for three years on the animations, so that doesn’t really count.)
I definitely like the idea of leveraging web technologies for IF, especially for graphics and sound. One of my goals with my framework has been support for web-based games that take full advantage of the browser’s capabilities. Right now I have a tool that compiles the game code to JavaScript and connects it to a customizable interface. The framework includes libraries for multimedia and hypertext, so it’s possible to write a parser-based adventure that uses point-and-click instead of the keyboard. I compiled two versions of “Cloak of Darkness” to demonstrate.
The text version demonstrates the bare minimum interface (even plainer than the other demos on the site). It works about the same as Parchment.
The graphical version adds images and uses nothing but links in the interface. The multimedia and hypertext libraries automate a lot of the grunt work, so the game script only needed about 10 more lines of code. The underlying engine still uses the same parser-based system. My hope is to enable hypertext games that are built on world models instead of CYOA-style branching narratives.
Since the game code is encapsulated in a client-side JavaScript engine, they’re also playable offline.
It’s a work in progress, but I expect to release the code within a few weeks.
I forgot to add that another reason I want to be able to code offline is that my browser uses the tab key for moving between text fields, so I can’t actually type in tab keys online. This makes Playfic damn hard to use
I’d agree - AI to make the author’s job easier. Things like templates, consistency checks, smarter defaults, room/object generators and more.
The reasoning is that random generation is easy - making randomly generated things cohere into a narrative is not easy. If you want to try random generation of objects to fit a randomly generated narrative then… how does your game-world cohere? ie: what is the underlying order that explains why these objects are here; where is the author’s voice apart from “here’s a collection of stuff”.
But, give smarter tools to the authors and the authors can continue to add their human touch to the story. Authors can focus their efforts where the human touch is needed, use generation for the rest and have better object and narrative level consistency checking.
BTW: Anybody got more versu code snippets than is in the published papers / presentation on their site?
