Allowing a player to circumvent a bad effect by gaining a weaker effect of the same kind is clearly a problem.

Directly modifying the entity's stats is probably dangerous overall.  It seems games tend to have a "base" stat and a "current" stat, the latter being a throw-away-value that is recalculated from scratch as needed.  IMO this should apply not only for numeric stats, but things like the "enabled" bools for senses as well.

As for stackable/non-stackable buffs:  there are situations where both are useful, even more so based on underlying game system where for instance, two strength-boosting spells may or may not be stackable.

One solution I see is building the application of effects in a way that both are possible and work together (but any given system might chose to use only one methodology).  What I'm thinking this would look like would be:

* All modifiable Sats and Senses values will all gain a "current" value like Senses[SensoryType.Hearing].currentlyEnabled or Stats["strength"].currentValue.

* These will not be modified directly by random code;  they will be recalculated at specific times to determine what the current value should be.  For instance, when a StatEffect is added or removed from an entity, the StatsManager would iterate through the entity's current list of effects, looking for StatEffects, and recalculating the current value of each stat.  Same thing for the SenseManger recalculating the current senses whenever a sensory effect is added/removed. (Aside: generalize SensoryEffect instead of just DeafEffect etc?)

* The managers' recalculation methods would also be called any time the Real values change; such as stats gained permanently via levelling up.

* During the iteration of effects, the total modifiers would be tracked independently for 4 categories: 

-- highest positive modifier for non-stacking effects (ie the biggest "str boost" spell)

-- lowest negative modifier for non-stacking effects (ie the worst "str sapping" spell)

-- total accumulation of stackable postive effects (ie a handful of different "str boost" effects)

-- total accumulation of stackable negative effects (ie a handful of different "str sapping" effects)

* Current value = Real value + MAX(the "highest positive non-stacking", "total accumulation of stacking")... thus we are treating all stacking effects as one accumulated effect for purposes of seeing if it overrides a non-stacking effect, in the event of there being both kinds of modifiers in this game system.

* Note that this totally removes the awkward "reduce the modifier to the biggest modifier it can be without setting the stat above the maximum" code since the post-recalculation would just set the "current" equal to max if it was greater than max.  Ditto for enforcing minimums.  This also totally fixes bugs that would have otherwise occurred around adding/removing effects in succession near the maximums and minimums.

Did I explain that well?  Does that seem viable?

~ Karak

Just as an aside, as it is now, TickElapsed in the Effects is when the effect wears off.  It is not a regular heartbeat.

I'm having to play around making a DOT poison effect with the TickElapsed calling the same class's Apply method.  Kind of fun, but a seperate HeartBeat or Tick would be nice. :)

Without knowing how the whole thing works, I was afraid of making it a generalized effect.

A deaf and a blind might stack, but two SensoryEffects might not.  Also, bit arraying them together makes more code - which isn't needed until the design is all finalized. 

It'll be easy once this system gets finalized to condense it all down to one if there is no reason to have them apart.

But, without more work, an eyedrop item that cures blindness, might also cure the deaf if they're just one general effect.

Good idea, I'll make a SensoryEffect and then inherit from that.  Perhaps a StatChangeEffect that is inherited will be a good idea too?  StatChangeEffect -> IntModifier.

I'm wasn't thinking along the lines of a new effect that does 3 seperate things, but of an item that applies 3 seperate effects.  So, we're in agreement on that.  In the end, we probably only need a handful of effects that do all we need.

But, my question still stands with this further clarification. :)