A fairly standard feature in choice-based IF—in my limited experience—is having some choices be disabled based on the state of the world. You chose to support the centaur tribe over the merfolk city-state back in chapter 1, so in chapter 2, the option to ask the merfolk archon for help is gone.
In ChoiceScript, the default way to do this grays the choice out, so the player knows it could have been possible (but isn’t any more). In Ink, the default way to do this doesn’t present it as an option at all. And one piece of feedback I got in IntroComp was that some players prefer the first way.
Technically speaking, this doesn’t seem too difficult to implement in Ink. (Or the opposite in ChoiceScript, for that matter.) But I’m more curious about the design aspects of it. What are the benefits and drawbacks of each option? And do people generally prefer one over the other?
Disabled choices give me the impression my choices matter. My actions did disable that choice. Or my future actions will enable it. I prefer the later, it’s like a locked door.
If you’re only talking about choices disabled forever because of past choices, I don’t know. If the game is set up for replayability, I think I’ll like the promise that my next run can be different.
The point of showing alternate choices is to orient the player in what else they could have done. To say more, you have to think about the game structure.
If the player can go out and get more (money/experience/nightmares/whatever) and then come back to this choice, you’re defining a gameplay loop. Disco Elysium does this.
If they can’t, but they expect to replay the game and try different branches next time, you’re defining a… I suppose I should call it a “metagameplay loop” but I’m not sure if anybody else does.
If you’re just taunting them with stuff they can no longer access, whether it’s a good or bad idea depends on how mean you feel. :)
Another way to look at it is if playing so many branches will open up a path to perfect ending. Visual Novels do this, but the perfect ending path is hidden and only revealed when available after playing all other available path. However, all normal paths are shown in the beginning, although they may be explored only one at a time.
I generally prefer the disabled choices to be hidden, because then I have to think more about what options I might not be seeing and why. This also makes it easier for the game to hide secrets (for example, there might be multiple different ways of trying to persuade someone to stop a war, some of which require knowledge of the political situation. It’s easier for the game to protect spoilers from players not ready to have them if choices are disabled.
However, I can certainly see the attraction of exposing the choices, especially in games where the secrets are between the choices rather than in the choice menu itself. Also, some people need to be able to see all the options to make plans. It’s a lot easier to justify using rollback promptly if a player can see why rollback could help.
For some games, the ability to toggle option visibility would be ideal.
Budacanta hides disabled choices since the disabled choices are not meant to have occurred to the character, thus not relayed to the player. The octopus project will probably reveal them, although this isn’t set yet. Different interactive fiction may have different optimum states.
For me it definitely depends on what the game is seeking to accomplish. In some cases, seeing disabled choices (when the disabling is the result of a past action that can’t be undone) can break my immersion; I get distracted thinking about why that choice is disabled and what I might be missing out on by not having it instead of focusing on the choices I do have. So generally, if a choice I make at some point makes some future choices un-pickable, I’d rather those un-pickable choices be hidden. BUT I can also imagine showing the disabled choices working really well (there are probably examples that I’ve played…), most likely in a very story/character-focused game, to specifically show the player what opportunities have been lost to them as a result of their past choices.
When disabled choices show me the possibility of something I could do in the future if conditions change, a la Disco Elysium, I do tend to like that.
In my particular case, the main reason options are disabled is because of the “character creation” (is there a better word for this?) in the prologue. In the first scene, you decide whether your character has always had friends everywhere or is good at working with technology, whether they can turn invisible or speak to animals, and so on. So it is about your choices, technically, but not in any particularly thematic way—more, “if you could turn invisible (but you can’t), you could spy on this meeting without getting caught”.
(In this work, options disabled due to later player choices tend to be obvious already—you burned your bridges with this character so now you can go to his office, but he’ll refuse to talk to you—so those I’m less worried about.)
I don’t think it takes much: your character musing once or twice in the game along the lines of “oh, to be a fly on the wall in that meeting” would probably be enough to get the player considering that they’d have different options available if they made different character creation choices. Especially since they (presumably?) saw all the options when the game started?
Ren’Py can definitely set the preference if an author adds the appropriate settings (and, for the really complicated cases, apply variables), although this isn’t done out of the box and most Ren’Py games use its default option (hide the choices).
Like Choicescript, it’s also possible to set this on a menu-by-menu and choice-by-choice basis. (Someone who doesn’t mind the complexity could even program modes involving different degrees of revelation, by revealing/hiding most choices but doing the opposite behaviour with some.
Revealing some but hiding a few might be useful in a game where much of the time is spent in a town with opening and closing phases (so the revealed disabled choices remind players where they can find the corner shop when it’s daytime or the nightclub when it’s no longer 8 am), but where some narrative secrets would be kept.
Hiding most but revealing a few could be useful if the interactive fiction is mostly a gauntlet dungeon with bad choices are only revealed if the player has previously blundered (thus people who play well are rewarded by seeing their character use the player’s earlier good decisions to automatically overcome threats), but where the last sequence has a boss fight where there are multiple ways the character can tell the enemy could be taken down without necessarily having the means to do so (at which point, the author probably wants to encourage replays in order that players can explore those different ways to take down the boss).
I think it depends on the kind of story you’re telling and how “gamified” it is.
Some stories are more personally immersive and experiential; the journey, not the destination. If there’s no clearly defined end-goal the PC and the player are aware of and working toward, being taunted with disabled choices is usually distracting and unnecessary. Especially if it’s not quite clear what previous choices served to toggle the current choices.
For replayable choice-labyrinths where the player is aware of their statistics and potential end-goals, seeing disabled choices is a good option since it indicates in real time where certain statistics might have been helpful. Especially in an RPG-like where the player can make diegetic grind choices toward a singular or multiple goals and endings: “Do you want to spend time at the gym (+1 STR), the library (+1 INT), or visit Bob (+1 REL)?”
Occasionally a disabled choice can also be an indication of brain state whether it can actually be toggled back on or not. Getting a choice like [Tell her you love her.] or [Admire the beautiful vase.] [Smash the vase to bits.] might be effective in a game where the PC has intrusive thoughts or emotional hesitancy, and can well-utilize the tropes of IF in meta-fashion to get across character detail without explicitly narrating it.
I think everyone’s pretty much covered it but there’s a use for both. Not so much over here, but if you plan release a game written in CS over on say HG, I find a lot of people playing choicescript games have a tendency to assume the game will be linear and there is probably one main goal to the story rather than a branching on (most CSGs tend to follow a branch and return format), so allowing disabled choices to show can be a kind of signpost to indicate there are other ways to go about something, or routes they haven’t seen.
If can also be used to show effects without having to constantly narrate it in the text itself. For example if you have a deteriorating stat, it might lock out out of certain actions. (For example increasing weakness, poor relationship status etc.)
On the other hand if showing choices that have not been uncovered yet will cause spoilers or give hints to puzzles you don’t want to give, you can hide them. For games that have a huge amount of customisation, hiding choices can also prevent huge lists of actions most of which are unselectable from happening. (For example those superhero games which allow you to choose particular powers. It’d probably get annoying having greyed out options the whole game to a power you haven’t selected.)
One of the projects I’m working on is a new version of Escape from the Crazy Place written in ChoiceScript. Previous versions of the game have been sprawling time-caves with branches that loop back and connect with others, creating a spaghetti-like narrative in which players can revisit past events and try a different path. In the new version I’ve tried to give the game a bit more structure, a sort of hybrid of branch-and-bottleneck and spoke-and-hub. In practice this has been a bit like trying to wrestle an angry python into a fishnet stocking.
One thing I’m keen to do is to prevent the reader from revisiting areas of the game where every branch has already been explored, and I’ve been doing this with state-tracking. Thus when the player finds themself back at a hub, a thoroughly explored area will no longer be accessible. For this I’ve used the greyed-out option, with a humorous explanation for the greyed-out-ness in the link (“out of order”, “closed for refurbishment”, “permanently closed”). In other cases, where for instance the player doesn’t have the right item to perform an action (the game has an inventory management system) I’ve used the invisible-choice option. That way the player won’t even know there was another option until they reach that point again having discovered the object in question. The game is designed for maximum replayability, with the ultimate goal being to find all of the endings.