-
Notifications
You must be signed in to change notification settings - Fork 13
Skill Trees ~ Complex Skills Summary
There are currently four complex skill types:
Combined complex skills: These execute each of its subskills. ex: deal 50 damage and incapacitate the victim for 50 seconds and throw a fireball.
Sequential complex skills: These execute each of its subskills in order, stopping execution once a subskill fails. Ex: deal 50 damage, then incapacitate the victim for 50 seconds, then throw a fireball.
Conditional complex skills: These check if a condition is met and, if so, executes its subskills. Ex: If the player is an orc, then deal 30 damage to the opponent.
Random complex skills: There are a few ways these skills can be used but this is currently being implemented, so more details will be added later; for now, one example of this skill would be a random chance complex skill which executes its subskills a certain percent of the time. Ex: Deals 30 damage and throws a fireball 50% of the time.
There are more specific details here: https://github.com/uchicago-cs/chiventure/wiki/Skill-Trees-~-Integrating-complex-skill-(combined,-random,-sequential,-etc.)-implementation
typedef struct complex_skill{
//Type of complex skill
complex_skill_type_t type;
//List of sub-skills used in complex skill
skill_t** skills;
//Number of sub-skills in skills list
int num_skills;
} complex_skill_t;
A complex_skill_t includes:
- an enum indicating the type of the complex skill (Sequential, Combined, Random, or Conditional)
- a list of sub-skills that are used by that complex skill
- an integer indicating the number of sub-skills used by the overall complex skill
As mentioned in the beginning section, the addition of the complex_skill field to the skill_t struct allows for the usage of nesting complex skills. Looking at the implementation of complex_skills:
typedef struct complex_skill{
//Type of complex skill
complex_skill_type_t type;
//List of sub-skills used in complex skill
skill_t** skills;
//Number of sub-skills in skills list
int num_skills;
} complex_skill_t;
For most circumstances, each skill within the skills struct will be a simple skill. However, due to the addition of the complex_skill_t struct, users could make one or all of the skills within the list a complex skill, allowing for the nesting of complex skills. It is not recommended to nest a large amount of complex skills, due to the complexity of storage, comprehension, and processing power of executing such a skill, but the functionality has been included.
As a part of the implementation of complex skills, the skill_t struct has been updated to include a new field for the complex_skill_t struct. This change does mean that all instances of skill_new() will need to be updated. However, the structure of it has purposely been made to be an easy update, by just adding a NULL parameter to the end. All simple skills will have a NULL parameter for the complex_skill field, so previous implementations won’t be changed very much.
The reason this design decision was made as opposed to just using the complex_skill_t struct as a separate kind of skill_t is for 2 reasons:
1.) To allow the updating of previous functions like skill_execute() and skill_level_up() to use complex skills so that projects that have already implemented them can more easily be updated to handle complex skills. For example, the skilltrees module has nodes that store skill_t, and this implementation won’t require the addition of a complex_skill_t struct to add support for them.
2.) It allows for the ability to nest complex skills within complex skills (Further explanation of this later in the article)
As a result of these design decisions, the complex_skill_t struct should not be viewed as a separate kind of skill than the skill_t struct, but rather as a way of storing all of the information needed if a skill is complex. Since this information is only required for complex skills, we created the complex_skill_t struct to store all that information in one place, allowing for the creation of simple skills to remain simple, adding one field that won’t be used rather than the three required for the complex_skills_t struct.
-
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