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 . . .
Thursday, May 12, 2011
Welcoming the unwelcome
So, getting right to it - I read Vincent Baker's anyway blog from time to time, and a recent discussion (http://www.lumpley.com/comment.php?entry=585) grabbed my interest, on two counts. Both are quibbles, that I expect Vincent fully understands, but I could be wrong. And while quibbles, they seem important enough (at least from a communication perspective) to post about.
Comment 43 is the easiest place to build my first quibble on. The thing is, IMO, the someone-who-is-David would NOT be entirely wrong to say "so it's not really unwelcome." If it becomes satisfying, by some understandings it is definitionaly not unwelcome. What I think Vincent is pointing at though, is true and very important - that the game design should push us into something that we wouldn't have already have been likely to do, and that the push will be, in many cases, uncomfortable. It's not easy to come up with terminology that communicates just exactly what Vincent is talking about, and I totally understand why someone might object to "unwelcome." On the other hand, I *think* I totally get what Vincent is pointing at, and he's right. So . . . "pushed by the designer into an uncomfortable place" is my substitute for "unwelcome." 'Cause I can welcome being uncomfortable, I can be satisfied by being uncomfortable, and maybe I can't be satisfied by something unwelcome.
Quibble two is easier, and again I think entirely a communication style issue rather than something Vincent has "wrong." When he says (in comment 42) "a game should sometimes force the group to violate its social expectations" (emphasis added), what he means is a game should coerce. Should encourage. Should establish as a principle (heck, a requirement) for desirable play. Maybe even (for some games) should trick, fool or otherwise deceive. And etc. Because, as he makes clear he understands in other posts, a game can't force a group to do anything, the group (and individuals in it) always have the option to negotiate outside the game rules and/or simply stop playing at all.
To repeat - what Vincent is getting at here, to me, is how the designers job is to make a game that will lead a group somewhere they wouldn't already have gone. And to make that work. And that along the way something uncomfortable (using my word pretty much as a replacement for his "unwelcome") really needs to happen.
He's dead on with that, IMO.
Comment 43 is the easiest place to build my first quibble on. The thing is, IMO, the someone-who-is-David would NOT be entirely wrong to say "so it's not really unwelcome." If it becomes satisfying, by some understandings it is definitionaly not unwelcome. What I think Vincent is pointing at though, is true and very important - that the game design should push us into something that we wouldn't have already have been likely to do, and that the push will be, in many cases, uncomfortable. It's not easy to come up with terminology that communicates just exactly what Vincent is talking about, and I totally understand why someone might object to "unwelcome." On the other hand, I *think* I totally get what Vincent is pointing at, and he's right. So . . . "pushed by the designer into an uncomfortable place" is my substitute for "unwelcome." 'Cause I can welcome being uncomfortable, I can be satisfied by being uncomfortable, and maybe I can't be satisfied by something unwelcome.
Quibble two is easier, and again I think entirely a communication style issue rather than something Vincent has "wrong." When he says (in comment 42) "a game should sometimes force the group to violate its social expectations" (emphasis added), what he means is a game should coerce. Should encourage. Should establish as a principle (heck, a requirement) for desirable play. Maybe even (for some games) should trick, fool or otherwise deceive. And etc. Because, as he makes clear he understands in other posts, a game can't force a group to do anything, the group (and individuals in it) always have the option to negotiate outside the game rules and/or simply stop playing at all.
To repeat - what Vincent is getting at here, to me, is how the designers job is to make a game that will lead a group somewhere they wouldn't already have gone. And to make that work. And that along the way something uncomfortable (using my word pretty much as a replacement for his "unwelcome") really needs to happen.
He's dead on with that, IMO.
Giving up, then pushing on
So I've given up trying to coerce myself into a re-engagement with net interaction - either it happens, or not, on a case by case basis. Clearly claiming "I've got to start this again" and then not, for years, is useless.
But something over at Vincent's anyway blog (http://www.lumpley.com/) grabbed my attention, so - a post will follow.
But something over at Vincent's anyway blog (http://www.lumpley.com/) grabbed my attention, so - a post will follow.
Wednesday, April 29, 2009
Monday, August 28, 2006
Neglect, and frustration
(Do not ignore the comma)
So, I've sadly neglected this blog. That I do NOT feel bad about it doesn't change the fact that it is true.
In other news, I am utterly frustrated by the Forge "diaspora." If you have no clue what this is, you can ask me (but it's probably not worth it). If you do, I'm not reaching out in the hopes of finding others who share my frustration - some do, some don't. I'm just acknowledging a fact, here.
Anyway, the frustration is that a good portion of the time, I have no clue as to where to post, what discusion to join in, and etc. So I don't. I'll have to find some kind of solution to this, acuz frustration is useless, and not participating sucks.
So, I've sadly neglected this blog. That I do NOT feel bad about it doesn't change the fact that it is true.
In other news, I am utterly frustrated by the Forge "diaspora." If you have no clue what this is, you can ask me (but it's probably not worth it). If you do, I'm not reaching out in the hopes of finding others who share my frustration - some do, some don't. I'm just acknowledging a fact, here.
Anyway, the frustration is that a good portion of the time, I have no clue as to where to post, what discusion to join in, and etc. So I don't. I'll have to find some kind of solution to this, acuz frustration is useless, and not participating sucks.
Subscribe to:
Comments (Atom)