Skill Trees ~ The Difficulty of the Reading the World - uchicago-cs/chiventure GitHub Wiki

Based on idea from past Skilltrees team as described here https://github.com/uchicago-cs/chiventure/wiki/Skill-Trees-~-Integrating-complex-skill-(combined,-random,-sequential,-etc.)-implementation

For several complex skills, they rely upon a mechanism for "looking at the world." While figuring out something about the world is relatively easy (with access to the chiventure_ctx object), being able to allow the game devs to specify what they are looking at is very tricky. In order to allow skills to understand context, we must add a group of effects (effect_components) called "Readers", each of which looks at something in the world and returns a value (a bool, or SUCCESS / FAILURE) to be used by the parent effect (Sequential or Either, as of now). Perhaps we have one that looks at stats, one that looks at attributes, and so on. If each reader only has one type of thing it looks at, this actually might be quite feasible. For an effect that does more damage to an undead enemy we might expect the constructor function for such a reader to look like this:

//Pseudo code

new_attribute_reader_effect("undead", SINGLE_TARGET);

For an effect that only affects a certain class of enemy, we might expect the constructor function for this reader to look like this:

//Pseudo code

new_attribute_reader_effect("class name", SINGLE_TARGET);

The SINGLE_TARGET enum tells the reader to go to "whatever the player is targeting." The first argument is simply the attribute to look at. While this may still seem hard, note that finding the target is something even simple skills will have to do, and accessing the attribute would be easy after that. The issue with this approach is that the ctx object (or rather, the game_t object, as we are reading from the current state of the game), contains a nearly endless amount of structs that a game designer might want to create a skill around. With the way C implements structs, there is no way one could “iterate” over every possible struct in order to find the correct one. For every possible variable one may want to check, there must be a line in the function pointing to that object, for instance if the player has x object in their inventory, if the room has y item, if the player has z health. If one wants to check the class of an enemy, then there must be an if statement or potentially a switch statement grabbing the class, for example:

//Pseudo code

execute_attribute_reader_effect(“undead”, SINGLE_TARGET){

`if(SINGLE_TARGET){`

	`char* s = ctx->game->battles->enemy->class->name;`

`}	`

}

If statements like these would have to be written manually, and enums checking each possible thing also have to be written manually. For attributes, this isn’t so bad, as a game designer will likely only want to check something simple like the class of an enemy or its name. The problem comes with stat readers, which will be explained. A stat reader could like something like the following: a integer, an enum representing the stat being looked at, what comparison is being made between the int and the stat, and the target being looked at, for example:

//Pseudo code

new_stat_reader(50, HEALTH, BELOW_EQUAL, SINGLE_TARGET);

Given the amount of potential stats to check, if everything were included, we would quickly create bloated, hard to read code. We are forced to include a limited amount of objects to look at and there is no way for users to create their own custom reader.

Furthermore, because of the enormous amount of struct calls it relies on to check the gamestate, the reader effect implementation would be sensitive to changes in those structs, so many dependencies would be created. There are many stats that are in chiventure, 7 within the battles struct alone, and there could be non-battle related stats within the game_t struct, with the potential of more being added in the future. New stats would be excluded from the reader, and writing code to check each individual stat would result in an increasingly long if or switch statement chain. For implementation, the Skilltrees team might consider working with Game-State in order to create an organized way of reading the world, given the importance of the game_t struct for readers.

---

Example of implementing a potential reader reading combatants statistics:

The battles team created statistics for a combatant all in the type of Ints. These involve fields such as:

int speed; //The combatant's speed. Used to determine who goes first in battle.

int defense; //The defense value of the player. Used in damage calculations.

int strength; //No description given; presumably the offensive value of the player used for damage calculation

etc.

We may be able to loop through these statistics with the help of switch statements (or using if statements as described above). Here's an example of using switch statements to loop through structs as found from this source https://stackoverflow.com/questions/14418595/c-method-for-iterating-through-a-structs-members-like-an-array

typedef struct vec3_s

{

float x, y, z;

} vec3;

float get_vec3(v *vec3, int i) {

switch(i) {

case 0: return v->x;

case 1: return v->y;

case 2: return v->z;

}

assert(0);

}

for (int i = 0; i < 3; i++) {

 `printf("%f\n", get_vec3(v, i));`

}