-
Notifications
You must be signed in to change notification settings - Fork 13
Enhanced CLI state of current CLI
Specifically, we are looking into the implementations of different operation.h function, command hashmap, and parsing functions. This is because they seem the most relevant to our goal of changing the way that commands strings are processed.
If we can identify how this works, we can figure out what aspects of the existing codebase we can leave alone
defines cli context struct, has list of previous actions and hashmap of "action entries"
has an allocate and free function
contains a lot of functions related to hashmaps
****includes "parser.h" "common/uthash.h" "action_management/action_structs.h" "common/ctx.h"
defines lookup_t struct, which is the entry for the actions hashtable
-use the hashmap in common/uthash (within chiventure), originally from http://troydhanson.github.com/uthash/ -used commonly throughout chiventure as well as other projects so safe to assume its a pretty good implementation -http://troydhanson.github.io/uthash/ here is a tutorial for using uthash
defines cmd data structure, contains string array and operation datatype
typedef char *operation(char *tokens[TOKEN_LIST_SIZE], chiventure_ctx_t *ctx);
Defines operation as something that takes in (char *tokens[TOKEN_LIST_SIZE], chiventure_ctx_t *ctx) and returns a string. So when a function has this pattern ((char *tokens[TOKEN_LIST_SIZE], chiventure_ctx_t ctx) in, (char )out), this is just a shorthand for it
contains basic shell stuff like printing the help text, greeting the user, printing the history of commands, and functions to handle errors.
defines a linked list struct for command words defines a max word length for a command
has two parsing functions:
parse_r which takes one string, and turns the ninto a list of tokenized commands parse which takes in a string and turns it into a list of words, space separated.
parse_r: (parses a string into a linked list, breaking on the string "AND") -takes in the string input -checks for an empty string (and returns null if its empty) -changes the input to be all caps, for compatibility with commands/objects/directions -puts tokenized segments of the inputted string in the command line with a delimiter "AND" into a list until the end of the string -If there are more than 4 words, parser returns NULL and does not attempt to pass the first four words as tokens
parse: (parses a string into a list of words, breaking on spaces) -takes in a string -checks for an empty string -changes the input to all caps (..I think. The function is case_insensitize() TODO check this) -allocates space for a list of strings called words -creates a string of the tokens interspersed with " " (I think. The function is strtok() TODO check this)
puts the space separated tokens into the words array If there are more than 4 words, parser returns NULL and does not attempt to pass the first four words as tokens Thoughts on this: -So it looks like they wrote their own simple parser without using an existing library -I think we can use some/most of the token structure -the limit for input is 4 space separated commands. It makes sense they would do that for a simple cli, but we would definitely need a bigger size (we should have more details on this from the other teams wish lists but it would make sense to allow at least for and commands, accidental spaces etc)
Contains a shit ton of functions related to actually doing things within the CLI Going to look into the implementation of these to see how information is used.
All of these functions take in the parameter "char *tokens[TOKEN_LIST_SIZE]" which is the parsed and "validated" input string.
name_operation supposedly allows for the creation of synonyms of existing commands. TODO: look into how various functions actually use the token string array should be able to explain what is going on.
very simple module just describing the command list struct and function to add a command to the list. Only serves to record command history.
So long as we leave the actual command struct alone, we should be fine leaving this alone
cmd.h line 122: lookup_t_init
this function populates the actions hashmap with all possible commands. We are gonna have to figure out how to map multiple keys onto the same action to have actions aliases. And how to have transient words like "do" "that", "to" fit into this shell.h:
Update the greet/help text based on the changes we make the parsing All of these functions take in the parameter "*tokens[TOKEN_LIST_SIZE]" which is the parsed and "validated" input string.
****errors spotted: cmd.h misspell of creates shell.h, function paramaters make no mention of chiventure context struct shell.h, greet function should be moved to operation.c (apprently) operations.h, use of validified instead of validated
-
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