I agree with all the comments on the importance of “failing forward.” Then I wrote altogether too much about it, since it wasn’t really the subject of conversation in the first place.
So I'm sticking it inside a details box.
ChoiceScript games offer players far fewer chances to interact with their MC’s environment than a more traditional game like Mass Effect or Skyrim, so failures and Game-Over screens feel more like the developer is insulting the player, and less like the player made a mistake.
Choices where the “right” option causes everything to go in the MC’s favor and the “wrong” options cause everything to turn against the MC only exaggerate this effect.
One way to work around this problem while maintaining “severe consequences” is to change the way consequences work in the first place.
For example, each individual consequence could be relatively small, but could last for a longer and longer time as they become more severe, so that at higher challenge levels the multiple small consequences begin to stack up and combine to hinder the MC. Perhaps there’s a stat for how close the bandits have come to catching the MC. Perhaps passing an obstacle (read: stat check) reduces ${bandit_distance} a small amount, while failing an obstacle reduces it a large amount? And if ${bandit_distance} ever reaches zero, the MC is considered “cornered” and forced to fight.
Perhaps there’s a second stat, representing exhaustion, that goes up the longer the MC runs from the bandits. Perhaps combat with the bandits becomes slightly more difficult as exhaustion goes up, should the MC ever let ${bandit_distance} fall to zero and become “cornered.” Using an exhaustion stat to increase the difficulty of a stat check during combat would be quite simple: instead of *if strength >60 you could use *if strength >(60 + {exhaustion}).
Another way is to harm the MC in a way that doesn’t alter gameplay on a mechanical level, but does alter the player’s emotional interaction with the game. Perhaps instead of a Game Over screen when the bandits win, the MC takes a wicked cut across half her face, and goes blind in that eye. Or loses a finger or two. Permanently.
[i]Mecha Ace[/i] features a consequence like that: if the MC’s willpower is too low, she fails a stat check, leading to permanent loss of one hand. While there is a small stat change associated with the injury, it’s so small it has no mechanical effect on the game. The major point is the emotional weight of it — once that check is failed, the hand NEVER returns to normal.
Getting back to the question you asked…
Here’s a thought: Why not both?
Seriously, what about using *if commands within the *choice to present warnings in an immersive way? That is to say, quite literally presenting different options based on the MC’s ability to pass the relevant stat check.
Here's an example using an extra stat to measure how close the bandits are:
Your path around the cliff is blocked by a fallen boulder and the bandits are quickly gaining on you.
*choice
*if (strength >=65)
#You should be able to un-balance the boulder and send it rolling down the cliff with ease.
*set bandit_distance -1
*if bandit_distance >0
*goto keep_running
*else
*goto cornered_and_fight
*if (strength <65) and (strength >=35)
#It might take some time, but you should be able to un-balance the boulder enough it rolls on its own.
*set bandit_distance -5
*if bandit_distance >0
*goto keep_running
*else
*goto cornered_and_fight
*if (strength <35)
#That boulder looks completely immobile, but you'll never know if you can roll it unless you try.
*set bandit_distance -10
*if bandit_distance >0
*goto keep_running
*else
*goto cornered_and_fight
*if (agility >=40)
#You should be able to scramble over such an obstacle with ease.
*set bandit_distance -1
*if bandit_distance >0
*goto keep_running
*else
*goto cornered_and_fight
*if (agility <40) and (agility >=25)
#It might take some time, but you should be able to scramble over the boulder.
*set bandit_distance -5
*if bandit_distance >0
*goto keep_running
*else
*goto cornered_and_fight
*if (agility <25)
#That boulder looks completely un-scalable, but you'll never know if you can climb it unless you try.
*set bandit_distance -10
*if bandit_distance >0
*goto keep_running
*else
*goto cornered_and_fight
#If the bandits won't give up, you'll have to put them down.
*goto stand_and_fight
In that example, I gave each of the actions that call for a stat check three tiers of success, and rewrote the #options to reflect how much closer each choice would let the bandits approach.
Now imagine the MC started running with *temp bandit_distance 12, and encounters two obstacles. First, the boulder that can be passed with high strength or moderate agility. Second… perhaps a fallen tree branch? Something reasonably light and easy to move, but oddly shaped and difficult to climb over, allowing it to be passed with only moderate strength, but requiring high agility.
In that two-obstacle chase, an MC would only be caught if at least one stat check was at the lowest tier of success AND none of the stat checks were at the highest tier of success.
More importantly, they’ll have an understanding about how difficult each action will be before they attempt it, and without a potentially immersion-breaking “requires 60+ strength” plastered all over the #options.
.