Could someone explain why this is a better CYOA demo than CoD?
I’d like to give a shot at making it after the design settles down.
Parser systems are typically designed for games in which you can walk around from location to location, interact with things and pick up and drop portable objects (the label “medium-sized dry goods simulator” is used with varying degrees of derision, but does accurately describe the core domain of much parser IF). Many choice-based games devote little to none of their attention to world or inventory modelling and are better thought of as narratives with branches or conditionals. So although you can build CoD in, e.g. Twine (and people have done so), you’re not necessarily producing a useful demonstration of what the system is like to use for a prospective choice author, who wants to know what it looks like to branch to a new passage, provide choices with different responses, etc.
Do you have a thought of what kind of thing that might be? I’m struggling a little to think of something that couldn’t be expressed as a combination of visited choice counts, since that’s what most things in a choice game are… I tend to see it more as an aesthetic coding decision, I think?
Like there’s a certain point of complexity where it’s easier to have the author manually track a variable than maintain a large automatically-evaluated expression that computes the same thing (e.g. “the light is on if the sum of the visit counts of light switches A, B, and C is even”), but a lot of times you could implement it either way and it’s a question of personal taste. Which do you find more error-prone: remembering to update the variable in each individual place, or remembering to update the centralized computation each time you add a new option? Which do you find more readable when you’re trying to remember how the light switches work?
Oh, nothing that complex; more like “doing X or Y or Z increments the count by one, and at the end it says that you did this thing N times”. Just showing how basic math works in the system.
But then again, Cloak of Darkness doesn’t really have any math in it either, even though basically all parser systems can do that.
I guess if we wanted to add it to Aster’s spec, we could say “you’ve examined N things”? But if it’s not in Cloak of Darkness, I’m not too fussed.
Yeah, I was most of the way through outlining a little bigger-scale demo (more like Craverly Heights, maybe?) when Aster posted Road of Darkness and wondering about fitting it into that…
Maybe add something that lets the user set, I dunno, the color of their scarf early on, and then describes that scarf later, using that color?
Or for Aster’s example, setting the season of the story.
I like both these examples. The scarf one plays into the character customization frequent in choice games!
You can show this too!
I went down a stupid rabbit hole of looking at the different functionality in Harlowe, SugarCube, Chapbook, and Ink with the result that uhhh… the whole thing still only exists scribbled on several sheets of scrap paper. But I don’t think I ballooned the scope at all, just tweaked things a bit, so I’ll try to sit back down tonight and get something shareable.
Josh, I don’t think that studying the different functionality of IF languages/libraries is a rabbit hole, and is definitively NOT a stupid thing. Exactly the opposite; when starting a project, the first thing I always do is what language/libraries is the most appropriate for the project. and looking at the differences between language and libraries IS how one discover the strenghts and weakness of a language or library.
So isn’t a rabbit hole, and is NOT stupid.
Best regards from Italy,
dott. Piergiorgio.
Ugh. This is reminding me how much Twine sucks if you accidentally want to do something that doesn’t quite fit its paradigms (like, y’know, filtering a list of choices). But I’m getting there.
Also I just remembered that Harlowe has a Quack of Duckness parody of Cloak of Darkness to demonstrate a bunch of useful features.
I like this new Road of Darkness specification, though it seems I can’t look at the demo for now because Itch has started to block VPN users, likely as an antibotting measure.
It did always strike me that Cloak of Darkness is geared towards parser systems instead of choice ones, what with the inventory management and all. I wouldn’t mind if several new test games for new choice systems popped up, but if this was the one the community decided on as the standard, I’d be satisfied with it.
Also, I agree that there should be some kind of customization testing aspect such as a scarf or season specification. I’d lean towards scarf color because changing the season might require the writing to change to describe small environmental details. Maybe the player chooses the color of their scarf at the start, and then that gets mentioned if the player gets the cloak and replaces their scarf with it? Sorry if this is already in the demo game.
It’s not yet, but I like that as the way to bring the scarf up again. I’ll add it to the specification and demo.
The classic situation is that 2+ choices lead to the same passage, but you wish to track which choices were used to get there, which is different from just tracking where you went.
Not all choice systems can easily do this out of the box. I had to write a fairly hacky custom insert to get Chapbook to do this, for example. So I think it’s a good thing for a reference game to include
I have updated the game/specs/source code to include the ability to customize your scarf color and have it referenced later. I think anything else is a bit out of scope for this demo in particular!
I’ve played the demo now - whatever Itch was using to block VPN users was either temporary or only applied to that one VPN location or both, since I can get in now. It has some nice sensory details for a demo game; the original Cloak of Darkness is much more minimalist. (And what a variety of scarf colors!) The next step, I guess, would be to replicate Road of Darkness in a variety of choice systems as a point of comparison. I don’t know Ink or ChronicleHub or DendryNexus but I’d be curious what it would look like in those systems, if it can be implemented there. A JS-dependent implementation in Snowman I could manage.
Once I have some time I’m going to try it in Dialog, using its actual choice-select mode (rather than effectively building a tiny parser from scratch for Mini-Cluedo). I find that mode pretty unwieldy compared to its parser mode, but it’ll be nice to have a demonstration of exactly how unwieldy compared to something designed around choices first and foremost.