Social-Play Model: Social Contract vs. Play
Bruce asked me about my Social-Play Model:
This may be my lack of familiarity with TBM but I was wondering if you might elaborate on your division between Social Contract and Play, more specifically on the fact that Procedures, System, Techniques and IIEE sit outside Play in your model. I think I can kind of see what you're getting at but am myself inclined to think of these as elements of play. Any thoughts?
These things create play but are not play themselves. Here's an analogy.
Take, for the sake of example, a cook. I'm not much of a cook myself, so I'm gonna stick to what I know: barbecue. Okay? So a bunch of people want to come together and grill some steaks, and eat them. They're the players in the analogy. The play is the act of cooking and eating the steaks. All the social contract stuff in the model? That's the tools by which cooking and eating get done: the agreement to meet at my house on Saturday at noon, my bad-ass cast iron charcoal grill, the charcoal and lighter fluid, the tongs and spatula, and the steaks themselves. It's tempting to want to categorize the steaks in the cooking and eating category, but they're not. They're the material, not the act.
Now let's go back to my Social-Play Model. When you role-play, a bunch of players agree to get together, use some set of rules, apply those rules as specific techniques, and talk and stuff. All that stuff is Social Contract in the model, because it's the means of play, not play itself.
To use another analogy -- this one a bit specialized -- take object-oriented programming. In such languages you have classes, which are generalized collections of methods and data, and you have objects, which are specific instantiations of classes. For example, the RolePlayingGame class might be your representation of all games you have on your bookshelf, but when you look at a specific game on your shelf (via the code) then you need to get a particular object. In the Social-Play Model, play is the specific instantiation of a social contract.
Bruce said almost exactly the same thing in his own article, RPG Theory Journey: back to basics (January 23, 2008):
I’m going to start with a statement that I made in a post I wrote a few months back which basically theorised that the constituent elements of roleplay were Players (the participants), the Game (the system of play) and Story (the product of play).
We're saying the same thing. My Players are Bruce's Players. My Play is Bruce's Story (we're using the two terms to mean exactly the same thing: the product of play). My Social Contract is Bruce's Game. The system of play in my model includes the Social Contract because that's how play really happens.
This may be my lack of familiarity with TBM but I was wondering if you might elaborate on your division between Social Contract and Play, more specifically on the fact that Procedures, System, Techniques and IIEE sit outside Play in your model. I think I can kind of see what you're getting at but am myself inclined to think of these as elements of play. Any thoughts?
These things create play but are not play themselves. Here's an analogy.
Take, for the sake of example, a cook. I'm not much of a cook myself, so I'm gonna stick to what I know: barbecue. Okay? So a bunch of people want to come together and grill some steaks, and eat them. They're the players in the analogy. The play is the act of cooking and eating the steaks. All the social contract stuff in the model? That's the tools by which cooking and eating get done: the agreement to meet at my house on Saturday at noon, my bad-ass cast iron charcoal grill, the charcoal and lighter fluid, the tongs and spatula, and the steaks themselves. It's tempting to want to categorize the steaks in the cooking and eating category, but they're not. They're the material, not the act.
Now let's go back to my Social-Play Model. When you role-play, a bunch of players agree to get together, use some set of rules, apply those rules as specific techniques, and talk and stuff. All that stuff is Social Contract in the model, because it's the means of play, not play itself.
To use another analogy -- this one a bit specialized -- take object-oriented programming. In such languages you have classes, which are generalized collections of methods and data, and you have objects, which are specific instantiations of classes. For example, the RolePlayingGame class might be your representation of all games you have on your bookshelf, but when you look at a specific game on your shelf (via the code) then you need to get a particular object. In the Social-Play Model, play is the specific instantiation of a social contract.
Bruce said almost exactly the same thing in his own article, RPG Theory Journey: back to basics (January 23, 2008):
I’m going to start with a statement that I made in a post I wrote a few months back which basically theorised that the constituent elements of roleplay were Players (the participants), the Game (the system of play) and Story (the product of play).
We're saying the same thing. My Players are Bruce's Players. My Play is Bruce's Story (we're using the two terms to mean exactly the same thing: the product of play). My Social Contract is Bruce's Game. The system of play in my model includes the Social Contract because that's how play really happens.