Playtesting in Detail

[howandwhy99]

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]

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

 

[Li Shenron]

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]

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]

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]

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]

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]

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]

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.

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.

 

[Zaukrie]

I thought it was a great translation of agile methodology for a non IT implementation.