At least for Twine, that’s my take on it too. I’m a person who likes coding and I’m already comfortable with Javascript and CSS, but this puts everything complex outside the scope of Twine itself.
It’s possible to create new templates for Twine. Somebody with time and the inclination (probably not me) could put together a template that builds in macros that are otherwise one-offs, maybe basing it on Sugarcane to start. With Javascript wrapped in new macros, it seems possible to standardize things that currently require custom code, like game saving/loading, relationships between “rooms”, inventory, and whatever else. Those things can be done in Twine, but they aren’t there by default.
Two issues: first, they rely on relaying commands through the parser prompt, which feels awkward and vestigial. I feel pretty strongly that if a game’s primarily driven by hyperlinks or menus, as opposed to having them as an occasional convenience, you should stop kidding yourself and take the parser prompt out entirely. (I’m not certain that Vorpled I7 would support this, but it seems like my best bet. And maybe this is not true of TADS 3, but frankly I’m still a little scared of TADS 3.)
Second, if I’m going to be making a hyperlink-driven interface, it makes most sense to have it target browsers. I’m not convinced about this - I’d much rather deal with a download than, e.g., put up with server-side StoryNexus lag or client-side Parchment lag. But in that case, I’d want the trade-off to be a custom, CYOA-targeted front-end, not a parser interpreter reluctantly accommodating CYOA.
You can build a pretty good hyperlink-driven interface in I7 that targets the browser (via Quixe). The tools to do that exist now, and there’s no need to use one of the awkward CYOA extensions that have been built to use the parser (the parser input line is pretty easily bypassed). The main problem is Quixe’s relatively slow performance, not the ability of I7 to do this use-case well.
Of course, there would be no point to doing this with I7 if you’re just going to create a Twine-style game of jumping from relatively static node to relatively static node. You’d do it if you wanted to retain the world model and other library capabilities of I7.
What Erik said. A Colder Light, while not having a very pretty UI, certainly has an extremely flexible one, and it was relatively efficient to get it up and running from inside Inform 7. All in all, quite a pleasant authoring experience with a lot of power - - but Quixe is terribly slow out the other end, and has a few quirks (as I recall) that can make things a little messy.
But it does feel like rather a lot of steps in the tool-chain: I7 to make a game, low-level I7 (if such a thing exists) to manipulate the interface, CSS to tweak the window layout… if I did it again I’d probably starting looking a Vorple route instead, which is somewhat quicker but still not integrated.
(So these days, I’m writing mostly in inkle’s homebrew scripting language, which is as quirky as Inform 5, but does provide a lot of power – you can’t quite knock out a world model, but you can build one with a bit of effort. Sorcery! had a relative-directional maze that flipped left/right depending on how you played the game, mostly just to prove we could do it; Sorcery! 2 has a set of gambling NPCs who move around a hall challenging each other to games. And it compiles to JSON, which is bulky but very loadable in pretty much any environment. At some point, I want to make Make It Good as an inkle game. But the language is >>> web inklewriter, and obviously our interfaces are totally built from scratch each time. So, yeah. Doesn’t do anyone else any good.)
Still, it makes me wonder if the thing to do is start making an Inform compiler that creates JSON not Z-code?
Erik’s answered maga pretty darned well, I just want to add:
Well, yeah. That’s why I was replying to:
Side-note: on a defunct WIP of mine, I actually wanted to switch at certain key points between CYOA and parser input. It was awkward going at first, because I wanted to remove/hide the prompt completely for the CYOA sections, and make sure that anything the player typed was not recognised (the player’s very first command seemed to be, for some reason, but that got fixed), and that meant making sure there were some SAVE/RESTORE/RESTART links always available, and boy getting RESTORE to work properly was…
ANYWAY. It was awkward at first, but once I got into the swing of it, it became seriously cool. And extremely powerful. And playing it on browsers is all up to Quixe and Parchment, isn’t Parchment playing Glulx games now?
EDIT - Well, this is interesting. I tested and no, Parchment can’t run Glulx, whatever gave me that idea. But Quixe can’t run my pretty simple CYOA either, I get an error. Well, I’ve helped derail the thread long enough.
I keep touting AXMA. It’s twine-like with a graphic web of nodes, but has variable tracking, lists, native multimedia support, timed output, produces nice readable text (not modifiable unless you pay for the pro version but nicely formatted like an e-book reader) and is offline, and produces an offline playable file.