-
Notifications
You must be signed in to change notification settings - Fork 13
Rooms ~ Conditional Connections Between Rooms Design Plan
In order to make sure rooms can't be entered without pre-requisites, the attribute for the "OPEN" action must be false in the attribute_hash_t parameter of the door item struct that corresponds to the path that enters that room. Path structs have an item called through, which is for the door that the player must pass through to take that path. If the "OPEN" attribute is set to false for the door item in that path, then the player can't pass through that door.
The "OPEN" attribute of the door will always start out as false if there are pre-requisites for entering the next room. Otherwise, it will start as true. To change the false to true for the paths with pre-requisites, the pre-requisites must be cleared. The path struct's description in game-state/room.h states that there is a "list of conditions that must be fulfilled to move to the room." This list of conditions is not present in the actual struct, but it must be added. It should be made as a linked list.
The next step is to add a trigger to the actions. The trigger will be a char* trigger in the action_type_t struct that has the same value as the room_id in the room struct of the path. If the action isn't a pre-requisite for anything, then it doesn't require a trigger, so the trigger value will be 0. When one of the do functions in actionmanagement.c carries out the action, the trigger value has to be checked. If it is not NULL, then the linked list will be searched in a helper function that takes the trigger value and finds the according path, then takes the id of the path/item(s) and searches for it in the linked list. When the items and actions are found to be the same, that element will be removed from the linked list and the trigger value will be changed to the value 0 (if the player does the same exact action again then the function won't search for it again).
That helper function will check if removing the action produces a NULL linked list. If it does, then it will call the set_bool_attr function in game-state/item.c to change the "OPEN" attribute to true. The room will then be accessible.
- Create a function that takes an action and removes it from any linked list that contains the action and changes the boolean for "OPEN" if it removes the only item of the list.
- Apply the function to the do functions in action management.c
- Add a linked list of conditions to the path struct.
- Add the trigger value parameter to the action_type_t struct.
/* goes into the list_action_type_t struct of path_t and removes the coinciding action_type_t */ Void remove_completed_action(path_t, action_type_t) {
}
/* checks if action has trigger value */ bool trigger_check(action_type_t) { Return false; }
/* checks if list of actions in path_t is empty */ bool conditions(path_t) { Return false; }
/* changes the door attribute to OPEN */ Void allow_path_access(item_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