Pyrel dev log, part 4

[Derakon]

I think your arbitrarily extensible categorisation idea is a stroke of genius. We bin type and subtype altogether (yay!) and operate on categories. Brilliant. Presumably one of the categories will be for use of the definite article:

Phial of Galadriel: light source, phial, unique

I was thinking the "unique" aspect would actually be a separate aspect of the nameInfo dict -- either a shouldUseDefiniteArticle boolean or simply invoking a different name Proc altogether.

But we need to be careful that we don't confuse or conflate naming categories with object flags. Harmed by Foo is a flag, I think.

It's interesting that you bring up flags, since they're basically the same thing -- binary stats. In the case of categories, the binary nature is determined by presence/absence in a grouping; in the case of flags, it's a +1 or 0 in the Stats instance. The important thing, when deciding which to use, is in how we plan to make use of the information. My thinking is that the game will generate a set of Containers, one for each category, so that you can ask for all the items in a given intersection of categories (e.g. all items in the player's inventory that are potions). But flags are hidden in the Stats instance, so it's much harder to query them. If you wanted "harmed by foo" to be a flag, then to find all the items in the player's inventory that are harmed by whatever then you'd need to manually iterate over the contents of the inventory, asking each item for its HarmedByFoo stat.

In short, I think there's definitely room for gameplay-meaningful categories, as opposed to ones that are just used for deciding what kinds of items are generated or how to describe them.

I do think we need the nameInfo field to have something called shortName or baseName or something - so we can easily and simply refer to the kind without any clutter. This field would contain "potion", "scroll", "dagger", "greaves", "soft boots", "phial" etc. No article, plural marker or Pair/Set/Suit - just the shortest unambiguous name of the kind. Yes this will in most cases duplicate one of the category entries, but I think it's important to know which.

I don't object in principle to this, but I'm not certain what we'd use it for. Do you have any reasonably concrete examples? Assuming we did do this then the cleanest way to implement it would probably be to have the baseName automatically be inserted into the categories list, so you don't have to have a duplicate string in every object entry.

[Magnate]

I think your arbitrarily extensible categorisation idea is a stroke of genius. We bin type and subtype altogether (yay!) and operate on categories. Brilliant. Presumably one of the categories will be for use of the definite article:

Phial of Galadriel: light source, phial, unique

But we need to be careful that we don't confuse or conflate naming categories with object flags. Harmed by Foo is a flag, I think.

I do think we need the nameInfo field to have something called shortName or baseName or something - so we can easily and simply refer to the kind without any clutter. This field would contain "potion", "scroll", "dagger", "greaves", "soft boots", "phial" etc. No article, plural marker or Pair/Set/Suit - just the shortest unambiguous name of the kind. Yes this will in most cases duplicate one of the category entries, but I think it's important to know which.

I don't think this is incompatible with any of your suggestions. For example, Pair of Greaves would be:

{ "categories": ["armour", "boots", "greaves"],
"pluralisation": "Pair~ of Greaves",
"baseName": "greaves" }

[Derakon]

The devteam has been having some discussion about the proper way to name things. Kinematic has put a lot of thoughts up on his pull request. Given that I initially gave him some bad advice, I thought it would be best to try to hash out the proper way to handle things here on the forums, where we can have a discussion that's a) more permanent than IRC, and b) easier to track than pullreq comments.

First off, given the myriad different ways we may want to name things, we should be handing naming off to a set of Procs. These functions would be handed an item and possibly a context, and be told to come up with a name for them. Basically they'd implement Item.getShortDescription().

(Actually, we may want namer Procs for other purposes too, e.g. to figure out how to pluralize enemies when we write "14 Snagas scream in agony" or the like)

The most obvious reason to use Procs here is to handle the artifact/normal-item split, where artifacts get a definite article and a name, while normal items get an indefinite article, a quantity, and typically a prefix/suffix (Foo Bar of Baz). So we'd have an ArtifactName Proc, and a NormalItemName Proc (or whatever we want to call them). But as noted earlier in the thread, there are a few more splits: flavored items use a different naming scheme (Flavor Basetype of Subtype), some items are represented as compound nones (e.g. Pairs of Soft Leather Boots), and we rapidly get into the whole affix system as well. There's also the question of how we store naming information in the item records, and what exactly are type and subtype for?

I'm just going to lay down some thoughts here and let you guys loose on 'em.

1) We can store arbitrary information in the item record. Let's say we add a new element to the record: "nameInfo". This element is a dictionary that holds whatever we need it to hold. In particular, this dict should tell us which Proc to use to generate a name for the item. All of the other entries in the dict can be passed to the Proc as parameters. So for example:

"nameInfo": {"proc": "normal item name", "pluralization": "[Pair|Pairs] of Soft Leather Boots"}

leads to...

class NormalItemNameProc(NameProc):
    def trigger(self, item, pluralization):
        if item.quantity == 1:
            name = generate singular name
        else:
            ...
        ...
        return name

ItemFactory becomes responsible for assembling the nameInfo dictionary from templates, just as it does many other records. But we avoid having a proliferation of naming-related fields in the Item class, which is helpful especially as we may have wildly-variant naming systems depending on item type.


2) What are type and subtype for? I see two major reasons now: one is that affixes want a way to refer to classes of items without having to enumerate every item in the class (e.g. the "Dwarven" theme can be applied to any hard body armor). The other is to help the user learn what different symbols are, via the '/' command. But that latter gets badly bogged down in display info -- the '[' symbol won't even be displayed if you're using tiles, for example, so how should you know to do /[ to learn what it is? So for now I'm going to ignore that use case; I think it can be worked around via sufficient UI effort.

Instead, I suggest that we let each item record define what categories the item falls into, and each item can be in as many or as few categories as it wants. Instead of having "type" and "subtype" we can just have "categories: ["general category", "specific category"]". For example:

Augmented Chain Mail: hard armor, body armor, augmented chain mail
Dagger: sword, sharp weapon, dagger
Halberd: polearm, sharp weapon, halberd
Potion of Cure Light Wounds: potion, cure light wounds, harmed by cold, harmed by shards
Staff of Cure Light Wounds: staff, cure light wounds, harmed by fire

Then the affix system can just say "I want to apply to all items that are the intersection of [body armor, hard armor] except for Brigandine", or whatever. I suspect it already does something fairly similar but operates on type and subtype instead.

And as you note, this kind of system is ideal for specifying what kinds of items can be damaged by elemental effects. Just query the player's inventory for items intersecting the category "harmed by X" and deal damage to them.

I think that about does it for now. Thoughts?

[Magnate]

Welcome to the Pyrel devteam.

Zippedidoodah!

[Derakon]

Question: Should a StatMod object contain the stat it affects? It seems strange to be creating a mod of "+3" that isn't tied to anything, and then adding that mod to, say, STR. Seems a disconnect compared to creating a mod of "+3", type "STR" (ie: a ring of str +3).

No real technical issues with either choice, just feels more awkward for the mod to not know what it's modifying, particularly for more complicated mods (eg: the ring that increases dex based on magic device skill, the vampire bonus from time of day, etc).

As a general rule, if an object doesn't need to know something, then it shouldn't know it. Otherwise you end up having values that you aren't really using, which means you aren't actively ensuring they remain accurate. If someone later comes to rely on them being accurate, they could accumulate bugs easily...

In any event, StatMods should only ever be accessed via Stats, and the Stats instance will know what statistic the StatMod is modifying. So the information is accessible, just not immediately at the point you're looking at.

Also noticed that the thing I thought was a bug wasn't a bug in the way I thought it was, but was still a bug in how it got constructed.

Seems you sort the mods by tier when they're added to a stats object (had missed that), so when you get stats they're already in proper order and shouldn't have the 1/3/2/3/1 problem ordering. However when you get all the mods to add up you also append all children stat objects - each of which will be sorted - but don't sort the combined list. That leaves the possibility of a list with tiers of [parent] 1/1/1/2/2/2 [child] 1/1/2/2. The tier 2s from the parent won't properly include the tier 1s from the child.

Fixed this by sorting the combined list before returning it, though it means extra code being run on every query. Maybe want to create a combined list that gets populated and sorted when adding children, or something.

Oop, good catch. Thanks! Functionally this means that getMod() will ignore child modifiers sometimes. Sorting the list in getAllStatModsFor() seems like a reasonable first pass; it'll fix the problem. If it turns out to be slow (as indicated by profiling) then we can optimize it later.

Wouldn't be so concerned if the uncompiled debug version wasn't so slooooooow. It takes over 20 seconds to load the initial window on an i7 CPU. Compiled version only takes about 3 seconds though, and optimizations aren't something to worry about at this stage anyway. Still annoying.

That's a bit painful. Eventual release versions of Pyrel can ship with precompiled code so the compiler doesn't have to do anything on first launch. Of course this doesn't have anything to do with deciding when to sort lists. It's just a matter of generating all those .pyc files.

Welcome to the Pyrel devteam.

[Kinematics]

Got Python working in Visual Studio, so now can do actual debugging.

Filed first bug in Bitbucket.

Redid the stats.py code. Very little actual change (and two of those changes are just renaming functions so that they make sense). Now I'm just trying to figure out how to create something that will test the functionality properly.


Question: Should a StatMod object contain the stat it affects? It seems strange to be creating a mod of "+3" that isn't tied to anything, and then adding that mod to, say, STR. Seems a disconnect compared to creating a mod of "+3", type "STR" (ie: a ring of str +3).

No real technical issues with either choice, just feels more awkward for the mod to not know what it's modifying, particularly for more complicated mods (eg: the ring that increases dex based on magic device skill, the vampire bonus from time of day, etc).



Also noticed that the thing I thought was a bug wasn't a bug in the way I thought it was, but was still a bug in how it got constructed.

Seems you sort the mods by tier when they're added to a stats object (had missed that), so when you get stats they're already in proper order and shouldn't have the 1/3/2/3/1 problem ordering. However when you get all the mods to add up you also append all children stat objects - each of which will be sorted - but don't sort the combined list. That leaves the possibility of a list with tiers of [parent] 1/1/1/2/2/2 [child] 1/1/2/2. The tier 2s from the parent won't properly include the tier 1s from the child.

Fixed this by sorting the combined list before returning it, though it means extra code being run on every query. Maybe want to create a combined list that gets populated and sorted when adding children, or something.

Wouldn't be so concerned if the uncompiled debug version wasn't so slooooooow. It takes over 20 seconds to load the initial window on an i7 CPU. Compiled version only takes about 3 seconds though, and optimizations aren't something to worry about at this stage anyway. Still annoying.

[Derakon]

Tiers are bound to StatMods. An overall Stats instance is, broadly speaking, a mapping of strings to lists of StatMods, which are sorted by tier. When you go to the Stats and ask "What is the value of the STR stat?", it looks up "STR" in its mapping, finds a list of StatMods, iterates over them in order by tier, and generates a value.

Stats themselves (as entries in that mapping) have no inherent tier. If a designer decides that they want to tier the stats, then that's up to them; just use one set of tiers for StatMods that apply to one set of stats, and another set of tiers for a different set of StatMods that apply to a different set of stats.

I'm glad to have more eyes looking at the code. Let me know if you have any questions. You might consider joining the #angband-dev IRC channel on freenode.net, too.

[Kinematics]

Ok, tiering as a means of restricting circular references didn't make sense, but tiering as a means of ordering arithmatic operations does.

These seem to be equivalent to me. Is that what you're trying to say?

No, they're not equivalent. Ordering operations is whether 1 + 2 * 3 is equal to 7 or 9; essentially, the ability to add parentheses to the calculations. Circular references is an algorithmic issue separate of that. Ordering can influence circular references, but circular references have no bearing on arithmatic order.

For what it's worth, the only reason that additive and multiplier mods exist as separate things from proc-based mods is because I expect that they will be the profound majority of modifiers in the game, to the extent that it's worth having some "syntactic sugar" to support them. You could do everything through Procs, but it would make the data files needlessly wordy. My expectation is that each StatMod instance will only do one of add, multiply, or "trigger" (as you put it).

Yep, makes sense.

I could see that being potentially helpful, yes. It could be done by having the Stats instance maintain a mapping of categories to lists of stat modifiers. Of course now every stat must have a descriptive category attached to it in addition to a tier**, or else the lookup table is useless. But if you're going to co-opt the tiering system to categorize modifiers then you might as well use strings anyway.

** Do you mean stat mod? (though yes, each one would need both a tier and a category)

EG: A ring of +10 Str and a ring of +20% str can have different tiers, correct? They're not forced to the same tier simply because both work on Str, or both are permanent effects, right?

Though going back to your earlier example, it seems like you are still binding tiers to stats, which is why you'd have to create an entire duplicate set of stats to handle multiplication.

If tiers are bound to mods, the filtering is trivial; just perform a list comprehension/filter on a given stat's collection of mods. However if tiers are bound to stats, you'd have to get not only the stat you're working on, but all variants on that stat that were created to handle the artificial tiering.



As an aside, I finally got the whole python environment installed and working, so I'll be able to play around with things a bit more directly, as I have time.

[Derakon]

The primary sticking point still seems to be the multipliers, though. Should multipliers affect values on the same tier, or only tiers below?

As written, a given tier can only consider tiers of strictly lower value when calculating itself, since otherwise circular dependencies can result (assuming you don't use some other method to avoid them). As you noted, you can always just stick multiplier mods on a higher tier than additive mods.

For what it's worth, the only reason that additive and multiplier mods exist as separate things from proc-based mods is because I expect that they will be the profound majority of modifiers in the game, to the extent that it's worth having some "syntactic sugar" to support them. You could do everything through Procs, but it would make the data files needlessly wordy. My expectation is that each StatMod instance will only do one of add, multiply, or "trigger" (as you put it).

(Also: can a trigger call produce a multiplier instead of an add? Probably doesn't need to, though, since it's given curVal as a parameter, which -should- include the total from all lower tiers (aside from the possible bug), so any multiplication can be done internally.)

Exactly. If you want to produce a multiplier in a proc, then you just calculate what the additive effect of the multiplier would be, and return that instead. Ultimately all stat mods are additive; there's just different rules for how the addition is performed.

I think the ability to query for mod types (separate from tier name) would still be useful (eg: affect all temporary buffs on tier 1; double all racial bonuses; etc).

I could see that being potentially helpful, yes. It could be done by having the Stats instance maintain a mapping of categories to lists of stat modifiers. Of course now every stat must have a descriptive category attached to it in addition to a tier, or else the lookup table is useless. But if you're going to co-opt the tiering system to categorize modifiers then you might as well use strings anyway.

I guess my bottom line on all of this is that I'm a bit tired of working on stats (I'm also a bit tired, period -- I didn't sleep well last night). If someone is willing to take on the work to implement a better system (and can convince me that it's truly better) then they're welcome to do so, but I'm not about to tackle it myself; I have bigger fish to fry.

[fizzix]

Ok, tiering as a means of restricting circular references didn't make sense, but tiering as a means of ordering arithmatic operations does.

These seem to be equivalent to me. Is that what you're trying to say?

When I'm thinking of stat systems, the one thing I'm looking at is game balance. Game balance is much easier if you only have additive values. However, you can get much richer results with both additive and multiplicative bonuses. Unfortunately this makes calculations harder for the game-player as well.

Of course pyrel should support both. But the worry is somewhat mitigated by the fact that these are so damn hard to get right from the design perspective that most designers are likely to only choose additive values.

[Kinematics]

Ah, ok. fizzix shows two additional use cases for me.


Case 5) A temporary effect that increases a stat by 20%, but only base and gear totals; it doesn't modify or get modified by other temporary effects. This would be well-suited for a tiered system.

Case 6) A temporary effect that increases a stat by a fixed value (eg: str +10), but that isn't affected by other multipliers (either in gear or other temporary effects). This would also be very well suited for a tiered system.

Each of those could be done with a non-tiered queryable system, but it would be a bit of extra work (sort of like the extra work you described for handling my example). The value of the tiering would be in being able to prevent certain types of mods from affecting each other.

The next implied question would be, is the default use case to want to prevent certain mods from affecting each other, or is the default use case that all mods should be treated equally? For either choice, doing the other will be a bit more work, so which approach will likely be less extra work for the majority of designs?


So tiering would allow for

(A + b) * c + d

or even

((A + b) * c + d) * e + f

and so forth.


What I was suggesting would only (by default) allow for

(A + b) * c



So, for example, the Vampire bonus -- supposing its intended design is that the nighttime bonus a vampire gets is outside of any multipliers gear might provide. Having a ring of +20% str would not increase a nighttime bonus from +10 to +12. -That- makes sense for a tiering system.

The primary sticking point still seems to be the multipliers, though. Should multipliers affect values on the same tier, or only tiers below? (Also: can a trigger call produce a multiplier instead of an add? Probably doesn't need to, though, since it's given curVal as a parameter, which -should- include the total from all lower tiers (aside from the possible bug), so any multiplication can be done internally.)

As long as you can define a mod's tier per item/effect/etc, then the designer can enforce a particular type of ordering. Leaving it as is, with multiplies only affecting tiers below, simply means you need to segregate tiers in the same way. If you simply make all adds Type 1 by default, and all multiplies Type 2 by default, then most operations would proceed normally. You could also add a vampire bonus that's Type 2, and thus outside most normal multipliers.


Ok, tiering as a means of restricting circular references didn't make sense, but tiering as a means of ordering arithmatic operations does.

I think the ability to query for mod types (separate from tier name) would still be useful (eg: affect all temporary buffs on tier 1; double all racial bonuses; etc). And the handling of recursive blocking could still be done such that you don't need to enforce a dependency chain.

[fizzix]

Ah the great fuzzy space where simplicity runs up into possibility. I'm a fan of simplicity even if it presents access to some possibilities. Now, I think Derakon's opinion is that it's fine for the game designer to impose such restrictions, but the engine need not do that. And I guess that's ok, but you then do run into the problem of an engine being forced to support all sorts of crazy schemes, many of which, no sane designer should ever choose (i.e. circular dependencies.)

I'm also a little behind on the discussion, so I can't remember whether these things have already been said. Anyway.

All stats can support the following modifiers.

Addition to base stat.
Multiplication to base stat + additions to 1
Addition to stat.

Obviously adding to the base stat is the most important, and that's probably what you'd get with potions. Your final result would be,

(STR + base stat mod) * multiplicative mod + stat addition.

For derived stats it works the same except the initial value is derived from the top tier stats, and then all the base modifiers.

The only difficulty is that the player needs to understand the difference between base modifiers and normal modifiers. If that seems like a subtlety you don't want to require, it's easy to change by forcing all modifiers to be either base modifiers or post-multiplication modifiers.

[Kinematics]

First: sorry for the length, but it takes a bit to go through all the points, and I want to make sure that each one is clear. If I'm completely out in left field on this analysis, smack me and send me to my room.

This is true until you decide to add a modifier that can't be easily expressed by addition or multiplication. A StatMod can invoke a Proc to generate a value based on whatever it likes, including e.g. distance from something on a map (grunts getting a morale bonus when close to their leaders), items in inventory (taking a speed penalty because you're carrying heavy stuff), time of day (vampires get bonuses at night), etc. All of these could scale in very weird ways if that's the way the designer wants to run things.

Hmm. I'm not sure I get what you mean here. Each of those effects -depend- on non-integral information, but will any of them ever -generate- non-integral (or at least floating point) information? And how does tiering make those possible where non-tiering would not? (Note: Please answer this; it's not a rhetorical question.)

[Aside: Ah, I see you actually have 3 modifiers per mod: an addition, a multiplication, and a trigger (the results of which are added). I've been thinking of things as solely having a trigger value, though hoisting the addition/multiplication for trivial needs makes things simpler for most cases. However it does leave out the possibility of the trigger producing a multiplier that can apply only to totals that have not had multipliers applied, unless your tiers are explicitly separated between additive and multiplicative mods, which isn't something you can guarantee based on the code alone.]


EG: Time of day affects a vampire's strength. Ok, then maybe something like, every hour after dusk, til midnight, the str modifier increases by a non-linear amount (eg: +1 str, +3 str, +6 str, +10 str, +15 str, +25 str). You need to figure out the time of day, and the difference in time, maybe a lookup table, etc, but ultimately it all feeds back into a modification to str, which will only ever be an addition or multiplication (or maybe theoretically log or exponent, though those can largely be reduced to multiplications). That is, the final result of the StatMod function can only perform a simple value manipulation of the stat; you'll never modify the stat by the time itself because the combinations of those two values doesn't make sense (different units, can't combine).

Regardless, you'll never be returning a time value, or a distance value, or whatever. A function may need to know the distance from leader as a parameter, but it must eventually return an actual value that needs to be combined with the base value (eg: morale). None of that oddball stuff is a stat or stat mod, unless maybe you want to allow for dimensional-altering spells that change the distances between any two points (look up a pdf on hyperbolic space-time curvature as it relates to the Cthulhu Mythos for some fun reading). Even then, though, the alteration to the distance must still give you a value that you can use as a parameter, which means it itself is still subject to the same basic mathematical manipulations.

Pyrel's guiding principle for design is "If I can imagine use cases I might reasonably implement that require this feature, then it should be implemented." I'm not going to try to stretch the design to do everything under the sun -- it'd never be done, that way -- but I can easily imagine wanting to have complex stat modifier interactions. Stats form such a key part of the game; that makes them a good place to look to if you want to add interesting decisions.

I can absolutely agree with the general principal espoused here. What I disagree with is whether the tiering implementation actually serves that goal.

Basically, I cannot think of any sort of stat manipulation that cannot be expressed as either [stat += StatMod()] or [stat += stat * StatMod()] (though the aformentioned hyperbolic space-time might be a little tricky). Now, StatMod() itself can do all kinds of funky stuff, but that's completely isolated from the ultimate adjustment to the stat (at the level where tiers are in play), and any other stats that StatMod() references must themselves be constrained by those same limits.

The point of using tiers was so that you could be certain that if you needed information about a stat to make a calculation within a StatMod(), then that stat was completely calculated before attempting to use it. However recursion restriction gives you exactly that already. You just can't have a StatMod() that modifies itself, which is the same restriction that is required when using tiers.

So it doesn't seem that you *gain* anything with tiers except extra complexity.


Now, all that said, can I think of any way to make use of tiers that could not be done without them?

1) An effect (eg: pylon in the dungeon) that amplifies magical bonuses. In other words, it doesn't increase base stats, but instead gives a +50% potency to any magical enhancements. So if you had a +10 str spell on you, this would make it a +15 str spell, but a +10 str ring would stay +10.

Counterargument: The tiers wouldn't explicitly allow for this anyway. A modification at a higher level than temp effects would still also apply to every tier below it, so this bonus would affect gear and base stats as well. Instead you'd need a query that gave you all the current temporary effect bonuses. At that point you can take 50% of that value and return it to be added to the stat, but then tiers become irrelevant, as the query would be of a certain 'type' of StatMod.

One could, perhaps, have a modifier that explicitly applies to each effect itself (and thus could apply to only temporary effect), but it would be difficult to have a common reference that would be universally workable, and it would require each effect to be aware of the possibility and code that into its own inner workings. Seems fragile.


2) Same thing, but only affecting base stats, not gear or temp effects. In that case tiering works. However this is really just a special case of the general desire to "affect only the stats on a particular tier" (and fails on any except the lowest tier), which can just as easily be described as "affect only the stat mods of this 'type'" (which would work for any defined type, even if those types are effectively just tiers, if such a query was available).


3) An effect that requires a minimum value before a bonus is given, and that excludes a certain class of other bonuses (eg: no magic bonuses, or no gear). In that case, tiering would work better because you want to exclude a set of bonuses, which means you need to have knowledge of all possible bonus types except the one you want to exclude if you wanted to use the query method (though it wouldn't be too difficult to instead say "get All mods; remove type 'x' mods from this list").


4) Vampire at night gets a 50% bonus to all gear mods, one of which is a ring that increases Int based on Magic Device Skill (which itself depends on Int). So now, what's the value of Int?

Tiered: can't get just all gear effects, but assuming we take all effects underneath 'temporary' (thus, base+gear) the 50% multiplier is straightforward, if not exactly what we wanted. However the ring just won't work because of the tiering -- either MDS is above Int, or Int is above MDS, and can't have both at the same time.

Non-tiered: Query for all gear effects means that aspect is simple. Ring requires MDS, which requires Int, which requires both the ring and the Vampire bonus. Recursion block means that MDS is calculated without the ring's Int bonus, but with the Vampire bonus for the remaining gear. After that the ring bonus is returned, and the Vampire bonus is calculated again on -all- of the gear. Leads to a lot of duplicate calls, which could be mildly annoying if this were to occur on, say, Searching, where you're likely to repeat the call very frequently, and had lots of effects with complicated computations. However it gives us a consistent, 'mostly' correct answer every time.



aside #2) My redirection of everything to a query of type is in large part simply a renaming of the existing 'tier' value -- you still need some means of isolating classes of mods, and just because I say tiers aren't necessary doesn't mean that part of their potential use isn't necessary. However a query on type has freedom to choose any arbitrary mod class at any given time, whereas tiers can necessarily only know about lower tiers (unless you keep adding higher tiers, but then you run into the "turtles all the way down" problem).



aside #3) I left it out of my earlier post to try to keep things simple, but wanted to be clear about the issue of inconsistent values.

Any time you combine multiplied values in a tiered system, you necessarily introduce the possibility that adding exactly the same two stat mods can give different results, simply due to the fact that they are applied on different tiers. EG:

Base str: 100

Ring +10 str & Ring +20% str = 130 str (due to them being on the same tier)
Ring +20% str & Spell +10 str = 130 str
Ring +10 str & Spell +20% str = 132 str !

Also:
Ring +20% str & Ring +20% str = 140 str
Spell +20% str & Spell +20% str = 140 str
Ring +20% str & Spell +20% str = 144 str !

This inconsistency may eventually lead to issues with difficulty in balancing the game, or potential exploits due to spell/gear combinations that yield values outside expectations.


If I'm significantly misreading the behavior of the code, let me know.

[Derakon]

There's really only two necessary operations: unit-based addition (the value is concrete), and unitless multiplication (the value depends on the existing value, and can only be applied after all the concrete values are added in). One might argue the option of multiplying all of the the unitless values together vs adding them together before multiplying by the total (I'd suggest the latter); otherwise I'd expect completely agnostic calculations.

This is true until you decide to add a modifier that can't be easily expressed by addition or multiplication. A StatMod can invoke a Proc to generate a value based on whatever it likes, including e.g. distance from something on a map (grunts getting a morale bonus when close to their leaders), items in inventory (taking a speed penalty because you're carrying heavy stuff), time of day (vampires get bonuses at night), etc. All of these could scale in very weird ways if that's the way the designer wants to run things.

Pyrel's guiding principle for design is "If I can imagine use cases I might reasonably implement that require this feature, then it should be implemented." I'm not going to try to stretch the design to do everything under the sun -- it'd never be done, that way -- but I can easily imagine wanting to have complex stat modifier interactions. Stats form such a key part of the game; that makes them a good place to look to if you want to add interesting decisions.

For what it's worth, if you want to have additive and multiplicative modifiers as separate things, then you can add a new stat that all the multipliers add to, and then attach a low-priority modifier to the base stat that incorporates the multipliers. E.g. have a "STR Multiplier" stat which receives additive modifiers, and then have a multiplicative modifier on STR that uses 1 + the "STR Multiplier" value. This is kind of indirect, but it gets the job done just fine.

[Kinematics]

"Inherent", "permanent", "temporary", etc. tiers may or may not make sense depending on what the designer wants to do, but they clearly won't fit every possible design.

Been going over the code more. I -think- it's generic enough that my thoughts could be represented with the framework.

If I'm reading it correctly, each mod can set its own tier? That is, individual stats aren't given tiers, just the mods, so the tier isn't dependent on what stat is being calculated?

So, I could have a Ring +3 str on the Add (first) tier, and a Ring +20% str on the Multiply (second) tier, and generally define all stats and mods with respect to just those two tiers?

Possible bug: Not sure, but it looks like if the mods are listed out of order with respect to tier (eg: a queue of tier 1, tier 3, tier 2, tier 3, tier 1, etc) that the results would be unpredictable (specifically, if there are any multiplications in the queue).

Also, I think you preempt the recursive calls too early, and too completely. Basically, rather than blocking recursion at the stat level, it should be blocked at the mod level. Would require mods to be copied by reference rather than generating multiple instances of them, so that local state has meaning, but then you can just have ~~

    if (!blocked) then
      blocked = true
      get proc value
      blocked = false
      return value
    else
      return 0

Or use whatever atomic lock operations you want, though it shouldn't matter if you're not doing multi-threading.

Honestly, I still think the tiers are a bad idea. The same operation on a different tier can give a different result, which means a single effect (eg: +20% str) can't be relied on to produce consistent values if applied at different tiers. Plus they don't actually add anything of value; their entire purpose of stopping circular calculations can be handled by simply blocking the recursion.

There's really only two necessary operations: unit-based addition (the value is concrete), and unitless multiplication (the value depends on the existing value, and can only be applied after all the concrete values are added in). One might argue the option of multiplying all of the the unitless values together vs adding them together before multiplying by the total (I'd suggest the latter); otherwise I'd expect completely agnostic calculations.