It looks like you're new here. If you want to get involved, click one of these buttons!
It's been a long time since my first (and last) thread here. I've gotten to a point where I'm trying to work on my game again, an RPG. I needed to figure out a way to make a list of attributes for characters that would be easily configurable, so I thought of creating a solver DSL for defining the relationships between attributes, in any arbitrary order so long as no loops are detected, which could then be attached to arbitrary orxObjects to automatically generate any dependent attributes on that object. The reasoning for this is to have an easy repository for all equations used in the game, which could be reused not just for stats but also damage calculations, or anything else really.
An example using hp, where equipped_list and effects_list are keys on the object that are just lists of other sections that currently affect the character:
[StatSolver] Equations = StatEquations Defaults = StatDefaults Update = change [StatDefaults] base_hp = 10 base_mult_hp = 1 damage_hp = 0 [StatEquations] max_hp = Clamp(0, max_hp_cap, (base_hp * base_mult_hp) + (equipment_mod_hp * equipment_mod_mult_hp)) total_hp = max_hp + (temporary_mod_hp * temporary_mod_mult_hp) - damage_hp max_hp_cap = infinity equipment_mod_hp = Sum(equipped_list, equip_modifier_hp, default: 0) equipment_mod_mult_hp = Sum(equipped_list, equip_modifier_mult_hp, default: 0) temporary_mod_hp = Sum(effects_list, temp_modifier_hp, default: 0) temporary_mod_mult_hp = Sum(effects_list, temp_modifier_mult_hp, default: 0)
This would, given any orx object, generate the attributes base_hp, base_mult_hp, damage_hp, total_hp, max_hp_cap, equipment_mod_hp, equipment_mod_mult_hp, temporary_mod_hp, and temporary_mod_mult_hp on that object.
I've currently got a parser and topological sort working, I've started on setting up a VM for it, but I noticed that the orxConfig API isn't thread safe, which I would need if I wanted to solve for multiple characters in parallel if the equations are referencing lists of config sections, but not if they're just referencing other variables on the object itself, since that can be saved to a hashtable beforehand. The only solutions I can think of so far are either manually doing mutex locks when reading the config (not ideal), duplicating the code from the config module to read values from another section without modifying the config section stack (also not ideal), or just dealing with solving for one object at a time (which limits how much it can be used). Just wondering if there's any tips on this.