Looks really nice, but I couldn’t figure out how to hang up my cloak. I thought clicking on hook would give me a choice to do it, but it didn’t.
You have to bring up the inventory and click on your cloak while in either the cloakroom or looking at the hook.
Right - the implementation of situation is always going to be different between choice and parser. My personal intention was maybe a bit of a meta step up from “how do you model containers in Twine” - rather how would an author use the specific features and tools of each engine that to get the same narrative and story across. I haven’t used TADS or Dialog, but it would be cool to see if I should be if there are neat tricks I don’t know they do.
It might be as cut and dried as brushing your teeth in parser involves a brush object, a sink container, device taps that turn on, a bristle supporter, a toothpaste tube container with a measured amount of paste, and actions BRUSH UP, BRUSH DOWN, BRUSH UP, SPIT, FLOSS - where a choice narrative likely is going to narrate this scenario more directly maybe with some more subtly-authored choices besides “click to brush your teeth.”
I played with this a bit in Cannery Vale in how the hotel room description gave an initial “verbose” version without choices which I then hid on second view of the passage, but could be accessed if the player wanted it again via an inline link. Then on repeat views, more text describing the room with available interactions would be gradually revealed as if the player is becoming more aware of their surroundings - sort of simulating how EXAMINING in parser works. The paragraphs allowing access to the TV and desk phone are initially not present so as not to hit the player with a mega-wall of text and choices the first time, keep the room interesting, and provide some direction to the experience. I didn’t want the player leaving the room immediately right when the game starts.
Someone figured out how to script virtual reality games with Ink, so I wouldn’t count Ink out. It seems flexible enough.
Edit: (hit return by accident).
What am I looking at? A bridge for a web VR platform and Ink? I’m not really sure what that has to do with implementing parser game world objects in a choice game.
Edit: Ah. The mobile browser editor takes up the full screen so I didn’t see you edit.
You could in theory add Ink to whatever as it’s just a dialogue tree framework. But if you add Ink to the dialogue portions of an Inform game, it doesn’t make it a parser game engine, just like using it to render the dialogue in Mass Effect wouldn’t make it an action game engine.
By itself, Ink isn’t up to the task of handling the world model, just like Sadako isn’t. I can fake it, or I can even write a pure parser engine in JS (as I’ve done with one of my demos), but that’s really stretching the engine beyond what it’s designed for to the point that it barely resembles what it originally was.
This actually sums up perfectly why I’ve grown to prefer choice over parser. It’s just a personal preference, of course, but while I like that parser games let your explore and interact with a world, they too often get bogged down in the minutiae. I could completely see that teeth brushing “puzzle” being put into a game, if it hasn’t already, even though it’s like the text version of Heavy Rain’s opening controller introduction tutorial.
Choice games in comparison, as you say, would just narrate that stuff and not force you have to do it, even if they maybe have you initiate the action with a choice.
Disregarding the fact that both formats are written in 2nd person present tense, they’re really trying to emulate different things. Choice games are emulating novels, and parser games are emulating D&D-style role playing sessions. In other words, parser games concern themselves with the moment by moment call and response of it all, and choice games do broad strokes where they just summarize or even skip the unimportant parts.
This generally makes the entire choice game story a giant puzzle as opposed to having a ton of puzzles like a parser game, where the puzzle is trying to figure out how to get your ideal ending (whether it’s the “true” ending, or the one with your favorite waifu), or sometimes a personal meta puzzle that is solving the overall mystery which requires seeing more than just the true path and sometimes even the dead ends.
Anyway, they just have really different goals, is what I’m saying. Trying to change one to be like the other is like trying to put a square peg into a round hole.
Also - troubleshooting and testing choice is much less involved. That’s not to say there’s no testing required, especially with some of my ridiculous conceits. There’s much less unknown “what could the player do to goof this up” involved since there’s more authorial control.
That is only a stylistic thing and not a requirement though. I’ve had parser and choice games that changed prose tense and viewpoint for various reasons (Cannery Vale, Alice Aforethought, and my Cragne Manor room actually uses I7’s parser-tense/viewpoint setting to switch at key points.)
That said, that’s always my goal: to make choice games that include more interaction and agency. I personally don’t care to write binary 1:1 time cave “choose this: get this” in choice. That’s why my games tend to get complicated since I started in parser and want that. It involves structuring loops and variables and hub sections almost like a board game. I rarely want the player to feel like, “Oh, I only have exactly three choices at this node.”
Part of this was fostered because I worked for a long while in StoryNexus, which was a consumer version of the basic engine that Fallen London uses (FL being potentially the longest choice narrative with people playing for years), and was able to adopt their grinding/story techniques (gauntlet, staircase, and grandfather clock are some of their terms for them) to structure text that can use repetition in a hopefully interesting way.
My last three choice narratives all contain a ridiculous amount of content that many people may not get to because of that. I would never be able to accomplish that in parser with any amount of polish without testing for like a year at minimum. It feels like the troubleshooting requirements in choice are maybe 30% or less of what’s necessary for a parser game.
I think this is a misnomer. The challenges just shift areas. Like if you have a game with multiple paths, that actually becomes much more difficult to manage than implementing a water puzzle in a parser game, because the parser game just involves looking at the one area, and the multiple paths require looking at the entire project. Like if a character dies, you can’t accidentally mention them 20 passages later. That’s not something that’s going to throw a script error or even flag a spellchecker. It’s just a buttload of playtesting while being observant. And considering that the paths grow exponentially with each choice until you funnel them back onto a common path, this is pretty daunting.
This is actually a large part of the reason as to why all of my examples of Sadako have been emulating a parser game so far; they’re just easier to manage and write. IMO, anyway.
True, but the advantage is the author does not have to get inside a hypothetical player’s head and go “What is someone going to try to do here?” since the player technically can’t do anything the author doesn’t specify.
For example: in a parser game if I want the player to use a wire coat hanger to pick a lock, I have to consider all the ways they might do that. BEND HANGER. UNBEND HANGER. BEND HANGER INTO KEY. BEND HANGER INTO POODLE-SHAPE. PUT COAT ON HANGER. HANG HANGER ON RAIL. THROW HANGER INTO THE POND. EAT HANGER… whereas in choice I can include all these ridiculous choices for fun, but the player can’t experiment in the scenario in any way I don’t explicitly let them. Parser is more akin to a physics engine with emergent unexpected gameplay that is hard to predict and test for.
And yeah, there is troubleshooting in choice, but much less. It’s the author that allows a character to get killed and has to account for referencing them later in the prose. A good author should plan for this and it’s not an unexpected interaction like what can happen in parser.
I wrote Cannery Vale beginning to end in about 4 months and that game is huge and it was mostly bug free on release with casual feedback from perhaps two beta testers. That would have been impossible with a parser game.
Yeah, you make good points. I think it boils down to the strengths and weaknesses of the author. Even given your example, I still feel that choice is more intimidating because I have a difficult time remembering small details over time (just ask my girlfriend ), but I can do hyperfocusing on a single problem like the multiple ways of saying the same phrase and how to implement them.
Overboard!, the latest Inkle game, does have a world model though, the world comprising seven characters with dynamic schedules, awareness of their surroundings during dialogue, and extensive memories. It’s all done ink-side, as far as I’m aware. Honestly, creating a world model is possible in any reasonably well-developed engine (Twine’s Sugarcube included, and probably Sadako, as well, you shouldn’t sell it short). This with the perennial caveat of “what even is a world model, durrr”.
How this translates to an actually playable game is another matter.
Yeah, but Ink doesn’t come with a world model. I’m sure most of Overboard!'s model was written in C# inside of Unity and Ink just reacted to variable states. It’s not really the same thing.
On the flip side, there are ChoiceScript-style dialogue tree libraries that people have written for Inform 6 and 7. If you wrote a game that was entirely a choice game using that library, does that makes Inform a choice game engine? Personally, I’d say no, because vanilla Inform doesn’t come with that functionality.
It might be splitting hairs, but that’s basically what I was trying to say.
And to the larger point, I don’t think vanilla anything should be the measuring stick for what a system is geared towards. Most of the fun in working in an engine is extending it and pushing its envelope. Inform, to a huge degree, is its libraries, as far as any halfway sophisticated user of it is concerned.
I saw that you say that but it sounded like speculation, so I speculated myself in response. I’d love to see the source to find out either way.
And we may have to agree to disagree about the library thing. Yeah, libraries are great, of course, but I don’t think you can use them to change the label of the original engine based on a single library.
For laughs I put a fighting game I wrote in python into ren’py, a visual novel engine. Do you market it as a fighting game engine now?
Dare not go near the Marshes of Marketing! Seriously, it’s an entirely different thing, far, far removed from an author in their underpants in their bedroom, tinkering with an engine to see what it’s capable of (and how easily).
Usually the last people who know what will become of an engine are the people who market it, unless they themselves are power users.
And yeah, Jon Ingold has said all the logic is ink. From Twitter:
(…) The goal was to keep all the game logic inside ink, so the game was just a view. What that view needed to be evolved as we played the game (We added the inventory, cut a log book screen, added replay features) - but we had most of the bones of the game in about a day
But really, they’ve been doing it since Sorcery!: storylets, salience-based narrative, knowledge-modeling. These are a matter of design, which by now has become well-documented in multiple places.
Implementation is sometimes trivial, sometimes tricky, depending on the engine, and the results may feel awkward or awesome, which is where the difference between tools is, not in how an engine is promoted.
…what were talking about again?
That’s really interesting! I definitely want to see the source now.
Whether Ink could be considered capable of providing a world model. I think.
But anyway, it was just musings to pass the time. It’s not like I was expecting to solve some giant problem with our little debate. Haha.
Haha, well I really hadn’t expected my little rant would spawn two sizeable threads, but I’d be all for a speed IF jam if that idea goes anywhere. I agree with others here that a theme referring only to some plot detail would be best so as not to seem to favor one style of IF over another.
Anyhow, still a bit overwhelmed by the replies and catching up with both threads, I’ve barely been online since I made it to tell the truth due to work and some family issues.
Make that 3 threads since fos1 started Speed IF jam.
They put some code up on their patreon (inkle is creating The Ink Engine | Patreon) and promised to disclose more (Ingold hinted about the world model of the initial cabin at the beginning of the game on his twitter)