-
Notifications
You must be signed in to change notification settings - Fork 13
Battles ~ Battle Planning 2022
Here are some of the things we hope to implement for Spring 2022. These are subject to change. Currently we have an idea of what we want to add, where it should be added, and how it will be implemented. As an overall goal, we would also like to integrate our overall stubs with the rest of the interface (move_t, battle_item_t, stat_change_t, and stat_t).
Auto-battle is used whenever the player doesn’t want to manually take actions in battle. It is essentially AI vs AI.
Where: AI Module, but it’s own separate file
How: Relies on the existing battle_ai.c functions but instead makes it applied to the actual user. With this implementation, we will need to make sure that these random actions are specific to the user and still continue to maintain the player state properly. The functions for the auto battle file may not directly use the battle_ai.c functions, but instead it will most likely be very similar to those functions.
We want to add more customizability to our AI opponents. By adding a defensive mode, it adds a different type of difficulty opponent that will be different to fight compared to the greedy opponents.
Where: AI Module (battle_ai.c & battle_ai.h) and battle_common.h
How: Currently there is a function called find_greedy(), which returns the most offensive move possible. This would be the reverse, where it instead returns the most “defensive” move possible. We would also need to change the enum “difficulty” to support BATTLE_AI_DEFENSIVE. However, we need to also be mindful that the AI will not just spam a damage prevention move over and over again.
Support reverting item-based stat changes for things like temporary stat boosters that only take effect for the duration of the battle
Where: battle_logic.h
How: We will have to collaborate with and reach out to other teams to integrate our code for this functionality. Based on past documentation, we need to work with rpg_classes to do this.
We would like to add more stats beyond just HP, Defense, and Damage. Things such as accuracy, special attack, special defense, critical chance, critical damage, and magic power.
Where: battle_structs.h
How: We can easily modify the stat_t to implement these new stats. From there, depending on the different stats they can be modified in other modules like battle_logic, battle_moves, and battle_state.
We want to make battles more complex by adding moves that wouldn’t just attack the opponent, to add more of a strategy component to the games.
Where: battle_structs.h and battle_moves.h
How: In battle_moves, we would have to add support for different “types” of attacks. Current in stat_t, there is a field labeled “attack” that is a boolean. Instead we could possibily modify this struct to allow for different “types” of attacks - OFFENSIVE, DEFENSIVE, STAT_CHANGE, etc. From there, we would have to implement ways to allow for these different types of moves to be processed/manipulated.
We want to be able to have status effects, such as sleep, poisoned, paralysis, burned, petrified, frozen, etc. These can be inflicted through items/moves. We also hope to have some sort of items or moves that can cleanse these status effects.
Where: battle_common.h battle_moves.h battle_logic.h
How: We would want the combatant struct to have a field that marks if and what status they have been inflicted with. Additionally, we need functions to be able to inflict the affects of the status on stats and moves etc. In the battle_moves.h and battle_logic.h, we need to incorporate ways for items and moves to inflict status effects on the opponent. We also need to add some functions that would allow certain items or moves to “cleanse” status effects.
This will prevent a player from using a battle move after using it a certain number of times. This will encourage players to use strategy when in battle, rather than spamming the most powerful/effective attack.
Where: battle_structs.h
How: In battle_structs.h, there is a struct called move_t, which we can add a field to for this purpose. This field can count the number of moves left and once it reaches 0, you cannot use that move anymore. We can also have another field that has the maximum number of times you can use the certain battle move. This second field is useful in case there is an item that allows you to use a battle move more than you normally can (for example, you can use move “x” only a maximum of 5 times, but the item allows you to use it a maximum of 10 times instead).
Support reverting item-based stat changes for things like temporary stat boosters that only take effect for the duration of the battle
Where: battle_logic.h
How: We will have to collaborate with and reach out to other teams to integrate our code for this functionality. Based on past documentation, we need to work with rpg_classes to do this.
-
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