NPC Editor

Personality / Traits

NPC personality and traits are utilized as part of two downstream prompt chains. First, when a message is sent to an NPC, the personality of the NPC is extremely important. The information that goes into this box is extremely important in determining the general characteristics and traits of the NPC. Second, this information is also utilized when determining mission outcomes. This is because the traits (fighter, accountant) of the NPC could potentially be extremely important in determining what the outcome of a mission could be.

There is one extremely important concept to understand though before filling in this box. This is information about the NPC that you DO NOT want to change and that will never change. For instance, maybe the NPC starts off as being happy go lucky, but something happens and the NPC is now extremely sad. Therefore, it may not be wise to include information that is subject to change in this text box. For this reason, I am considering removing this field entirely and instead tracking NPC personality and traits over time via the Long Term Memory system. For more information on how this would be done see ‘Long Term Memory’.

Availability Logic

Availability logic dictates the requirements for an NPC to be available to chat with. Please reference ‘availability’ logic for more information on how to fill in this field.

NPC Objectives

NPC objectives are slightly difficult to explain just because they can serve so many purposes. Broadly speaking you should create an NPC objective any time you want an NPC to be more than a chat bot. For instance, let’s say an NPC has access to some mission-relevant knowledge that could potentially cause the companion(s) you send on that mission to “choose” a different mission outcome. Alternatively, let’s say you want to allow an NPC to become a companion. Alternatively again, let’s say you want to create a series of quests for an NPC. Each of these can be handled using NPC objectives.

Okay, so what are the components of an NPC objective, what do they, or can they do, and how should you fill them in?

Objective_name: this is just the identifier for the npc_objective. Name it something that is unique enough that you will remember what this objective is.

Objective completion string: After each dialogue exchange between the player and an NPC, the conversation as well as each available objective completion string is passed to the LLM. The LLM is queried like “given this conversation between the player and NPC, which of these objectives have been completed?”. For example, an objective completion string could be “upon the player’s request, Andre agrees to work for the player’s mercenary group” or “Bubba informs the player that his daughter is sick and has requested the player acquires medicine from the herbalist for her”. In this way, during each dialogue step, each available npc objective is either marked as completed or not_completed. In the situation in which an objective is marked as completed, all npc objective effects are carried out and all npcs/npc_objectives/mission logics that are dependent on this objective’s completion are reassessed to determine if they should now be marked as available.

Availability Logic: Availability logic dictates the requirements for an npc objective to be available. Please reference ‘availability’ logic for more information on how to fill in this field.

Prompt Injection Strings: Every NPC objective has one of three possible states: unavailable, available, or completed. Unavailable means that the NPC is locked and cannot be completed. Available means that the availability logic conditions have been met and that the npc objective is available to be completed. Completed means…the npc objective has been completed. The prompt_completed, prompt_available, and prompt_unavailable fields serve to allow the game designer to control what information is passed to the NPC when the user sends the NPC a message. For instance, let’s say you want an NPC to be able to become a companion at some point in time, but until you complete a certain leadup npc_objective, that you do not want the NPC to agreeing to becoming a companion (joining your mercenary group). Therefore, in the prompt unavailable field you might write, “Andre is interested in joining your mercenary group however he currently has such-and-such to attend to and is absolutely unwilling to join your mercenary group at this time”. In the prompt available field you might write “Andre has finished up such-and-such and is actively looking to join the player’s mercenary guild”. This essentially makes it so that as long as the npc_objective is marked as unavailable, the first sentence is passed to the LLM and the AI/LLM knows now to have Andre agree to join your guild, period. However, once you complete such-and-such and the npc_objective becomes available, Andre is now actively looking to join your group. Of course, if you wanted to change up the prompt to something like “Andre has finished up his work and with a little convincing is open to joining your guild” you could do that as well.

Completion Effects: Completion effects are things that happen when an npc objective is marked as completed. Currently, there are two different types of effects. The first effect is an npc becoming a companion. This essentially just means that the npc has agreed to join your guild and you can now send those companions on missions. The second effect is knowledge acquisition. Every companion has access to a knowledge document which I call the “user journal”. This is essentially a store of important/useful information that the user has acquired by talking to NPCs and completing NPC objectives that is useful for companions to know as it may cause mission outcomes to change. For example, if you’re tasked with dealing with some bandits, and you find out a crucial piece of information from an NPC that their son is one of the bandits, maybe the companion sent on the mission might be a little more lenient on the bandits, or maybe a certain mission outcome (save such and such NPC) will be achieved which in turn unlocks a new mission.

Knowledge

Here, your NPCs are given access to various knowledge in the form of (tag, level) pairs. A tag is essentially a unique identifier for some entity. In most cases I believe this will likely be a person, place, or thing. A level is the degree of knowledge that your NPC knows. By default, all NPCs know all knowledge of level 0. This is like all general world knowledge that all NPCs know. I call this innate knowledge. It can be utilized to give your NPCs general knowledge about the world that you want them to be aware of but that you don’t want to clog up your LLM context window with. Level 1 is general knowledge. This is essentially knowledge that “if you know about this entity, then you will know this knowledge”. Levels 2-5 are just higher levels. If you want to be able to make an NPC an expert in history etc, you can utilize these levels, but I imagine less and less information would be in these higher levels. An NPC need not be assigned multiple (tag, level) pairs. Just assign the NPC the highest level you want them to know and they’ll know all lesser levels. Something to note about knowledge level 1 is that this common knowledge is also inherited. What does that mean? If a knowledge tag inherits from another knowledge tag, then an NPC assigned the parent tag will know all level 1 information of the child tag.

Backstory and Long Term Memory

When creating a character, you need to be able to initialize said character with memories. To create memories for your NPC, write a prose backstory for your character. Then, click the ‘generate memories from backstory button’. Wait for the long term memories to be extracted from the backstory before proceeding (this might take a minute). Anyways, now, when you load up a new game, your NPC will have access to these memories. I note that these memories are only utilized to initialize your NPC. They will not be utilized further once your NPC has already been loaded up for the first time in your game-state.