-
Notifications
You must be signed in to change notification settings - Fork 13
Action Management ~ Do Action Functions
The functions that the CLI module ultimately call given a user's command are contained within the actionmanagement.c
module. At the time of this writing, there are 4 of these functions: do_item_action
, do_path_action
, do_item_item_action
, and do_self_action
.
This function handles actions that involve a single item. An example of this is eat bread
. This function is called by CLI in the kind1_action_operation
function in their operations.c
file.
-
chiventure_ctx_c *c
is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.) -
action_type_t *a
is the struct representing the action. This is assigned to the correct command string (i.e."eat"
) by the CLI team, using a list containing all available actions. CLI gets this list from our get_supported_actions in our get_actions.c file -
item_t *i
, the item that the user wants to act on. Again, this is set and passed in by CLI -
char **ret_string
is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.
- Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
- This function then collapses multiple different commands into one blanket command (e.g.
"use"
,"eat"
, etc. into"consume"
). - If the action type is unsupported, assign
ret_string
to an error string - Implement the actual effect by calling
do_all_effects
- If there are other actions with a condition associated with this item action, remove the condition from all associated actions.
- Test if the player has won the game with this item. If so, set
ret_string
to the winning string
This function handles actions that involve a path. An example of this is go north
. This function is called by CLI in the kind2_action_operation
function in their operations.c
file.
-
chiventure_ctx_c *c
is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.) -
action_type_t *a
is the struct representing the action. This is assigned to the correct command string (i.e."go"
) by the CLI team, using a list containing all available actions. CLI gets this list from ourget_supported_actions
in ourget_actions.c
file -
path_t *i
, the path that the user wants to take. Again, this is set and passed in by CLI -
char **ret_string
is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.
- Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
- If the action type is unsupported, assign
ret_string
to an error string - If valid path, move into the corresponding room by calling
move_room
- If there are other actions with a condition associated with this path action, remove the condition from all associated actions.
- Test if the player is in the end/game-winning room. If so, set
ret_string
to the winning string
This function handles actions that involve a two items. An example of this is put chair table
, meaning put chair on table. This function is called by CLI in the kind3_action_operation
function in their operations.c
file.
-
chiventure_ctx_c *c
is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.) -
action_type_t *a
is the struct representing the action. This is assigned to the correct command string (i.e."put"
) by the CLI team, using a list containing all available actions. CLI gets this list from ourget_supported_actions
in ourget_actions.c
file -
item_t *direct
, the first item that does the acting. Again, this is set and passed in by CLI -
item_t *indirect
, the second item that receives the acting. -
char **ret_string
is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.
- Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
- If the action type is unsupported, assign
ret_string
to an error string - Implement a list of effects on the second item using a while loop
- If the effects are not successfully applied, assign
ret_string
to error message. - If there are other actions with a condition associated with this item action, remove the condition from all associated actions.
- Test if the player has won the game with these items. If so, set
ret_string
to the winning string
This function handles actions that involve the player. An example of this is view stats
. The structure of this function is different because no effects are being applied anywhere. Currently, this function only supports the view
command on multiple things (stats, skills, quests, inventory, effects). This function is called by CLI in the kind4_action_operation
function in their operations.c
file.
-
chiventure_ctx_c *c
is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.) -
action_type_t *a
is the struct representing the action. This is assigned to the correct command string (i.e."view"
) by the CLI team, using a list containing all available actions. CLI gets this list from ourget_supported_actions
in ourget_actions.c
file -
char **target
, an array of strings the user wants to act on. Currently, we support one or 2 strings (view quests
orview quests "quest-id"
). This is set and passed in by CLI after they parse user input -
char **ret_string
is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.
- Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
- If the action type is unsupported, assign
ret_string
to an error string - The logic of this function is currently implemented as a nested if-elseif-else chain.
- We first test what the command is. We currently only support
"view"
. Then, we check what the first string intarget
is. - If the first string is
"stats"
, we display the stats of the player by callingdisplay_stats from
game-state/player.h` - If the first string is
"effects"
, we display the stat effects from the player by callingdisplay_stat_effects' from
game-state/player.h` - If the first string is
"inventory"
, if the second string is NULL, we print the entire inventory using thedisplay_inventory
function ingame-state/player.h
. If the second string is not null, we pass this string in as the inventory item we want to view in more detail todisplay_inventory_item
ingame-state/player.h
- If the first string is
"skills"
, if the second string is NULL, we print the entire skills list using thedisplay_skills
function inskilltrees/skilltree.h
. If the second string is not null, we pass this string in as the skill we want to view in more detail todisplay_skill_description
inskilltrees/skilltree.h
- If the first string is
"quests"
, if the second string is NULL, we print the entire quest list using theshow_quests
function inquests/quests_cli.h
. If the second string is not null, we pass this string in as the quest we want to view in more detail toshow_task_tree
inquests/quests_cli.h
- If the first string is
"task"
, if the second string is NULL, we give an error string. This because"task"
is only used if we want to view a specific task within a quest. Therefore, we need a task-id. If the second string is not null, we pass this string in as the task we want to view in more detail toshow_task
inquests/quests_cli.h
-
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