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.