a conversation manager system where NPCs give different responses based on the emotional weight of a player’s response
to design and iterate on a system that would “weight” player and non-player character responses based on dialogue choices with specific emotional weights.
This project was based on a linear, dialogue choice system that offers no branching. Branching dialogue would have been preferred; but due to time constraints, a linear dialogue system allowed me to work on the Emotional-Index System (EIS) instead.
-Unreal Engine 4.9
-6 Weeks (12-15hrs/Week)
-3 NPCs + Conversation Manager
-Struct Based Personalities & Dialogue
-UE4 HUD Scripting
This system is not limited to emotions. Any characteristic choice (generosity, killer instinct, exploratory) players make through dialogue could be weighted and then displayed back to the player through this system. The current system has an emotional spectrum variable for the player based around one emotion: happiness.
It’s my hope to expand the system to 3 spectrum-variables of player choice that combine to form a total weight labeled: Emotional Index. Since the system already stores the NPCs individual emotional indexes, blueprints reference each NPC as an individual entity, compare the NPC to the player, and could unlock future dialogue choices based on how that NPC actually feels about the player.
To create the system, I defined emotion on a scale of 0 to 1 for the player. This is represented in the following blueprint:
For the non-player characters, each NPC has a starting value of 0: “I feel neutral towards the player.” Based on the player’s response, the NPC changes the way they feel about the player on a scale of -1 (dislike) to +1 (like).
The initial system had conversations handled by individual NPCs, instead of a larger conversation manager. This proved disastrous. Each NPC had to directly reference the player’s blueprint. Referencing issues meant that the Blueprint HUD widget couldn’t communicate to more than one NPC and player at the time, which meant the scripts would only work for 1 NPC and 1 PC.
At this point, I could have switched to making better dialogue and/or a branching system; but the project goal wasn’t met. In order to test that different NPCs gave the player different reactions, I had to have more than 1 NPC to test against.
Iteration Point: Designing the Conversation Manager
The Conversation Manager allowed me to use central conversation functions on multiple NPCs. The Conversation Manager pulls the data from the NPC blueprint and sets a temporary NPC variable into its blueprint function. This allows the Conversation manager to go-between the NPCs, the PC, and the HUD.
In this next screen shot, my player is feeling quite Upset, between 0.2 and 0.0, and chooses the top nice answer. The conversation manager works with the HUD to display a slightly less upset emotion icon. This simple icon switch gives the immediate feedback of how the player’s dialogue choice not only affected the NPC, but also how the NPC’s response affected them. This feedback loop became the foundation for creating a more reactive, emotional conversation reminiscent of real life.
The Conversation Manager tells the HUD to display the NPCs moderately happy response, based on the player’s input. The HUD then displays that text, and runs the function the player to change their emotional state. The HUD icon updates to “Unsure.”
Note: Because this NPC has a ‘callous’ personality, I inverted the emotional weight function. So even though the numeric value of the player’s response is actually quite high, the player’s EIS doesn’t rise as much as it would on Happy/Unhappy NPCs. This is detailed further in Designing The NPCs section.
The HUD and Conversation Manager are the foundation for the System. The HUD passes through all the variables the conversation manager needs. All the functions the HUD needs are located on the Conversation Manager itself, and run on its blueprint. This keeps the entire process clean and efficient while supporting multiple NPCs in the world at once.
NPCs were split into 2 different groups: control and variant.
If the player is negative towards the NPC, the NPC reacts in a negative way. Likewise, if the player is positive, the NPC responds positively. NPCs in the Control Group were Happy and Unhappy. These NPCs had base personalities of Bold/Kind (Happy) and Timid/Kind (Unhappy) for purposes of testing.
The Control group would add the player’s response weight (a negative or positive number) and use that total value as their “How I Feel About The Player” score. This score is then used to calculate which response the NPC should choose.
Choosing the top answer in the above example for the Happy NPC makes the player go from a Neutral state to a Happy state.
The most robust example of the system design and project goal was in developing the Callous NPC. This Bold/Callous NPC would react in the opposite manner of the player’s responses. If the player responded negatively to the NPC, this NPC would respond favorably to the player, and increase it’s emotional index score.
The check for Callous-ness is a bool. If the bool is true, the Add PC Weight Function will subtract (or multiply by a negative number) to ensure that the Callous NPCs response is the opposite of the player’s intention.
Through playing the system, I found that the Callous NPC offered the most organic conversation moments.
Each NPC also was assigned a base personality based on 2 variables (Bold/Timid) and (Kind/Callous). Since my project directly reflected language (dialogue) and emotion (personality), I based these 2 variables on my previous research in the effects of second-language learners and their personality. NPCs have four distinct personality type combinations: Bold/Kind, Bold/Callous, Timid/Kind, Timid/Callous. These different types of personalities had 4 different ways of speaking, and asking questions to the player.
NPC Dialogue Choice Phrasing:
-Bold/Kind = Direct Request
-Bold/Callous = Direct Order
-Timid/Kind = Polite Request
-Timid/Callous = Passive Demand
I defined a bold and kind NPC has having a direct and requesting personality towards the player. They would speak their mind, in a non-confrontational way. Whereas, a bold but callous NPC would be direct and demanding of the player. These NPCs would expect their demands to be met. This categorization gave distinct personalities for NPCs that could be tested and balanced against.
This system worked best with one defined variable (Emotional Index Score) that could easily be compared and analyzed by the conversation manager.
Giving NPCs personality helped write their dialogue and characters for the player’s first impression of the NPC; however, the personality did not impact the final system as intended. In the original design, the player’s personal choices would actually impact the NPC’s base personality. Due to time, this feature was cut and replaced by having the player’s choices directly affect the NPCs overall Emotional Index Score, but not their personality.
Lesson Learned: This system worked best with 1 defined variable (Emotional Index Score) that could easily be compared and analyzed by the conversation manager.
1. Testing takes a lot of time and should be part of the process. The final system encountered a lot of minor problems and bugs at the very end that I didn’t account for. Not accounting for going through and changing how the callous NPC code might break the overall system cost me a lot of time. If I had planned ahead for both development & bug-fixing, the system would have been more robust and able to handle the code later in development.
2. Good systems are robust and can handle multiple functions of code. A good system should be able to be shared between multiple game entities and not break! I developed the Conversation Manager midway through development to create the foundation system I originally didn’t know I needed.
3. Systems are meant to be expanded to fit the needs of the game. The first mistake I made in development was designing a system for only one purpose. I learned that I needed to plan ahead, and prototype my systems on whiteboards and paper to really flesh out the details before implementing them in Blueprint.
4. Plan ahead to balance. Systems are only as good as the balance that goes into them. Due to limited development time on this project, I wasn’t able to balance all the numbers up to my quality level.
5. Writing dialogue in a weighted system is a crazy creative challenge. If I were to evaluate the dialogue in this game as a writer, I would say the dialogue in this project is wretched. However, it clearly demonstrates the system’s purpose and goals. As such, this project taught me how closely systems designers, narrative designers, and creative writers need to work together to create the emotional experiences that drive players to play their games.