Earlier today, I did a search on how to design Depth in video games. The reason I did this was because of a podcast I saw on Devil May Cry and the fact that its combat system works as well as it does because it has limited mechanics and options but those mechanics can be used in an infinite number of ways because of the depth.
And, me being someone who wants to design deep games, deep combat systems, etc, I decided to look up how to design depth. And what I found was startlingly lacking. I found a number of different things that talk about depth, define it, and all that but most of what I found was more about "why" a game needs depth rather than "how" to design it.
So today, I'd like to talk about how to design depth so that anyone who's designing video games has a clearer idea of how to design their games with it in mind.
The first thing I want to do is define what depth is and use that term to discuss the whole thing. Depth, in layman's terms, is the number of meaningful decisions you can make in any situation. Depth is often compared with complexity in this regard, and I'll get to why in a moment, but first, I want to define that too. Complexity is the number of options you have available to start with.
A game that has high depth and low complexity will have a large number of meaningful decisions among the options available. A game with low depth and high complexity will have a large number of options but only one or two that you'll default on in every single circumstance.
The problem that a lot of people come across when trying to talk about how to design depth is by trying to get across that you should focus on deep gameplay while minimizing complexity as much as you can. The problem with this is that the lower the complexity gets, the lower the limit of depth gets.
As I said, Depth is determined by the number of meaningful decisions you can make in any circumstance but for that to mean anything there has to be options available in the first place. It's one thing to say a game shouldn't be complex when talking about a game that has a hundred different moves but only two that are useful. But what about a game where you only have two moves to begin with? If you only have two moves to start with, even if you mix them up and combine them in different circumstances, that limit on decision making is still going to be a lot lower than if you add one more mechanic to that moveset.
One guy I saw stated that depth and complexity is not simply about the number of rules and the decisions they spawn. That is the gist of it, but there's more to it than that. Depth and Complexity both come from the Rules your game has. The smaller the rule list, the lower the complexity and the lower the limit on maximum depth.
More rules can increase the maximum allowed depth but, the thing is, not all rules are created equal. Some rules are overly hard to understand for what they bring to the table. Some rules are really easy to understand and give you a plethora of possibilities. Some rules can be easy to understand but offer so little in terms of depth that they can be removed with little consequence. And some rules can be hard to wrap your mind around until you engage with them but, once you do, you see all the options that are available and that number is high.
So the first thing you want to do when designing your game is to build a list of rules. Every game will have different rules depending on the focus, the genre, and everything else, but you want to make a certain number of rules to accommodate the mechanics you want to implement. In terms of how many rules you want to have, that's hard to say but, for a game with minimal complexity and maximum depth, generally 10-15 rules will suffice.
"But what is a rule?"
That's a question I had when I came across this because, in order to figure out what rules you need, you need to know what qualifies as a rule. To that, I'm going to say, a rule is something in the game that has some consequence for using or interacting with it.
Mechanics, by themselves, are not rules. What are rules are what you can do with those mechanics. For example, "Press Square to Attack" is not a rule but "Attacks deal damage" is a rule. That's something you want to define ahead of time so you know how to figure out your rules.
Once you gather your list of rules, you want to look at it. Some genres will require a larger amount of rules than others, it's worth mentioning that. Devil May Cry has more rules than Jak & Daxter but that's because it's an action game compared to a platformer and action games require systems, platformers only require mobility, so Devil May Cry needs more rules than Jak & Daxter to function as well as it does. So if your game has a lot of rules after you finish writing or typing them down, don't fret quite yet because a lot of those rules may be necessary for your game to function.
Once you have your list of rules, you want to look at it and evaluate how much depth each rule provides to your game and how complex each rule is. If you work well with numbers, you can give each rule a rating for depth and complexity, I would put them both on a scale of 1-10 but, whatever scale you use, make sure they're both graded in the same way so that you can properly go onto the next step.
If you rated these rules based on depth and complexity, you want to divide each respective rating. Depth/Complexity. You can also make it a ratio: depth:complexity. If the number you end up with after this step is less than 1, you'll want to remove it because it does not offer enough depth to justify its complexity. If the number is higher than 1, then obviously you want to keep it. If the number is 1 exactly, it does not mean you have to keep the rule but it doesn't mean you have to get rid of it either. If you think your game will benefit from keeping the 1's, you can keep them but, if you're thinking about simplifying the game as much as possible, remove the 1's that are not necessary for the game to function properly.
"But what if I don't like numbers? What if I prefer feeling?"
That is a valid complaint. Not everybody is able to quantify things with numbers. Some people are more intuitive and will be more likely to look at a rule and immediately be able to determine whether it's worth keeping or not, even if they can't put the reason into words.
If you're not good with either, then I recommend finding someone who is good at doing one or the other. But, be warned, if you find someone who uses a number system, you'll want to know how they got to the grade so you can put it under proper scrutiny but, if you get someone who is intuitive and simply recognizes whether something works or not, don't argue with them because they may not be able to articulate why they feel that way.
Once you've simplified the rule list a bit, that's when you want to do some proper simulations. Figure out if the rule-set you have results in varied decision making among different people and the impact those decisions have. You'll also want to test for how easy those rules are to grasp to anyone who's about to test them.
And remember, just because a rule is complex or hard to understand does not mean that it should be axed right away. If a rule is complex but offers enough depth to justify that complexity, you might alienate some people who don't want to bother with it but people who are willing to bother with it will learn all they can from it and utilize it effectively.
Also, just because a rule is simple does not mean that it has the depth to justify it. A rule that is easy to understand can be axed relatively easily if it offers nothing of value to the ones using it.
Finally, don't judge the value of a rule's depth by itself. Some rules may not have much depth by themselves but may work as a multiplier of the depth of the package when working together with other rules.
If I answered some questions, that's good. If I haven't made it clear, go ahead and tell me and I'll see how I can help. This is a problem that very few people seem to understand and even fewer go into detail about. I'm just trying my best.
Have a wonderful day.
No comments:
Post a Comment