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. 
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."
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. 
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. 
$!{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.
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
*rand height VERY_SHORT VERY_TALL
@{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, 
. It’s commonly called constant-case, though.
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.
Honestly, I think using ${him} to stand in for “her” or “them” would actually confuse me more than ${object}. My brain is just weird.
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.
Just remember “his” appears twice.
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.
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