The MUD Development forum.
Game Development Discussion, Chat, Technical Debate, and people who just love games talking about building worlds.

Home » Hosted Mud Projects » Wheelmud » General » The relationship of Effects to Behaviors - WheelMUD - A C# MUD Server - Forums - WheelMUD - Design
The relationship of Effects to Behaviors - WheelMUD - A C# MUD Server - Forums - WheelMUD - Design [message #453] Sun, 22 March 2015 11:43
Karak is currently offline  Karak
Messages: 489
Registered: March 2015
Location: Seattle, WA
Senior Member
This thread originates from prior WheelMUD forum software archives. It has been migrated here to preserve the contents.

Post by Karak (03 May 2012 03:36 AM):
Basically the line I see between the two is solely of expected duration. I think that Effects will be coded basically the same as comparable Behaviors, but an Effect will have some expiration, and maybe be targetable by 'dispel' spells, etc. I think it's clear that an Effect alters behavior in pretty much the same way as a Behavior alters behavior, and that both sources must be considered simultaneously when thinking of the "final, actual state" of a Thing.
Further, there are probably many cases where a coder will want something implemented as a Behavior to also be implemented as an Effect, or vice versa. For example, suppose we have an admin command that places a permanent MutedBehavior on a player. Then a world coder adds a "mute" spell with a MutedEffect and basically copies and pastes the behavior into an effect, but adds the self-expiring timer code. Should they instead be able to inherit from MutedBehavior and add the expiring logic, instead of doing copy pasting (obviously bad in general)?
Another example might be an AlterLimbsBehavior which is permanently attached to races which have more than two arms, but then a spell is added which sprouts a new, temporary magic limb on the player (via an AlterLimbsEffect). I can see this being a recurring theme. I think not only must Effects and Behaviors co-exist together, but I think we should change from using a base Effect class to using an IEffect which just designates that a given varient of a behavior is also considered a less permanent effect. IE:
public abstract class Behavior : IPersistsWithPlayer
public interface IEffect { ... maybe require a duration property... }
public class MutedBehavior : Behavior
public class MutedEffect : MutedBehavior, IEffect { ... has a duration property and adds expiration logic ... }

Post by Karak (03 May 2012 03:52 AM):
There are also benefits to housing these similar class instance all in one place, the BehaviorManager. It allows for various powerful querying to be done in a much simpler manner than having to union results between multiple managers... and supports easiness in all the related scenarios I can think of off the top of my head.

Suppose for an inventory/paperdoll system, we choose to scan for all alterations of the number of limbs available (either to determine how many arms we have to display on the paperdoll, or determine if we have a free hand to wield the targeted sword, and so on). Ideally for this scenario we just query the BehaviorManager for all instances of AlterLimbsEffects and add up how many extra/lost arms the player has across all those. This single query correctly picks up both the permanent (perhaps racial) Behavior and any spell Effects which stack up, due to the inheritence. Another common result may be having to add up all of some sort of AltersStatEffects (from spell buffs/debuffs and such) and AltersStatBehaviors (from permanent racial modifiers and such).

Suppose we want to find all magical effects for a 'dispel' spell to target: we just query the BehaviorManager for any IEffect instances it has.

Suppose we have a spell that specifically fixes limb alteration effects: we just query the BehaviorManager for any AltersLimbsEffects it has.

Since Behaviors are not as prone to on-the-fly adding/removal, I can't think of where we'd want to target the Behavior and not the Effect, from an external source. So fortunately that rare case is the one that gets a touch more complicated instead of less, which is thus the right place to add the complexity: one would query for the Behaviors, then exclude any that are also of IEffect. (LINQ can do this pretty easy of course.Wink

Post by Fastalanasa (03 May 2012 11:57 AM):
Makes sense to have Effects being derived from Behaviors. Now, to make things a tad more discoverable, I propose that we rename BehaviorManager to something like BehaviorAndEffectManager, BehaviorEffectManager, or something like it.

Post by Karak (03 May 2012 10:43 PM):
I can live with that Smile
Previous Topic: Order from Chaos - Documenting our API - WheelMUD - A C# MUD Server - Forums - WheelMUD - Design
Next Topic: Persisting PlayerBehavior - WheelMUD - A C# MUD Server - Forums - WheelMUD - Bug Reports
Goto Forum:

Current Time: Thu Nov 23 08:53:18 PST 2017