Imagine a game in which the player is presented with a simple quiz, something that looks a bit this:

The answers in this quiz are being pulled, at random, from a list, and offered to the player via a loop. But there's one problem: how do we stop the game from offering "Banana" multiple times on the same turn? 

Here's a neat little solution which uses a function to record what options we've offered, and prevents them being reused on the same turn, using a list element as a key.

The function "offer_answer" does three things:

- if it hasn't been called yet this turn, it clears out the variable that records what's been shown so far 

- if the element sent to it isn't noted as having been shown, it notes it and returns true 

- otherwise, it returns false 

The function can then be used as follows: 

This is the core part of the quiz loop: it picks a random fruit, and if it hasn't been offered as a choice, it offers it. 

(And the whole ink file for quiz game is here.)

Now, you could do all this by using the PossibleFruits and simply, say, removing elements from it as you offer choices. Why have an extra function at all?

The great thing about the approach here is that it scales.  If you want to do a second shuffled list elsewhere; or use elements from multiple lists; you can do that, without any extra work. If you want to add more options, they just need to have a list item - any list item - as a "key".

So instead of our fruit-quiz, imagine a game where you collect clues - perhaps there are hundreds, even thousands of them - and when you encounter a character, you might want to ask the character about particular clues. You could offer a list of dialogue options in a list, but that list could get long - instead, it might be more elegant to pick a few available ones each turn and just show them. 

You can do that, and use the offer_answer function to ensure that, while picking choices are random each turn, choices don't get offered twice. Something like the following...

(Full source here.)

And the beauty of this is the "key" used by offer_answer only has to be unique to that line of dialogue in that shuffle block; you don't need to cross-reference the key anywhere, or even write down which you used for what!