Is this too unfair (ingame riddle using random)


#1

A couple of games make use of the random and input_text function to make riddles and the like.
Usually though the answer is given not too far before the riddle.

However, would the following be too unfair:

I just finished coding a scene in which the player gets the chance to look around a house.
There are three special rooms in there, which are generated at random.
When the player comes back the following day, one of the rooms will be slightly different from how they were before. And later the night the MC will wake up, potentially realizing what’s been bothering them.
Between the first and second visit, though, is an entire different scene.

So, would it be too unfair asking for a really tiny detail?

The riddle is not necessary to proceed in the story, it’s just one of the way to earn points to unlock a secret plot. Points which can be earned in the required amount elsewhere, too.


#2

Sounds pretty hard, but it’s only unfair if you don’t drop the hint :wink:


#3

I’m considering if I should have the word in question in italics or not.


#4

Since it’s not necessary for the main plot and since you can get enough points to unlock the secret plot elsewhere, the spot the difference puzzle isn’t necessarily unfair. However, it really depends on the rest of the game. If this sort of thing showed up in a game with a lot of puzzles, then it would feel like par for the game. But if this is the only instance of a puzzle in the game, then it wouldn’t be expected and would feel unfair.

Providing the word in italics would be good, especially if this is the only puzzle in the game. That way the reader might have a chance of remembering the detail.


#5

There’s a couple of such puzzles throughout the game, usually they all earn you points for unlocking secrets


#6

As long as player doesn’t die because of random variable it’s all good. Plus, hey, replayability!


#7

My problem with things like this is that I often take breaks in the middle of games, for hours, sometimes even days.
Remembering some minor detail a few days after reading them isn’t always the easiest.


#8

True.

Mhn… I could either have the word in italics then. Or add in a stats check to see if you can remember if you entered the wrong thing.


#9

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.


#10

I have it by now that on the second day visit (if you visited on day 1) your kid (it makes sense in context) will play with/have a closer look/otherwise interact with the item in question.
Also, there’ll be a hint above the input field.
Plus the aforementioned skill-check if you do it wrong.


#11

I would suggest a multiple-choice approach. When the person wakes up in the middle of the night have a list of everything that might have changed.

You say that there are three randomly chosen rooms from a pool which I am assuming includes at least 4 right? Coding wise the multiple-choice method could easily be achieved by first asking what room the change occurred in and then behind the scenes disable the option(s) for all the rooms that were not shown this playthrough. Then each object is listed under each room so there is no possibility that the player sees more object options than were presented to them.

Sorry I’m late, I got distracted but have decided that I might as well post my idea still.


#12

Btw, @Avery_Moore did this in the Dryad’s Riddle. Iirc, the code:

*create answer ""
*comment take example of the answer = blaah


*input_text answer
 
*if ("$!!{answer}" = "BLAAH")
   true
*else
   false

I’m also using it on my WIP :"


#13

Yeah, got that down, and that works so far :smiley:
Fiddling with the details atm.
Looks like this atm:

Summary
   *if ("$!!{odd_oddity}" = "$!!{cafe_oddity}")
      Of course! The ${cafe_oddity}!
      *line_break
      You would bet your behind that it was in a different place today than it was yesterday.
      *set [MASSIVE SPOILER]
      *line_break
      *if (unflappable <=45)
         You fidget a little. Has someone been in the house? [i]Is[/i] there maybe someone in the house? Right now? While you and $!{kid_firstname} are asleep?
         *line_break
         Or at least should be asleep?
         *line_break
         What now?
         *line_break
         You look at $!{kid_firstname} sleeping peacefully next to you, and decide the best course of action would be to blockade the door with your luggage and the chair in the corner.
         *line_break
         That done, you fall asleep the moment your head hits the pillow.
         *set door_block_1 "true"
         *page_break
         *goto day3
      *else
         You furrow your brow. Has someone been in the house? [i]Is[/i] there maybe someone in the house? Right now? While you and $!{kid_firstname} are asleep?
         *line_break
         Or at least $!{kid_firstname} being asleep?
         *line_break
         What now?
         *line_break
         You look at $!{kid_firstname} sleeping peacefully next to you, and decide the best course of action would be to blockade the door with your luggage and the chair in the corner.
         *line_break
         That done, you fall asleep the moment your head hits the pillow.
         *set door_block_1 "true"
         *page_break
         *goto day3
   *else
      You wreck your brain, but you can't think of anything.
      *line_break
      *if (curious >=55)
         You take a deep breath, and concentrate on your first visit here. But of course! The ${cafe_oddity}!
         *line_break

#14

Small note - If you want, the code could be simplified to this:

      *if (unflappable <=45)
         You fidget a little. Has someone been in the house? [i]Is[/i] there maybe someone in the house? Right now? While you and $!{kid_firstname} are asleep?
      *else
         You furrow your brow. Has someone been in the house? [i]Is[/i] there maybe someone in the house? Right now? While you and $!{kid_firstname} are asleep?
      *line_break
      Or at least $!{kid_firstname} being asleep?
      *line_break
      What now?
      *line_break
      You look at $!{kid_firstname} sleeping peacefully next to you, and decide the best course of action would be to blockade the door with your luggage and the chair in the corner.
      *line_break
      That done, you fall asleep the moment your head hits the pillow.
      *set door_block_1 "true"
      *page_break
      *goto day3

Everything should be on the same indent sorry if not, I’m on my phone.


#15

True.
I’ll see to that before stuff goes live.


#16

I’ve been playing around with hiding things in my game, too! :smirk::sunglasses:

I mostly agree with what’s been said here – using text_input is really hard to make fair because someone who’s figured out the clue still needs to figure out how to write it correctly, and drawing a little more attention to that detail with the kid sounds brilliant. Also, the article @Minnow’ linked on The Three Clue Rule was fascinating. (It looks like no one else has clicked on it yet?) Give players at least three ways to do anything vital to the plot – which reduces the frustration of not finding that one way to move forward and adds the fun of finding a different way to do things next time. (And also, as the author demonstrated and I’ve found writing in my own obscure options, really flesh out the background of the story) Maybe this is something we should take into account writing relationships or romances? I’ve seen so many help threads for games asking how do you get the ending where you marry so and so? where the answer turns out to be do this exact thing and make sure you get this scene What if there were different routes that led to different kinds of relationships? Ramble, ramble… These areas where interactive fiction differs so much from linear fiction really fascinate me.

Anyway, my little suggestion I was going to add was to maybe make the clue or difference the same every time, but the insignificant/red herring details around it randomized. That way, the more you played the section, the more obvious that clue would become. But combined with the kid interacting with the object it seems maybe a bit much? And the kid idea seems to add to the story in a more significant way than extra room details (or maybe not – are these rooms plot-significant elsewhere?)

To add to @Kelvin’s coding suggestion, I’ve had a couple problems with mid-paragraph *if clauses confusing my formatting (mostly mid-sentence breaks adding extra spaces) or just forgetting to include all the possibilities. (Oh, and the example above won’t work unless you have implicit control flow enabled.) I’ve been using mulitreplace a lot where most authors use *if clauses. It’s a fairly new command, but happened to be one of the first posts I read on the forums, so it’s always been an option to me :blush:

@{(unflappable <=45) You fidget a little.|You furrow your brow.} Has someone been in the house? [i]Is[/i] there maybe someone in the house? Right now? While you and $!{kid_firstname} are asleep?
*line_break
Or at least $!{kid_firstname} being asleep?
*line_break
What now?
More examples

You don’t have to include text for every variable:

You've got this. @{(status = "wheeled") Even in a wheelchair.|}

You can change the information given or tone of a sentence by what the player knows or wants:

Straight ahead, @{seentablet in the direction of the hangar|presumably deeper into the facility}, the hall ends in a set of thick double doors.

You can use it in choices to have multiple versions of text for a single destination:

*choice
	#I wanted to @{seenhangar get a closer look at the [i]Delora[/i]|see the hangar}
		*goto hangar
	#@{seencommons I'm heading back to||I sill haven't seen} the common area beyond my quarters.
		*goto thecommons
	#@{(time > 9) It's getting late;|} I'm heading @{seenquarters back|} to my quarters now.
		*goto quarters

Excuse my rambling, I’ve been having a lot of fun with this command!