-
Notifications
You must be signed in to change notification settings - Fork 13
NPC ~ Player Interaction Design and Planning
This document will outline the design of player interaction with NPCs. This will intersect with action management, UI, and CLI.
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.
Overview: Contains structures for npc actions, npc action kinds, and npc action types in addition to functions utilizing these structs
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.
Overview: Contains structures for npc game actions (how NPC actions interact with current game state) in addition to functions utilizing these structs
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.
-
Action Management
-
Battles
- Design Document
- Text Based Combat in Other Games
- User Stories
- Wishlist
- Battle Planning 2022
- Battle User Stories Review 2022
- Structs in Other Modules Related to Battles 2022
- Stat Changes Design Document
- Run Function Design Document
- CLI Integration Design Document
- Move Changes Design Document
- Unstubbing Stubs Design Document
- Battle Items and Equipment Design Document
- Battle Item Stats
- Battles Demo Design Document
- Battles Testing Moves, Items, and Equipment Design Document
- Sound integration with battle (design document)
-
Custom Actions
-
Custom Scripts
-
DSL
-
CLI
-
Enhanced CLI
-
Game-State
-
Graphics
- Design Plan
- Design document for integrating split screen graphics with chiventure
- GDL (Graphical Description Language)
- Graphics Sandbox
- Design Document for NPC Graphics and Dialogue
- Feature Wishlist (Spring 2021)
- Installing and Building raylib on a VM
- LibSDL Research
- Module Interactions
- Working with Raylib and SSH
- raylib
- GDL
-
Linking the Libzip and Json C to chiventure on CSIL machines
-
Lua
-
NPC
- Dependencies: Player class, Open world, Battle
- Action Documentation
- Design Document for NPC Generation in Openworld
- Design and Planning
- Establishing Dependencies
- Implementation of Custom Scripts
- Independent Feature: NPC Movement Design Document
- Player Interaction Design and Planning
- Dialogue
- Design Document for NPC Dialogue and Action Implementation
- Loading NPCs from WDL Files
- NPC Battle Integration Design Document
- NPC Battle Integration Changes Design Document
-
Open World
- Autogeneration and Game State
- Deciding an integration approach
- Designing approach for static integration into chiventure
- Feature Wishlist
- Generation Module Design layout
- Potential connections to the rest of chiventure
- Single Room Generation Module Design
- Source Document
- User Stories
- World Generation Algorithm Plan
- Loading OpenWorld Attribute from WDL
-
Player Class
-
Player
-
Quests
-
Rooms
-
Skill Trees
- Avoiding soft locks in skill tree integration
- Components of Exemplary Skill Trees
- Design Document and Interface Guide
- Environment interactions based on skill characteristics
- Integrating complex skill (combined, random, sequential, etc.) implementation
- Integration of a Leveling System
- Potential Integration with existing WDL
- Research on game balancing in regards to skill trees
- Research on skill tree support in modern day game engines
- SkillTree Wiki Summary
- Skilltree "effect" implementation and roadmap
- Summary of md doc file for skilltrees
- Design ideas in connection to other features
- Summary of Skill Tree Integration 2022
- The Difficulty of the Reading the World
- Complex Skills Summary
-
Sound
-
Stats
-
WDL