Rules Engine Replacement

[DavidRieman]

The rules engine we used was based on old, retired code from codeplex (http://rulesengine.codeplex.com) that doesn't appear to have migrated anywhere AFAICT.

The old Rules engine ended up having to be ripped out for the latest major WheelMUD upgrades. In addition, the way it was built was pretty dangerous. For example, they were making permanent modifications to core player stats and such, trusting that removal of said objects would always correctly deprecate them, and that a player would never find a way to get these modifications to occur additionally. Actually it may already have been stacking extra changes every time you logged in too!

We may want to consider if it will be worthwhile to seek a suitable replacement to serve similar needs. If so, some desirable traits may be:

• More actively developed/maintained/used.
• Capable of taking back improvements.
• Housed in NuGet or something.
• Simple to use.
• Simple to debug.

However, perhaps handling stats/attributes/etc should occur with a specific set of classes and API that doesn't actually need such a deep rules engine? IMO we can cover the needs with actual, directly-debuggable C# classes.
One design for a replacement system that comes to mind is a system where we have loaded/attached class instances register into collections of "active" stat-modifying class instances.

Some specific details and implementation ideas:

• We would only add the class to the list if it is not already in the list, to help prevent abuse/bugs.
• This would not be a persisted list; it would be on the class to attach itself properly (in a similar pattern to behaviors attaching to the relevant requests/events they care about) upon (re)attach to a Thing.
• This could be a separate list for each unique stat, so we can efficiently iterate just the relevant active ones.
• This could apply for Effects as well as Talents or other game-specific mechanisms. For example, say a spell Effect reduces your strength by 10: It can register itself in the strength-modifiers
• The effects registered could require a priority rating, so that a game system could implement "order of operations" like having additions/subtractions occur before percentage based changes, or vice versa, or some mix of whatever they prefer.
• When an effect expires and disposes, it would remove itself from the list. Game systems that want a "fresh casting" to replace an old one can opt to do so by having the new instance interact with the old one to refresh it's expiration or whatever. Game systems that want a "stacking" can similarly do so by letting multiple instances of the same type attach. (Though one instance should never be in the list more than once.)
• Permanent character traits (like WRM Talents) would plainly attach themselves in the stat modifying lists (potentially being multiple lists for talents with multiple effects) each time the character loads (and remove themselves if removed, to keep to a solid pattern even if we don't expect removal of such a permanent character trait to happen in practice).
• For starting simplicity, instead of trying to model "rules" and "formulas" and such for arguably negligible or even negative performance change - we can start by having these classes implement a simple interface saying they need to have a function which takes the starting value, and returns the modified value. (Recent years of C# syntax improvements may allow us to define these in a pretty elegant and brief way anyways, especially for simple things like additions or scaling multipliers.)