Best practices for puzzle design in Choice based IF

All parser games are so convoluted and ridiculously over-engineered. :smile:

That is a great point. There are benefits with using both command and choice mechanics.

And thank you for going in depth with your philosophy in designing your game (the screenshots supported your points really well – it looks so slick, by the way). You do bring up a very valid point in that choice-based puzzles benefit more so from being woven into the narrative. Parser games are more forgiving with not integrating their puzzles into the story; the puzzles can simply be there without context in many cases and still feel purposeful somehow. This probably comes from the sentiment you made about how parser games are more about world simulation and their puzzles being inherently object-orientated.

Yes, please! I think boardgame mechanics would be a huge strength of choice-based IF, even without graphics.

There’s great stuff in this topic!

2 Likes

I don’t know if that’s a widely shared opinion!

  • The first half of King’s Quest V is spent walking around in Serenia, solving puzzles and collecting a lot of items that will admittedly come in handy later. But we’re given absolutely no indication why King Graham should be bothering with all this, considering he needs to journey through the mountains to save his family. It’s just aimless wandering about. All because of what’s preventing him from just going up into the mountains right off the bat: a single snake. And instead of just beating it with any number of things that end up in your inventory (like a hammer) or just walking around it, you instead have to wander all over hell and back until you get a tambourine to scare it away with.

  • The Interactive Fiction game Not Just an Ordinary Ballerina is better than it sounds — but includes more than one pointless puzzle nailed to the wall. The worst example is a Magic Fifteen puzzle that spells out the words of a song. Hope you know the song…

  • Zork: Grand Inquisitor The cocoa recipe. An answering machine tells you of a recipe for a cocoa blend. With the ingredients at hand, you naturally try to make it, for no conceivable reason. Once you do, your companion is reminded of a spell of his he developed while drinking it, and teaches it to you.

While there is a genre of “puzzle box” IF (Like what Andrew Schultz does, and games like Ad Verbum which are there to feature themed but mostly random puzzles) I don’t think parser narratives get any specific slack for “just for the heck of it” puzzles designed solely as a non-diegetic obstacle. Or something like “You must bring Bob his package of hamster food from the post office before he will consider explaining how to save the world from the approaching meteor that will land in 60 minutes” type situations outside of specifically absurdist comedy - or something like Counterfeit Monkey which goes into extreme detail to logically justify an entire setting where anagrams and similar wordplay control the universe. :stuck_out_tongue_winking_eye:

8 Likes

I don’t know if you’re joking or serious half the time!

Edit: Oh, good Lord. I’m so dense sometimes. Don’t quote that back to me. :wink:

2 Likes

Three things come to my mind:

  • The options to click (or move) should be not too few (and probably not too many. But too few is worse than too many).

  • Normally it is a good idea to allow the player to walk away from the puzzle and come back later (there are exceptions when it fits the story to force the player to solve it).

  • What happens when a false try was done? And how many tries does the player have?

3 Likes

I reckon it’s possible to make a ChoiceScript game with satisfying puzzles, where the solution-level outcomes aren’t simply offered to the reader in a choice block – even if you don’t use text input or graphical features, just the usual menu button choices affecting stats. The stats can stay under the hood, after all; you don’t need to broadcast the aspects of the situation that make the solution obvious, any more than you do in a parser game.

@mathbrush, you’ve played Choice of Rebels as well as roughly a bajillion more parser games than I have – if you remember it, do you think surviving the winter in Ch 2 of Rebels counts as “a puzzle” for the purposes we’re discussing here? I’m not sure how analogous it is to parser puzzles… but I think a lot of people have approached and experienced it as a puzzle, albeit chasing a range of different solutions beyond just “survive the winter without triggering a mutiny” (e.g. minimize casualties without stealing; maximize anarchy and wealth; maximize band size without locking yourself out of the “stand and fight” option in Ch 4; etc.).

Regardless, I wouldn’t hold it up as an ideal of “what works” for a choice based game. Plenty of readers clearly found it frustrating to grapple with in the absence of a graphical interface; what I was trying might well have worked better with a more diverse UI than the CoG-standard radio buttons. And the code’s a mess (in keeping with the lower bar for coding skill in CS compared to just about any other IF language).

In terms of world model, this particular puzzle ended up involving some 500+ variables (though many of those involved cosmetic features of the narrative for that chapter, and I’m not going to dive in now and try to figure out how many were really intrinsic to the “solution”. :slight_smile: ) It was, as @HanonO well said, a model built with events more than locations. It involved a “hub” (the start of another week of surviving winter with your bandits in the woods, with week-specific events popping up each time the game brings you back to the hub) from which the player is able to choose from a menu of possible events (raids or non-violent ways of feeding your outlaws) until you run out of outlaws to deploy and you get some end-week events. The player revisits the hub 10 times, and then winter is over and the game moves on with whatever outcome you achieved.

Even if that falls short of the definition of a puzzle, I’m pretty sure someone could use a similar approach to craft choice-game puzzles that don’t have an obvious “CLICK ME” solution and can generate some of the same eureka moments as a good parser puzzle. In fact, I think Mike Walter’s already done that in ChoiceScript; finding my ways through the time loops of his Paradox Factor was as satisfying as many of the parser puzzles I’ve played.

9 Likes

I’d classify it as a ‘complex system’ type puzzle, just like learning a language or operating a complex machine in parser games. I tend to like those kinds of puzzles, because you’re actually learning new things instead of applying old knowledge.

I think the difference between your system and (most) parser puzzles is that you have:
-degrees of success (not just ‘right’ or ‘wrong’), and
-the story can progress even if you do ‘bad’

So I think its place in the world is slightly different from parser puzzles (which usually stand as binary ‘gates’ to progress) but the kind of thinking you use to overcome it is similar to that used in some of the better parser puzzles.

6 Likes

I think this is accurate… and that neither of those differences is inherent to ChoiceScript, let alone choice-based IF more broadly. Those were design choices I made; the latter one especially may be a requirement of CoG as a publisher, but they’re not required by the medium.

3 Likes

This starts to touch on quality-based narratives, or QBNs. Without using variables, choice narratives can be limited mostly to putting the solution in a choice, which describes the “lawnmowering choices” type of game that @HAL9000 mentions when it’s ventured that “there can be no puzzles in choice.”

ChoiceScript has statistics which can represent different values, such as relationship with another character or statistics like strength or intelligence, or values that are more specific like “Research Progress.” Variables can be used in Twine and other choice systems. These stats or qualities may be under the hood behind the scenes, or be displayed to the player. One feature of games like Fallen London is the player might have stats or qualities that are vague “An Inkling of Revolution…” that may hint the player about something that can happen or just control plot mechanics to gate what they’re capable of, or be obvious such as a health stat. If a player isn’t “healthy” enough, they may be restricted from entering a hospital for fear of spreading disease.

A feature of a QBN is certain choices are available or not based on a “quality” (variable/stat) the player has. Qualities can be true/false or number based. The most simple is something like a library the player cannot enter unless they have visited the passage where a key can be found that sets $hasKey to “true”. The choice to enter the library doesn’t appear or is not selectable unless $hasKey is true, or the link will do something different - such as allow the player into the library instead of telling them “The door is locked” and turning them away. The “puzzle” is locating the key. Maybe it’s found by visiting another character and asking for it (the choice to ask for the key may also not appear unless the player has discovered the library door and knows they need to unlock it) or clicking a link to examine the stable floor where it might have been dropped.

The other major feature of QBN is “grind” which essentially means the player must do something multiple times to “grind” a variable up to a certain amount. Dating sims use this - you must visit or do something nice for a character enough times before new options are unlocked.

Let’s say once the player can enter the library they have access to a book that contains the research they need to set out on a quest. The player won’t be allowed to go on the quest until they’ve done enough research. Clicking the link to read the book may raise the “research” statistic by 1. The player may click several times and receive actual text regarding the story/plot/lore they need until the stat reaches 5, which unlocks the link to begin the quest. Or there may be a random chance - say based on their “focus” level (which can be increased by resting or decreased by doing other activities) they have a 50% chance of “successfully” acquiring the knowledge they need and increasing the research stat by 1 each time click the book to do research, so it may take some players extra time. They may want to raise “focus” to get a better chance of succeeding so they don’t have to try as many times. Or, the player might only be able to click on the book to do research once per day; doing so advances clock and they must leave the library and come back on 5 consecutive days to continue their research and get the stat to 5 before they can leave the area to set off on the quest. So the grind becomes less about the player solving a puzzle and more about time-management and potential skill/quality management to accomplish tasks in shorter amounts of time. The player might need to live in this town for a while and choose which days to spend in research, and which to do work to acquire money which they may also need on their quest which takes away research time, and this simulates a multi-day preparation for the quest during which other plot and story elements may occur to inform or distract the player. The player must “grind” their stats up to a level so they have the qualities they need to proceed along the story route they choose.

This is a very short version of how Fallen London mostly works. Fallen London also includes a “draw cards” mechanic for randomness, so until the player gets the card “A rumor about a quest…” none of these options may be available and the player may not know there even is a quest. The ‘deck’ may even be stacked so that they won’t be able to randomly draw the card to initiate this quest unless they’ve spent a specific amount of time in the town (another quality) so that the locals feel confident enough to tell them about the quest - “confidence” may be another quality and the player might need to grind enough daily work through other links to raise this high enough to even draw this card randomly and be eligible for the quest. So “quality based narrative” involves lots of qualities (perhaps hundreds in a big game, or thousands in an epic like Fallen London) that represent the player and the story/plot/logistical situation which opens up potential for cards to be drawn and other choices to be made. To go on the quest, the player must have randomly drawn the card for the quest to know about it, which requires “confidence” to be high enough and some luck, then the player must do enough research to qualify to take the quest, and they probably want to have enough money to support the endeavor. That is grind - the player deciding what to work on each day to raise enough stats to the point where something new will happen and more choices become available.

8 Likes

The discussions of Fallen London (and games like it) on this thread have been interesting to me, because some part of brain when I posted this topic was overlooking that style of game (and it’s been several years since I’ve taken a look at Fallen London.).

Yet these types of “hidden attributes” can provide some very interesting game play, especially when there are signs along the way that the attributes are being recorded and incrementally rewarded. (Bee is another game that was mentioned.). The player doesn’t need to see a number on a stats page, if they are reminded in other ways that they’ve made progress along a continuum.

6 Likes

“Clementine will remember that…”

The Walking Dead game would show these ominous messages and it was hotly debated how much these choices the player made would really change things or divert the plot over the course of a commercial episodic game. Even if they didn’t do much, many players suddenly became more invested in their behavior and this paralleled the television series that required difficult life-and-death decisions that often came back to haunt the characters. I believe some people reported that there were a couple places where the plot didn’t really change significantly, but the tone of certain conversations would change calling back to how the player reacted before.

It’s like theater: people say “it’s a different show every night” but that isn’t completely true: the script and the story and the blocking really doesn’t change, but an actor might read a line more angrily one performance and then sad the next time, which might give a set scene with the same dialogue a new meaning, and good actors “will remember that” and it can have a ripple effect on character arcs throughout the whole show, even if nothing actually changes.

Players of TWD often accused the game of “fake agency” but this goes along with my philosophy of giving the player the illusion of more gameplay and agency than there really is to keep the plot simplified. Whether or not those messages functioned diegetically or not, they served both as a potential indication of plot forks, but also the PC’s consciousness reminding the player the decisions they made had effects on other people for good or bad.

People play Fallen London for months and even years and it is at its heart a choice-narrative where the thousands of qualities operating under the hood is what makes everyone’s route through the game unique and keeps them coming back to continue. That along with the candle-regeneration system which meant the game cannot be binged all at once. Now the game is so enormous that I doubt you could do that even if the game allowed it.

ETA: The candle itself could be considered a quality - “the energy you have to accomplish things in each real time round before you must rest again and come back later.” It almost serves to split gameplay into what might be thought of as “days” in Fallen London (since there is no sun to differentiate!) though usually the candle would fully regenerate multiple times in a 24-hour period.

7 Likes

What style of UI is preferred for presenting choices in a puzzle-driven game?

This is a question that lends itself to more definitive answers. A lot of the players of choice IF, especially choice visual novels (my specialism) are doing so on mobile. An increasing proportion of them have disabilities of various kinds that influence their experience. There is also, and I cannot stress this enough, no single UI template to use in choice. This is different to parser, where many options delegate part of the UI choice to their interpreter. This means that choice authors have to be aware of things like font choice, colour and size in a way that a lot of parser creators don’t. (In parser, it’s primarily about not stopping the interpreter from making reasonable adaptations to the text).

A number of choice platforms will automatically resize and/or reflow content for mobile (and for different types of mobile). Make use of these options when available.

Mobile users often do not want to use on-screen keyboards for more than incidental writing (such as giving their character a name). It is certainly possible to have more typing required, but this will somewhat limit the audience. On the other hand, some people (even on mobile!) need a keyboard to be able to play IF at all, regardless of whether it is choice or parser. Thus, everything should be navigable using keyboards, but it should always be possible to skip text input sections (perhaps by having a default choice for cosmetic text inputs, and by having choices alongside type-in additional responses if in a choice-parser hybrid area of the game).

I would recommend that any choice game that plays in a browser respects the browser’s choice of font settings by default, offering its own choice in settings. This is because people who use browsers will already have set them to something they can use and to a font that exists on their device. Many browser-based choice options don’t even offer an alternative and there’s no need in that instance.

Everyone else (including anyone who has a browser-based choice game and feels they have compelling reasons to ignore the previous paragraph) should make sure there’s a choice of fonts. At least one should be sans-serif and resemble/be a familiar font to people who enjoy that style of IF. In some cases an engine will come with a font - if so, make that an option. It’s fine to have stylistic and fancy fonts, as long as alternatives exist. Oh, and if you want to do translations, please do yourself a favour and make sure there’s at least one (preferably two) fonts that work with each alphabet you’re translating!

High-and-low contrast colour options, as well as light and dark options, are good to have. Be wary of making the background red, however, particularly if that ever changes colour and you have any sort of “skip previously-seen text” option. That’s a good way to accidentally give someone a headache (or if sufficiently unlucky, a seizure).

I recommend at least 3 choices of font in engines that don’t figure out the size from the player’s browser: the engine default or whatever is comfortable for the author, a size comparable to caption size, and the biggest size that allows the text to remain visible. You can have more if you feel the gaps between these sizes are too big, and if all 3 of those fonts would be huge it’s OK to also have a smaller one. The caption-sized one is popular with people who play while multi-tasking or are Deaf. Some players will need the biggest font size possible. Obviously you, the author, needs a font that is comfortable because you will spend quite a while testing your IF. Nonetheless, test all your text and UI elements fit on the biggest font size even under stress, and that the smallest doesn’t look lost (justifying text and putting simple decorative elements near the justified side can help with this).

Make sure there’s enough room for the words! Parser rarely has to think about this, only about the effect the chosen quantity of words has. In many choice engines, it can be the difference between the entire sentence being visible and parts of it falling off-screen (in a way that may be impossible to read, even with scrolling). If there could be translations of your IF, make sure 1/3 of the text space is unused in the language you originally write the IF, so translators’ job is possible - but also be prepared to put the end of sentences on other screens or negotiate shortening sentences if necessary.

If using choice buttons for choices (a common choice), make sure choices make sense in the context provided. Not all choice engines show the question on-screen that the player is expected to answer, depending on rollback for understanding. Your player will appreciate it if the choices make some sort of sense even without that rollback.

Radio buttons, in my experience, rarely cause UI implementation difficulties in themselves. However, if your engine doesn’t do this for you, make sure there’s a separate confirm button, because radio buttons lend themselves to people selecting an option while mulling over whether they in fact wish to take it (instead of pressing the button only when sure this is the choice they wish to make, as often happens with buttons).

Don’t offer too many options. This can, in the UI, cause one of 4 problems:

  • Too much scrolling. Some players will accept quite a bit of scrolling thanks to social media platforms, but everyone has limits. Long scrolls should be reserved for optional moments where there’s an important reason not to make it no-scroll or a short/moderate scroll.

  • A temptation to reduce the size of UI items. This is a disaster on mobile - you can shrink buttons but people can’t shrink their fingers.

  • Too many similar options. Lots of coding work for the author and a threat of decision paralysis to the player, neither of which is fun.

  • A temptation to reduce the maximum size of the font. People with visual disabilities want to read the text too.

(On a similar note: if feasible to make screen-reader compatible or self-voicing, your choice IF should do so. Both, if you can figure out how. Many engines will do this for you, but it’s still on you to not accidentally disable this accessibility aid).

Also check the UI doesn’t provide accidental clues to the puzzles. Any clues they do provide should be deliberate. Give your players confidence that if they see something unusual in the interface, that this matters and that they are good players for catching onto your design decisions;.

Some choice IF have histories that allow you to understand what you’ve done. Sometimes, these allow players to quickly skip back to a previous point faster than rollback would. This is a useful accessibility aid (allows players to remind themselves what happened last time they played) and encourages exploration. Specifically for puzzles, it can also show approaches that have previously worked, thus helping with problem-solving for future puzzles. Consider adding this.

If you have an inventory in choice IF, consider having a method of looking at it at the player’s choice.

Add accessibility aids that you can think of, can easily add and make sense for your IF. The ability to turn off spiders and help arachnophobes makes no sense in a horror centering around a spider lair, but is worth adding to a slice-of-life choice IF where one text passage has a spider minding its own business in a corner for pure decoration.

Customising the UI is a good advanced idea if your IF would benefit from extra options (or the removal of ones that don’t serve the IF) and you can figure out how to do this. Having UI features react to how the player is playing can be a good idea, but make sure anything expressed in graphics is also expressible in a screen-readable format (for example, by allowing an extra screen with this information in text at times when that is useful).

Your IF engine may have custom UIs other people have made that include some of these ideas and/or include other things you think are cool. Investigating them for possible inclusion is a good idea.

I shouldn’t have to say this, but bug-test and play-test your UI, especially if you deliberately modify your chosen engine’s default options.

9 Likes

I’ve always heard that some people have trouble with text flow with sans-serif fonts, but are there problems with serif fonts as well? I know some fonts are - if not uncomfortable, just weird to read a lot of text in. I always was told “if it comes down to one font, choose serif.” “Book-ish” fonts are preferred, and many fonts are great for headers or headlines or decorative text, but suck to read blocks of body text in. There are also preferred fonts for people with dyslexia.

(There it in the first example - serif fonts can trip up people with dyslexia, so in their case you don’t want the letters to flow together for speed.)

I remember being surprised what colors don’t work together for people with color blindness. If you need a link to stand out from the rest of the text, it often works better to make links a contrast/brightness change rather than a color change for people with reduced color sensitivity.

6 Likes

Also there are apps that simulate different kinds of color blindness. Part of my UI design process for visual games is trying to navigate gameplay while looking through each of the filters to make sure I can tell what’s going on.

I don’t think I’m dyslexic but if a body of text uses serif fonts, I read almost 4 times slower and my eyes hurt. I need all of my text-heavy interfaces to be sans-serif, especially because my base reading speed is already slow compared to the average.

I also know people where serif fonts allow them to read faster while sans causes similar slowdown and eyestrain.

This is not a one-size-fits-all accessibility thing, and it needs to be a toggle option to actually be actually accessible.

7 Likes

It’s always appreciated when people do this! My own color blindness is not very severe but it comes up annoyingly often in certain kinds of UIs.

6 Likes

I’d like to preface my comments on your comment by saying that if your choice IF has a choice of at least three fonts, and is written in a Latin alphabet or another alphabet where serif fonts or their analogues exist, making one of the font options serif/serif-analogue is a good idea.

Some people nowadays aren’t taught to read cursive or don’t get to practise looking at non-sans-serif text much and struggle to decipher certain fonts, regardless of whether they have dyslexia or not. Some are emerging readers in the language and benefit from being able to easily distinguish particular characters. Some people are reading on dodgy screens, or in sub-optimal lighting conditions, which sometimes makes serif more difficult to interpret (but not always and not for everyone). There was a time where having dyslexia was automatically thought to equate to particular difficulty with serif fonts, but later research found that wasn’t necessarily true. These are all good reasons to make a sans-serif font of some description one of the choices if the engine doesn’t get the font information from another location such as the browser.

My understanding is that the best font for someone with dyslexia is the one they consider the most familiar and comfortable to use. This guided some of my advice on font options (some categories of choice IF, and some choice IF platforms, are sufficiently strongly associated with a particular font that making that one of the options is a significant help, and browser-based IF defaults to a font commonly used by people who use that browser unless the user overrides it - in which case it is likely overridden by a font the user uses and has available to them). Unfortunately, most non-browser-based choice IF isn’t quite that flexible.

6 Likes

Good point! I’ve gotten so used to Twine, ChoiceScript, and Ink that I’d forgotten that there’s also plenty of choice-based IF that’s not played in a web browser. I was going to say the best practice would be to just assume the user has their browser configured in a way that works best for them, and not override that setting—but of course if you’re making a Unity game, that’s not helpful.

3 Likes

Very true. Ren’Py, the IF engine I use, doesn’t run in a browser or attempt to auto-detect user preference in fonts. At this point, I’ve got 6 fonts in my UI font selector, including a serif font for each of Latin and Cyrillic (3 and 1 sans-serif respectively).

4 Likes

I thought Ren’Py ran in the browser. The documentation says it does, but with limitations. Is there a deal breaker limitation when it comes to browser support for you?

3 Likes

By default, Ren’Py runs in its own executable, which out of the box can be made for several platforms. Web is treated as one of those platforms (effectively converting it into an executable that can be run from a HTML wrapper). Since it’s only treated as a platform choice at the end of the process, it doesn’t detect anything in the browser beyond the fact it’s in one (and, possibly, whether the browser is on a mobile device). As such, even browser-based support has to have things like font choices added as an extra. It’s a different philosophy of creation than an IF engine developed primarily for browsers such as Twine, where downloadable versions are simply put through the same conversion as would happen for any other saved web page, making zero difference to the author by default (because the necessary changes between the web and download version get written at the IF engine and browser levels).

(At the time the Budacanta demo was written, the web version of Ren’Py didn’t exist, although it was under development. People who started Ren’Py games later may well release web-only, especially if it was since the more stable version 8 got released, but they still have to put in font selection manually if it is desired).

I’m hoping to sell the IF I’m producing, and there is one sale pathway I’m thinking of where a web version would help, but at least some of the pathways I’m expecting to sell in expect a downloadable, installable version. So it’s more of “I need all the versions and must configure UI options accordingly” rather than “web can’t be one of the versions”.

5 Likes

Indeed. You could make a web demo version which makes it easy for people to try it without the effort of download & install.

2 Likes