Here’s part two of our illustrated transcript and analysis of Wyatt Cheng’s GDC presentation on Diablo 3’s Iteration in development. You can view this video on Gamasutra; the time stamps listed below correspond to it.
I’ve added much better formatting in this part two, including numerous slides taken from the panel and more exact quoting. I’ll upgrade Part One to this format later tonight, and add Part Three as well. The goal is to present a robust text companion to the video presentation.
Wyatt’s presentation is an interesting view of how the game’s systems were created and developed through iteration, from initial ideas to final ship version (and sometimes changes were made even after that.) It’s basically a “how we made Diablo 3” presentation, and should be interesting to anyone who is interested in video game design, or who wants more info about the nuts and bolts of Diablo 3’s construction.
System 2: Command Input
16:10 — Before I get into this, I want to preface by saying that, I could talk about controls all day. I love geeking out about controls. I think that really tight controls are hard to do well and my favorite games unanimously have tight controls.
As we looked at Diablo 3 we knew we were going to have six skills available on the hot bar. It seemed pretty straight-forward at first. Skills are bound to 1-4, LMB, and RMB. But we immediately started to run into problems during development. And this was the idea of “lost clicks.”
Click through for the rest of this presentation:
Command Input: “Lost” Clicks
Players play Diablo III very frenetically, constantly clicking keys and making mouse strokes, often all at once. But your character has to animate, and that’s a key part of making the player feel connected to the game. You issue a commend, your character executes it, and you get the result. So how do we handle it with the player telling us so many things at once?
Before we get into that problem too much, let’s go over the animation structure.
Command Input: Animation Structure
All of our combat actions involve an animation usually that’s usually 18-28 frames long. These have 3 important points. 1) The start frame, 2) the contact frame, and 3) the end frame.
The start frame is our way of letting the user know that your command has been received and we’re going to start the power. One of the things I want to call out about this is an extreme pose. If you look at the Barbarian demonstration here, the start pose is an extreme silhouette. Because when the player clicks that button and the animation begins, in a lot of these we have what’s called “anticipation” at the beginning of the animation.
An analogy is to a console platformer, that you don’t want a character to bend his knees and windup to jump, since it doesn’t feel responsive to have that delay. What we found in Diablo 3 is that controls that feel really responsive, we skip and cut out most of the anticipation. Go directly to a strong silhouette pose which sends a clear message to the user that the command has been received and is about to be executed. This gives a great sense of control.
From the start frame, we animate through to the contact frame. That’s always located between 1/4 to 1/3 of the way through the animation. We tried other positions, but that felt like the best compromise between giving the weapon some weight and giving some impact out.
The contact frame for melee characters is when the weapon seems to hit the target. If it’s a ranged attack it’s when the projectile actually comes out. If I’m a caster it’s when the buff goes off. And then that time from the contact to the end is the follow through. That’s where the animators can indicate a lot of weight into the weapon. That’s where your attack speed really comes into play if you have a slow vs. fast weapon. And all of that happens from the contact through to the end.
As a side note, that’s where we allow the player to move, which is another iteration we did. Not to go into too much detail on that, but we found that players really enjoyed the ability to stutter-step their animations through, so we allow movement after the contact frame.
Command Input: Wizard Skills
So lets get back to the original problem. The palyer can issue up to six commands a t once. For the purposes of illustration today, I’m going to focus on four Wizard skills: Magic Missile, Arcane Orb, Blizzard, and Ice Armor.
[Short videos from a testing area are shown for each skill. In all of them the Wizard fires the skills at 3 Fallen Imp enemies who just stand there motionless.]
20:15 — The first skill is Magic Missile, and here’s a video of what it looks like. Magic Missile is a single target skill. It shoots a fairly fast projectile that hits one enemy and has no resource cost.
Here’s Arcane Orb. It shoots a slower projectile that does Area of Effect damage and has a high resource cost. So you can see why as a player I might want to use one or the other for different situations.
Third skill is Blizzard. I go through my animation; upon hitting the contact frame ice begins to fall from the sky. Once that begins I’m free to do other things, and ice will continue to fall from the sky and do damage to an area.
The last skill is Ice Armor. This one’s a buff. I go through the animation and cast a buff on myself, and that buff is represented by that large shell of ice that you see forming around the Wizard. That’s in response to me casting Ice Armor. While I have that buff on me, the monsters that swing at me are frozen.
[Short video of the Wizard standing motionless while a Fallen Imp runs up, swings, and gets frozen in place.]
There’s a great feeling of power as a player when a monster walks up and is just frozen in its tracks.
Iteration 1: Secondary Animation Powers
21:40 — So, let’s get back to the problem of lost clicks. First thing we did was divide all of our powers into “primary animation powers” and “secondary animation powers.” That distinction was pretty quick to make.
The idea here is that a primary animation power really wants to play its animation. In fact, if you can’t play your animation, then the power is going to fail. This really ties into anything that does damage; your normal attacks, swings, etc. Because if I don’t animate and a projectile doesn’t come out, that’s weird. The player won’t feel as connected to the action, and it won’t feel visceral. So the animation is really, really important.
A secondary animation power is one where we felt like, “you know what, if you can’t play the animation, that’s okay. You can still have the power go off.” So we tied some very loud, strong visual effects to all of our secondary animation effects. So that even if you were already animating something else, you could still have the power go off. The particle effects go off to communicate that we’ve received and executed the command, but we don’t interrupt what your character is already doing. We also don’t want that action to fail.
So here’s what that looks like.
Of the four skills, Ice Armor is the secondary animation power. It’s a buff, so if the full animation doesn’t show, that’s okay.
[The video shows a Wizard running and casting Ice Armor repeatedly. There’s no casting animation, but the shell of ice forms every time, and the blue glow appears as well.]
I can even be attacking while I’m casting Ice Armor. Here you see me shooting Magic Missiles while casting Ice Armor. Ice Armor goes off every time the player clicks the spell.
23:10 — The result of that. Very good. We consider that experiment a success. Improved control for the player, some developers argued that there’s a slight increase in power for the players. “Hey, you know before I had to stop moving to cast Ice Armor. Isn’t that part of the gameplay of keeping up a two minute buff? The opportunity cost of casting that spell?”
Our ultimate conclusion was that the feeling of these lost clicks and really feeling in control of your character was more important than tying in that animation, and was worth that slight increase in power that we were giving to the player. While this is good, and improved the reports of lost clicks we were getting, and doesn’t take care of all the skills we needed to animate.
Iteration 2: Interrupting Powers
The first thing we tried is interrupting powers. The idea here is that if I issue a whole bunch of commands, just animation execute the last command that was issued by the user.
That kind of makes sense on an intuitive level, because if I’m pushing a whole bunch of buttons, then there’s probably a skill right at the end that needs to be shown. So if I’m a Wizard and I cast Magic Missile, Arcane Orb, and then at the end I’m hammering on Blizzard, I really expect Blizzard to come out. So why don’t we stop what we’re doing and have that show instead?
24:35 — Here’s what that would look like. This video is slowed down to 1/3 normal speed, so you can see what’s happening. For reference here’s the Wizard just casting some Magic Missile, and then Arcane Orb. But now watch as they’re allowed to interrupt each other.
Between the contact frame and the end frame, before the animation is completely finished, the user issues another command and the game immediately responds. The rest of the animation is cut off and the next spell is cast immediately.
[Video shows MM and Arcane Orb being cast one after the other, with MM sometimes appearing very shortly after Arcane Orb and passing it in flight since MM moves much more quickly.]
The result is improved controls. Players expect that if they push a button, a skill goes off. The downside is that it results in some increased DPS in the player. We always have to evaluate how much increased power we’re giving to the player while also boosting the control.
It’s kind of negative in that it creates what I call a “burden of optimal play.” This is the idea that the player can increase their power level, but that they do so in a way that’s not necessarily enjoyable. Although they can get extra frames of animation trimmed off of the skill, they have to stare at the character very closely in order to do so. The player has to take speed and many other factors into account and that didn’t seem very appealing.
More important, I can still also lose some commands, if the command is triggered before the impact frame. Let’s take a look at what those two problems look like.
Here’s an example of how a player could increase their DPS. By weaving Arcane Orbs and Magic Missiles together, and switching back and forth, I can actually cut off all the time from the Contact Frame through to the End Frame, and get almost twice as many projectiles as I could before. Remember though, that this video is running at 33% speed, so you can imagine what this would be like to play at normal speed. That’s the burden of optimal play.
[Video shows the Wizard on the test screen again, firing MM and then AO in very rapid succession.]
26:30 — But the bigger problem was this problem: If I clicked too quickly, before the contact frame, the spell casting animation was interrupted and nothing happened. As you can see, the Wizard is kind of interrupting herself and nothing comes out. This was a huge problem and we were like, “We can’t ship with this!” The player is spamming Arcane Orb and Magic Missile and nothing is happening.
[Video shows the casting animation repeating and repeating, but never quite finishing and no projectiles are appearing.]
So we knew we had to try something else.
Iteration 3: Queue
27:00 — The next idea we tried was this idea of the command queue. This is pretty common in a lot of games, ARPGs and RPG as well, that you queue up a lot of commands. We were apprehensive about this for two reasons.
The first is at that point in time we were already in Beta. We’d tried the interrupting method and a lot of players had tried it and picked up on this optimal DPS problem, and at that point we were in complete feature lockdown, because we were trying to hit a ship date. And there’s that time when you’re just polishing all your systems and want to wrap things up and get the game out the door. But, the team believes in tight controls. So we sat down and really evaluated how big a deal we thought this was.
At Blizzard one of our key design values is “control is king.” We had a discussion and we said, “Even if we have to delay the game, the controls *must* feel tight and responsive. We knew this to be the case since even though a lot of other features could probably be cut or delayed or worked on later or pushed back, it was unacceptable that we’d go out with anything other than very tight controls.
That was our first concern. The second concern was that we’d seen other games do command queuing, and sometimes it even results in controls that feel worse.
Command Queuing Details
A lot of times, when we played some other ARPGs, your character ends up queuing a lot of commands, and it feels like there’s a loss of control. To use an extreme example, imagine if we had full queuing. Imagine that I cast list five Magic Missiles in a row by clicking really fast. I certainly wouldn’t expect to be able to take my hands off the keyboard and watch while my character shot out five Magic Missiles. So too much queuing felt like even less control of your character at that point.
So, what we did were “queue windows.” These windows are very carefully tuned to have some rules around them.
The first rule is, never queue more than one command at a time. This seems obvious and most games implement this pretty early on when they do command queuing. So even if I click Magic Missile five times in a row, I’m going to queue the one I’m casting, and one more, and that’s it.
The second rule is that we only queue commands for a very brief time window. We tried different times from 0.1 to 1.0 seconds, and found that there’s a sweet spot between 0.3 and 0.5 seconds. That’s how long you want to feel like you’re holding onto a command. If you think about it from a qualitative stand point, what you’re really asking is, “How long ago could the player have asked the character to do something, that when it comes out the player isn’t surprised?”
And that feels like 0.3-0.5 seconds. Like, “Yeah, I kind of cast Blizzard! I just did that. It should come out. That feels right.”
So all of our powers are set up with a time of between 0.3 and 0.4 or 0.5 seconds for the amount of time they’re allowed to queue.
The next thing we had to do is figure what would happen when the player tried to queue up more than two commands. We’ve already established that we’re not going to queue more than one in advance. So what happens when players try to queue up more than one? I’m going to give you some examples, but the basic rule is if one is already executing, the different command takes priority.
Command Queuing Rules
To illustrate again what that means, imagine I’m casting Magic Missile a lot. Missile, Missile, Missile, Missile, and then I insert an Arcane Orb command. That’s happening all the time in our game, since players are spamming the LMB as fast as they can. That command, since it’s different than what’s currently being done, is super important. The player expects that different command to happen. So it gets higher priority in the queue, and it can’t be knocked off by another cast of Magic Missile until it comes out. That’s rule number one.
The other rule is if both of them are different than the current command. So to use my Magic Missile example from earlier, imagine if the sequence goes Missile, Missile, Missile, Missile, Arcane Orb, Blizzard. Which one does the game show now? In that case, we do the latest one. That’s a lesson we picked up from that interrupting experiement earlier. The player does have an association with the latest thing they’re doing. But you don’t want to interrupt what you’re currently doing. So you want to do the latest thing without interrupting the current action.
Command Input Summary
That works great! It’s what we ended up shipping with.
We had the primary and secondary animation powers, we had the command queuing with a lot of rules. In general you want to prioritize the most likely skill. What that means is like the skill we think the user was actual trying to do.
There’s still some edge cases, mostly around movement skills like Whirlwind or Vault. In those cases there are some client sever synchronization issues where we’ve tried to really tighten up the controls and we’re still working on those, but overall most of the other commands feel really good in the players command.
Lessons Learned: Command Input
32:53 — What did we learn? Well, good controls are really hard to do. This has been my experience on almost every game I’ve worked on. If you’re going to have really good controls, there are going to be a lot of edge cases and a lot of special rules. In general the rule you want to think about is what did the player intend to do?
A lot of times I’m talking to our gameplay programmers, and we’re having that discussion. And we’ll say something like, “You know what, we should try, there are a lot of special case issues in that command queue. Why is it so complicated? Isn’t one of our design principles to achieve simplicity?”
And the realization we had is that designs are simple from the user’s point of view. Sometimes there’s a lot of complexity under the hood in order to present something simple to the user. An example I’d use is voice recognition. Voice recognition is super complicated under the hood, purely to present the simplest possible interface to the user.
This is part two of our illustrated transcript of Wyatt Cheng’s GDC 2013 presentation on Iterating Diablo 3’s Systems. Part One can be seen here. Part three will be added later tonight.