We're hoping this column becomes your window into roleplaying design and development -- or at least the way we approach these things here at Wizards of the Coast. We'll handle a wide range of topics in weeks to come, from frank discussions about over- or underpowered material, to the design goals of a certain supplement, to what we think are the next big ideas for the Dungeons & Dragons game. All of this comes bundled with a healthy look at the people and events that are roleplaying R&D.
This week, we start with a look at the development side of things.
What is Development?
"If you like a book, it's because design came up with a great product. If you don't, it's because development didn't get it right." Interested in what goes into the creation of Dungeons & Dragons? R&D members Jesse Decker and David Noonan offer this behind-the-scenes look at Wizards of the Coast, sharing their insights and philosophies into the making of the game. In this first article, Jesse Decker introduces the developers' side of things, offering the art and science behind D&D's development.
If you like a book, it's because design came up with a great product. If you don't, it's because development didn't get it right.
Know Your Role
Twenty-two fulltime R&D staff members share the task of building Dungeons & Dragons roleplaying material. Half of them, seven designers and four developers, do the things that we'll talk about in this column. So what's the difference between a designer and a developer? For the long answer, and a chance to see the two in action, you'll need to follow this column.
But the short answer is this: A designer's job is to ask, "What can we do?" The designers try to find new places for us (the developers) to play, to break boundaries, and expand the game. Theirs is the job of creating cool stuff for us all to play with.
The developers, on the other hand must answer the question, "Does it work?" The developers spend their time making sure that things are balanced and costed properly so that a powerful feat or spell, no matter how exciting, doesn't destroy the game. Our job is to make the game fair.
The two tasks must be separate so that both receive the attention and energy they deserve. A designer bogged down with game balance concerns has little room to be daring. A developer who doesn't examine how one game element interacts with another allows degenerate character builds. Neither is good for the game. This week we're talking about development, but we'll often shift between the two.
Art vs. Science
Development work falls into two broad categories -- what we like to call the art and science of development. The science of development is the quantifiable part of the process; answering such concerns as, "Is this feat balanced?" is part of the science, because there are concrete tools that allow us to answer this question. Careful comparison with other feats (or even other game elements such as class features, spells, or magic items) can give us a precise understanding of the feat's power level and therefore the appropriate cost. There's a lot to the science of development, including the accurate assessment of the power level of many interrelated game elements, testing these assessments whenever possible, and ensuring that the intent of the mechanics is communicated clearly. That said, it's the easiest thing that we do.
The art of development involves all the things that are not quantifiable, addressing such questions as, "Will this resonate with the fans, how do we communicate that this strange mechanic benefits the play experience, and is this book addressing the most important aspects of the topic?"
Tangent Alert: What do we mean by cost? In development we often talk about the "cost" of a particular game element, but the meaning changes depending on the specific game element being discussed. For a feat, the cost is mostly a combination of two factors. The biggest of these two is the opportunity cost of not taking another feat. With so many feats in the game, a big part of a feat's power involves the other feats that you could take instead. The second aspect of a feat's cost is shaped by its prerequisites. Depending on the power level of the prerequisites, they can serve as a simple level gateway or a tax on the feat.
Cost for other game elements works in a similar fashion, but is usually shaped by different factors. When talking about magic items, cost is a straightforward discussion of the item's gp value. For miniatures, it's the figure's point cost. For spells, cost and spell level are pretty much the same thing. Prestige classes are costed much like feats: what are you passing on in order to unlock the classes' abilities, and how many suboptimal choices do the prerequisites require you to make? (Note: That second part is often confused with "how hard are the prerequisites to meet?" and while the two are related, they are not necessarily the same thing. For example, a prestige class that allows full arcane spellcasting progression and a number of good class features might look balanced if it requires five metamagic feats to qualify for and the ability to cast 5th-level arcane spells. However, since there are a number of powerful metamagic feats available, the difficulty of attaining the class doesn't have much effect on the class's cost.)
A Day in The Life
There's no such thing as typical day around R&D, but if such a mythical event were to occur, it might go something like this for a developer:
9:00-ish to 10:00: Deal with email and other minor tasks when you've just arrived, and then prep for the first development meeting of the day.
10 to Noon: Your team of three meets for two hours on its current project; this is really the heart of the development process, and since we're taking the time to second-guess a designer's work, we never do it in a vacuum. Three is the magic number because there are no ties, but it's still a small enough group to move quickly through the material. You've got six weeks to work through two products, and your morning meeting is devoted to the first.
Noon: Git me a sammich!!
1:00 to 3:00: A mirror of the before-lunch meeting, but on the second project.
3:00 to 6:30-ish: All those great ideas and comments made in development team meetings become real here, and the bulk of the changes to the manuscripts are implemented in this end-of-the-day period.
Of course, this simple description doesn't really do justice to the chaos that surrounds us!
Can You Do It? The Development Test
We've hired two developers in the last year, and each time we've asked them to take the following test. In the very near future, we'll post the answers given by Mike Mearls, our most recent hire. And yes, he got some wrong. (Interested to share your own answers to the test? Please use this message board thread.)
Dear Prospective Developer,
Hello, and thank you for your interest in the RPG/D&D Miniatures developer position in Wizards of the Coast R&D. This test is meant to measure both your technical knowledge and your writing ability. To give you a little background on RPG/Minis development, we've provided some explanation of the development phase (see below).
What Is Development?
Development is the phase in which the mechanical elements of a product are reviewed and adjusted to match the expectations and sensibilities of the game and its setting. This includes both the appropriateness of the subject matter ("Does this prestige class fit in D&D?") and the "game balance" of the mechanical elements ("Is this prestige class balanced compared to similar options?").
The design team is responsible for creating innovative game concepts (rules and non-rules); the development team is responsible for evaluating and, when necessary, revising the execution of those concepts. It's not the development team's job just to second-guess the design team's work, but instead to serve as a reality check, sounding board, testing ground, and unflinchingly honest and open-minded evaluator of the work's appropriateness for the game and its setting.
Why Do We Develop?
Development serves as a valuable step between the pure creativity of design and the detail-oriented editing phase. Developers can evaluate a product without personal bias, reviewing both big-picture and small-picture issues related to its mechanical elements.
Developers also ensure that certain standards of expectation are met regarding the gaming experience provided by our products; i.e., that two different products don't vary wildly in the quality or balance of their mechanical elements. Players and DMs should be able to look at any book in our line and reliably assume that it meets the expected standards of the D&D game line, and it's the developers' job to make sure that's always true.
1. In D&D, class and race are crucial elements that define a character's role in the party and his place in the world. It's no coincidence that they're among the most important game mechanics for developers to understand.
a) What is the most powerful class in the Player's Handbook, and why is it the most powerful?
b) What is the least powerful race in the Player's Handbook, and why is it the least powerful?
2. Longstrider is a 1st-level ranger and druid spell that increases movement by 10 feet for 1 hour per level. Is this spell more powerful, equally powerful, or less powerful than most 1st-level spells? Why do you think this is true?
3. The concept of the "swift action" (as described in such books as Expanded Psionics Handbook and Complete Arcane) is a relatively new addition to D&D. Why were swift actions (especially swift-action casting time spells) added to the game? What's the downside of adding swift actions to the game?
4. You're part of the development team for the next D&D sourcebook. If these two feats were part of the design turnover, what are some comments that you would make about them?
Your knowledge of one school of spells enables you to better resist spells from that school.
Prerequisites: Int 12, Spell Focus in the chosen school, ability to cast one spell from the selected school.
Benefit: Select one school of spells that you can cast and for which you have the Spell Focus feat. You get a +1 bonus on saving throws against spells from that school.
Burning Barrier of Breath
You can channel the power of your breath weapon to create a barrier of flames.
Prerequisites: Cha 13, breath weapon.
Benefit: Use your breath weapon to cast wall of fire.
5. You're part of the development team for the next set of D&D Miniatures. If this model were part of the design turnover, what comments would you make about it?
Melee Attack: +4/+4 (10)
Regeneration 5 (heal 5 damage each time Ruby golem is activated)
Sonic weakness (Ruby golem cannot regenerate damage from sonic attacks)
Magic Immunity (Whenever a spell is cast on ruby golem roll 1-10 the caster gets the spell back and it has no effect, 11-20 the caster loses the spell and it has no effect.)
Ruby Golem can be played in any warband but costs an extra 5 points and loses fearless if he is not in CG.
6. Your development team has decided that this rule is mechanically balanced, but the team lead tells you that it needs to be rewritten for clarity. How might you rewrite this rule and why?
While this effect affects you, your Reflexive saves are improved by +2 if you're a rogue or other kind of character with evasion, except when she's flat-footed or loses her AC Dex bonus, in which case she doesn't get any bonus, but if she has improved evasion improves you to +4.
7. Describe a game mechanic (from a game other than a roleplaying game) that you think is good, and explain why you think it's good.
(Interested to share your own answers to the test? Please use this message board thread.)
About the Authors
Design: David Noonan is a designer/developer for Wizards of the Coast. His credits include co-designing Dungeon Master's Guide II, Heroes of Battle, and numerous products for the Eberron campaign setting. He lives in Washington state with his wife, son, and daughter.
Development: Jesse Decker (male human, CR 1/8): I first picked up a d20 somewhere in the early eighties, and I often tell the story of my intro to D&D. I was in elementary school, and a friend received the now famous "red box" set as a gift from his parents. I was instantly hooked, and soon became a regular haunt of the one hobby bookshop here in Renton, WA. Fast forward through some-teen years of gaming (with occasional interruptions for things like school), and just out of college I land a job as editorial assistant for Dragon Magazine. The eight years since that entrance to the gaming industry have included a two-year stint as editor-in-chief of Dragon, freelance design credits such as Hammer & Helm, and Unearthed Arcana.
In the middle of 2003, I left the helm of Dragon for a chance to do full-time design in Wizards' R&D group, and was lucky enough to work on books like Complete Adventurer and the DMG II. I clearly liked to talk too much to remain on the design team, so I moved over to manage the relatively new development team for RPGs and D&D Minis.
It's easily the best job in the whole world, but even so, I swear that as soon as I level up I'm taking the Talk Less in Class feat.
Thoughts or suggestions for this article? Topics for future Design & Development articles you'd like to see covered? By all means, please feel free to write directly to the authors, at: firstname.lastname@example.org.