-
Notifications
You must be signed in to change notification settings - Fork 13
Quests ~ Incorporating Quests into NPC
One of the ways we wanted to incorporate quests into the game was to have NPC give players quests and also allow players to interact with them as part of missions to complete tasks. For this to happen, we needed the NPCs to have certain dialogues which would allow them to speak about a specific quest/task with the player. But there would also need to be the case where the NPCs had normal dialogue if the NPC has already given the quest/task or if the NPC cannot give that particular player a quest/task.
We were able to incorporate quests into the NPC struct through an npc_quest_t
and npc_task_t
which both simply hold a task id, the dialogue that would be triggered if the NPC can give the player the quest/task, and the next quest/task in the list:
/* Forward Declaration */
typedef struct npc_quest npc_quest_t;
/*
* A singular quest node for npc_quest_list_t
* (provided by the Quest team)
*/
typedef struct npc_quest {
char *id;
convo_t *dialogue;
npc_quest_t *next;
} npc_quest_t;
/*
* A linked list of npc_quest structs
* (provided by the Quest team)
*/
typedef struct npc_quest_list {
npc_quest_t *head;
int length;
} npc_quest_list_t;
/*
* tasks and task lists have the same format as quest lists
* (provided by the Quest team)
*/
typedef npc_quest_t npc_task_t;
typedef npc_quest_list_t npc_task_list_t;
In the NPC struct, we have active_dialogue which would be triggered if the NPC can give a quest/task to the player and if the player can complete said quest/struct.
/* A non-playable character in game */
typedef struct npc {
/* hh is used for hashtable, as provided in uthash.h */
/* Second hash handle is for storing npcs in specific rooms */
UT_hash_handle hh, hh_room;
/* NPC identifier */
char *npc_id;
/* short description of the NPC, <51 chars */
char *short_desc;
/* long description of the NPC, <301 chars */
char *long_desc;
/* pointer to existing convo struct; changed depending on whether
npc has activated quest or task convo */
convo_t *active_dialogue;
/* pointer to an existing convo struct; for normal dialogue */
convo_t *standard_dialogue;
/* pointer to inventory hashtable */
item_hash_t *inventory;
/* pointer to an existing class struct */
class_t *class;
/* pointer to an existing npc_move struct */
npc_mov_t *movement;
/* enum indicating hostility level of the npc */
hostility_t hostility_level;
/* either NULL or a pointer to an existing npc_battle struct */
npc_battle_t *npc_battle;
/* linked list of all possible actions the player can initiate with the npc */
list_action_t *npc_actions;
/* pointer to a quest with dialogue */
npc_quest_list_t *quests;
/* pointer to a task with dialogue */
npc_task_list_t *tasks;
/* pointer to game_action hashtable */
game_action_hash_t *actions;
} npc_t;
In our quests_state.h
file, we wrote two functions that would see if the NPC can give the quest and if the player can complete the task. The intention of writing these two functions was so that the NPC team did not need to access our other features. These two functions would help determine what dialogue the NPCs should give.
/* Checks to see if the player can start a quest given by the NPC
*
* Parameter:
* - qctx: a quest context struct which includes the player and a list of all quests
* - quest_id: a quest id given by the npc
*
* Returns:
* - true: if the player can start the quest
* - false: if the player cannot start the quest
*/
bool can_player_start_quest(quest_ctx_t *qctx, char *quest_id);
/* Checks to see if the player can start a task given by the NPC
*
* Parameter:
* - qctx: a quest context struct which includes the player and a list of all quests
* - task_id: a quest id given by the npc
*
* Returns:
* - true: if the player can start the quest
* - false: if the player cannot start the quest
*/
bool can_player_complete_task(quest_ctx_t *qctx, char *task_id);
On the NPC functionality side, they would utilize our functions to actually properly set the correct dialogue. If the can_player_start_quest
returned true, then the NPC would use the active dialogue, and similarly for task completion. Once the player was done receive or finished the quest/task, the NPCs dialogue would also be set back to normal.
/* Sets the npc's active dialogue to the proper dialogue
* - This handles quest interaction, since NPCs can have different
* dialogue when giving quests or completing tasks
*
* Parameters:
* - qctx: A quest context containing a player and a hash of all quests in the game
* - npc: An npc
*
* Returns:
* - SUCCESS on success, FAILURE if an error occurs
*/
int set_proper_dialogue(quest_ctx_t *qctx, npc_t *npc);
-
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