Hey Dan–thanks for the response, appreciate your time.
I also appreciate the bug-screening intent of the *choice / *fake_choice distinction. But even using it, it’s still tricky not to lose yourself in big code blocks. Forcing people to use *gotos doesn’t affect those 100 lines of code per choice, so our CS example shouldn’t leave them out:
*choice
#Be very naughty.
[...100 lines of text later...]
Santa punishes your inefficient coding practice.
*goto present
Requiring a "goto doesn’t shrink the distance between the choice text and the branch point. If your last line of code before the *goto doesn’t happen to include a clear reminder that this is the end of the block following the “naughty” choice, a code reviewer still needs a good memory to catch the bug.
In general, whether a choice starts with *choice or *fake_choice, the code reviewer still needs to be reading attentively enough to answer: Should this choice lead to different immediate outcomes? Is that being done using a *goto or a stat adjustment? (With delayed branching as the “special sauce” for CS works, most branches don’t happen using *goto immediately following a *choice anyway, but *set followed at some remove by *if or similar.)
So I do wonder how many bugs are actually getting caught by keeping *goto mandatory. It feels to me like a minor debugging improvement that most authors and editors seem to be forgoing anyway (by preferential use of *fake_choice even if they don’t toggle on ICF).
Regardless, making *goto optional for *choice wouldn’t force coders to abandon the extensive use of *goto as a safety rail. And if there are still CoG editors who join you in prioritizing debugging over efficiency, it wouldn’t stop them from asking their authors to write that way.
It would just rescue us from the current absurdity of the tacit deprecation of *choice, and reduce the obtusity of the language for novice programmers. (“Why can I use *fake_choice for literally every kind of choice, not just fake ones…and why am I being pushed to use it as much as possible?”)
I’m not a programmer, so my instinct against manual testing isn’t as develoepd as it no doubt should be. But as an author, it seems to me that extensive “manual testing” – i.e. reading how your text will actually look in the UI – is inevitable with CS, at least if you care about pacing, dialogue, prose style, and overall readability. All the more so as CS’s growing arsenal of bells and whistles moves us away from txt files that look like this:
*if a
big block of prose
*if b
block of rather different prose
to something more like:
${char_name} verb${s} @{a some text|other text} before @{b some text|other text}.
which looks nothing like it will on the “page.”
Thankfully, CSIDE’s console feature now makes it way easier to manually test CS games. But from my perspective, the need for plenty of manual testing should also somewhat reduce our reliance on mandatory *gotos to avoid bugs.