Idrelle Games
patreon
Twine Guide: Character Creators
🕑 Added 2022-03-25 00:07:28 +0000 UTCThis is part of a larger project I am working on this year. The goal is to eventually release a PDF guide to creating IF gamebooks in Twine (SugarCube only) and an annotated template that provides sample code and examples of popular IF elements.
I've included a Twine HTML file available on this post that has some examples of the character creator elements I discuss here. Because the Patreon text editor doesn’t allow code blocks, I highly recommend looking at the code in the HTML file rather than copy/pasting from here.
Character creators are an essential part an interactive fiction game. While some IFs give the player an established or pre-existing character to play, the medium is known for its customization and roleplaying capabilities. The ability to make a character and define who they are within the game’s world is a valued mechanic, with many games implementing the ability for players to choose their character’s gender, pronouns, and a multitude of other customization options.
Your game’s character creator (CC) will likely be one of the first things you code. As many of the variables defined in the CC will be used throughout your entire game, you need to decide how much customization you’re going to offer, how and where you are storing that data, and how you are going to present customization options in a clear, concise way to the player.
TYPES OF CHARACTER CREATORS
There are three types of character creators in IF games: fixed, embedded, and mixed. There are pros and cons to all three; which one you want to use will depend on the design of your game, how much customization you offer, and the impression you want to leave on the player.
Fixed Character Creators
Fixed character creators are CCs that occur at the very start of the game. Before the player does anything else, before they even hit the first passage of text or make any choices, the game walks them through making their character. All aspects are chosen, set in place, and once the player is happy with what they have, they can proceed to the game itself.
Fixed CCs are good in instances where you have a lot of customization options. You can design your pages to make the customization as clear and concise as possible, so the player knows exactly what they’re choosing as they design their character. The player can easily backtrack if they make a mistake or change their mind without requiring them to replay any actual gameplay.
Fixed CCs are “gamey” and more closely resemble the CCs of traditional video games. While they may break immersion in the moment, they do allow the player to set everything up first so they’re not interrupted later.
Embedded Character Creators
Embedded character creators are a staple of IF games. They take the customization options of the fixed CC and put them into the text of the game itself. Depending on the game’s handling of prose and description, this can make the character creation process immersive and part of the game’s actual gameplay, rather than something separate. An embedded CC makes a game feel more like a novel than it does a game.
However, because they are embedded the gameplay itself, it is harder for the player to easily backtrack if they change their mind or make a mistake. It is also very easy to write yourself into a cliché (such as the player looking at themselves in the mirror to choose their hair and eye colour). If you have a lot of customization options, embedded CCs can get very unwieldly to implement and take up far more space and time than they should.
Mixed Character Creators
Mixed character creators use elements of both. For example, a game may have most of their customization options defined at the beginning of the game, but leave the name and background choices to an immersive dialogue option during the first section of gameplay. Some games set the player character’s gender and pronouns in a fixed CC at the beginning, then put the rest of their customization options in an embedded CC later in the game’s text.
CUSTOMIZATION OPTIONS
I. THE BASICS
Gender, pronouns, and player character names are the main components of a CC.
Selecting Gender
Establishing the player character’s gender can be both simple and complex. While setting the gender variable is relatively straightforward, you should consider how that variable is going to be used in game. What will gender affect and how does it impact the player? Here are some things to think about:
- Does gender impact the choices the player can make and the paths they can pursue? For example: gender-locked romances (ROs that can only be pursued if the player is a certain gender).
- Does it change the language that is used to refer to the player character? For example: characters referring to the player character as a man if they are male, a woman if they are female, or a person or other gender-neutral language if they are nonbinary/agender/bigender, etc.
- Is gender there for aesthetic purposes? For example, a descriptor in the player character’s in-game profile referring to them as male/female/nonbinary, etc.
How much you want to utilize gender as a control variable depends on your game’s story and setting. A game where gender is not a factor (i.e. a fantasy world without established gender roles) may not need a gender variable at all, where as a game where the player character’s gender actively changes the story (i.e. a historical piece with clearly defined gender norms) will.
Even if your game only ever mentions the player character’s gender in their profile, you may still want to include it. Defining the player character’s gender is extremely important to a lot of players, especially for marginalized gender identities, and seeing their selected gender on a profile can greatly enhance their experience.
Code Examples
Gender can be defined through a link with a single variable.
:: Gender
Select Your Gender
[[1. Male.|Next Passage][$gender = "male"]]
[[2. Female.|Next Passage][$gender = "female"]]
[[3. Nonbinary.|Next Passage][$gender = "nonbinary"]]
If you’re planning on using gendered language to refer to the player character, you can set that here as well. In this example, assume the game is a medieval fantasy game where the address my lord/my lady/ser is used frequently.
:: Gender
Select Your Gender
[[1. Male. |Next Passage][$gender = "male", $person = "man", $ser = "my lord"]]
[[2. Female.|Next Passage][$gender = "female", $person = "woman", $ser = "my lady"]]
[[3. Nonbinary.|Next Passage][$gender = "nonbinary", $person = "person", $ser = "ser"]]
Once the variables are set, you use them in a conditional statement to determine different outcomes or print them in the text.
:: Sample Gender-Controlled Romance Lock
<<if $gender is "male" or $gender is "nonbinary">>The merchant grins at you. “I thought you were a $person of impeccable taste,” they say, smirking suggestively at you.
<<else>>The merchant shrugs. “By all means, continuing browsing.”<</if>>
Selecting Pronouns
Personal pronouns are a little tricker to define than gender. While some games combine pronouns with gender (i.e. choosing to play as a female character sets the player character’s pronouns to she/her) and others take gender out of the equation and only use pronouns, many new in development IF games separate gender and pronoun selection. Others take it a step further and allow the player to configure their own pronoun sets, which keeps the game open to neopronouns.
Regardless of how you choose to implement pronouns, you will need to create some sort of code to handle grammar conjugation. The singular “they” is conjugated in the plural, so if you intend to offer they/them pronouns as an option, you will have to account for this.
Each pronoun case needs a separate variable and an appropriate string. For the sake of clarity, I am going to use they/them pronouns for the variables. It doesn’t matter what you use here as the player will never see it (for example, instead of $they you could use $he, $she, $xe, etc.), but you should choose something that is easy for you to write with.
Subjective: $they
Objective: $them
Pronominal Possessive: $their
Predicative Possessive: $theirs
Reflexive: $themself
Using the above in a sentence would then become:
Subjective: I don’t know what $they wants.
Objective: I met $them today.
Pronominal Possessive: If $they doesn’t get a haircut, $their hair grows long.
Predicative Possessive: If I need a laptop my friend will let me borrow $theirs.
Reflexive: River baked this cake $themself.
And if the pronouns were set to she/her pronouns, the above would print as:
Subjective: I don’t know what she wants.
Objective: I met her today.
Pronominal Possessive: If she doesn’t get a haircut, her hair grows long.
Predicative Possessive: If I need a laptop my friend will let me borrow hers.
Reflexive: River baked this cake herself.
This example does leave you with grammatical errors for they/them pronouns. Set that aside for the moment, we’ll come back to it in a bit.
Code Samples
You can define your pronoun variables through a link or a button.
<<button "He/Him" "Next Passage">><<set $they to "he", $them to "him", $their to "his", $theirs to "his", $themself to "himself", $plural to false>><</button>>
<<button "She/Her" " Next Passage ">><<set $they to "she", $them to "her", $their to "her", $theirs to "hers", $themself to "herself", $plural to false>><</button>>
<<button "They/Them" " Next Passage ">><<set $they to "they", $them to "them", $their to "their", $theirs to "theirs", $themself to "themself", $plural to true>><</button>>
Once your pronouns are set, you can handle pronoun capitalization in your game’s text by using <string.>toUpperFirst() and the print macro. You can add this to your game’s widgets to simplify capitalization.
<<widget "They">><<print $they.toUpperFirst()>><</widget>>
<<widget "Them">><<print $them.toUpperFirst()>><</widget>>
<<widget "Their">><<print $their.toUpperFirst()>><</widget>>
<<widget "Theirs">><<print $theirs.toUpperFirst()>><</widget>>
<<widget "Themself">><<print $themself.toUpperFirst()>><</widget>>
Note: Widgets must be defined in a passaged tagged "widget". See the template for an example.
Alternatively, you can also define a second set of pronoun variables for capitalized pronouns.
<<button "He/Him" "Next Passage">>
<<set $They to "He", $they to "he", $Them to "Him", $them to "him", $Their to "His", $their to "his", $Theirs to "His", $theirs to "his", $Themself to "Himself", $themself to "himself", $plural to false>>
<</button>>
<<button "She/Her" "Next Passage ">>
<<set $They to "She", $they to "she", $Them to "Her", $them to "her", $Their to "Her", $their to "her", $Theirs to "Theirs", $theirs to "hers", $Themself to "Themself", $themself to "herself", $plural to false>>
<</button>>
<<button "They/Them" "Next Passage">>
<<set $They to "They", $they to "they", $Them to "Them", $them to "them", $Their to "Their", $their to "their", $Theirs to "Theirs", $theirs to "theirs", $Themself to "Themself", $themself to "themself", $plural to true>>
<</button>>
Custom Pronouns
If you want to let the player input their own pronouns, you can create a form using textboxes. Whatever they input into the textboxes will print as their pronouns. It’s a good idea to be very clear about which pronoun cases are associated with each textbox. You should also provide a way for the player to double-check that their pronouns are printed the way they want before they proceed to the rest of the game.
If you are defining pronoun variables for both capitalized and uncapitalized pronouns, you should provide two textboxes for each pronoun case. Clearly label which one is for capitalized pronouns and which one is for uncapitalized pronouns.
Modifying Grammar
As seen in the earlier example, you will need to modify your grammar for they/them pronouns. The simplest way to do this is to create a widget to handle the common differences between singular and plural grammar.
The first step is to set a variable to control whether the pronouns are pluralized or not. In your pronoun setup, for singular pronouns you can add:
$plural to false
And the following for they/them pronouns:
$plural to true
If you have a custom pronoun form, you may want to add a radiobutton check so the player can select whether they want their pronouns conjugated with singular or plural grammar.
In your widgets, add:
<<widget "are">><<switch $plural>><<case true>>are<<case false>>is<</switch>><</widget>>
<<widget "were">><<switch $plural>><<case true>>were<<case false>>was<</switch>><</widget>>
<<widget "s">><<switch $plural>><<case true>><<case false>>s<</switch>><</widget>>
<<widget "es">><<switch $plural>><<case true>><<case false>>es<</switch>><</widget>>
<<widget "re">><<switch $plural>><<case true>>re<<case false>>s<</switch>><</widget>>
<<widget "ve">><<switch $plural>><<case true>>ve<<case false>>s<</switch>><</widget>>
When you write a sentence later in your game, you can call on the widgets like so:
$They <<are>> a great person.
Depending on the pronouns chosen, this will print as:
She is a great person.
He is a great person.
They are a great person.
Alternatively—or for conditions not covered by the widget—you can also control it with a basic if/else statement.
$They <<if $plural is true>>are<<else>>is<</if>> a great person.
Pronoun Templates & Changing Gender/Pronouns Post-CC
If you want to let the player change their gender and pronouns whenever they want, you may want to use Chapel’s pronoun template. This will open a dialog box that lets the player configure their gender and pronouns at any time from your game’s settings. The sample code and instructions can be found here. I have also included it in the downloadable Twine sample below.
Pronoun templates like this can be extremely useful when gender in your game has no concrete effects on the game itself. As you won’t be able to easily reference the player character changing their gender/pronouns, this is purely a mechanical option and the continuity of when and where the player changes their gender/pronouns cannot be referenced in-game. Furthermore, if you have gender-locked romances or content, it could be difficult to implement those paths if the player can get around the locks by switching to the required gender to unlock the scene, and then switching back.
If you don’t plan to have gender-locked content, the pronoun template is the most straightforward way of configuring the player’s gender and pronouns.
NOTE: Templates cannot be used in conjunction with if/else statements. If you intend to use the template but also want to include gender-locked content, you will not be able to close off options like you would with a regular $variable:
This Works:
<<if $person is “woman”>>Content gender-locked to women.
<<else>>Other content.<</if>>
This Does Not Work:
<<if ?person is “woman”>>Content gender-locked to women.
<<else>>Other content.<</if>>
II. NAMES
Naming the player character is possibly the most important part of any CC. Name selection screens can be as simple as a single textbox input or much more complex. Some games have multiple name variables to cover factors such as surnames and nicknames. Some have default names that are determined by other determining factors, such as background or origin. How complicated you get with it will depend on the type of game you’re making and the setting (for example, fantasy games sometimes come with default names or name suggestions to familiarize the player with naming conventions).
Simple Textbox Input
The player character has a single name, input by the player through a textbox.
<<textbox "$name" "">>
<<button "Confirm">>
<<run Engine.play("Next Passage")>>
<</button>>
Complex Textbox Input
The player character has a first and last name, input by the player through a textbox. The textboxes autofill with a default name based on gender and background, and there is an additional name suggestions dialog box that can be opened by the player.
<b>GIVEN NAME:</b> <<if $gender is "male">><<textbox "$name" "Gary">>
<<elseif $gender is "female">><<textbox "$name" "Isabella">>
<<else>><<textbox "$name" "River">><</if>>
<b>SURNAME:</b> <<if $background is "thief">><<textbox "$surname" "Rider">><<elseif $background is "noble">><<textbox "$surname" "Percival">><<else>><<textbox "$surname" "Galavant">><</if>>
<<button "Confirm”>>
<<run Engine.play("Next Passage")>>
<</if>><</button>>
<<button "View Given Name Suggestions">>
<<dialog 'Name Suggestions'>>
Masculine Names
* Name 1
* Name 2
* Name 3
Feminine Names
* Name 1
* Name 2
* Name 3
Gender-Neutral
* Name 1
* Name 2
* Name 3
<</dialog>>
<</button>>
<<button "View Surname Suggestions">>
<<dialog 'Name Suggestions'>>
* Surname 1
* Surname 2
* Surname 3
<</dialog>>
<</button>>
Anticipating User Error
Due to the textbox input, the examples above will allow the player to progress through the CC even if they leave the textbox blank. Though I’m sure not many players will want to progress through the game without a character name, you can code your name selection to prevent this from happening. Additionally, you may also want to prevent players from choosing specific names, such as the name of a major character or romance option.
<b>Given Name:</b> <<textbox "$name" "">>
<b>Surname:</b> <<textbox "$surname" "">>
<<button "Confirm">><<if $name is "" and $surname is "">><<replace "#textbox-error">>
Please enter a full name.<</replace>>
<<elseif $name is "">><<replace "#textbox-error">>
Please enter a given name.<</replace>>
<<elseif $surname is "">><<replace "#textbox-error">>
Please enter a surname.<</replace>>
<<else>>
<<replace "#textbox-error">><</replace>>
<<run Engine.play("Next Passage")>>
<</if>><</button>><span id="textbox-error"></span>
If the player character’s name is determined by a textbox, their name will display as the exact text the player inputs, including any capitalization errors. While the player can go back and redo the CC to correct their mistake, you can also fix this by using <<print $name.toUpperFirst()>> whenever you need to print the player character’s name.
III. ADVANCED OPTIONS
Customization can go much farther than gender. Many games offer a wide array of appearance options, backgrounds, and origins that further customize the player character and impact gameplay. Some common appearance options include skin colour, eye colour, and hair colour and texture.
With some options, like backgrounds and origins, it’s a chance for you to introduce a little bit of your game’s world before the story gets started. You may want to add some kind of descriptor or dialog box that explains what the background/origin is and how it affects gameplay mechanics such as stat increases, unique dialogue options, and/or unique abilities (examples are including in the Twine guidebook).
Every game is different and has different needs. While it may be tempting to put in as much customization as possible, always consider how you intend to use those variables. If they have no impact on the game (i.e. you never reference these variables outside the player character’s profile and they never show up in the game’s text or affect gameplay in any significant way), you risk unnecessarily bloating your game.
This is particularly true for appearance options. IF games are different from other gaming because everything within them is communicated via prose and prose is fundamentally different from visual media. Because there are no 3D models or character art to look at, the player has much more flexibility to imagine what their character looks like. In some cases, they may not be necessary at all.
When deciding what additional options you’re going to put into your CC, consider how you are going to use that data in the future. A rule of thumb here is to avoid bloating your game’s data with idle variables. If you put a variable in the game, use it. Don’t let CC options become surface level.
Setting Multiple Options
In SugarCube, the simplest way of setting multiple additional options without forcing the player to click through many, many passages is to use radiobuttons on a single page. This allows the player to select multiple CC elements on the same page and set them with a single link.
Here is a visual example from Wayfarer:
Radiobuttons can be set up with something like this:
<h2>Skin Tone</h2>
<label><<radiobutton "$skintone" "black" checked>> Black</label>
<label><<radiobutton "$skintone" "brown">> Brown</label>
<label><<radiobutton "$skintone" "beige">> Beige</label></div>
<h2>Eye Colour</h2>
<label><<radiobutton "$eye_colour" "black" checked>> Black</label>
<label><<radiobutton "$eye_colour" "brown">> Brown</label>
<label><<radiobutton "$eye_colour" "green">> Green</label>
<label><<radiobutton "$eye_colour" "blue">> Blue</label>
<h2>Hair Colour</h2>
<label><<radiobutton "$hair_colour" "black" checked>> Black</label>
<label><<radiobutton "$hair_colour" "brown">> Brown</label>
<label><<radiobutton "$hair_colour" "auburn">> Auburn</label>
<label><<radiobutton "$hair_colour" "red">> Red</label>
<label><<radiobutton "$hair_colour" "blonde">> Blonde</label></div>
<h2>Hair Length</h2><label><<radiobutton "$hair_length" "shaved" checked>> Shaved</label>
<label><<radiobutton "$hair_length" "short">> Short</label>
<label><<radiobutton "$hair_length" "shoulder-length">> Shoulder-length</label>
<label><<radiobutton "$hair_length" "long">> Long</label>
<label><<radiobutton "$hair_length" "waist-length">> Waist-length</label>
Assign each option its own variable. Use “checked” to set a default value (this prevents user error in case the player clicks through to the next passage without selecting an option). To improve accessibility, wrap each option with the <label> wrapper to allow the player to click on the radiobutton text (otherwise they will have to click on the little button).
In your Story Stylesheet, add the following CSS:
label {
cursor: pointer;
}
This will turn the player’s cursor into a pointer when they hover over the radiobutton’s text, indicating that they can interact with it.
You can also achieve a similar thing with dropdown menus (listboxes) and cycling links.
Listboxes
<b>SKIN TONE:</b> <<listbox "$skintone" autoselect>>
<<option "black">>
<<option "brown">>
<<option "beige">>
<</listbox>>
<b>EYE COLOUR:</b> <<listbox "$eye_colour" autoselect>>
<<option "black">>
<<option "brown">>
<<option "green">>
<<option "blue">>
<</listbox>>
<b>HAIR COLOUR:</b> <<listbox "$hair_colour" autoselect>>
<<option "black">>
<<option "brown">>
<<option "auburn">>
<<option "red">>
<<option "blonde">>
<</listbox>>
<b>HAIR LENGTH:</b> <<listbox "$hair_length" autoselect>>
<<option "shaved">>
<<option "short">>
<<option "shoulder-length">>
<<option "long">>
<<option "waist-length">>
<</listbox>>
Cycling Links
<b>SKIN TONE:</b> <<cycle "$skintone" autoselect>>
<<option "black">>
<<option "brown">>
<<option "beige">>
<</cycle>>
<b>EYE COLOUR:</b> <<cycle "$eye_colour" autoselect>>
<<option "black">>
<<option "brown">>
<<option "green">>
<<option "blue">>
<</cycle>>
<b>HAIR LENGTH:</b> <<cycle "$hair_length" autoselect>>
<<option "shaved">>
<<option "short">>
<<option "shoulder-length">>
<<option "long">>
<<option "waist-length">>
<</cycle>>
<b>HAIR COLOUR:</b> <<cycle "$hair_colour" autoselect>>
<<option "black">>
<<option "brown">>
<<option "auburn">>
<<option "red">>
<<option "blonde">>
<</cycle>>
NOTE: Cycling links are links the player clicks on multiple times to cycle through their options until they find one they like. Use cycling links with caution. Despite the interactivity they bring, they have a few major disadvantages.
1. There’s no differentiation between a cycling link that changes variables and values, and a normal link that forwards the player to the next passage.
This can cause confusion for the player, particularly in segments where the passage ends with an interactive text link to forward them to the next passage.
If you have add in unique CSS to differentiate your navigational links, then this isn’t much of a concern. However, you should always consider how your game design can be misinterpreted and fail to communicate what you intended.
In the template, I have added a cycle icon in front of the cycling link macro.
2. Cycling links make it difficult for the player to see all of their options in one go.
This can harm player experience if you have multiple cycles setting multiple variables with many, many options. Players have to continually click on the cycle to see what all the options are, then click through again to get back to the option they want. This is, in my opinion, a pretty frustrating experience, especially for in-depth character creators with many, many options. I don’t think the seamlessness of an embedded character creator is worth it when balanced against poor user experience.
If your character creator is small and doesn’t have a lot of options, then it’s most likely fine. But I would reconsider using the <<cycle>> macro if character customization is a significant part of your game.
3. Screen readers cannot read the <<cycle>> macro.
This is a major accessibility issue for players who need a screen reader to play your game. HiEv has provided a workaround which requires some additional JavaScript and CSS which I have included in the template. However, this has not been fully tested and it may not work with all screen readers.
Setting Character Backgrounds
If you want to incorporate character backgrounds into your game, you should first decide how those backgrounds are going to affect gameplay. A common way to make a background relevant beyond changing flavour text is to make it adjust character stats or to give the player a unique ability.
It’s a good idea to provide some kind of description of the background so the player has all the information they need before they make their choice. You can do this using the <<message>> macro, a dialogue box, or simply providing the description below the setter link. I’ve provided a couple different examples in the template.
If you want to have the character background adjust stats, you can do that when you set the background. For example:
:: Background Selection
* [[Thief|Next Passage][$background to "thief", $sneaking +=2]]
* [[Noble|Next Passage][$background to "noble", $diplomacy +=2]]
* [[Knight|Next Passage][$background to "knight", $combat +=2]]
Clicking on these links will set the $background variable as well as give +2 to the relative stat (sneaking, diplomacy, or combat).
You should set your player character stats to 0 in your StoryInit passage (or whatever your base number happens to be). Otherwise, there a number won’t exist for the game to adjust.
PRACTICE TEMPLATE
If you want to see examples of some of the code shown here in action, download the Twine Guidebook Version 1.1 HTML file. You can either run it in your browser or pop it into the Twine editor and view the code.
I haven’t designed the template’s UI yet, so this version uses the default SugarCube UI.
If you work in Visual Studio Code, you will have to decompile the HTML file its TW file, CSS and JavaScript components and then open it in VSC. I won’t be providing these separate files until this project is done.
