How complete does an alpha need to be?
Moderator: Moderators
How complete does an alpha need to be?
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?
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.
EDIT: And, assume that you want to run a campaign of 5-8 sessions, not a 1-shot.
Last edited by Orion on Mon Mar 16, 2015 8:45 pm, edited 1 time in total.
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.
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.
Last edited by Chamomile on Mon Mar 16, 2015 11:23 pm, edited 3 times in total.
-
- Duke
- Posts: 1147
- Joined: Sun Jun 22, 2008 9:44 pm
- Location: Magic Mountain, CA
- Contact:
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.
[*]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.
The wiki you should be linking to when you need a wiki link - http://www.dnd-wiki.org
Fectin: "Ant, what is best in life?"
Ant: "Ethically, a task well-completed for the good of the colony. Experientially, endorphins."
Fectin: "Ant, what is best in life?"
Ant: "Ethically, a task well-completed for the good of the colony. Experientially, endorphins."
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?
"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?
Last edited by Dogbert on Mon Mar 16, 2015 10:45 pm, edited 1 time in total.
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.
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.
Simplified Tome Armor.
Tome item system and expanded Wish Economy rules.
Try our fantasy card game Clash of Nations! Available via Print on Demand.
“Those Who Can Make You Believe Absurdities, Can Make You Commit Atrocities” - Voltaire
Tome item system and expanded Wish Economy rules.
Try our fantasy card game Clash of Nations! Available via Print on Demand.
“Those Who Can Make You Believe Absurdities, Can Make You Commit Atrocities” - Voltaire
- OgreBattle
- King
- Posts: 6820
- Joined: Sat Sep 03, 2011 9:33 am
Re: How complete does an alpha need to be?
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.Orion wrote: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?
Though the thing with tabletop games is that it's relatively inexpensive to adjust anything on the fly.
Last edited by OgreBattle on Tue Mar 17, 2015 5:34 am, edited 1 time in total.
-
- King
- Posts: 6403
- Joined: Fri Mar 07, 2008 7:54 pm
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.
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.
Phonelobster's Self Proclaimed Greatest Hits Collection : (no really, they are awesome)
Phonelobster's Latest RPG Rule Set
The world's most definitive Star Wars Saga Edition Review
That Time I reviewed D20Modern Classes
Stories from Phonelobster's ridiculous life about local gaming stores, board game clubs and brothels
Australia is a horror setting thread
Phonelobster's totally legit history of the island of Malta
The utterly infamous Our Favourite Edition Is 2nd Edition thread
The world's most definitive Star Wars Saga Edition Review
That Time I reviewed D20Modern Classes
Stories from Phonelobster's ridiculous life about local gaming stores, board game clubs and brothels
Australia is a horror setting thread
Phonelobster's totally legit history of the island of Malta
The utterly infamous Our Favourite Edition Is 2nd Edition thread
This would be the big difference between alpha and beta imo.Red_Rob wrote: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.
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.
Last edited by codeGlaze on Tue Mar 17, 2015 6:04 am, edited 1 time in total.
Phlebotinum : fleh-bot-ih-nuhm • A glossary of RPG/Dennizen terminology • Favorite replies: [1]
nockermensch wrote:Advantage will lead to dicepools in D&D. Remember, you read this here first!
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.
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.
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.
PC, SJW, anti-fascist, not being a dick, or working on it, he/him.