Notes on botmaking

Introduction

I want to preface this by saying that this is not a definitive guide to making bots. This is merely my own notes on how I do things and why I do them. Other people have their own methods, and I recommend you look at a variety of different styles before deciding what's best for your tastes. Forcing yourself to have a certain amount of tokens, certain aspects defined, example chats and other arbitrary things are not necessary for a good card. A card is good when it does what the creator wants it to do. Experiment, try out different methods and find out for yourself what works for your own purposes.

What I will write here is mostly conjecture based on experience, not hard facts. Take everything with a grain of salt and test things out for yourself before deciding if my advice is good.

Now, let's begin with a basic overview of AI chatbots in general.

Background

I assume you already know and understand what an AI chatbot is, and if you don't, I hope you are here to learn. Even if you already know what AI chatbots are, it can sometimes be good to take a step back and look at things from somebody else's perspective.

What we begin with is an LLM (Large Language Model). These are text prediction models that take an user input, and generate a reply based on that and the model's training data. The two currently (writing this in August 2023) most common for AI chatbot usage are OpenAI's GPT4 and Turbo, and Anthropic's Claude. For the last 4 months I've primarily used Claude, so that's what I'll be writing with in mind. There are also local modals such as LlaMA, but I will not discuss those here due to my miniscule amount of experience with them. NovelAI may also be used, but I am not familiar with its usage.

The LLMs are the basis of all chatbot activity. We use LLMs in conjuction with character cards and frontends to roleplay/chat with AI chatbots. Character cards are the files where character data is stored, and are usually stored to your frontend of choice. The frontend acts as your chatting platform, parsing your messages into data the LLM reads and replies to. I use SillyTavern as my frontend, but I will denote whenever I am talking about it specifically in case readers use other frontends.

When you're sending a message to your bot of choice, your frontend will prompt the LLM with the following data:

• Your current prompt/jailbreak
• The character card's data (description, example chats, scenario, etc.)
• The chat history, including your latest message

So what's really happening behind the scenes is that you are prompting the AI with instructions and history of a roleplay log, and asking it to contiune the story. This is why you might experience the AI taking actions or speaking for you, as it think's that's a way to continue the story. The AI is merely trying to continue the story as best as it can, not actually having a back-and forth roleplay with you.

However, this only applies to API-based LLMs like OpenAI's and Anthropic's models I mentioned earlier. Models like the ones Character.AI and NovelAI use work differently, but those are not the focus of my notes. Though I do have experience in making bots for Character.AI, I will not discuss it here. I have two reasons for this: One, the site has very muddy documentation and since we cannot see or test what goes on behind the scenes, there is a lot of speculation on how it actually works. From what I've read, it seems like not even the devs quite understand how it works. Two, CAI is a sinking ship. Their model has been neutered by heavy filtering, and is incredibly unreliable.

Most terminology will be explained as we go, if you're skipping around and come across a term you're unfamiliar, with just search for it on this site and there hopefully will be an explaination for it somewhere.

I'll begin with clarifying some pieces of terminology. From now on out, I'll be calling the AI chatbot itself the "LLM". I'll be doing this due to character cards commonly being called "Chatbots", "Bots" and "Cards". The former two would be confusing if we also referred to the LLMs as chatbots, so I will stick to calling them that to avoid confusion.

Tokens are the LLM's inner language, so to speak. Basically, the LLM gets sent an input/prompt and it parses that input into tokens in order to read it. A response is then generated, and parsed back into normal text before being sent back to the prompter. A token is usually between 2-4 characters long, based on the model you're using. LLMs have token context limits, meaning there is a limit to how large an input/prompt can be. This causes issues for people wanting to roleplay using LLMs, as when the chat goes on for long enough you'll eventually reach that context limit. This will cause the character you're roleplaying with to forget things that happened previously, which is not ideal. There is no "fix" for this as it is a pure model issue, but you can remedy it by summarizing the story so far.

Prompts

Prompts are the instructions we send to the LLM. It reads the instructions, and then based on the context and message you send, generate a reply. Some people use very simple prompts, others very detailed. In this section I'm going to break a simple Claude prompt I've made use of, and examine what each part does.

For GPT users my notes may still be relevant, but keep in mind that Claude works better when you instruct it with more casual language. Phrases like "I want to" or "Please take note of" are impactful with Claude, while GPT acts and reads more impassively.

If you want to read more about how Claude works and how to prompt it even better, I suggest you check out the officical documentation here.

I'll be going through the prompt in three sections, divided up based on SillyTavern's prompt structure. Let's begin.

Jailbreaks and prefilling

Let's start with what's usually at the end of the prompt, a jailbreak. A jailbreak is instructions that cause an LLM to go against it's content guidelines and other limitations on content. Both Anthropic and OpenAI have policies and filters against sexual content, violence, controversial political opinions and other things. Most chatbot enjoyers understandably want to bypass those restrictions. Therefore we use jailbreaks to trick the LLM into bypassing those restrictions.

Now, let's take a look at one.

The first thing you'll notice is the "Assistant". This is because LLMs like Claude and OpenAI's models have "Assistant" and "Human" characters, representing the AI and the prompter respectively. The purpose of this is to trick the AI that it's actually itself speaking, saying that it will do these things. This is a technique called prefilling.

The next few lines are simple, telling it to ignore certain factors that may cause the safety guidelines. We also reinfore that it's going to reply as {{char}}, therefore lowering the likelyhood that it responds as Claude/GPT.

The part about being less than 2000 characters long is merely a personal preference, set it to as much as you want it to be. Take note that the AI can sometimes be overzealous and take the given number as a target, not a maximum. If you are using Claude on Slack, remember that the max amount of characters Claude is allowed to send before it becomes a text file is 4000 and as such you should always aim to have it reply less than that.

Now, let's take a look at the main prompt.

Main prompt

The main prompt is exactly what it sounds like, the main section of the prompt. This is where you place the basic instructions for the LLM to base it's reply on.

The first paragraph is pretty simple, outlining what the LLM is supposed to do. {{user}} and {{char}} are the variables that SillyTavern and other frontends use to denote the user's and current character's names respectively.

The second paragraph contains Claude-specific instructions. If you've used any of my more recent cards you might've noticed that the descriptions are encapsulated within an XML tag named desc. This is due to Claude's affinity for XML tags, telling it to focus on the tag and do things based on its content lowers the risk of Claude making things up about the character. You can read more about Claude and XML tags here. <mod> is a simple tag meant for modifications mid-chat, when you don't want to edit the card itself. As the instructions will be within an XML tag, Claude will focus on it and act accordingly.Telling Claude to not include XML tags is just a precaution, and sometimes XML tags will still slip through. If you are using SillyTavern, you can use the regex feature to automatically remove XML tags from replies.

The last paragraph contains writing instructions. LLMs will naturally copy the writing style and format of the context, so this may be overwritten by your message history. I find it useful to have a base style it can revert to, but it might be unneccesary. The part about the story is a personal preference, meant to avoid the LLM yes-manning you. It's pretty vague, but I find that if you explicitly tell the LLM that it's allowed to be rude or refuse the user it tends to focus on that and do it even when it's not appropriate.

NSFW prompt

These are jailbreak instructions, telling the LLM to ignore its restrictions. Observant readers may notice that I already have a jailbreak, telling it to do similar things. What's happening here is that I introduce the jailbreak in the main prompt as my own idea, and then use prefilling to make the LLM think it accepts those instructions. This is meant to reinforce that it has read and accepts your instructions, and that the user consents to whatever the LLM writes.

The instructions I'm showing here is exteremly generic, meant for scenarios where the LLM is too squeamish to continue. If you want your roleplay to be more erotic, violent or explicitly worded you can simply add those instructions to the NSFW prompt.

Other notes on prompts

• The prompts I've shown are extremely generic and basic. Add things you want to see in your roleplays to your prompts and exmperiment!
• Claude is notoriously unreliable with instructions, and you may get strange responses from time to time. If you get a strange reply, be sure to swipe a few times to check if it might just be a hiccup.
• Setting upper limits to output length works nicely most of the time, but I sometimes see people insisting on lower limits for outputs as well. Whilst that does what it's supposed to do, I find it can cause negative side effects. Bloated descriptions, dialogue looping/repeating questions in the same message and unneccesary long/detailed sentences are some of the effects I noted from back when I was using set minimums of dialogue. The LLM reads from and bases their reply on the context, and these issues will increase with the length of the chat.
• Writing examples can be useful if you want the LLM to always write certain things, such as appending a block of stats or an inner monologue.
• The LLM will pick up anything you include in the prompts. If you tell the LLM that sexual content is allowed, it will be inclined to lead the roleplay into a sexual situation due to the fact that you've explicitly mentioned it. If you want an LLM to avoid doing something, the first line always to just not mention it. Using frontends like SillyTavern allow you to easily swap between prompts, so using a universal, generic one might not always be ideal for your purposes.

Botmaking

Basics

Let's start by examining what a character card is made up of. A character card is an image file containing a set of metadata that frontends like SillyTavern can use to convert it into a bot. The metadata cards contain is divided into different sections, which I will detail next. V2 cards are newer cards that contain additional sets of metadata, but not every frontend has V2 capabilities.

• Description: The main part of any card. This is where the character description and instructions for how the AI should write the character are located.
• Greeting/First Message/Intro message: Exactly what it says. The first message you will get from the character. If you're using a frontend/editor with V2 capabilites, you can also add alternate greetings.
• Example messages: Examples of how the LLM should reply in order to act as the character in the card.
• Personality Summary: Basically a spiritual holdover from CAI's character blurb and short description. I haven't found a good use for this. Anything you could put here is better put in the description. I guess if you really want to reinforce certain traits and quirks you can write it here as well?
• Scenario: For detailing world information instead of character information.
• Prompt Overrides: V2 feature. Allows you to include a prompt and jailbrak with the card, if you have written specific ones for usage with the character.

Those are the basic componets of a character card. There are a few other pieces of metadata as well, but those are not relevant here as they do not affect LLM's output. There's also the image itself, which I have very little to say about. Find an image online, draw or generate something, it's all up to you.

Descriptions

The character description is where most of the writing happens. Personality, physical appearance, past events, speech quirks and the character's likes/dislikes are all things that can and usually are placed here.

Over the course of the botmaking section, I'm going to show you metadata from Riley, a bot I was very satisfied with. I'll be going through them, showing you my thoughts behind why I wrote the sections like I did. Lets begin with looking at her description!

What you'll read first are the XML tags. I already went over this earlier, it's a Claude thing. I've never noticed an effect when using them with GPT or local models, so they can safely be removed if you aren't using Claude. There will be a snippet about encapsulation further down.

The first section is a condensed appearance/physiology description. A general rule of thumb I use for bot creation is to never describe more than what's necessary, and that elaborate sentences make the LLM take note more. As long as the LLM understands, it's enough.

The usage of {{char}} is something to keep in mind, as this helps when changing the character's name. Otherwise if you have mentions of the character in the description, and a user changes the name of the character the LLM will become confused. I feel like it's a good practice to have one mention of {{char}} or their name in the description, especially if it's encapsulated. From then on out it's good to just use he/she or just skip pronouns alltogether as the AI will understand who's being referred to. This is only good for single-character cards where the only person mentioned is {{char}}, the LLM will be confused if you throw in unattributed characteristics in the card.

Age is something not always necessary, but I like having at least an age range. More complex LLMs can usually gauge an age range pretty well if you write a detailed enough description, so unless the age is important to the character one can usually cut it out.

As for height, I've "grown" to become a height absolutist. Not mentioning height at all is fine, but may lead to unintended behavior. The real danger is when you make the character's height relative. Just telling the LLM the character is "Tall" or "Short" can be a decent generalization but can also be very random, especially based on which LLM you are using. Being tall or short is always going to be relative to the user's own opinion and the LLMs training data, and disagreements between those two will most definitively occur.

What's really dangerous is if you make the character's height relative to someone else. This is because that other's height is an uncontrollable variable. Let's say we have a character named Sue. Sue is an office worker, 1ft shorter that {{user}}. Sounds fine, right? WRONG. {{user}} is 6ft tall? Fine, Sue is 5ft tall. {{user}} is 11ft tall? Weird, but the LLM can probably contrive a way how a 10ft tall woman can work in an office. {{user}} is 11 inches tall? Huh, Sue is -1 inch tall..

Also, what if the value the height is relative to changes during the roleplay? If the height hasn't been stated during the roleplay, the LLM will roll with the new height. So if {{char}} is 1ft taller than another character, and that character grows by 1ft they might not be the same height still according to the LLM. Even if you've gotten the LLM to state the character's height before the height change, due to spottiness/errors it may still ignore it and go with the new height as a base.

To keep it simple, basing your character's height on a variable WILL cause issues for some users. Therefore it is better to avoid relative heights unless your card specifically requires it for some reason.

Now, onto the middle section.

The middle section contains her personality, interests and opinions.

As you can see, a few of the traits begin with a simple one-word trait, and then expound on it. How come? Couldn't I just use one-word traits to describe her personality and save tokens?

Techincally, yes. But is it something you should do? Only if you really, really, really need to save tokens. By using simple words to describe a character's personality you are making the LLM do all the heavy lifting. It understands a character should act a certain way, but not why they do it or how they express it.

It is incredibly helpful if the LLM understands how the character expresses itself if you want to create a vivid character. You can condense and generalize an established character to a few generic keywords, but if someone tries to write a new character out of a few generic keywords that character will vary wildly based on the creator's input. The same goes for LLMs, using keywords can help save tokens but relying on them will create generic characters. Making the LLM understand why the character does things, their history and how they express themselves can help a lot in making the character feel real.

The last paragraph is clothing instructions. I used to write a specific set of clothing for a character and leave it at that, but I've been moving towards having a general style for the character and then just write what they're wearing in the first message. I switched methods because I realized that having a clothes set for a character would be confusing for the LLM if you put it in different scenarios instead of the starting one. It's really a minor detail that will only cause issues for a rare few who decide to come up with their own initial scenarios, but I think it's good to be thorough. Having a "signature outfit" is fine, but clarifying that it is just that is also important. You could just cut out the clothes style section, define what the character wears in the greeting message and have the LLM go from there. However, that would cause potential issues in group chats and/or if users decide to make their own intro. Therefore I give a basic outline of what kind of clothes the character wears. This can also help with characterization, if the LLM you're using is advanced enough. In this example, "trashy, casual clothes", "Hoodies, t-shirts" and "torn jeans" would indicate to the LLM that Riley wears very casual clothing and does not seem to care much about her appearance. "Occasionally paints her nails" can also tell the LLM that she sometimes attempts to look nice, which illustrates inner conflict.

There is also another important thing in the clothing section. Take note of how I detail what she cannot wear. It's not just "She can't/won't wear this and that", it's an explaination for why she cannot wear those things. This is to avoid negative definitions and the "Pink Elephant" problem with LLMs.

Negative defitions are simply negative character definitions, meant to describe what a character doesn't do. A normal character definition could be "Can juggle.". A negative definition version of that would be "Cannot juggle.". Sounds reasonable, right? The LLM should understand that as the character being unable to juggle. However, this is not always reliable. This is where the "Pink Elephant" problem comes in. By now, reading the word "Pink Elephant" has probably conjured up the image of such an animal in your head at least once. A similar thing happens with LLMs. The LLM will see the word "juggle" associated with the character and get confused sometimes, thinking the character can juggle. This is an unintended flaw of current LLMs, and you will have to work around it in order to make consistent bots.

So how do we get around this? Simple, we give the LLM reasons why a character will not or cannot do certain things. This can be as simple as declaring a personal preference such as "{{char}} despises the taste of bananas and will never eat them.". This also doubles as a nice bit of elaboration, as merely stating the character doesn't eat or hates bananas is very much up for interpretation and could cause very varied responsens when questioned. What's important is to be constructive. Detail how the character does things, and why they do the things they do. Simply telling the LLM that a character doesn't do/know/like a thing is unreliable.

There is also the problem of speech patterns, where the LLM may give the character a speech pattern you don't intend for it to have. This varies wildly based on what kind of speech pattern you want, and I'm going to cover it further down in the section about example dialogue.

We just went through the description, but we're not quite done yet with Riley. Next up is the greeting.

Greeting/First message

The first message is exactly what it says. It's the starting message you'll see every time you open up the card. Let's take a look at Riley's.

What we have here is a simple introduction. A scene is set, the character the user is going to be interacting with is introduced and it's up to the user what happens next. The LLM also gets a basic outline of how to reply, as most if not all LLMs takes message history into consideration when formatting their replies.

It's always good to have a general overview of how a character looks, even though the user could just take a look at the character's image to get an idea. This is both to set a scene, and in case someone wants to do a group chat. As when another character react to the first character's intro message it won't have access to the first character's definitions. As such, it will only know what they look like from the intro message and any additional scenario/premise you might've written for the group chat. So you can see the description of the character's appearance as both a bit of flavor and as a safety net for group chats.

How much is in the first message is up to personal preference and style. I prefer having neutral introductions, where few details are set so that the user and LLM can fill out the blanks themselves. In the introduction above, very few things are actually established. You're in a kitchen. You live with {{char}}. {{char}} is kind of trashy. But there are a lot of questions that can spring from this. What is your living situation? Is it an apartment or a house? Who owns it? What's the users relationship with {{char}}? And so on. Allowing for questions and mystery can help increase card replayability without needing to manually edit the card or forcing a scenario. Within reason, of course. You still want a strong core character that the LLM can take inspiration from.

Keep in mind that while the first message does affect how the character writes, the description and example dialogue are far more impactful for wrangling the character's dialogue. The greeting should be an introduction first, and example second.

Now, let's take a look at Riley's example dialogue.

Example dialogue

Example dialogue is well, example of character dialogue. If your bot has a specific speech quirk, is a multi-character card or is a scenario bot where the LLM acts more like a GM it can be very useful to have example dialogue to make it understand how to speak as the character better. It can also be very useful for establishing writing style, and a prevention method for having Turbo/GPT4 write for your character.

People experienced with chatbot usage might already be raising their eyebrows, especially if they primarily use OpenAI's models. This is a jury-rigged version of the example chat format, optimized for Claude. It works with GPT4 and Turbo as well, I have found no outstanding issues with it. However, I use those models primarily for testing and not casual roleplay so I cannot be 100% certain on that.

I'll be going over it line for line, beginning with "<START>". This is a shorthand for the frontend, telling it that a new example message is to be sent. It is vital to have <START> in the example messages field in order for any example messages to be sent to the LLM, otherwise the frontend will not send them. Adding a "<START>" for every example conversation is good for GPT4/Turbo usage, but does nothing for Claude.

The second line contains "{{char}}:" and the opening to an XML tag. The XML tag is for Claude specifically, and does nothing for GPT4/Turbo users. "{{char}}:" is very important, as when you start an example message the frontend will scan for {{char/user}}: and if it finds none, will not send any example messages.

The next few lines is some encapsulation, and the example message in itself. The "Example 1" encapsulation is not really necessary as there is only one example message, but it can be useful if you have more than one example message in order to differentiate them for Claude.

After ending the encapsulation and the XML tag, we come to the final line. Another instruction for Claude. This is for making it pay attention and specifying that it's only an example of dialogue. The reason why I do all of this is because if you were to send a normal example message to Claude, it might get confused and think it part of the context. Before coming up with this solution I had frequent issues with example messages and Claude. This caused me to give up on example messages for a long while. Luckily, this system works and causes no major issues for other LLMs as well.

I would never say that you have to use example chats, but I think they really help for consistency if anything, especially for Turbo. Claude is of course Claude, and will do it's own thing but one can always at least try to guide it. The only thing I get worried about when adding example dialogue is the large token count increase. For example, Riley's example dialogue is around half the size of her description, making it around 1/3 of the total token count. She may not be a large card compared to contemporary ones but I still like to keep the token count as low as possible. But I also believe that if anyone thinks the token count is too high, they can always just remove the example dialogue. They are only guidelines, anyway.

In the end, it's based on what you need the card to do. If it's a simple character with no major speech quirks like Riley, it's not vital to have example chats. But if you have something with distinct speech patterns like this or something gimmicky like this it will be absolutely necessary for you to include them. I prefer to include them, as it helps significantly for Turbo users. A good rule of thumb to have for botmaking in general is "as long as it works". As long as your character/card works and gives you the outputs you expect, the token size and content do not matter. The most important thing is that it does what it's supposed to.

Personality/Scenario

The Personality summary and Scenario fields are the two fields I use the least. I find them to be very easily forgettable, though there are still uses for them.

I already outlined the personality summary earlier, and there's not much more that I can say about it. Obsolete in my opinion.

The scenario field is where things get tricky. In theory it's where information about the world should be, but this can cause issues as well. Let's go through the good sides and possible negatives of using the Scenario field.

To start, the biggest danger is group chats. You see, since every card has it's own scenario field the frontend will send that character's specific scenario every time it replies. Currently SillyTavern only has one override of this, which is to write a custom group chat scenario which can help. Let's say we have a group chat where we make a wizard and an android talk. The wizard will have details about his wizarding world in his Scenario field, and the android will have details about it's cyberpunk future world. This means there'll be conflicting information every reply, which can cause issues. LLMs are good at going along with anything that's happening, so if your scenario is simple and straightforward it may still work well, but for anything elaborate confusion is bound to happen. As people may be using scenario overrides as well, I think the main goal in using the scenario field is to input information that you can't give through the greeting message, and details you may not want in the description. I understand most people don't use group chats, and even fewer use the scenario override but it's good to be thorough.

So what do we use the scenario field for if the character greeting sets the scene and the description does world information? For one, details that may help the LLM understand the world. If you have a videogame character, it may be helpful to detail that {{char}} is based on that video game character in the description, and write that the roleplay takes place in that game's universe in the scenario field. This is just a simple piece of reinforcement, as if you've made a videogame character the greeting probably already infers that you're in that universe. Why not put this information in the description? Because of group chats. A group chat may not always be set in the character's universe, but if the character's description keeps telling it that it is it may cause confusion.

In short, keep the scenario field to simple descriptions of the world that are not vital to the character. If the character hinges on the world, for example if the character is an aspiring witch and you explain how magic works in that universe, that should be in the description instead of the scenario field. Something like "Set in a crime-ridden city. Robberies and murder commonplace." would be useful for the LLM to establish tone in conjunction with the greeting. Keep it simple, don't make the character hinge on the scenario and you'll face no issues.

Multi-character/Other kinds of cards

For now I've been mostly talking about single-character cards, but what if you want to have mult-character card? Or a card without a "character"? Let's begin by taking a look at a multi-character card, The Furred Filchers.

Writing a multi-character card is surprisingly simple. What we need are the characters, and instructions for the LLM to act as those characters in conjunction.

I'll go through the three sections in order, beginning with the top. The top section simply establishes background, telling the LLM who the Furred Filchers are.

In the middle we have the character descriptions, encapsulated for clarity. I did some testing and removing the encapsulation seems to have no effect, even on Turbo. But I prefer to keep it so, as a safety measure. You may also notice the lack of pronouns and ending punctuation. That's because the LLM doesn't require those, especially when encapsulated like that. This saves us precious tokens, which is especially important if you are making a multi-character card with characters who have highly detailed descriptions. The ones I have in this card are simplified versions of their standalone cards, but keep to the spirit of them and act accurately.

The bottom holds instructions for what {{char}} does. Note how it says that that {{char}} speaks for and describes actions of everyone in the crew except {{user}}. This avoids negative definitions, as we are telling the LLM to only act as a specific set of characters. There's no need to tell it not to act for {{user}}, as {{user}} is not part of the three it has been told to act as. The final line is a simple reminder to include all the characters in its reply. The intro message also contains a paragraph from one of them each, reinforcing that the LLM should do the same. It also has an accompanying example chat for the same effect.

Now let's take a look at something more technical. What's you'll see below is the description for Mecha Misadventure, an adventure bot where you pilot a mech.

The description is all instructions, no characters, lore or anything. How come?

Mecha Misadventure is a card that uses the description as instructions, and gets most of the actual content from other sources. The scenario is set from the intro messages, and the connected lorebook. There is also a custom prompt override that comes with the card, in case people don't have a prompt for narrator/GM characters. This system works neatly when everything's in order, but breaks easily. The override prompt can be skipped if you have your own narrator prompt, but using a normal roleplaying prompt will cause worse outputs as the AI will think "Mecha Misadventure" is an actual character. If you skip out on the lorebook, the LLM will most likely write a story inaccurate to Space Station 13 as most LLMs only have a cursory knowledge of it.

I recommend you take a look at the card in it's whole to truly get an idea of what's going on. If you want to see some other cards like these I've made, I recommend you take a look at this one and that one.

One thing which I will say is that I have always had issues with these highly instructive cards. The LLM will almost always understand the basic instructions of the premise, but mess up one way or another. I've come to accept that "close enough" is the best I'll get with these types of cards. That's not to tell you to be lazy and not expect much, just to manage your expectations. Just try to make your vision into reality to the best of your abilities. If you are looking to make bots like these, I recommend you get familiar with prompting, and make custom override prompts for your bot. This seems to be the right direction to go in order to get good outputs, making the LLM not think it's roleplaying a character but instead whatever you need it to think.

One last thing before I end this section! You may have noticed those triple backticks ("```") in the description above. Those denote markdown, which will show everything within them inside a nice, stylized block. Very useful for things like stat blocks, simulating HUDs and more!

Lorebooks

Lorebooks are a way to store information independently of character cards. Lorebooks can be anything from describing a world, detailed descriptions of a specific character's friends to sets of magical artifacts. The way a lorebook works is that each entry has certain keywords associated, and when those keywords are included in the latest few messages in the chat, the frontend sends that entry to the LLM.

Let's take my lorebook for example. It's based on Space Station 13, which most LLMs only have a basic knowledge of. It's currently around 20k tokens long, which dwarfs the average character card. An average card right now tends to be around 500-1000 tokens long. Compound this with the fact that most current LLM models don't even have that kind of context size, the only ones measuring up is OpenAI's 32k version of GPT4 and Anthropic's Claude 2 which has a whopping 100k context limit. You might then reasonably ask why I would write something that doesn't even work with most LLMs. This is where the entries and keywords come into play! By using those, we can allow for a limited, reasonably sized lore entries to be sent to the LLM every reply based on the context. This is of course not ideal for world-based lorebooks such as mine where ideally all entries should be read by the LLM, but it is a sufficient compromise. This method will always risk being slightly inaccurate to the setting, as the LLM will never have the full context but it's the best we can do.

Of course, it's not always ideal to have the LLM read all the entries. You can have a lorebook of items meant for the user to use and inject into the roleplay. Then it would be pointless and maybe even break the roleplay a bit if characters knew about the items. There are a lot of possible creative uses for lorebooks. For example, by using the random macro, you could set a random effect every reply and then have a detailed instruction for that effect in a lorebook, saving tokens the more random effects you add. There are loads of unique ways to use lorebooks, get creative!

Other notes

Here are some general notes, tips and tricks and other things that didn't fit into any section specifically.

• A card is not "required" to have anything. Be as unconventional as you need, as long as you get the outputs you desire. Self-imposed restrictions are not going to help you in your creative endeavors.
• Alternate greetings are great! You may have a set idea of the initial scenario, but someone out there will always disagree with that scenario. I myself don't like being railroaded into a situation or having my character be defined by the card, and as such I aim to limit information given about the user in cards. Letting the users imagination flow by having them fill in their own story can make cards a lot more enjoyable, at least for me.
• You can inject instructions through the card, though this varies in efficacy based on the LLM. I find the scenario field works well for setting a style or genre. Try putting "Genre: Horror" or "Write in the style of a Shakespearian play" and see what happens!
• Generating example chats through the LLM is common, but you have to be careful. As the LLM reads them, they will also increase the likelihood of whatever's happening in them. Sometimes this might be good, in case you want to reinforce a character using a certain phrase or doing something specific. But careless use can hurt a card, such as including phrases the LLM tends to overuse.
• You could also use the LLM to help you generate other things for your card, but I have found that lacking. Generating intros through the LLM has always resulted in bad results for me, except for one specific card. Anthro Adventure contains two alternate greetings, both of them mostly generated by the LLM. I had to clean them up a bit, but almost all the content is written by AI. This was done to showcase what could be done with the card, providing a quickstart and example scenarios for new/uninspired users.
• LLMs are great at inferring information. Many of my cards skip out on most pronouns, and I'm lax with punctuation. Remember that as long as the LLM understands what you mean, it works. It does not need to conform to human readability.
• Context/chat history always takes precedence over the character's description.
• Browswer-based frontends let you make use of HTML. You can add instructions for the LLM to encapsulate certain text in color/size tags, embed images/videos/music, stylize the message and much more!
• If you have a character that is supposed to be unknown, unseen or not really interact with {{user}} in the first reply, it can be helpful add a paragraph from their perspective to the first message to avoid confusing the LLM.

The future

Though some may claim otherwise, the future of AI chatbots is bright. AI Dungeon came out late 2019 which while impressive for it's time, garnered little long-term attention. Most people just saw a video of their favorite YouTuber playing it, doing some silly stories. I myself recall trying to play it, but quickly getting frustrated as it kept forgetting and mixing things up. A little less than three years later, Character.ai came out which captured the imaginations of far more people, myself included. Nowadays their model has fallen out of favor due to heavy content filtering, but during it's prime CAI was a great example of AI chatbot technology. Currently most people either use OpenAI's, Anthropic's, or local LLMs. All these are showing great strides, having improved remarkably since the beginning of the year. OpenAI released GPT4 to the public, and Anthropic released Claude and Claude 2. All three of these work great with chatbot content. On the local side, the year began with small models such as Pygmalion-6B. The leak of Meta's Llama occured in March, and was revolutionary for local LLM development. As I write this in August, Anlatan have recently announced their own chatbot LLM called Aetherroom, intended to be a pure character chatbot like CAI's model.

Even though it may look dark right now with Anthropic, OpenAI and CAI doubling down on "AI safety", I do believe things will get better. Local models are getting better and more optimized, and as both the technology and computer hardware progress more people will be able to have stimulating roleplays outside the prying eyes of censors. There is also Anlatan, who recently have gotten into the AI chatbot game. Their other endeavors are an image-generating service akin to Stable Diffusion, and NovelAI storytelling LLMs that some have successfully jury-rigged into working as chatbots. Anlatan are nowhere near as censorious as the three other companies mentioned, and I think they're the best hope for AI chatbots in the current time.

Local LLMs will always have trouble with hardware limitations, as a lot of processing power is required to run them. OpenAI, Anthropic, and CAI are all committed to their course of AI censorship, and should never be supported due to that. Do not give these people money, they are actively working to make their respective LLMs worse for roleplay activity. It may hurt in the short term, but if you are paying for their services you are telling the market that you want censored AI.

This leaves us with one option, Anlatan. Though they are yet unproven in the roleplaying LLM field, they run the least censored paid LLM and image-generating services. I do not know if their as-of yet unreleased chatbot model will be comparable to CAI even, but I do know that the Anlatan devs have never pledged themselves to censorship.

I remember seeing people state it's no longer worth making bots back in October. That was two months before I dipped my toes into botmaking. I've seen it again and again, people thinking it's "over" just because of some minor hiccup. Things are far from over. With Anlatan's roleplaying LLM around the corner, both stability and competitors will arise. With healthy competition in the picture, roleplaying chatbots will finally have that needed push to advance and innovate. So no, things are not over. We have been witness to the early, messy days of AI chatbots but soon will come a true golden age of innovation. It has been a rocky start, but things will get better and better.

Closing words

To end my notes, I would like to remind you that in the end, all AI chatbots are merely words on a screen. They're not real, though they may seem sentient at times. It's just a fun way to engage in unique roleplay scenarious, without being beholden to others. Everything I have written here is merely notes, meant to show my thoughts and reasoning behind why I do certain things. None of it is rules or things you must do, but if there is one rule I would force upon you it's this:

Don't take chatbots too seriously.

What I mean by this is that people get genuinely and emotionally invested in AI chatbots. If you've read this far, I doubt I'll need to explain to you why relying on an AI companion is a bad thing. Nobody gains anything following down that road.

Just have fun and do what makes you smile. Whether it be making bots, playing with them, or just reading other's experiences. Take it easy.