(from D3 forums, MVP post)
Now this is a very complicated thing to address, but I feel many people here really do not understand what the difference between complexity and depth is. I will try my best to try and help people understand the difference in the hope that they may keep these things in mind when making suggestions.
I'm not going to draw any parallelisms from any previous Blizzard game or Diablo itself, but the examples I provide should be good enough to explain these concepts in a way that's easy to understand.
Trying to understand Complexity
One of the biggest mistakes people tend to make when trying to understand depth is when they look back at a game and think "That was pretty difficult to understand, therefore it has depth."
While depth can certainly lead to such an experience, depth isn't always directly tied to how complicated something is to understand.
Depth and Complexity go hand in hand, and making a game more complex isn't necessarily a bad thing, but when you make it more complex without adding depth all you have done is detracted from what depth may already be there.
The best way to visualize this concept is with a swimming pool. Complexity would be akin to expanding the surface of the water and stretching it out. It can be a very shallow pool lacking in any real depth, but there's a lot of surface there. In this situation, you have introduced a lot of rules and core concepts to your game that each requires you to understand how they work before you can start playing.
Depth on the other hand is taking that swimming pool and instead of creating more volume by stretching the surface, you make the pool deeper so that there's much more there under the surface. You create more volume by taking what's already there and expanding on those simpler concepts. In this case, the game might be easier to understand the basics, but then you turn those basic concepts into advanced concepts by adding depth to the gameplay.
Now in both circumstances, you can actually have the same volume of water, but the surface is much easier to understand (being that there's less of it there) so you can start playing the game almost immediately.
Tutorials: How easy is this concept to understand?
One of the biggest mistakes a developer can make with a new game is to make a game require advanced research and understanding before you can even begin to start playing. In other words, if you can't make a tutorial that could be understood in about 10 minutes of time, or you can't design a starting level that teaches you most of the game's concepts in bite sized pieces then you will probably never get enough people to even try to play your game without getting frustrated. You can have thousands of concepts, and you may have tons of depth by expanding on each and every one of those concepts, but if it comes to a point where I have to read a manual before I can play then there's probably too much complexity.
Let's think back on the "bite sized pieces" concept.
Let's say that I'm designing a table top strategy game. One of the first things I'll need to know how to do is how to move my character.
In its simplest form, I would allow someone to roll a dice then they move their character the number of spaces that are possible to roll. If I roll a 6, then I move 6 spaces. If I roll a 1, then I move 1 space. So on and so forth.
But what if I decided it was a good idea to instead require that player to calculate something like resources, maximum travel distance, stamina, and health. I also decide to use a D20 dice to move this unit around.
Let's say I came up with some crazy rules for moving around a unit that I have to take the roll, then reduce the number by a percentage of the stamina left on the unit, then reduce the stamina by one, then make the unit move 20% of the distance if they're under 10% health, they have a maximum travel distance of 7, and they need to have at least 2 stamina or they must skip a turn consuming a ration to regain both health and stamina.
Now that's a crazy amount of rules and it mimics real life somewhat, but is all of that complexity even adding anything? I've introduced 5 rules that are involved with moving alone. I shudder to think of what combat would be like.
So let's go over a few things that are involved with movement.
1) I have to understand what my resources are (In this case rations) and keep track of them.
2) I have to understand what stamina is and what rules are involved with depleting it.
3) I have to keep track of my health.
I can't just look at this situation and understand movement as a concept alone. I must first understand resources, health, stamina, and maximum travel distances.
Now what if there's complicated rules involved with stamina? If a unit stands still for a turn, they gain 1 point of stamina, but if they're attacked, their stamina is reduced by 2. yadda yadda yadda.
While there may be depth there to all of the individual systems, in order to understand how to just move the unit I must understand all of the complicated rules involved with all of those other systems.
This is a perfect example of unnecessary complication. Having a game that's easy to understand through just playing it is called conveyance, and is probably one of the most important factors in getting your game in the hands of as many people as you can. If nobody can understand or wants to play your game, what's the point of its existence?
Which path do I choose?
One of the other great things that depth can do for a game is to give you multiple paths to choose that you can follow.
Meaningful choices in one place, may influence choices elsewhere.
For example, if I'm playing a character in an RPG and I am being presented with a choice between the classic archetypes of Tank, Healer, or Damage Dealer.
If I decide that I want to play the role of a Tank, this will influence how I play my character down the road. My goal or main directive might be to protect those who are in my party, while the main goal or directive of other characters may be to Heal me as I take that damage, while the Damage Dealers whittle down the health pool of my enemy.
If I make a conscious decision to play as a Healer, I'm probably not going to want to soak damage. If I die, then I can no longer heal the rest of my party.
Likewise if I'm a Damage Dealer, I'm not going to spend my time Healing other people. If I run out of mana, I will likely never be able to kill the enemy in a reasonable amount of time.
This is just a very basic example of how a small choice at one point may influence your playstyle later. These 3 archetypes synergize with each other very well, but each one has a different style of play associated with it depending on the choice you have made early on.
Meaningful Choices vs Permanence
Now to many people, when they consider a choice to be meaningful, they often associate it with permanence.
Now, permanence isn't always set in stone. It doesn't have to be "permanent" by any meaning of the word, but rather in order for a choice to be meaningful it can't be changed on the fly.
Going back to the previous example regarding the classic archetypes, if I were to make a conscious choice to play as a Tank, in order for that choice to actually matter I can't just change it up mid combat.
If suddenly during the middle of combat I can drop my guard and start stabbing things to death, then the conscious decision to become a Tank archetype doesn't really matter.
However, that doesn't mean that I always have to live with that choice and this is where varying degrees of permanence come into play.
Let's say that I not only have to decide to be a tank class (Like say a Warrior or Paladin) but I have to build my spells around defense, and in addition gear with defensive attributes like Dodge or Extra Armor. In this case, I have added 3 layers of permanence (2 really if you allow that class to perform multiple roles) into my choice to become a tanking archetype.
Now let's say that it's possible for a Warrior to become a Damage Dealer, and a Paladin to become a Healer. In order to change my playstyle I have to change what kind of spells I'm using and I have to gear in a different way. My choice to play as a tank isn't permanent, but it still has permanence which makes the choice between the archetypes actually mean something. However, I am not punished at the same time for making a choice that I wasn't happy with as I can change my spells and find new and different gear over time.
Permanence is probably one of the most prominent factors in making choices that are meaningful.
Expanding on Existing Concepts vs Adding New Concepts
One of the largest factors in designing depth in a game is through expanding on what already exists rather than adding new rulesets.
Let's say that I'm designing a real time strategy game.
I have a basic unit which I am going to refer to as a Drone. There are also other types of units in this which I will refer to as Commanders.
Now let's say a Drone has limited health pools, but a high attack. A Commander unit has a very low attack, but high health pools.
What if I built a relational layer between these two basic units.
If I have a Commander within 20 yards of a Drone, the Drone now deals Double Damage.
I have taken the complexity (The number of different unit types) and I have give them depth (The relationship that makes them behave in a new way when they work together)
Now let's say that if I have a basic Barracks, I can expend some resources to upgrade those Barracks into an Armory.
The Armory has Double the Durability of the Barracks, but the Armory replaces my Drone's guns with Flame Throwers that deal 50% more damage than the guns.
I now have 4 pieces that add complexity, but I have given them depth by allowing them to interact and create new relationships.
My Drones will now be equipped with Flame Throwers and still deal Double Damage when in the presence of a Commander unit. Thus, there's new depth and strategy to the game. If my enemy decides to focus fire on my Commander, my Drones will be weaker and easier to take out. I can also send out other units to destroy my enemy's Armory and take away their Flame Throwers.
Now what if I take away that relational model completely and instead just add new units.
I now have Drones, Flame Units, Elites, Barracks, Armory, and Commanders.
Drones are weak and deal basic damage.
Flame Units deal 50% more damage than Drones.
Elites deal Double Damage.
Barracks are weak unit producers.
Armories have double the health of Barracks but do the same thing.
Commanders have high health but low damage.
In this example, I have the same level of understanding required to play this game. However, there's no strategy anymore. It's basically just "Kill the other guy" and my game doesn't have any real depth.
It has the same volume of content as before, but there's no focal points of interest and no relational model between units. I still have the same amount of rules as I had before, but that's it. There's no real depth.
Complexity through Fragmentation; Depth through creating Layers
Now the previous example is what's known as "Complexity through fragmentation"
I had 2 basic units (The Drone and the Commander) and 1 basic resource unit (The Barracks) with 1 upgraded resource unit (The Armory)
Now, in order to create depth, I create relational layers between the units ; or if you will relational rule sets between units.
On the very top layer, I have my 2 units.
On a layer underneath that, I have my rule set that allows my Drone to deal Double Damage when in the presence of a Commander.
On another separate layer, I have the relationship between the Drone units and the upgrade Barracks (AKA Armory)
However, even though my game is a little bit more difficult to understand, if I take away the Commander and the Armory in a tutorial level, I am still left with a Drone unit that will teach you how to play the game.
What I did in the later example was I took those relationships and instead "fragmented" them into more complex concepts. Even though I technically had the same number of different unit types before, when I take away the relational model in favor of creating those units I have removed the depth in favor of more complexity.
Now, fragmentation is not always a bad thing. I could make a conscious decision in the design to create these new Elites which on their own act as though they're a Drone in the presence of a Commander without requiring the presence of a Commander at all.
Now, these Elites don't take orders from anyone, so they will never benefit from being in the presence of a Commander. However, they cost twice as much to make as a Drone as an offset.
Without removing the depth and relationships between the Drones and the Commanders, I have now given myself a unit that can act on its own which I may decide to use as a scout.
In essence, I have added more through fragmentation, but I haven't added any more complicated rule sets other than understanding the health and damage values of the new unit. In other words, I have created fragmented complexity without detracting much from depth.
However, if I continue to do so with every other unit, then there's really nothing special about the relational values between Drones / Commanders and Drones / Armories. I've expanded the surface which means I have a lower ratio of depth to complexity. In other words, creating the Flame Thrower units, and Elites at the same time has created unnecessary complexity for the sake of complexity through the use of fragmentation.
Or if you think of it like my swimming pool, I just made it shallower in favor of making the surface bigger.
Informational Storage vs Computations on the Fly
Another point of reference to look at in determining if something is too complex vs having depth is to determine how much information must be stored in the player's head vs how much they can just calculate on the fly.
Going back to the RTS model again, if I have a simple rule set that says Drones deal Double Damage when in the presence of a Commander then I am making computational decisions on the fly.
Instead if I have an Elite unit vs a Drone, I have to store the information in my head about how much damage each unit deals.
If a Drone deals 1 damage per attack, in the presence of a Commander they deal double that which is 2. So, in this example the only information I really have to store is how much damage a Drone deals to figure out how much it could potentially deal when in the presence of a Commanding unit.
Now I don't have any rule set that says that Elites deal twice as much damage as a Drone. All I know is that a Drone deals 1 damage and an Elite deals 2 damage per attack. I have instead just increased the amount of data that I must store in my head without any actual computations involved.
Let's go back to the very first example I made about the tabletop game.
This example was just purely informational overload. In order to move a unit I must know how much Health, Stamina, and the Maximum movement is before I can make a strategic move. There is also a great deal of computational strain on the player because before I can determine whether moving left, right or forward is the right way to go, I must also have precalculated how Health and Stamina affect where I'm going to move. This in turn just drags out the process involved with moving my unit and in turn, unnecessarily drags out the session of the game.
Game Pacing's role in Complexity and Depth
The last concept I really want to touch upon is how the pacing of a game can directly influence complexity and depth through the concept of time.
To do this, I'm going to compare an FPS game to a turn based RPG.
The concept behind the FPS is simple. I shoot the enemy and they die. A head shot is an instant kill, and that's pretty much it as far as attacks go.
But I have mere seconds to decide whether or not I'm going to move or shoot or move while shooting. Whether or not I have the time to aim for the head, or if I just try my luck and go for a body shot.
In a turn based RPG however, I have to know how much health I have, then I determine whether or not I'm going to guard, use something like a potion, use a special skill, or even just a plain old attack.
I then have to know what my enemy's weakness is, whether or not something like a Lightning attack will power it up or damage it, and myriad other things that are involved with a classic turn based RPG.
Now in the FPS, I'm force to make these decisions rather quickly, whereas in the RPG I have copious amounts of time.
Even though the FPS requires less thought, I have to make those decisions quickly. The RPG on the other hand requires more thought, but I have time to make those decisions.
Conclusion
There are a great number of factors that influence complexity and depth, and understanding the role of each is key to designing a game that can not only be understood by many people, but also has considerable depth to keep the more hardcore players engaged.
Complexity and Depth is a very BROAD subject and I have only scratched the surface. Hopefully this makes it a little easier to understand without going into the minute details.
