-
Notifications
You must be signed in to change notification settings - Fork 13
Action Management ~ Player Integration Plan
The player module in the dev
branch currently defines a player as follows:
/* A player in game */
typedef struct player {
/* hh is used for hashtable, as provided in uthash.h*/
UT_hash_handle hh;
char *player_id;
int level;
int health;
int xp;
class_t *player_class;
item_hash_t *inventory;
} player_t;
The following features were desired by previous (2020) and current (2021), iterations of RPG teams (copied from here):
- Player class (monk, knight, healer, ninja, etc.) with different skills/stats
- Handled by team RPG player class
- Player race (human, orc, elf, etc.)
- Handled by ?
- Player stats, such as health, experience, speed, attack, mana, stamina, charisma, etc.
- Handled by team RPG player stats (no 2021 iteration, may be handled by other parties)
- Skill trees (unlock spells like teleportation, lock-picking, or magic light sources for some random underwater room that would put a normal torch out)
- Handled by team RPG skill trees
- Player statuses: these would be effects that modify a player's stats for a given amount of time or until a condition is fulfilled
- Handled by team RPG player stats (no 2021 iteration, may be handled by other parties)
In the playerclass/skilltree-integration
branch in the file include/playerclass/class_structs.h
(link):
/* A player class struct storing the name, descriptions, attributes,
* and stats */
typedef struct class {
// Name of the class
char* name;
// A short description of the class
char* shortdesc;
// A long description of the class
char* longdesc;
// An object containing all the attributes of the class
obj_t* attributes;
// All the stats of the class
stats_hash_t* stats;
// Effects/temporary status on the class
effects_hash_t* effects;
// Class skilltree
skill_tree_t* skilltree;
/*
* Note: There is a concern here about the combat vs noncombat distinction,
* since the skilltrees code divides between passive and active skills.
*
* Should we adjust the division below so that we track passive vs active
* skills?
*/
// Class combat actions
skill_inventory_t* combat;
// Class noncombat actions
skill_inventory_t* noncombat;
} class_t;
Since the class_t *player_class
has been added to the player struct there are no apparent additions necessary from the class module.
As of April 30th, 2021, it seems like a player's race will have no effects on stats/skills/etc. Therefore, it can simply be an additional string field in the player struct.
In the dev
branch in the file include/game-state/stats.h
(link) (Valid link as of April 25th, 2021):
// GLOBAL STATS STRUCT DEFINITION ----------------------------------------------------
/* This struct represents the global table that keeps track of all stats available.
* It contains:
* the name of the stat,
* which is also the key to the hashtable
*
* the maximal value a stat could have
* */
typedef struct stats_global{
char *name;
double max;
UT_hash_handle hh;
} stats_global_t;
typedef struct stats_global stats_global_hash_t;
// STATS STRUCT DEFINITION -----------------------------------------------------
/* This struct represents a stat of the player.
* It contains:
* The string name of the stat,
* which is also its key in the hashtable
*
* a pointer to the corresponding global stat
*
* the base value of the stat,
* whose final value will be multiplied by the modifier
* note that the base value should not exceed max value and
* the base val * modifier should not exceed global max
*
* cumulative modifiers from effects, set to 1 by default
* */
typedef struct stats {
char *key; //key for hashtable (same as global stat name)
stats_global_t *global;
double val;
double max;
double modifier;
UT_hash_handle hh;
} stats_t;
typedef struct stats stats_hash_t;
Note: In the rpg-stats/effects
branch in the file include/game-state/stats.h
there is no field char *key; // key for hashtable (same as global stat name)
in the stats struct (link) (Valid link as of April 25th, 2021).
In the dev
branch in the file include/skilltrees/skilltrees_common.h
(link) (Valid link as of April 25th, 2021):
/* An INDIVIDUAL skill, belonging to a player */
typedef struct skill {
// The skill ID that uniquely identifies the skill
sid_t sid;
// The skill type
skill_type_t type;
// The name of the skill
char* name;
// The description of the skill
char* desc;
// The player's current level of the skill
unsigned int level;
// The player's current experience points associated with the skill
unsigned int xp;
// The maximum level to which the skill can be upgraded
unsigned int max_level;
// The minimum number of experience points needed to level up
unsigned int min_xp;
// The pointer to the function that will execute the skill effect
skill_effect_t effect;
} skill_t;
In the dev
branch in the file include/skilltrees/inventory.h
(link) (Valid link as of April 25th, 2021):
/* ALL the skills belonging to a player */
typedef struct skill_inventory {
// An array of active skills belonging to a player
skill_t** active;
// The number of active skills belonging to a player
unsigned int num_active;
// The maximum number of active skills a player can possess
// (This field helps to enforce skill tree balancing)
unsigned int max_active;
// An array of passive skills belonging to a player
skill_t** passive;
// The number of passive skills belonging to a player
unsigned int num_passive;
// The maximum number of passive skills a player can possess
// (This field helps to enforce skill tree balancing)
unsigned int max_passive;
} skill_inventory_t;
Although there are skill_inventory_t
fields present in the class struct, the addition of a skill_inventory_t
to the player struct is necessary to track all of the acquired skills of the player.
In the dev
branch in the file include/game-state/stats.h
(link) (Valid link as of April 25th, 2021:
/* This struct represents an effect that changes player's stats.
* It contains:
* the name of the effect,
* which is also the key to the hashtable
*
* a pointer to the related global effect
*
* a linked list, stat_mod_t, which contains the stats effected
* and the modifier value for each stat (an empty list means the
* the effect is turned off)
* */
typedef struct effects{
char *key; //key for hashtable (should be same as name of effect)
effects_global_t *global;
stat_mod_t *stat_list;
UT_hash_handle hh;
} stat_effect_t;
typedef struct effects effects_hash_t;
Although there is an effects_hash_t
field present in class_structs.h
(for both the dev
branch and the branch with the most updated version of class_structs.h
the playerclass/skilltree-integration
branch), there may be effects that are not relevant to the player's class. Therefore, a seperate effects_hash_t
field must be in the player struct.
After communicating with the current (2021) iterations of relevant RPG teams, the player struct will need to look like this:
/* A player in game */
typedef struct player {
/* hh is used for hashtable, as provided in uthash.h*/
UT_hash_handle hh;
/* Unique id identifying the player */
char *player_id;
/* The player's current health, separate from their maximum health */
int health;
/* The player's current level */
int level;
/* The cumulative total of experience points acquired by the player */
int xp;
/* A string containing the player's race */
char *player_race;
/* The player's current class. class_t contains the base health, stats, and skills for that class at
the beginning of a game. These may change throughout the game, so their current states are stored
in the health, player_stats, player_skills fields in this player struct */
class_t *player_class;
/* All of the stats, with their values, the player has */
stats_hash_t *player_stats;
/* The current skills known to the player */
skill_inventory_t *player_skills;
/* All of the effects the player is currently experiencing */
effects_hash_t *player_effects;
/* The current items held by the player*/
item_hash_t *inventory;
} player_t;
-
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