Depth in rules systems (engineered complexity)

You often hear RPG fans discussing titles and either lauding a title for great depth or deriding another for a lack of depth.  What is depth?  In the terms of rules systems, what the user perceives as “depth” is a level of complexity to the rules which require some effort to understand.  Titles which lack depth typically have simple rules and are easy to understand, but at the same time are very limited in reach and scope.  Titles which have depth exhibit reward for learning the rules and engaging in strategic use of abilities or actions to gain advantage in the game.  I’ve personally been involved in the “interpretation” of a pen and paper rules system into a real-time computer combat rules system.  This was not a trivial exercise, as the rules were complex and inter-related.  The end result was a high degree of perceived depth, but at a very high cost in implementation.  Our approach was to reduce the rules system into as many simple atomic actions as possible and then develop a structure to process those atomic action elements accordingly.  This did force us to “interpret” a few spells in a slightly different manner than described, but as a whole we felt we maintained the integrity of the rules.


If you think in game rules as how a computer would treat the interaction of the rules, you can better understand the issues.  Imagine a case where you have fire based spell and it does a 5 hp of damage to the target.  But, if the target has an item which grants protection against fire, the character takes no damage.  This is easy enough to describe, but from a programmatic standpoint it requires more thought.  If there is only ever one fire spell in the game it is easy enough to implement.  If the fire effects are many, it makes sense to order the rules into a logical flow.  In the fire spell example, I would create a spell item which assigns a “fire damage effect” to the target player.  The effect is evaluated at the player object during the rules arbitration.  Given that the player has a protection item, the effect is checked against a list of character effects, such as fire immunity.  As such, the fire damage effect is dismissed and never applied.  This simple effect and modifier stack allows us to model great rules complexity, but allows us to keep the mechanics very simple.  We have a series of simple systems interacting to deliver complex behavior.  The effect evaluation stack was a key component in the design of Neverwinter Nights and other Bioware RPG’s as it allowed us to take somewhat arbitrary rules and classify them and have them behave as part of a system.  This is also the reason we did not implement certain spells and abilities, as they did not fit into a systemic approach and as such would have added greatly to the complexity of the system in unstable ways.


The evaluation stack also allowed us to systemically support timed events, temporary effects and a whole host of other complex interactions without going mad.  Consider a temporary fire protection potion, it applies an effect to the player which is set to exhaust in four turns.  When fire is going to be applied, it is evaluated against the protection effects active and is ignored.  When the fire protection expires, it is removed from the stack and the fire effect damage is applied normally.  This schema allows for a great deal of complex interaction modeling without having to go in an custom code each individual spell.


If you are creating a rules system from the ground up, I would put forward this atomic element approach as you can engineer a great deal of predictable, yet complex behavior from simple interacting elements.  If you attempt to add complexity from the top down, without a simple underlying system to handle them, you quickly create an unpredictable and very hard to test monster of complexity.