Expanding upon the proper relationships of your atoms, ¬( A ⇒ B )

In a previous post we declared that if some thing, A, implies to some other thing, B, and if nothing else implies B, and A implies nothing else, then we have a serious design flaw. That is to say if ( A ⇒ B ), then we should omit one entirely and only work with the other.

This is not the only thing worth understanding. There are two other rules which one should bear in mind when designing a proper Mud. The following are simultaneoously true at all times for any properly designed Mud:

1. ( A → B ) ⇒ ( A ∨ B )
2. ( A ∧ B ) ⇒ C
3. A ⇒ { B, C, …, ℵ_∞, … }

The first equation, which we've seen before, tells us that if a thing, B, has one and only one antecedent, A, and A does not give rise to anything else, then A must be removed to leave B to stand on its own. To recycle the earlier example, if you were to design an attribute Endurance to give rise to some other attribute, Health, and Endurance didn't do anything else and Health didn't depend on anything else, then Endurance should be dropped. This is beause, in essence, Endurance doesn't actually exist; all we have is Health.

The second equation tells us that if we include some attribute or mechanic C, then it must be based on two or more other things. The players in your Mud might experience locked doors, and they may not be able to pick the locks. Could they force the door open by brute strength? You might be tempted to include a ``break doors'' attribute. Should strength matter? Should the bookworm have just as good a chance at smashing a door into splinters as the burly barbarian? If you say yes, then you have the dangerous ground of equation #1. The easy resolution is to skip the ``break doors'' attribute and just base everything directly on Strength. However, you might also want a character's level to matter as well. High level characters are natually better at breaking doors because of their vast experience in the art. This is fine, and we can then restore the ``break doors'' attribute, because now it is based on two or more other attributes, ( stregnth ∧ level ) ⇒ breakDoors.

The last equation states that if an attribute exists, it may be self-supporting, such as Health in the first example, or it must support two or more other attributes; it cannot support just one. So Health can exist on it's own and Endurance discarded, unless we find further use for Endurance. To give an obvious example, Strength would not only impact the ``break doors'' attribute but also impact meleeDamage attribute, and the encumberance attribute, and so forth.

Applying equation #3 is often the trickiest part of design. We designers are often quite eager to add more and more stuff, so we seldom have a trouble with multi-purposing these Attributes. This gives rise to the very real problem of adding an attribute just for the sake of justifying some other attribute, which perhaps ought to have been left out completely. For example, maybe you really really really want to give characters different maximum running speeds. This is great and fine, and perhaps you want Strength to modify on the assumption that strong leg muscles make for faster people. However this would violate equation #1 so you, grasping at straws, invent some other attribute to satisfy equation #2, which then leaves you in a lurch regarding equation #3, because this new attribute can't exist to support only one thing because violates #1, but you're notion is so specific you can't see how it applies to anything else. You would be better off making Speed a base attribute rather than an implied attribute.