NPC ~ Player Interaction Design and Planning - uchicago-cs/chiventure GitHub Wiki

This document will outline the design of player interaction with NPCs. This will intersect with action management, UI, and CLI.

• Important Existing Interfaces
• New NPC Action Module
• Modification of Existing Files

This file includes an enum outlining the current actions that are doable for the player (which the CLI can parse). These actions are split into three "kinds." We propose three new kinds to handle actions involving NPCs:

• KIND 4 ACTIONS - ACTION <npc>
  • This kind will include actions such as TALK, BATTLE, IGNORE, etc. that involve only the player and the NPC.
• KIND 5 ACTIONS <npc_item>
  • This kind will include actions such as GIVE and TAKE that involve the player, the NPC, and one item.
• KIND 6 ACTIONS - ACTION <npc_item_item>
  • This kind will include actions such as TRADE and BUY that involve the player, the NPC, and two items.
  • It is possible that this kind will simply involve two calls to actions in kind 5.

It is important to note that these functions will likely not involve much of the existing action management code, as they will have to interact with the new NPC struct. For this reason, we plan to create an npc_action module within the current NPC folders. They are named kinds 4, 5, and 6 just to avoid confusion with the existing kinds.

This file contains the interface for the new, init, and free functions for the action_type_t struct. It also includes a function that creates a list of all supported actions. Finally, it has one function for each kind to execute an action of that kind.

This file contains the interface for the new, init, and free functions for the game_action_t struct defined in game-state/item.h. A game_action_t contains a hash handle, a string action name, a list of action_conditions, a list of action_effects, and strings for both success and failure. Both an action_condition (game_action_condition_t) and an action_affect (game_action_effect_t) contain an item, an attribute, an attribute_value_t, and it is a linked list, containing a *next pointer to another of itself.

If we base this struct on the current action_type_t struct and its supporting enums, it will look something like this:

enum npc_actions {
    // KIND 4 ACTIONS
    TALK_TO,
    IGNORE,
    // ATTACK,
    
    // KIND 5 ACTIONS
    GIVE,
    STEAL,

    // KIND 6 ACTIONS
    TRADE,
    BUY
};

enum npc_action_kind {
    NPC = 4,
    NPC_ITEM = 5,
    NPC_ITEM_ITEM = 6
};

typedef struct npc_action_type {
    char *c_name; // e.g. "ignore"
    enum npc_action_kind kind;
} npc_action_type_t;

Keeping the same structure as the existing action management code is good for continuity and reflects our method with the game-state npc files.

• New, init, and free functions for npc_action_type_t structs.
• A function that creates a linked list of support npc actions.
• Functions that execute each kind of npc action.

typedef struct game_action {
    UT_hash_handle hh;
    char* action_name;
    condition_list_t *conditions; //must be initialized to NULL
    action_effect_list_t *effects; //must be initialized to NULL
    char* success_str;
    char* fail_str;
} game_action_t;

Using the same game_action struct as located in game-state/item.h

• Functions that involve searching for and conducting actions
• Functions that add, check, and delete conditions for actions
• Functions that add, set, and delete effects of actions

A field will need to be added to the existing NPC struct to hold the actions that are allowed to be performed on the NPC (it will be assumed that all NPCs can talk, but only some can battle or trade, etc.). Whether this will be an npc_action_type_hash_t or a game_npc_action_hash_t. For the current actions and items, this looks like the game_action_hash_t *actions field in the item struct. It is unclear whether NPCs require the additional level of abstraction that is game_actions, or whether we can just work with npc_action_types.