non-choice
[nɒn-tʃɔɪs],[non-; nan-chois]
One-time disclaimer on this first post – scroll down to the About section to learn more about the project and how You can contribute!
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
Author commentary: 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 providing these options, so long as the player has 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 case 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 thread 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.
———–
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 formation is mostly to fill space and for comedic effect, 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 (which will be appropriately marked as such). This description will probably vary in length and delivery until I settle on a method I particularly like.
- 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.
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 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 ChimborazoRPG server). Please note that submissions will be subjected to editing but worry not, no final version will be uploaded without your explicit approval.
