Text with lots of pronoun variables

I’ve seen some snippets in the monthly support threads, so I know these are out there!

Here’s one from my wip:
$!{nan_pronoun_sub} @{nan_plural_verb blink|blinks}, then @{nan_plural_verb let|lets} ${nan_pronoun_obj}self be pulled in. Once ${nan_pronoun_apo} on solid ground, ${nan_pronoun_sub} @{nan_plural_verb mutter|mutters} a sheepish "thanks."

That’s not really all that complex, but it’s got almost as many multireplaces and variables as actual text, help. :laughing:


At that point I’d just use an *if tree.


I’m not currently working on anything. But I’d use almost the same amount of interpolation. I prefere shorter variable names because of that. I use camel-case instead of snake-case too.

*create nanThey "he" 
*create nanThem "him" 
*create nanTheir "his" 
*create nanTheirs "his" 
*create nanThemself "himself" 
*create nanTheyre "he's" 

I also use a variable to save the final “s”. It can be an empty string in case of “they”.

*create nanS "s" 

Só in the end it would be something like this:

$!{nanThey} blink${nanS}, then let${nanS} ${nanThemself} be pulled in. Once ${nanTheyre} on solid ground, ${nanThey} mutter${nanS} a sheepish "thanks."

:exploding_head: This absolutely sounded like gibberish in my own head, I don’t think my brain is equipped to try to understand that LOL

I didn’t know they were called that! That’s really cool! The more you know.

I understand this at vague value but I would not be able to make heads or tails of it when reading. Definitely more of an “if” statement person. :no_mouth:


if/else statements would massively inflate the amount of code in the game over the long run, although I suppose in most cases the pronoun variables aren’t used so heavily and aren’t as hard to figure out:

This person's eyes aren't just wide, you realize with a start. That's panic, running away every bit as fast as ${nan_pronoun_sub} @{nan_plural_verb were|was} a moment before.

At least for me, I’ve also found that if/else statements introduce more room for error. I’m much more likely to miss changing a pronoun or introduce a typo if I’m having to go through the same bits of text three times each!

Shortening the variable names makes sense. I do tend to make mine long in general… lol


Years ago, someone on the COG Discord (I think it was Chris_Conley; apologies if I’m mistaken) shared how to do pronouns with arrays and I’ve greatly preferred that method ever since.

Using the Nan example:

*create_array he 3 "he" "she" "they"
*create_array him 3 "him" "her" "them"
*create_array his 3 "his" "her" "their"
*create_array hes 3 "he's" "she's" "they're"
*create_array s 3 "s" "s" ""
*create_array is 3 "is" "is" "are"

*create nan 2

$!{he[nan]} blink${s[nan]}, then let${s[nan]} ${him[nan]}self be pulled in. Once ${hes[nan]} on solid ground, ${he[nan]} mutter${s[nan]} a sheepish "thanks."

That’s how I would do it if I were optimizing for readability.

In reality, as the only soul who has to maintain my projects’ code, I often prioritize other things over readability. *if statements? Only as a last resort. :wink:

$!{E[stag]} examine${S[stag]} the faded photograph. "After @{stag Wynley|Hazelton|Corbinger}, @{stag=burke we studied together|I studied} at Tolfield.@{stag=burke "| That is where we met."} $!{E[stag]} pause${S[stag]}, placing the photograph back down on ${EIR[stag]} desk. "$!{E[burke]} was a @{((stag=MALE) and (burke=FEMALE)) close companion|friend}@{stag=burke , though I suspect ${E[burke]} wished we were something more|}."

I’ve vaguely thought about writing a guide to alternatives to *ifs, (tentatively titled Impractical ChoiceScripting: A Guide to Clearcutting Your If/Else Tree Forest and Other Questionable Coding Techniques to Miss the Forest for the Trees), but I can’t imagine it being remotely useful to, well, anyone.

There are a lot of funky names. In addition to snake_case, there is SCREAMING_SNAKE_CASE, kebab-case, TRAIN-CASE, lowerCamelCase, UpperCamelCase...

kebab-case can’t be used in variable names, but it can be used in file names and label names.

I use it to tell crunch and fluff apart at a glance. If I see *gosub poker-win, I know it is just showing a scene and coming back, while *gosub play_poker is doing work behind the scenes.

I use SCREAMING_SNAKE_CASE for variables I have to make coding easier, but that shouldn’t change value. E.g.,

*create height 1
*create VERY_SHORT 1
*create SHORT 2
*create AVERAGE 3
*create TALL 4
*create VERY_TALL 5


@{height>AVERAGE You're tall!|You're not tall!}

Makes them easier to understand, plus you can easily discover if you messed up by searching for *set (any capital letter).

Edit: even with all those words I didn’t get around to saying what I really like about the array method – you need a whole lot fewer variables.

Setting up a new gender-variable character is as easy as adding a single variable. Adding new gender-related words is as easy as a *create_array command.

I’ve found it has let me do fun (for me) things like have characters with multiple pronoun sets or make very minor characters gender-randomized. If the player input custom pronouns (which I generally store at the 4th and 5th positions in the arrays), it’s easy to have other characters in the world use them.


This is a really good way of doing it!

Also super creative way of handling it. I just do it this way:

*create height 1
*comment 1 very short
*comment 2 short
*comment 3 average
*comment 4 tall
*comment 5 very tall

But I like how your method doesn’t require any cross-referencing. It’s easier to understand height>AVERAGE than height>3 at a glance.


That’s actually a common coding practice. A variable that doesn’t change value is called a constant. It’s Google practice to change “magic numbers” (this is the actual name of the concept) for constants.

And this is the first time I’ve seen it called screaming snake case, I think I prefer this name, :joy:. It’s commonly called constant-case, though.

1 Like

This is why I use he/him/his/etc as variable names. Writing “It belongs to ${him}!” is so much easier than using a neutral grammatically descriptive variable name. I’d prefer if it didn’t reinforce male-as-default and all that, but for under the hood coding it saves so much time and makes things so much more readable.

1 Like

Honestly, I think using ${him} to stand in for “her” or “them” would actually confuse me more than ${object}. My brain is just weird. :laughing:

I do like the idea of using arrays! I always forget that choicescript supports them.

The fact that you could stick blink${s[nan]} in a multi_replace definitely is compelling.

I’m not sure it’s worth the time to change course when I’ve already written some of the game… but I guess it would be better to do it now that I’ve only got a chapter and a bit written, rather than later down the line. I might play around with it and see how long it takes me to go in and change the code.

1 Like

Just remember “his” appears twice.

1 Like

That’s why I prefere “they”. They’re all different.

They He She Thou
Them Him Her Thee
Their His Her Thy
Theirs His Hers Thine
Themself Himself Herself Thyself

There you go. :joy:


I like the height>SHORT way of doing it a lot; I do what @will does and sometimes have to look up what each value means.

I’d love to use arrays for neater variable creation, but I find it harder to touch-type the square brackets and to read the text. I’m sure it’s just a case of getting used to it though!

This is what I do:
Fiore has said nothing. $!{fio_they} ${fio_have} clasped ${fio_their} hands behind ${fio_their} back, looking supremely uncomfortable at this turn of events. $!{fio_they} @{fio_pl take|takes} a deep breath. "I really should be going," ${fio_they} ${fio_say}. "This is entirely not my business—"

In Noblesse Oblige I only used one letter and he/him so p_he etc but the three-letter prefix feels good too. I create ${npc_say} and other common verbs so I don’t have to do things like that @fio_pl take|takes} for frequently repeated words - it’s been much more accurate in terms of typing things out.

There was an interesting thing before I started at a former workplace where npc_she was used by default, and the writers wrote a scene with “she” in their minds, which then came across unpleasantly when the same dialogue and description was used to describe a male NPC. Perhaps if npc_he or npc_they was used behind the scenes, it might not have been written in the same way.

I’ve found that when writing with ${npc_they}, which I’ve been doing for the first time in my current project, players notice verb-agreement typos more reliably. More players pick he or she for themselves and their characters, so if I accidentally write ${fio_they} say more players will spot the incorrect printing of he/she say. But when I used ${npc_he}, if I accidentally wrote ${p_he} says most people would see he/she says and the error was less likely to be seen and corrected.


I might use “thou” just to amuse myself, if I wasn’t using arrays :laughing: