The question of game contracts
Apr. 13th, 2003 12:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
lathanyA recent entry by ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
smiorgan got me thinking about game contracts. Recent LJ postings (and conversations) suggest that they are The New Big Thing (TM) and that no game should be run without them. However, smiorgan was sceptical and, frankly, so am I.
Of course, it is usually a good idea to let your players know what sort of game you plan to run. This saves an awful lot of disappointment on both sides. And most GMs (that I know) do it, either informally (whilst chatting to potential players) or otherwise.
For example,bateleur's Monde website includes a Game Style section with comments from "The two focal aspects of the game throughout will be plot and roleplaying in roughly equal measure" to "Perhaps the least accessible aspect of the game style is that I don't want to run a 'beer and pretzels' game" (although onebyone broke this rather literally last session with his choice of snacks ;-) ). My Fallen Star website included the fact that I wasn't going to reveal the choice of genre to the players (their 'murder mystery' cruise included a trip to hell).
However, to me, much of the information provided in this way is to inform the players about the game so that they can choose to play or not to play. It isn't a list of guarantees, it's a set of guidelines. Roleplaying can only be planned so far; there is a certain amount of improvisation, not to mention twists and surprises in any game. When it comes down to it, I regard roleplaying as a social activity; I'll try and run a good game / play a good character and hope that the players / GM enjoys it.
A contract adds a level of formality that I'm personally not terribly keen on. If a player of mine has a problem with my game or GMing style, I'd hope that they would come and chat to me privately about it. If I agree it's broke, I'll fix it; if I think it's a question of style I'll explain and if I think they're plain wrong, I'll tell them that (as tactfully as I can manage). I don't feel that having a contract adds anything here - because it makes the initial approach more confrontational (ie. "You're doing Y where the contract states X").
Of course, the whole issue of providing any sort of feedback is controversial. There is, perhaps, a case to be made for saying nothing, staying to the end of the game (assuming it isn't a long or open-ended campaign) and then quietly noting to oneself, that that particular game-type/GMing style doesn't suit and not playing again. It avoids any sort of confrontation with the GM. However, I'm less convinced that the person who goes this route would suddenly take the feedback option just because there was a 'game contract'.
Overall I regard guidelines, information on what the game will contain, as a Good Thing. Particularly for open-invite games where players know little about the GM(s) or their likely styles/genres/session format. But I don't like the idea of making such things a contract. It adds a sense of formality which a game doesn't need.
smiorgan got me thinking about game contracts. Recent LJ postings (and conversations) suggest that they are The New Big Thing (TM) and that no game should be run without them. However, smiorgan was sceptical and, frankly, so am I.Of course, it is usually a good idea to let your players know what sort of game you plan to run. This saves an awful lot of disappointment on both sides. And most GMs (that I know) do it, either informally (whilst chatting to potential players) or otherwise.
For example,
bateleur's Monde website includes a Game Style section with comments from "The two focal aspects of the game throughout will be plot and roleplaying in roughly equal measure" to "Perhaps the least accessible aspect of the game style is that I don't want to run a 'beer and pretzels' game" (although onebyone broke this rather literally last session with his choice of snacks ;-) ). My Fallen Star website included the fact that I wasn't going to reveal the choice of genre to the players (their 'murder mystery' cruise included a trip to hell).However, to me, much of the information provided in this way is to inform the players about the game so that they can choose to play or not to play. It isn't a list of guarantees, it's a set of guidelines. Roleplaying can only be planned so far; there is a certain amount of improvisation, not to mention twists and surprises in any game. When it comes down to it, I regard roleplaying as a social activity; I'll try and run a good game / play a good character and hope that the players / GM enjoys it.
A contract adds a level of formality that I'm personally not terribly keen on. If a player of mine has a problem with my game or GMing style, I'd hope that they would come and chat to me privately about it. If I agree it's broke, I'll fix it; if I think it's a question of style I'll explain and if I think they're plain wrong, I'll tell them that (as tactfully as I can manage). I don't feel that having a contract adds anything here - because it makes the initial approach more confrontational (ie. "You're doing Y where the contract states X").
Of course, the whole issue of providing any sort of feedback is controversial. There is, perhaps, a case to be made for saying nothing, staying to the end of the game (assuming it isn't a long or open-ended campaign) and then quietly noting to oneself, that that particular game-type/GMing style doesn't suit and not playing again. It avoids any sort of confrontation with the GM. However, I'm less convinced that the person who goes this route would suddenly take the feedback option just because there was a 'game contract'.
Overall I regard guidelines, information on what the game will contain, as a Good Thing. Particularly for open-invite games where players know little about the GM(s) or their likely styles/genres/session format. But I don't like the idea of making such things a contract. It adds a sense of formality which a game doesn't need.
