Thinking about the discussion at anyway has inspired yet another thought. I think it would be quite interesting to use this as a starting point for thinking about roleplaying, and see where it leads. The thought is something like this: the purpose of system in an RPG is to generate validation of contributions (including, but not limited, to moves?) to the fiction, and that validation is perpetually contingent - that is, it can be challenged, retracted, or modified at any time.
That may still need a ton of work, and it may not say anything more than what Boss-Baker already say. Or - part of that principle is about the realization of what system is: that it is revealed retroactivly by whatever the people involved actually do. It certainly touches on what system is for (its' purpose), but maybe it would be helpful to split things up into what system IS, where it comes FROM, and what it DOES?
All still less-than-full-formed, but I wanted to get something down in case the holidays overwhelmed me.
Sunday, December 23, 2012
Thursday, December 13, 2012
More Ownership/Authority/etc. in RPGs
More posting inspired by Vincent Bakers' anyway. For all the (uncorrected) flaws I currently see in it, I think the section below from my book SNAP covers a lot of what I'd have to say about ownership/authority/leadership in RPGs:
Step Zero: Collaboration, Leadership, and “the last word”
Yes, I’m calling this first step “step zero,” because it surfaces throughout both the story preparation process and the actual play of the story. You’re never entirely done with step zero, because it describes some of the basic fundamentals of what it takes to make SNAP work.
The driving principle behind everything in SNAP is collaboration. If you want to create a story on your own, there are plenty of books and teachers to help with that process – SNAP isn’t one of them. As players, everyone is working towards the same goal: to create an engaging story involving the various PCs (either together or separately). That doesn’t mean leadership is unimportant. A collaborative enterprise always needs leaders, organizers, instigators, managers – that’s just how the process works.
The discussion of story preparation above mentioned one thing that needs “leadership” in SNAP: guiding the group through these steps and recording some of the results. That’s a role that needs to be filled. There are, of course, lots of ways to take care of that. But to keep things simple, this book assumes there is one person who takes on that role and a number of other leadership roles in SNAP. I’m calling that person the story leader, and wherever you see those words, you can mentally add a parenthetical “or whichever person or persons the group has agreed will take on that role.”
But since SNAP is a collaborative process, the story leader is never SOLELY responsible for anything in play. Everyone should keep in mind from time to time the issues that the story leader has to deal with, and should feel free to offer ideas and suggestions about those things at appropriate times during (as well as outside of) play.
Part of the point of having a leader, though, is have someone who can get “the last word” in a discussion that’s just not getting anywhere. Someone who, after all the discussion and debate, has the authority and responsibility to make a decision that everyone will then follow.
The SNAP system is actually set up so that the last word does not always fall to the story leader – at certain times in play, or about certain issues in play, it is another player who has the ultimate authority and responsibility. Of course, it’s often good to accept input from others, including the story leader, but those decisions will ultimately be their call.
Step Zero: Collaboration, Leadership, and “the last word”
Yes, I’m calling this first step “step zero,” because it surfaces throughout both the story preparation process and the actual play of the story. You’re never entirely done with step zero, because it describes some of the basic fundamentals of what it takes to make SNAP work.
The driving principle behind everything in SNAP is collaboration. If you want to create a story on your own, there are plenty of books and teachers to help with that process – SNAP isn’t one of them. As players, everyone is working towards the same goal: to create an engaging story involving the various PCs (either together or separately). That doesn’t mean leadership is unimportant. A collaborative enterprise always needs leaders, organizers, instigators, managers – that’s just how the process works.
The discussion of story preparation above mentioned one thing that needs “leadership” in SNAP: guiding the group through these steps and recording some of the results. That’s a role that needs to be filled. There are, of course, lots of ways to take care of that. But to keep things simple, this book assumes there is one person who takes on that role and a number of other leadership roles in SNAP. I’m calling that person the story leader, and wherever you see those words, you can mentally add a parenthetical “or whichever person or persons the group has agreed will take on that role.”
But since SNAP is a collaborative process, the story leader is never SOLELY responsible for anything in play. Everyone should keep in mind from time to time the issues that the story leader has to deal with, and should feel free to offer ideas and suggestions about those things at appropriate times during (as well as outside of) play.
Part of the point of having a leader, though, is have someone who can get “the last word” in a discussion that’s just not getting anywhere. Someone who, after all the discussion and debate, has the authority and responsibility to make a decision that everyone will then follow.
The SNAP system is actually set up so that the last word does not always fall to the story leader – at certain times in play, or about certain issues in play, it is another player who has the ultimate authority and responsibility. Of course, it’s often good to accept input from others, including the story leader, but those decisions will ultimately be their call.
Wednesday, December 05, 2012
What's really happening with fictional timelines
That amazingly clever monkey (in so many ways that definitely include RPG play and design) Vincent Baker is up to his new/old tricks over on his blog (http://www.lumpley.com/). In service of what I expect will be some really interesting, not yet revealed conclusions, he's talking about "fictional timelines" and "fictional positioning." After some poking, I'm pretty sure he's got a perfectly good conceptual underpinning for what he's building, but as he acknowledges, fictional timelines are tricksy beasts. So I'm putting some stuff about how I'd think about that term here, to avoid further clogging-up his progress over there.
Key to my thinking is that a "fictional timeline" is, at the fundamental level, a wholly ephemeral and arbitrary creation. Every time we need it, we recreate it in its' entirety. In the examples Vincent is using, every time a player makes a "move," and every time within that move that there is an opportunity for any of the players to communicate (in the broadest sense), it would be more accurate to say "we create a new fictional timeline" than it is to say that "the fictional timeline advances." It's also incredibly unwieldy to think/talk about it that way all the time, because quite often the new timeline we construct is a LOT like the previous one. This is particularly true within the confines of a particular move (a particular IIEE cycle, to use the Forge shorthand).
But the facts are the facts - a single, coherent fictional timeline simply doesn't exist. Yet persisting the components of the timeline each time it is created is (with caveats and nuances) often very, VERY desireable. It's not so hard to do that within a single IIEE cycle - that's part of why thinking about IIEE is so useful. But it becomes more problematic to do so across a whole session of play, and especially problematic across multiple sessions of play. Good design will really help, though, and I expect that's part of where Vincent is heading.
I wouldn't think of this as treating a fictional timeline "concretely," however - I think that lures us too far into thinking about the fictional timeline as "just like" a real world timeline. I'm not sure what to do about the fact that it's innacurate but helpful to talk about any fictional timeline other than the one we built right now. I'd rather talk about PERSISTING past (real world past) decisions about fictional elements, events and interactions than MAINTAINING a concrete timeline.
So maybe - if I were in charge, most things Vincent labels "fictional timeline" I'd just call "persistent fiction." On those occasions when it's useful to talk about the timeline of that fiction (e.g., IIEE), we can do so within the "persistent fiction" umbrella.
At least given how I'm understanding all this right now . . .
Subscribe to:
Posts (Atom)