then when they go to a meetup or a con, anyone they meet will have a different version
No, that would actually be wonderful. We can learn from each other and compile our best findings.
That’s...not the strategy I would choose for playtesting multiple versions of a game. Consider:
Testers aren’t familiar with the mainline version and don’t know how their version differs from it, so can’t explain what their test condition is or how their results differ
You don’t know how their version differs either, or even whether it differs, except by getting them to teach you their full rules.
There’s a high risk they will accidentally leave out important details of the rules—even professional rulebooks often have issues, and that’s not what you’ll be getting. So interpreting whatever feedback you get will be a significant issue.
You can’t guarantee that any particular version gets tested
You can’t exclude variants that you believe are not worth testing
You can’t control how much testing is devoted to each version
Many players may invent bad rules and then blame their bad experience on your game, or simply refuse to play at all if you’re going to force them to invent rules, so you end up with a smaller and less-appreciative playerbase overall
The only real advantage I see to this strategy is that it may result in substantially more testers than asking for volunteers. But it accomplishes that by functionally deceiving your players about the fact that they’re testing variants, which isn’t a policy I endorse, either on moral or pragmatic grounds.
Most of the people that you’ve tricked into testing for you will never actually deliver any benefits to you. Even among volunteers, only a small percentage of playtesters actually deliver notable feedback (perhaps a tenth, depending on how you recruit). Among people who wouldn’t have volunteered, I imagine the percentage will be much lower.
[failed line of thought, don’t read]
Maybe limit it to bringing 1 thing with you? But notice this permits “stealing” items from other players, since “being carried” is not a persistent state.
“longer descriptions of the abilities”
I’d like that. That would be a good additional manual page, mostly generated.
If you’re imagine having a computer program generate this, I’m not sure how that could work. The purpose is not merely to be verbose, but to act as a FAQ for each specific ability, hopefully providing a direct answer whatever question prompted them to look that ability up.
If you aren’t familiar with this practice, maybe take a look at the Dominion rulebook as an example.
That’s...not the strategy I would choose for playtesting multiple versions of a game. Consider
I think you misunderstood, I wouldn’t write the manual this way after publishing for a broad audience. It’s just fine for developers. But there are also some other reasons that stuff is less relevant:
It’s a game about choosing whatever rules make the most sense. Mainly setting laws, rather than game rules, but the mindset transfers.
Everyone has complete information, and players are generally cooperatively striving towards mutual understanding (rather than away from it), so everyone’s assumptions about the game rules are visible, if there’s a difference in interpretation, you’ll notice it in peoples’ choices and you’re usually going to want to bring it up.
Speaking as a developer, I would rather have a complete worked-out example as a baseline for my modifications than a box of loose parts.
I do not think that the designer mindset of unilaterally specifying neutral rules to provide a good experience for all players is especially similar to the negotiator mindset of trying to make the deal that will score you the most points.
I haven’t played Optimal Weave yet, but my player model predicts that a nontrivial fraction of players are going to try to trick each other during their first game. Also I don’t think any hidden info or trickery is required in order for rule disagreements to become an issue.
That’s...not the strategy I would choose for playtesting multiple versions of a game. Consider:
Testers aren’t familiar with the mainline version and don’t know how their version differs from it, so can’t explain what their test condition is or how their results differ
You don’t know how their version differs either, or even whether it differs, except by getting them to teach you their full rules.
There’s a high risk they will accidentally leave out important details of the rules—even professional rulebooks often have issues, and that’s not what you’ll be getting. So interpreting whatever feedback you get will be a significant issue.
You can’t guarantee that any particular version gets tested
You can’t exclude variants that you believe are not worth testing
You can’t control how much testing is devoted to each version
Many players may invent bad rules and then blame their bad experience on your game, or simply refuse to play at all if you’re going to force them to invent rules, so you end up with a smaller and less-appreciative playerbase overall
The only real advantage I see to this strategy is that it may result in substantially more testers than asking for volunteers. But it accomplishes that by functionally deceiving your players about the fact that they’re testing variants, which isn’t a policy I endorse, either on moral or pragmatic grounds.
Most of the people that you’ve tricked into testing for you will never actually deliver any benefits to you. Even among volunteers, only a small percentage of playtesters actually deliver notable feedback (perhaps a tenth, depending on how you recruit). Among people who wouldn’t have volunteered, I imagine the percentage will be much lower.
Maybe limit it to bringing 1 thing with you? But notice this permits “stealing” items from other players, since “being carried” is not a persistent state.
If you’re imagine having a computer program generate this, I’m not sure how that could work. The purpose is not merely to be verbose, but to act as a FAQ for each specific ability, hopefully providing a direct answer whatever question prompted them to look that ability up.
If you aren’t familiar with this practice, maybe take a look at the Dominion rulebook as an example.
I think you misunderstood, I wouldn’t write the manual this way after publishing for a broad audience. It’s just fine for developers. But there are also some other reasons that stuff is less relevant:
It’s a game about choosing whatever rules make the most sense. Mainly setting laws, rather than game rules, but the mindset transfers.
Everyone has complete information, and players are generally cooperatively striving towards mutual understanding (rather than away from it), so everyone’s assumptions about the game rules are visible, if there’s a difference in interpretation, you’ll notice it in peoples’ choices and you’re usually going to want to bring it up.
Speaking as a developer, I would rather have a complete worked-out example as a baseline for my modifications than a box of loose parts.
I do not think that the designer mindset of unilaterally specifying neutral rules to provide a good experience for all players is especially similar to the negotiator mindset of trying to make the deal that will score you the most points.
I haven’t played Optimal Weave yet, but my player model predicts that a nontrivial fraction of players are going to try to trick each other during their first game. Also I don’t think any hidden info or trickery is required in order for rule disagreements to become an issue.