Playtesting in Detail

howandwhy99 · Nov 12, 2012

Overview of D&D Rules Cyclopedia.
Of course, not everything should or will be a rules module.
[sblock]

Backgrounds ?
Races as Classes
Mystic Class
Reversible Spells
Land & Water Transportation, Mount or Vehicle
Commercial Transportation
Siege equipment and weapons
Training, teaching and studying
Weapon Mastery Trees & Special Effects
Long Skill List grouped by ability score
Movement, time, distance, becoming lost, finding food, swimming and drowning
Exploration and the Game Turn
Wandering Monsters, encounters, encounter distance, monster reactions, evasion and pursuit
Wilderness Encounters, by terrain type, & Evasion and Pursuit, gaining bearings
Waterborne Evasion
Balancing Encounters (Total Party Levels)
Combat - Group initiative (optionally individual)
Combat - (optional) Morale, determining morale scores
Combat - Maneuvers list
Combat - (optional) Partial Targets [moving from full cover to full cover]
Combat - (optiona) Striking, Wrestling,
Aerial Combat including bombing and swooping
Naval Combat - Missile ship to ship
Naval Combat - Close-Quarters, ramming, grappling and boarding, repairs
Underwater Combat
Seige Combat - Structural Damage, Special Attacks, NPC Siege Specialists
The War Machine (mass combat system)
Paths to Immortality (Dynast, Hero, Paragon, Polymath)
Creating High Level Player Characters
NPC - Retainers [i.e. Hirelings], Mercenaries, Specialists, Employer Charisma
Strongholds and Dominions - Options by Race & Class
Strongholds and Dominions - Authority from another and Independent Strongholds
Titles - Nobility, Royalty, Forms of Address
Strongholds - Construction Process & Design Plans, Costs and Time
Strongholds - NPC Retainers and Staff
Strongholds - Patrolling, Settling, Enlarging
Dominions - Basics, Administration, Tax and Income, Expenses, Record Keeping
Dominions - Confidence Checks, Confidence Level, Changing Rulers, Dominion Events
DM Procedures A to Z - Alignment Changes, Clues, Demihuman Clan Relics, Haste Spell, Lost Spell Books, Mapping, Multiple Characters, New Items and Monsters, Reality Shifts, Record Keeping, Time Keeping, Retirement, Special Conditions, Transferring Characters
Monsters - No. appearing, Morale, Treasure Type, Intelligence
Monsters Descriptions - Type - Normal Animal (w/ giant animals, prehistoric animals), Lowlife (w/ insects, arachnids, fungi, slimes, etc.), Construct, Dragon (w/ dragon-like or Dragon-kin), Humanoid (w/ human, demihuman, and giant humanoid), Monster, Planar Monster, and Undead. Enchanted Monsters too.
Monsters Descriptions - Rarity, habits & behavior (Carnivore / Herbivore / Insectivore / Omnivore) (Nocturnal / Diurnal), and (optionally) Load and Barding Multiplier
Monsters Descriptions - Terrain - Cavern, Cold/Arctic, Desert, Lost World, Mountain, Ocean, Open, River/Lake, Ruins, Settled, Swamp, Woods
Monsters Descriptions - Special Attacks - Acid, Blindness, Charge, Charm, Continuous Damage, Disease, Energy Drain, Paralysis, Petrification, Poison, Spell Ability, Swallow, Swoop, Trample
Monsters Descriptions - Special Defenses - Immunity to Normal Weapons, Spell Immunity
Monsters - Changing Monsters, basic variations, Size, Age, Environmental Variations, Spellcasters
Monsters - Undead Lieges and Spawns, turning controlled undead, duration of control, Energy Drainers
Immortals - Immortals and Spheres of Power, Interacting with Mortals, Behavior, Manipulations, Statisics, Mortal Form [avatar], Manifestation Form, Incorporeal Form, Fighting Immortals
Immortals - PCs Becoming Immortalsl, prerequisites, Finding a Sponsor, 4 paths, Retirement
Treasure - Division by players
Treasure - Treasure Types, by Lair and Individual
Treasure - Coins, Gems, variations, Jewelry, Magic Items
Magic Items - Permanent, Temporary, by class, race, or spellcasting type, artifacts
Magic Items - Buying and Selling magic items,
Magic Items - making magic items, enchanting, recharging, intelligent, making magical constructs, Making Huge Magical Items (fortifications),
Magic Items - Dispel Magic Attacks
Spell Research - Player Procedures, Character Procedures, Experience from,
Campaigning - Tone, Goals,
Campaigning - Desiging Settings (map, towns, cities, history, languages, important NPCs, Government, immortals, adapting the game to the setting, selecting elements)
Campaigning - Designing Adventures, Designing Dungeons
Campaigning - Running Adventures, DM Set Up, DM's Job
Planes of Existence - Arrangement, Interplanar Adventures, Time, Gravity, Vortexes and Wormholes, Ethereal Plane, Elemental Planes, Astral Plane, Outer Planes, beyond the Multiverse
Variant Rules - Lethality, Demihuman and Mystic XP levels, Non-lethal combat
Appendix 1 - The Known World Campaign Setting
Appendix 2 - Game Conversions (prior editions)
Appendix 3 - Record Sheets (DM character card, character record sheet, spell book sheet, adventure record sheet, hex grid
Appendix 4 - Indices (spells, tables, checklists, general topic index)

[/sblock]

Remathilis · Nov 12, 2012

Bear in mind a RC Mystic = Monk in AD&D parlance.

Li Shenron · Nov 12, 2012

Grimmjow said:
i agree with paladin, and i half-agree with half orc (see what i did there?) but whats a cavalier?

My guess is that Mike answers this question a few lines later: it's a prestige class, and probably in the core.

pauljathome · Nov 12, 2012

I actually found this part of the article the most interesting. And potentially disturbing.

In parallel with all this, I'm working closely with our business team to build a product plan for the game. That's probably the most exciting and most challenging part of the process.

Building a product plan really shouldn't be the most challenging and exciting part of the business for the customer advocate.

Its also interesting to see the misuse of Agile

. Nice to see one buzz word being misapplied in a completely different industry with totally different design parameters and process

.

Gundark · Nov 12, 2012

Chris_Nightwing said:
This approach worries me a little. I suspect, for instance, that expertise dice have already been green-lit. That means they won't try any other approaches, and it's unlikely they will ask opinion on green-lit elements in surveys. So they accept the first thing that's liked well enough and move on, designing themselves into a corner.

I hear what your saying, however at point would you want them to accept a green light rule and move on to designing other parts of the game?

delericho · Nov 12, 2012

pauljathome said:
Building a product plan really shouldn't be the most challenging and exciting part of the business for the customer advocate.

Bear in mind that he's also the head honcho.

And bear in mind also that if WotC get this one wrong it could well be game over, man.

DM Howard · Nov 12, 2012

pauljathome said:
Building a product plan really shouldn't be the most challenging and exciting part of the business for the customer advocate.

Actually, as a soon to be graduating Marketing major (Spring 2013 Woohoo!), I think it really can be sometimes and I think that D&DN is one of those times. If WotC doesn't put out the right products in the right order it won't matter for many if the system is really good because many won't look at the big picture and be willing to wait for that key product that will make the game rock for them.

Gadget · Nov 12, 2012

tomBitonti said:
Curious, this use of the agile process. How usual is the substitution of Scrum for Agile?

From my background, Product Owner and Customer Advocate are different roles. I'm still figuring out what I think about the roles being merged.

Isn't is usual to avoid using "customer" in customer facing writing? I would have used "players" or "play-testers" instead.

Thx!

TomB

Scum is an agile implementation where the Product Owner is the one who defines the product requirements and features desired in a system and sets priorities on what gets worked on first and what meets those requirements when it is "sold off" at the end of a sprint. This person is usually not a technical person and is the one who makes the business decisions about trade-offs in time, expense, and performance after the technical people give estimates and clearly lay out the options. In every shop I've been in the Product Owner is either directly interfacing with, or at least representing, the customer in the agile process.

This scenario is a little different, as Mike is really a kine of "technical" person himself (technical in this instance meaning game designer/developer) and there may be a strong temptation to cross-pollinate and "get his hands dirty in the code", so to speak. But I've seen a few ex-programers move into the role and leave the more technical side behind them; it gives them a sometimes more insightful understanding of the process if they can resist the temptation mentioned above.

Truename · Nov 12, 2012

tomBitonti said:
Curious, this use of the agile process. How usual is the substitution of Scrum for Agile?

Scrum the most widely-used Agile method, so quite usual.

From my background, Product Owner and Customer Advocate are different roles. I'm still figuring out what I think about the roles being merged.

Product Owner is a formal Scrum role that encompasses all aspects of "decide what product to create and the order in which it's going to be built." There's no "Customer Advocate" role in Scrum, but it's easy to see how a product owner would include advocating for the customer in his job.

Utlimately, in a product company, the product owner is responsible for creating a commercial success. It's a good fit for Mearls' position.

pauljathome said:
Its also interesting to see the misuse of Agile . Nice to see one buzz word being misapplied in a completely different industry with totally different design parameters and process .

Of all the Agile methods, Scrum is the one that's most applicable to other industries. I've run across people using Scrum in fields as diverse as HR and Legal. Scrum doesn't say anything about programming (well, hardly anything) so it's relatively easy to port.

I got the strong impression a few years ago that WotC's internal development shop (the one that took over the DDI tools) was using Scrum, so there's a good chance that R&D's use of Scrum migrated from the software team. That's a pretty typical progression--a software team uses Agile, which makes their work process more visible to the rest of the organization, which then adopts the non-programming aspects of Agile, typically with something Scrum-like.