Playtesting

MCDM's content goes through several passes of playtesting to ensure they're balanced and fun!

The MCDM Discord is the main hub for all playtesting, though occasionally Open Beta playtest documents are released publicly on Twitter, Reddit, and other spaces.

The main way to become a playtester is to join the MCDM Discord, head to the MCDM Playtesting category, and then opt into the Playtest Pool. Once there you can volunteer to join playtests run by Playtest Coordinators.

A Brief Overview of the Playtest Process

The main playtesting flow is as follows:

Initial testing is done by MCDM's contract testers.
Products enter Closed Alpha/Beta testing and are handed off to volunteer Playtest Coordinators to run for their tables and members of the Playtest Pool to then provide feedback.
Occasionally products may enter an Open Beta, where anyone can join the testing process and give feedback.

Playtest Coordinators

Coordinators are volunteer GMs who review, run playtests, and provide feedback on early content for Arcadia and other MCDM projects! If you're interested in applying to become a Playtest Coordinator, check out the application here: https://forms.gle/jygByAF2oYVDR6Et9

Generally people who are active in the Playtest Pool are the first picks for new Playtest Coordinators.

The Playtest Pool

Sometimes the Playtest Coordinators need an extra player or two for testing, or need a whole table of players. When this happens, they can ping the Playtest Pool channel in the MCDM Discord server to see if anyone is available to join a playtest at a specified time and date.

Anyone in the playtest pool can volunteer to join a Coordinator's playtest—simply reply to the message indicating your interest in joining. Please do not send them a DM, and please refrain from asking the Coordinator to adjust a playtest's scheduled start time/date to accommodate you.

Keep in mind that the amount of information conveyed about what specifically is being tested is likely to be minimal. Please be flexible and be ready for anything if you're selected. In addition, you should assume that a playtest session will be at least four hours long.

There's no guarantee that you'll be selected to join a playtest, and coordinators have full discretion over who they invite to their table.

What Makes A Good Tester

Testing has its ups and downs.

As a tester, you get access to cool new stuff! You get to see behind the scenes of a product’s development and watch as a design goes through a LOT of iteration. It can be cool and fun to see how the sausage is made and it SHOULD be fun! We value actual playtests, whether it’s putting a new class through a few encounters, or an entire adventure. Or sometimes a whole new rule system! You get to be the first people anywhere to test out this new stuff! You also get a lot of insight into the developers’ goals and intentions. It’s our responsibility to communicate what we’re testing, and what the intent of the design is. The better we do at communicating, the higher quality testing we get. Seeing the development process from the inside can be fun and rewarding! But testing can also be a chore. For one thing, you’re testing something new! This means it’s probably volatile, something different and maybe risky. And that means the rules might not work as smoothly as we’d like. Well, that’s why we’re testing it! But it can take some iteration to get to a fun, polished product and the road there can be….bumpy.

Sometimes you gotta test stuff you don’t believe in. You might register your issues and the developers respond with “Sure, but we still want to try it a few times in actual play before we give up on it.” The path to a finished, polished design is never straight. There are dead ends and switchbacks and sometimes you gotta slog through some clunky design to get the kind of feedback necessary to make it polished and fun. The first role of a tester is to read the manuscript and let us know what you think. Does it sound fun? Does it comport with the grammar of 5e? Is there any language that’s confusing or ambiguous? Does the design conflict with any existing 5e design? These are things you can learn just from reading.

But it’s not always obvious how a new system or class or adventure will work just by reading it, so the next step is Play it. MCDM will let you know what kind of testing we’re looking for. Sometimes just a few Danger Room encounters is enough, sometimes it takes more, like a short adventure. When testing some new design we want to know...was it fun? Were the rules clear? Did it feel “balanced” compared to other, similar official 5e design? Sometimes new rules look good on paper, but turn out to be a pain to manage in Actual Play. Some stuff that seems overpowered when you read it, turns out to need a buff! And some stuff that seemed fine when you read it, turns out it needs a nerf. Actual Play is where we find this out.

Above all keep this in mind; you are playing on behalf of all the people NOT in the playtest. Bring your experience as a player and/or a GM with you into the test. Think about, not only what YOU did during the test, but how you imagine other players might use these tools. This class, these new spells, these items, whatever. When you’ve played something, let us know how it went! Was it fun? Tedious? If things didn’t go well, can you pinpoint why? Ultimately we want to know; would you use this in your game? Why or why not?

Things To Avoid

If you identify a problem, feel free to offer a solution as long as it’s relatively short and straightforward. “This would work better as a bonus action,” is good feedback. Tweaking a class ability or spell is easy. If your proposed solution involves ripping out an entire ability or system, and replacing it with some design of your own, then you’ve gone too far. We can’t use your design in our products. At the end of the day, it’s up to MCDM to decide if there’s a problem and, if there is, figure out how to solve it. If you use the playtest as a chance to redesign something from scratch, you’re just going to get frustrated when the Devs ignore your solution in favor of their own. This is why we need clear direct feedback, ideally unencumbered by flowery prose and personality.

The devs need to focus on the actual mechanics in question and the easier it is for us to get to the heart of an issue, the easier it will be to fix.

If you’re a tester long enough you will eventually experience the Devs going in a direction you very strongly disagree with. That is the nature of game development. A good tester makes their case for an issue, and moves on. Once you’re said your piece, you’ve done your job and now it's up to the Devs to figure out what to do about it. But some folks find they can’t let an issue go, and will take every opportunity to bring it up in other discussions. This is just a distraction. Good testers do not use new issues to go back and refight old battles. If you report a bug, and we mark it “No Fix Planned” or “Not A Bug” that is not a personal attack. It doesn’t mean you’re a bad tester, it just means for various reasons related to production or schedule or just intent, we’re not going to act on that bug. It’s the testers job to throw up everything they think might be an issue, and then the Dev’s job to figure out which bugs are actionable. It will not always be obvious why we mark a bug NFP or Not A Bug.

Ultimately, the buck for game design decisions stops at the developers. MCDM will never throw you under the bus for a bad design decision.