I noticed one of the major drawbacks to using Twine over something like ChoiceScript is that the later has the quicktest and randomtest feature to run through your game, simulate available choices, and report bugs it finds. Is there anything like that for Twine or any attempts even? I know the Twine editor will give a big red box when I run through the game myself, but the game is getting very big and I doubt I’m finding every error possible by manually playing through over and over.
Obviously any tester will need edits for things like the buttons I use to get to the next passage, but is there any starting point that already exists which I can try to tinker with?
And there are many hurdles such a “Automatic Path Testing” system would need to cater for, like the fact that Twine supports multiple story formats and each has their own set of passage transitioning features.
eg. some such features of SugarCube only include: Markup & Macro based Links; Macro based Buttons; Input components; the “Goto” macro; HTML based Special Attributes; JavaScript based API calls; and the Config.navigation.override setting.
Then there’s the potential complication that a condition may need to be meet for such a Passage Transition to occur, unless such conditions are ignored during such testing.
And as many Twine story formats also support selectable components (links & buttons) that don’t cause a Passage Transition, should those be included in such / similar testing?
The complex answer is, a couple of Authors have developed specialised testing harnesses for their own projects. I don’t know if those Authors visit this forum, but at least one of them hangs out on the official Twine Discord server.
In a big Twine game, my solution can be called a “service tunnel”, that is, a passage connecting the first passage to mid- and late- story passages, and setting the appropriate flags. (think Hollywood Hijinx’s work room and the concept should became clear).
Incidentally, the chapter select feature of First Contact was not only a good (albeit underappreciated…) solution to the problem of Chapbook’s lack of save feature, but also was the reuse of the “service tunnel” used during development…