I can see two schools of thought about this:
- Assume this is your reader’s first PbtA game, explain it all.
- Assume most people are finding your game through the community, reference core materials and give a sense of the basics.
For a PbtA hack, how much should you explain about the system?
4 Likes
If you’re thinking of the game as a “hack” then making the text as small and compact as possible is a good idea, since you can focus what’s special about your game rather than recapitulating a bunch of material found elsewhere. That said, most successful games that get published will need to explain it all, so if you’re pretty sure you want to publish the game then maybe go ahead and start on figuring out how to explain things.
In practice, I would write a minimal hack, try play-testing it and sharing it with folks who are familiar with the space, and then based on its reception consider writing a more “complete” game as a follow-up.
6 Likes
Calris seems to have the right of it, I think. If you’re making something that’s never going to be “published” (Say, because it’s based on an IP you don’t own) you can probably skimp on this stuff – though if you do, I’d suggest SAYING so. Put in a clause that says “Hey, I’m not going to explain how Powered by the Apocalypse games work; I’m expecting you to know that. If you don’t, go check out >insert game here that you think does the best job of teaching how to play PbtA Games<”
But even that is unnecessary at early playtesting stages, since you’ll be running it, and you’ll know the people you are handing it off to to run at middle stages.
But yeah. If it’s a “hack” and billed as such, then I think most people won’t see it as a complete game anyway.
1 Like
I try to make games which are standalone as much as possible, since I can’t assume they’ve played any particular prior game. And honestly, at some point, it’s just less laborious to say “it works like X” rather than “okay, so take Move X from this game, but change Y and Z”.
Unless you’re talking about advice sections, etc. In that event, I’ll sometimes leave that out unless I’m going to put a lot of effort into the game. But I feel that (with the exception of early playtest stages that aren’t intended to be widely distributed) any text I put out there should be theoretically playable by anyone who stumbles across it.
Here’s an example of what I try to get at, it’s a World of Dungeons hack that I may or may not flesh out or revise in the future, dashed off very quickly. https://docs.google.com/document/d/1_1qyOaT4kFBcl9QbiCxC0p1ZBE9D8m76fDW3jY69Jfc/edit?usp=sharing
I was thinking less about moves and more about the general “how to play this game” part. Stuff like, “When does the GM make a move?” and the like. Which isn’t strictly speaking an “advice” section, but is still something that you probably don’t need to write on a hack.
1 Like
In early versions Fourth World, I only included things that changed from the sources I was hacking, with a note that those sources were “required reading”. Feedback told me that this was confusing. Eventually, my conclusion was this: if you are hacking some of the basic moves of a game, even if your text only mentions the stuff you are changing, you should have a reference sheet that contains the original moves and those you have changed together. That way, players don’t have to guess, or go back and forth between books.
The more generic sections like “How to Play” or the bestiary, I left out, and no one seemed to mind.
1 Like
I like that everyone has sort of their own twist on the same concepts. This is really helpful. I’m working on writing a full PbtA system at the moment, so I assumed I’d need to spell everything out, but his is affirming. I have a lot of ideas of little 10-page hacks and if the purpose is bite-sized changes, it’s hard to figure out where to draw those lines.
1 Like