Designer’s glossary: non-choice
One-time disclaimer on this first post – scroll down to the About section to learn more about the project and how You can contribute!
non-choice
[nɒn-tʃɔɪs],[non-; nan-chois]
noun
The act of presenting your players with multiple options, one of which one is strictly better than the rest. This can either be done intentionally, in order to test a player’s skill during a specific stage or stages of your game and measure their in-game knowledge and ability to recognise power levels and correctly identify properties, or unintentionally as the result of a mistake during the balancing process and/or overall design approach.
Antonym: meaningful choice
Contributor commentary (Krumov): While often confused and used interchangeably with “illusion of choice”, we use “non-choice” slightly differently. There is a small but important nuance in the implication of designer’s intention. When talking about illusion of choice, though often with the same overall outcome as non-choice, the focus falls on the illusory aspect of the mechanic. When a designer presents their players with the illusion of choice, they are interested in making the players feel as if they are influencing the outcome or making a distinct and/or impactful choice. In this case, the designer doesn’t really care about what options they are providing, so long as the player has any options to choose from, resulting in a feeling of control. This can be used poorly (lazy design) or to great effect (reinforcing emotions without letting the player make a mistake or veer off in the wrong direction).
What is distinct about non-choice mechanics is that the designer doesn’t necessarily try to mask the superior solution. They might, and in the sense that since there are multiple options, one can be lead to believe or even argue that they always have a choice. In that case, non-choice is a subcase of illusion of choice, if one were so inclined to define it as such, though the author of this entry does not believe that should necessarily be part of the definition.
Example: At its most basic level, a non-choice boils down to trivial decisions that test the absolute most basic mathematical skills in players. Though that can sometimes be valuable, choosing between Sword 1 which gives you +3 damage, and Sword 2 which gives you +6 damage, is not particularly interesting. One way to get around that would be to add a second property to the weapon, such as differentiation between damage types (say… slashing and piercing attacks).
Now we must tread carefully because difference between the type of output is one of the primary factors that go into providing meaningful choice instead. (Another way to do that would be to stagger the player’s choices in time, in order to make them more meaningful – encountering the weaker item first, then later providing the option to go for the stronger item but through a more dangerous route.) So, we can instead invalidate the aspect of choice, and thus turning what was meaningful into a non-choice, if we then give them the appropriate enemy to fight shortly after.
By pitting them against opponents clad in full plate harness, we can make sure one of these choices was strictly superior by making the other weapon completely useless in the immediate future. Obviously, in a vacuum that would be poor design, because the player generally doesn’t know what their future holds. But suppose they do. What if you have been dropping hints and clues about the upcoming encounter previously throughout the level? Well now in this particular case, you have created a non-choice that actively tests how much attention the player has been paying to the narrative.
In some cases, what would usually be meaningful choice can be rendered into a non-choice by outside factors (e.g. player skill, metagame influence, future updates, etc., among many). It is up to the designer to decide whether or not that’s intended and/or acceptable, or if they want to make the necessary changes to address it.
Example: Once you have a Quake player with near perfect reflexes, precision of aim, and knowledge of the game, the railgun quickly obsoletes basically everything else, reducing the choice of weapon from a meaningful strategic or tactical consideration to the non-choice of acquiring the railgun.
This particular scenario is a very pushed demonstration of this principle in play, but it’s there nonetheless, and it’s very hard to design around such external factors. There are good arguments on both sides of whether or not you even should try to design around such cases in the first place, and that is something each designer should evaluate for themselves and their product’s intended gameplay.
About this series
As is customary with a new periodical, the first entry should contain some sort of overview – what type of content one can expect going forward, what the goals of the publication are, etc. In this case here, the series will be extremely linear. All publications will follow the structure above and provide a short and focused overview of a particular term. The dictionary-like format is mostly to fill space and provide a little comic relief, though I don’t think it has ever hurt somebody to know how something should be pronounced. The key pieces of information presented in any glossary entry are:
- definition – A short paragraph that describes the intended use of the term from a game designer’s perspective, sometimes particularly focused on its application in RPGs, card games, board games, or war games (which will be appropriately marked as such). This description will probably vary in length and delivery until I settle on a particular method everyone is happy with.
- antonym – Juxtaposing one concept to another is equally helpful in understanding its intended functionality and twice as valuable for designers looking to build up their knowledge base. By providing a frame of reference with more common principles and the terminology, people can use their existing knowledge as a stepping stone in understanding and parsing new information.
- commentary – In this section the author of the entry provides insight on why this concept should be part of any designer’s toolkit, potential applications, best practices, etc. Typically between one and three paragraphs.
(do note that each entry can have multiple contributions, and every contributor provides their own commentary)
By building this glossary I hope to accomplish two things – arming fellow designers with the proper tools and giving them consistent terminology that they can use in communication with other designers. Normally, the information given in these entries should not be anything new to experienced game designers or anyone worth their salt, however one can always find something small and useful, perhaps a new way to frame a particular concept or something they haven’t heard before.
While nothing particularly revolutionary or groundbreaking as a project, combining these terms in one consistent, unified glossary, should be of value moving forward. I am then going to use it as a backbone of the AGD project (more info soon).
Lastly, if you want to contribute to this glossary by submitting additional commentary on an entry, disputing information in an entry , or creating a new entry altogther, you are most welcome and encouraged to do so! Contact Nickolay Krumov by e-mail, Twitter or Discord (link is to the TDA server). Please note that submissions will be subjected to editing but worry not, no final version will be uploaded without your explicit approval.
As we work towards creating a online resource with the entries from this glossary, we will be updating our process, so expect announcements to any changes.