Category: interactive fiction

As I’ve mentioned here before a few times, I’m working on a project for Choice of Games, and it’s once again brought me up against a challenge I’ve run into a few times before when writing for Fallen London and to some extent with Versu. As mental shorthand, I’ve come to think of this as “the check-or-set problem,” though really it should maybe be the check-set-or-gate problem. It is as follows:

When you’re writing in a choice-based medium backed with stats – so ChoiceScript, StoryNexus, Undum, Ren’Py, possibly a hand-rolled Twine system, or inklewriter if you choose to use variables extensively – you have to decide how to treat choices that relate to personality stats.

When I say personality stats, I do not mean “all stats that might make up the protagonist’s profile.” Choices that have to do with resources – how much money you have left, how many classes you have time to take – are comparatively easy to deal with because there are typically obvious narrative contexts where your resources might go up or down, or where your supply of a resource would come into play. I’m not considering that type of stat here.

No, the challenge comes in when dealing with personality traits where we’re trying to collect that data from the player and then reflect it back. In ChoiceScript, I’m especially talking about opposed stats. For instance, in ChoiceScript one might have the opposed stat of Daring/Practicality, where a score of 20% might represent that you are very daring and a score of 80% might represent that you are very practical. Both ends of the spectrum correspond to actual personality characteristics, rather than just the absence of something. And each end might be desirable in a different situation.

So here is the trick about personality stats. Some of the time you might be asking the player to make choices to establish character, in which case choosing to do something Daring should set the player’s Daring stat higher for future reference.

At other times, you might be using stats to determine whether the protagonist has the personality or skills to pull off the approach the protagonist just chose: are they Daring enough to do this skydiving stunt? In that case, you’re checking previously established stats to decide what result to report to the player.

Finally, you might use the player’s stats to determine whether a given choice is available at all. Perhaps a player with low Daring simply isn’t offered the skydiving option. Now you’re gating the option based on stats. At that point you have to make an additional decision about whether to show the player that the option exists but is just greyed out currently (*selectable_if, in ChoiceScript), or whether you want to conceal that option completely from players without the proper stat profile (regular *if).

Greyed out options advertise that alternate possibilities exist, which is useful for communicating to players when past actions are creating consequences in the present moment. On the other hand, secret options that appear only when you have the right knowledge or stats can be fun to discover on replaying.

If you don’t have a consistent strategy around when to check, set, or gate, you’re likely to confuse the player. I find this especially true in ChoiceScript, where the UI does not offer any warning about the mechanical implications of a choice: you just get “Skydive!” and no automatic information about whether that’s going to make you a more daring person or conversely test your previous daring.

For instance, here there are some narrative cues – this is the first move of the game, so we must be setting, and also the use of the past tense tells us that the player is establishing backstory and character aspects rather than taking a risk in the present moment. But nothing about the UI in this scenario distinguishes between setting and checking:

StoryNexus, by contrast, shows the player if a stat is going to be checked to determine chance of success, and gives information about what the current success odds look like. This level of mechanic-surfacing gives the output a more game-y flavor but also (in my opinion) provides the player with a greater level of control:

Undum sort of splits the difference by keeping the stats table permanently on screen in a sidebar, so while you might not know in advance what a link is going to do, you’re likely to be more aware of what is happening link-wise than in a ChoiceScript game in most UI configurations:

inklewriter, meanwhile, doesn’t automatically surface variables at all. And though there are personality stats underlying 80 Days, and though you sometimes get a message saying that yours have changed, you can never see a chart of all of them, and you don’t know when they’re being checked. You do get a number (see the lower lefthand corner) that describes your relationship to your master Fogg, but there’s quite a lot else happening here, to which the player doesn’t have access:

It largely works, I think, because those personalizing stats aren’t really the most important aspect of the game, and there’s a lot of state – cash flow, location, routes known, etc. – that the player does get to see. So our sense of agency focuses on those.

Below the fold, some thoughts on the different possible strategies for writing personality stats content.

Continue reading “Set, check, or gate? A problem in personality stats”