NPC ~ Design Document for NPC Dialogue and Action Implementation

Introduction

Dialogue in Chiventure currently lacks any custom actions players can take in conversation. As of now, users can respond with standard dialogue options; only an internal implementation of adding options to give or take items has been added to the dialogue code.

Adding a range of custom actions could enhance the variety of potential conversations. Designs for a couple of new actions, including STEAL, TRADE, and BUY within the npc/action design could easily be integrated into the node_actions struct in the dialogue module to represent actions. We will then create a design document explaining a future implementation of these actions into conversation.

Current Design of Dialogue and Action

Conversations are currently implemented as directed graphs where the nodes are the NPCs' reactions and the edges are the options the player can choose in response. These options include dialogue responses as well as two actions, defined as node_action_type– GIVE_ITEM and TAKE_ITEM. START_QUEST and START_BATTLE also exist but are not fully implemented as the battle and quest features of Chiventure have not been fleshed out enough yet.

On the other hand, documentation for the NPC action module defines a npc_type enum containing 6 potential actions– TALK_TO, IGNORE, GIVE, STEAL, TRADE, and BUY. It also defines an npc_action struct where custom NPC actions can be created. Consult the NPC Action Documentation for more details.

Outline for Integrating Actions into Dialogue

First we must consolidate the npc_actions and node_action structs. Some of the available action types already overlap in design– for example, GIVE and STEAL in npc_action with GIVE_ITEM and TAKE_ITEM in npc_dialogue. GIVE_ITEM and TAKE_ITEM provide a more flexible list of uses when compared to the situational STEAL option, so they will substitute for GIVE and STEAL respectively. TALK_TO would not need to be included within NPC dialogue as the initiation of the conversation implies the player talking to the character. The other 3 new actions in npc_actions will be integrated into the new enum type. Each unique node_action will be classified as either KIND 4, KIND 5, or KIND 6. A new module will need to be created to classify different types of NPCs and the KINDS of actions they have access to (design is provided in the next section).

Adding Action into Conversations

To fully implement npc_actions into the existing conversation design, custom functions for adding each of these actions as nodes into conversations would be necessary (modeled after add_give_item, add_take_item, add_start_quest, and add_start_battle). Their definitions would have the following format:

int add_action_name(convo_t *c, char *node_id);

TRADE would also require some type of char* item_id for each item part of the swap. A basic implementation of a 1-to-1 trade could be formatted as such:

int add_trade_item(convo_t *c, char *node_id, char* given_item_id, char* received_item_id);

Future implementations of a trade action where players can give and receive multiple items could include linked lists of strings. The item_wrapped_for_llist struct defined in game-state/item could be implemented as such:

int add_trade_item(convo_t *c, char *node_id, item_list_t* given_item_id_lst, item_list_t* received_item_id_lst);

Executing Conversation-Triggered Actions

Then, the cases in do_npc_action would need to be made for each unique action. The actions taken within the code would vary based on the content of the action– for example, GIVE/TAKE_ITEM uses functions from the game-state/items module to manipulate the player’s inventory. However, each of these cases should have error-raising conditionals to return FAILURE if the action cannot be completed under current conditions. To do this, functions from the action module from used, particularly do_npc_action, do_npc_item_action, and do_npc_item_item_action. These functions execute KIND 4, KIND 5, and KIND 6 actions respectively, returning a string indicating the success of the action. Once a new type and struct are created to consolidate npc_actions and node_actions, these functions can simply take a pointer to these actions and execute them on a case-by-case basis.

Wishlist

• A currency system to trade with NPCs

Currently there is no currency system implemented within Chiventure. This is to be expected since there was no need. However, one of the crucial aspects of npc-actions is to have the player be able to trade with the NPCs. This could be accomplished through simply trading items given that the implementation of actions and dialogue needs only an item to trade or steal. But having a currency system and module would be an interesting idea to explore. Other considerations would including needing to figure out where the currency comes from and integrating it with different modules including but not limited to NPCs, action, quests, battles, sound, etc.

• A NPC mood and personality module

This module could implement personality and mood features specific to NPCs that influence the way they interact with the player. For example, a mood meter could fluctuate depending on whether the player makes negative or positive actions towards the NPC. A lowered or heightened mood could restrict or expand an NPC’s available conversation choices or change rates of in-conversation events occurring (certain information or items being given). NPCs could also be assigned different personality types, requiring players to employ different strategies in conversation to unlock certain information, actions, or unique features of the characters.

• More types of NPC actions

Many other actions could be implemented to further diversify the range of NPC interactions. Some potential actions include: HUG, LAUGH, COMPLIMENT, INSULT, or RECRUIT TO PARTY (potential implementation of parties of NPCs accompanying the PC, providing services like giving items, healing, conversing, providing information, and battling). In terms of the action functionality, changes in game_state via the functions defined in mode could be implemented for actions that trigger changes outside of conversations. For example, an INSULT action could connect to the NPC state module and change an NPC’s mood value.