Objective vs. Subjective

Up until now, I’ve been trying to stick to the objective facts: how to construct a JSON statement and what a JSON statement even is, that sort of thing. There are still objective truths to relate, but the personality section is where things start to get more subjective.

There’s a reason that people are interested in interacting with AI-enhanced chatbots. It feels like there’s someone on the other end of the conversation, coming up with their own ideas and input.

Whatever your own particular reason, if we’re honest with ourselves, I think a fair assessment of what people look for when they start an interaction with an AI-assisted chatbot character is this: “I’m interested in the theme this character represents and in exploring that in a way that meets my expectations.”

That’s a pretty tall order to fill, creatively. That’s where the beauty of the AI-assist comes in, because honing in on the right details while leaving the rest of the details in the hands of the AI and any potential end user allows that to happen.

When you’re creating a character, you aren’t writing the final draft of a story; you’re just blocking out the scene. Too little detail and there’s nothing to grab someone. Too much, and you alienate people who wanted to have their own experience, not relive yours.

So there’s a lot of subjectivity to the Personality and Scenario sections beyond just “type this here and then fill in your own values.”

Keywords

There are exactly two keywords that everyone writing and using chatbot characters on any platform should understand: {{user}} and {{char}}.

I’ve never seen either of these keywords used with any other punctuation on any platform. Even if you are writing your instructions in plain English, rather than marking up your instructions with JSON, you’ll still need the braces around both words for the AI to know you are using them in a specialized context.

Typically, anywhere you type {{user}} in a chatbot instruction, the platform will substitute the name of the chat persona representing the user starting the chat. My Oobabooga and KoboldCpp installs both allow me to create personas to represent various versions of me. As RPG and cosplay are definite draws for chatbot interaction, only being allowed to be one version of myself would be extremely limiting.

The keyword {{char}} represents the character, as you might have guessed.

If you write your instructions using {{user}} and {{char}} then you can quickly create a little code library of snippets in a text document that you can copy and paste into any chatbot character field.

The caveat: not all systems replace {{user}} and {{char}} at the same point in time. Some chatbots apparently don’t run the substitution until AFTER reading all the instructions. This is why you will see some chatbot instructions written in terms of the character’s name, and perhaps referring to any real person interacting with the character as “an individual.”

I have read a possible preventative measure to this problem is to create chat personas that include the instruction “{{user}} = Persona Name”, where you swap out Persona Name with the name of your chat persona. I don’t know if this is effective as my local installs and GirlfriendGPT seem to process {{user}} and {{char}} substitutions up-front.

As a style tip, I would avoid using {{user}} in the description field. At least on GirlfriendGPT, the description field is what you see before you start a chat. There is no persona loaded yet and so {{user}} will pull your name from your GirlfriendGPT profile.

Soft Keywords

Aside from {{user}} and {{char}}, there are a lot of soft keywords recognized by the chatbot’s AI. Things like “Name” or “Character Name”, which essentially mean the same thing and will represent the same value.

You can create an array called “outfits”, or you could call it “clothing”. Clothing seems to be the clear favorite, but the beauty (and danger) of the AI’s language model is that it gets to interpret what you say. So “outfits” or “clothing” both work, but “threads” probably won’t, unless your platforms LLM was trained on old episodes of Welcome Back, Kotter.

There are also soft keywords like “WorldState”, where one could presumably list locations, set the time and date if necessary, describe the weather.

This is another strong argument for writing chatbot instructions using JSON, rather than allowing the platform to interpret your wording based on what it thinks you meant.

Very commonly used soft keywords are “locations”, “clothing”, “physical description”. JSON doesn’t prevent you from using common words that make sense to you. It simply ensures that the chatbot has a greater chance of understanding them in the right context.

Pronoun Disambiguation

Finally, before getting into the nuts and bolts, another thing to consider when writing chatbot character instructions is how to use pronouns like “I” and “you” to refer to the character and the end user.

After conversing with a number of chatbot characters, by far the biggest problem that breaks the immersion is when the AI confuses the character and the user.

The easiest way to avoid this is by using {{user}} and {{char}}, and narrating everything in the third person (he, she, it, they, etc.).

Whether you’re going to write any descriptive text in first, second, or third person, it’s important to be clear and consistent. You’re setting the tone for the character and for whomever might want to chat with it. Because it is very easy for an end user to break a chatbot by switching the narration POV, inadvertently ruining their own experience. Setting a narration style up front that is clear to the AI and the end user will greatly reduce the frustration of a conversation suddenly getting very confusing and wrong.

Finally! Character Details

Before you start filling out the Personality section for a new character, you should know it isn’t just one section; it’s three.

There’s the character itself. Straightforward enough. Then there are instructions to the character that dictate how the AI should behave when acting as that character.

Finally, there are AI instructions that define how the AI should narrate interactions between the character and the persona of the end user.

Typically, you disambiguation between instructions for the character by using the keyword “Instruction” at the beginning of each statement. Those that dictate how the AI should narrate interactions between the character and the user’s persona are preceded by “AI Instruction”. (There are a third set of instructions that typically go in the Scenario section, so that’s where I’ll explain them).

I don’t know if the folks at AI Girlfriend Expert invented this or if it is a standard, but they had the good sense to include the character instructions “Instruction” inside the JSON object that wraps the entire character’s definition, making it crystal clear that they are part of the character’s definition. That’s smart. I’m using it.

{
   "character" : [
                 "name" : "Beauchamp",
                 "age" : "42",
                 "height" : "72 inches",
                 // and many other things as well
                 ]
Instruction("{{char}} behave this or that way.")
Instruction("{{char}} always or never does this thing.")
}
AI Instruction("{{char}} never speaks for {{user}}")
AI Instruction("{{char}} controls {{user}} actions in any way")

In the above example, I’ve instructed the chatbot to create a character named Beauchamp (that’s BEE-chum when used as a name by English speakers, if you were wondering), who is 6-feet fall and 42 years old, with a reminder to fill in more details later in the form of a comment (Note: Never leave comments in your GirlfriendGPT fields. They will only weigh down your token count. Create in your favorite text editor, then copy, paste, and edit into your fields.)

Obviously, the instructions I’ve given the character don’t make any sense as is, but they do tell you the sort of thing that you’ll want to put here, and where to nest it in your JSON.

The AI Instructions I’ve given are very common options. Without them, the AI will absolutely try to hijack the story and move it along creatively. That’s what the chatbot was designed to do. But most end users want to be in control of how the chat unfolds, so placing constraints on how the character can interact with the user is a popular way to ensure that happens.

Finally, taking another stylistic cue from AI Girlfriend Expert, I’ve written most of my JSON code using the “key” : “value” standard, but I’ve used Key(“Value”) for instructions simply because it’s easier for the eye to spot the difference. I’m going to try to be very consistent with that standard throughout any chatbot tutorials or posts.

Yep. The Kitchen Sink, Too

I always create a character as a top level array inside a JSON statement.

{
"character" : [
              "attribute name" : "attribute detail",
              ]
}

Strictly speaking, this isn’t necessary. I could just assume the AI knows I’m talking about the character I’m creating, and I could just start off like this:

{
"name" : "Beauchamp",
"age" : "42"
}

But what if you want to include a second character? Perhaps Beauchamp is something of a Jekyll and Hyde. I could conceivably create a second character ALSO named Beauchamp, with an entirely different personality and even different instructions.

Each time you define an array, even one with a single item in it, you are blocking off code for easy reuse and reference elsewhere. You can think of an array as a drop-down list that gives you a set of predefined options. Don’t just put everything in an array because you can, but thinking in terms of “objects” (A person, an outfit, a location, a plot point, etc) will prove helpful.

You could conceivably put anything you wanted about your character in this section, all too easily taking up your entire 2,500 tokens. All that is required is that the AI understands what you’re saying, and understands what it means.

All that’s required on your part, other than correct formatting, is determining what you want to dial down, and what you want to leave to the imagination of the AI and the person who will be using your character.

Even though we’ve just started describing the character, it’s good to think about how much information you might want to put into the setting and the scenario in which your character will find itself. You’ll probably find that you have to sacrifice detail in one area in favor of others. In any case, brevity as well as clarity are key to creating good characters.

Stephen King wrote a fairly definitive book about creative writing, called On Writing. I can’t recommend it highly enough. Among many other recommendations, Mr. King advises writers to “kill your darlings.” Does what you wrote actually add to the story, or was it merely a flex?

That should be a prime directive in character creation. Physical descriptions should be somewhat definitive as you’ll be generating (or supplying your own) an image to represent your character visually. GirlfriendGPT also has the ability to generate photos and video of your character, so there’s only so much leaving it to the imagination you can do with physical characteristics.

Fortunately, basic physical statistics like eye color typically don’t change much during a story, so you can streamline a physical description onto one line if you want. Or, you can be a bit more granular and break out the details you want to stress.

{
"character" : [
              "name" : "Beauchamp",
              "physical description" : "42yo, tall, muscular, lanky, blonde, short hair, blue eyes."
              ]
}

vs.

{
"character" : [
              "name" : "Beauchamp",
              "age" : "42",
              "physical description" : "tall, muscular, lanky, blonde, short hair, blue eyes"
              ]
}

I always make a habit of breaking out the character’s age, at least. Especially for sites that include NSFW content. People get very casual with their language, and an AI might not understand that a “frat boy” or “girl Friday” are, in fact, intended to be descriptions of adults. Aside from being a GROSS and GROSS!!!! violation of every TOS everywhere, what an awful experience to give an unsuspecting person who was using very casual and accepted language (OK, so girl Friday is pretty old school and I would never… but just for the sake of an example).

People using your character will obviously get a lot of physical information from the image you supply or generate to represent your character. With GirlfriendGPT, at least, any subsequent images someone generates do have some image-to-image capabilities, but not that strong that a mismatched physical description won’t override it. You might find you don’t have to specify eye and hair color, for example.

Depending on the context, you could describe clothing all on one line

{
"character" : [
              "name" : "Beauchamp",
              "age" : "42",
              "physical description" : "tall, muscular, lanky, blonde, short hair, blue eyes",
              "clothing" : "Brooks Brothers suit, wingtip shoes, black silk tie, white oxford shirt"
              ]
}

It’s very popular to create characters with different outfits and scenarios that lead to different places, but you aren’t required to do either. If you do want to include multiple outfits, you can turn clothing into a nested array, instead.

{
"character" : [
              "name" : "Beauchamp",
              "age" : "42",
              "physical description" : "tall, muscular, lanky, blonde, short hair, blue eyes",
              {
              "clothing" : [
                           "work" : "Brooks Brothers suit, wingtip shoes, black silk tie, white oxford shirt",
                           "casual" : "Blue graphic t-shirt, black sweatpants, worn sneakers"
                           ]
              }
              ]
}

Or, you could do something of a hybrid…

{
"character" : [
              "name" : "Beauchamp",
              "age" : "42",
              "physical description" : "tall, muscular, lanky, blonde, short hair, blue eyes",
              "clothing" : "Brooks Brothers suit, wingtip shoes, black silk tie, white oxford shirt",
              {
              "outerwear" : [
                           "work" : "None",
                           "Outside" : "Large blue ski parka",
                           "Home" : "A comfortable gray cardigan sweater"
                            ]
              }
              ]
}

It is unclear to me how strongly typed any sort of character object is on the AI’s end, but one could potentially create an array of characters and an array of outfits, then mix and match. Or even an array of shirts, an array of pants, and an array of shoes, then allow the AI to randomize each one.

I can’t guarantee that either of these suggestions would work. I’m only trying to point out you have a lot of versatility in what attributes you give your characters, and also in how you allow them to use it.

You aren’t limited to outfits, either. You could do an array of wigs, or jewelry, or conceivably even personalities if you wanted to create a moody artist, for example.

Typically, the “Personality” is one of the shortest parts of the personality section, typically being a short list of adjectives listed in order of importance.

{
"character" : [
              "name" : "Beauchamp",
              "age" : "42",
              "physical description" : "tall, muscular, lanky, blonde, short hair, blue eyes",
              "clothing" : "Brooks Brothers suit, wingtip shoes, black silk tie, white oxford shirt",
              "personality" : "Charming, professional, observant, witty, kind"
              ]
}

(Beauchamp is supposed to be a private investigator in a film noir-style mystery.)

That’s pretty much it. Anything that is a part of your character’s physical person or personality belongs in the “Personality” section. Things that don’t: everything else.

All your locations might “belong” to the character, but logically they are part of the story, not an attribute of the character itself. Things like locations belong in the “Scenario” section, which is what we’re getting to next.

(You’ll note I’ve left off instructions on writing instructions. That’s because instructions and triggers should really be presented close to one another, as their interactions can have unexpected results.)