I’m a bit torn. On one hand, I think you should probably go for it. On the other, it’s almost certainly too unfair to the majority of your players.
Especially given the… contrariness of asking for responses through *input_text.
For example, if the clue is regarding a specific piece of furniture, can your code recognize synonyms like “couch” and “sofa?” What about capitalization variants like “Couch,” “Sofa,” “COUCH,” or “SOFA?” What about near-synonyms like “loveseat” or “divan,” and the various capitalization combinations of those? Can your code recognize phrases built on those nouns, like “The ${furniture_name}” and “A ${furniture_name},” plus their capitalization variants?
There are quite a number of points of failure introduced with a test like this. Some are desirable, as they’re the whole point of the test. Others, though…
- How closely did the players focus on the scenes’ details?
You can’t control this directly, but previous tests handled in a similar manner can give your players advance warning and encourage them to focus on and remember “tiny details.” That is to say, with care you can “train” your players for this type of gameplay.
- How much time passed between the players reading one scene and the next?
You can control how many distracting scenes come between the first and second relevant ones, but you can’t control your players’ lives, their distractions, interruptions, or families. @The_Lady_Luck touched on this.
- How many “tiny details” were actually offered in each scene?
If you push the limits of your players’ working memory, it’s more likely they’ll begin to forget items.
- How many alternate names for the “tiny details” in question are there?
You have some control over this by choosing which “tiny details” are relevant. Some will have more synonyms than others.
- How many of the alternate names for the “tiny details” can your code accept?
This is the “couch/sofa” example above.
- How does the prompt actually ask for input regarding the “tiny detail?”
An “open-ended” prompt like “Something changed. What?” may result in inputs like “The couch was moved half a meter east and the rug beneath is now wrinkled,” or “somebody moved my sofa.” A more narrow prompt like “Someone moved the ____. Can you fill in the blank?” will produce much more predictable and simple inputs, like “couch” or “the sofa.”
- How are players expected to handle notes and reminders?
Will there be an in-game system, or will it be entirely out of game? If players are meant to handle it, will there be in-game notices for them to pay attention? E.g.: I should write this down, I should remember this, This seems important, etc.
However, you’ve also made clear this is merely one of many ways to unlock bonus content, and is not actually required for anything. Thus, some level of unfairness is far more forgivable here than in something critical to players’ advancement. How fair does it actually need to be? In this situation, I’d wager it only needs to be partially fair.
From what you’ve described, I don’t believe the randomness actually affects the fairness or effectiveness of the puzzle. It’s the general format of the puzzle, specifically the use of *input_text that concerns me.
You may want to check out this essay about the “Three Clue Rule”. It might not appear directly related, as it’s in regards to encouraging players to draw conclusions from clues you provide, within the context of tabletop role-playing games such as Dungeons & Dragons or Call of Cthulhu. However, the examinations of potential failure points, alternate solutions, and player unpredictability (in addition to the general discussion of clue use) may be useful anyway. Player unpredictability may not be something we often worry about when making choice-based games, but the *input_text command opens so many possibilities we need to be careful when using it.
