today in #twine porn, I'm procrastinating on writing three interrelated cruel sex endings by thinking more about "already seen".
the limited form of seen-marking is working pretty well, I think it improves playability quite a bit, but it doesn't help the problem of "it's hard to know if I've playtested every meaningful path".
so I'm thinking of adding a milestone system. initial version will be only for playtesting, because it's going to be hard to make it work well for players.
the main problem is there are too many variants I want to mark, it's going to be super distracting to gameplay if they're all called out. this might be solvable by having most of them testing-only, and using gradual revelation of complexity.
another problem is a list of them is going to be illegible, it'll be impossible to understand where they are in the story, and a node graph isn't necessarily more legible.
the stupid problem is POV char uses metric, "milestone" sounds wrong. "waymark"?
It also isn't necessarily a purely playtesting thing; a lot of VNs track how many routes the player has seen, and after the first playthrough, provides a way to visualize and more easily re-explore other variants. A checkpoint system like this could be tweaked to store which checkpoints were hit on a given playthrough and track player progression through various permutations.
@desiree sure, the problem is that there really are too many. I'm estimating between 500-1000 waypoints that are interesting from a testing standpoint. for players, maybe only 10-20 are interesting. (manually marking all the waypoints is kinda tedious and gives me plenty of time to question my life choices, heh)
attempt 1 at waypoints in my #twine porn was to manually mark waypoint(17, "some name")
at various interesting points. doing a couple dozen of these was enough to convince me that I don't want to manually mark the 500 or so that would be useful.
simplification 1: drop the id number. I was thinking it would be more compact than using passage name, but I want an ordered list, not an unordered list, so I can't use a bitset. the list will be a string that gets gz'ed, so passage names are fine.
simplification 2: every passage is a waypoint, so I don't have to mark them at all. I was thinking that when there's a linear chain of passages, it's really only interesting to mark the last in the chain, but that's really an unnecessary optimization that's more work than it's worth. plus if I ask playtesters to send me their playing session data, it may be useful to know if someone quits a line of exploration partway through a linear chain
ok, I've decided I might as well solve the general problem: tag every text variant in my #twine porn, and track whether a variant has ever been seen by the player yet. this is slightly complicated by some text variants being in JavaScript instead of SugarCube, eg: his clothes <<= $naked ? "were" : "are">>
is more compact than his clothes <<if $naked>>were<<else>>are<</if>>
but most of the JS text is for small variants that are not really important, and ignoring them is fine for now.
first problem: identify all the text variants. one way to do it is to augment/replace SugarCube macros. <<if>><<switch>>, etc can report all their variants. I'm wary of doing that, mostly in that it's going to duplicate/fork a lot of SugarCube's code.
what I'm aiming for is arguably something that SugarCube should support itself, but if I go that route I'd dump SugarCube and make a completely different story-format language for Twine. not today, Satan.
I'm pretty sure I can do "identify all text variants" well enough with some simple regex matchers, especially since I don't have to make it work for every possible weird thing story authors might want to do. I just have to make it work for the weird things I want to do.
SugarCube itself is just a complicated set of regex matchers, and I can probably do something that's much faster than SugarCube's normal passage eval.
next problem: identify when a text variant is shown to the player. if I were replacing/augmenting macros, that would be part of the change to the macro. since I'm not, I'm going to do something simple and dumb: query the rendered dom for text spans, and match those with the variants I've identified.
there are lots of pitfalls in this approach, but as the sole author of all sides of this transaction, I can just avoid all the weird cases that makes this solution not work all that well in general
the stupid problem that I'm still wrestling with. how do I label each text fragment? if the story were final/immutable, I could just use char position of each fragment.
maybe I can still do that? it wouldn't work as a player-exposed feature, but for playtesting it doesn't matter if the tracked history gets out of sync when the story source gets changed.
and a player-exposed version of this will have a small amount of manually marked waypoints anyway, so maybe char position is fine...
Add comment