How complete does an alpha need to be?

[Orion]

Suppose you have the friendly acquaintance of 3-4 folks who have each played one or two RPGs once or twice, but with not much overlap in experience and no strong commitment to one system. You mention the concept of a game you've been writing meaning to write and they express willingness to test it. How finished would you want your game to be before you inflicted it on your acquaintances? What are the minimum required features?

[Seerow]

A resolution mechanic and a good enough idea of what character stats should look like to have a couple of premade sample characters should be enough to get started. Beyond that depends entirely on how complex of a system you are aiming to create.

[Orion]

Assume something about After Sundown level -- stats and skills, special abilities selected off lists, a combat system where each character has a few special moves, and a moderately large but knowable pool of enemy critters.

EDIT: And, assume that you want to run a campaign of 5-8 sessions, not a 1-shot.

[Chamomile]

Ideally, you'd want to begin testing as soon as you have something, anything playable ready. In practice, you'll want to adjust the level of completeness to your friends' tolerance for half-finished or poorly considered mechanics. There is not any stage of design where it is helpful to have less feedback.

EDIT: Oh, another thing to consider is repeat tests, though. You'll want the game to be complete and balanced enough that your group will be willing to run a short test campaign again sometime in the future so that you can continue playtesting after you've made modifications. This is entirely dependent on what your group's tolerance for this kind of thing is.

I should also state for the record that I am not endorsing the Mike Mearls school of game design. You cannot release a million playtest packets and try to build your game out of the audience feedback. Volunteer playtesters can reliably tell you when something has gone wrong, but cannot reliably tell you what it is or how to fix it. How to handle feedback isn't really the point of this thread, though.

[TarkisFlux]

What Cham said. If they're will to play something that potentially doesn't work, do that. You'll find out that it...
[*]doesn't work like you though it would, so you can make adjustments before you get much farther or too settled on things,
[*]does work well enough, so you can move forward with less second guessing and backward looking,
[*]some combination of the above with respect to different parts.
The sooner you know that stuff, the better you can build the right parts of it all. And because you're actually at the table, you can avoid a bit of reporting bias.

Just make sure that they know things can change as things go on, and that only the parts that work are set in stone. And buy them pizza or whatever in thanks for their willingness to play along.

[Dogbert]

Do a flowchart starting with chargen and ending with the end of your first session, include in said diagram sub charts for 1 combat, 1 social combat, 1 detective minigame, and 1 baseball game. If your desktop run* crashes at any point in between, it's not ready for test.

"I haven't thought of this situation yet" is a valid answer during a test, a sudden blue-screen equivalent like "combat started and I never bothered in a criteria for calculating damage avoidance/mitigation" is not.

* Could any IT people enlighten me on the English term for when you test an algorithm in paper before implementing it in a program?

[Zaranthan]

* Could any IT people enlighten me on the English term for when you test an algorithm in paper before implementing it in a program?

"Desk check"

[Red_Rob]

Explaining a system in person is a lot easier than transmitting the knowledge purely through written means, and having the system designer there in person makes it easier still. Due to this if you are planning on running the game yourself I'd say you just need enough of the system that you feel confident in running basic a scenario and adjudicating if anything comes up outside the rules you have written.

After all, part of the reason you are testing is to see how stuff works at the table. You don't want to write the entire system and find out the basic resolution method is too cumbersome during play.

[OgreBattle]

Suppose you have the friendly acquaintance of 3-4 folks who have each played one or two RPGs once or twice, but with not much overlap in experience and no strong commitment to one system. You mention the concept of a game you've been writing meaning to write and they express willingness to test it. How finished would you want your game to be before you inflicted it on your acquaintances? What are the minimum required features?

Getting down the core resolution mechanic, the skeleton of the game. The alpha is to test what you need to change with your PC's, Monsters, powers, all of the meat that goes over the skeleton.

Though the thing with tabletop games is that it's relatively inexpensive to adjust anything on the fly.

[PhoneLobster]

Rather than "testing" a system here you are talking about taking something you are working on and actually playing a proper ongoing game with it, which really isn't quite the same as testing it.

I've done a lot of it and I've done it two ways that worked.

1) Have a pretty complete system.
I mean, well, duh, if you have a system that is fairly complete in the options it covers you are pretty good to go. Having no answer to "What happens if I fall off something or try to wrestle stuff" is a pretty incomplete system that will cause problems, having no options for a specific fruit flavor of obscure voodoo wizardry you intend to get around to adding is not a big deal.

2) Build the whole thing as you go.
I ran one of my favorite recent campaigns like this. I had the firm mechanics for basic combat and resolution complete, I offered a selection of premade characters with fixed pre-written abilities, I had enough NPCs and items for the first adventure. And of course a pretty strong concept for the style, setting and over all direction of the campaign.

Then between adventures as well as coming up with the next game worth of adventures and NPCs, I was also writing up the new PC skills, items, and other mechanical options as they came up.


Now clearly the first option is workable and better. The second option can work, but I tell you one thing. Sure it worked for running that one campaign, but it left me with just about nothing usable as a final complete rules set that I could use for any other game. The final product from that was a big, highly campaign specific, total mess.

The games I went into with the first strategy were ones where any further rules modifications or additions were ones which were of use in more than one specific campaign. They were also not a total and utter chaotic mess.

[codeGlaze]

Explaining a system in person is a lot easier than transmitting the knowledge purely through written means, and having the system designer there in person makes it easier still.

This would be the big difference between alpha and beta imo.

Beta you expect the material to stand well enough on it's own that you don't need to be present for people to try and use it. Alpha you are still hot-gluing pieces back on as they fall off.
Alpha is also very iterative and liquid. Big and small pieces are constantly being put on or taken off as they are developed to a stay of use.

[Dogbert]

"Desk check"

Much obliged.

[K]

I'd probably write at least one canned adventure, then make sure that I had all the mechanics to cover the all the things I think could happen in that adventure. Players will always surprise you, but it's not hard to imagine that a planned fight needs a combat system and a planned diplomatic negotiation needs a decision to be made on how you want to handle that even if you want social stuff to be made of handwavium.

[tussock]

You need mechanics and numbers. Rolling dice, reading them, doing math with them, understanding what numbers you can actually generate, what your modifiers will look like.

Alpha is proof of concept, showing other people that what you have actually works, because you know it works but you just need to check it works with other people in the room. What they lack is content, one character fighting one monster with the most basic possible gear and choices is sufficient. It's a test: does rolling the dice do the thing you think it does?

Then you stop that and write all of the content. Any further unique mechanics also need an alpha test, but mostly you just write a game.

Beta is where you're finished writing it but it's probably full of bugs, so you show people and they tell you about how it doesn't run and you fix it so it does. There are a lot of betas, you just crap them out for a while until the remaining bugs become accepted.

Then you write your documentation, explaining the things people have trouble figuring out in beta, and also everything else.

Release candidates are next. Get random people to see if it works without having any help at all. This never works the first time, but RC3 usually makes it, or sometimes it's RC7, or 13, or they cancel your project and never mind. Often you just put workarounds in the docs, because it's far too late to fix stuff that didn't really work in alpha.

Gold is last. You print the thing, and it boots. Then you start patching the weird corner cases that the general public report, again, mostly as workarounds. Sometimes you wrote +1 and it's supposed to be +10, but usually it's fine.

---

Ideally, your alpha can test everything the game is supposed to be able to do. Realistically for an epic-scale RPG like D&D you have to have several alpha stages for different components. God-tier should work and steve-tier should work (and also both Fighters and Wizards) but you're probably not going to have them ready all at once.