Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="pemerton" data-source="post: 5795141" data-attributes="member: 42582">Are you talking about challenging the players, or their PCs? I was talking mostly about challenges that the player wants his/her PC to confront - I didn't say anything about whether or not they are challenges for the player, although in fact I prefer a game where they are.Also, where does the idea of "getting through uncscathed" come from? My example was of a player who wants his/her PC to confront Orcus (or an avatar of Orcus). Why would you expect that the PC is going to come through that unscathed? Even if s/he defeats Orcus, it seems like the sort of confrontation that might have pretty big ramifications down the line (assuming it's not the culmination of the campaign).Yes. My preferred exit strategy is to find a GM who runs a game more in line with my preferences.As far as I can see, it actually is exactly about that. You're positing a scenario where the most important decision for the players is whether or not their PCs stay and fight, or run away.Here is <a href="http://www.indie-rpgs.com/articles/10" target="_blank">one take</a> on that playstyle (with some ellision and interpolation to correct for context):The key assumption . . . is that if a gaming experience is to be intelligent . . then the most players can be relied upon to provide is kind of the "Id" of play - strategizing, killing, and conniving throughout the session. They are the raw energy, the driving "go," and the GM's role is to say, "You just scrap, strive, and kill, and I'll show ya . . . how it's all a brilliant evocative fantasy." It's not Illusionism - there's no illusion at all, just movement across the landscape and the willingness to fight as the baseline player things to do. At worst, the players are apparently slathering kill-counters . . . sometimes, they are encouraged to give characters "personality" like "hates fish" or "likes fancy clothes"; and most of the time, they're just absent [as contributors to the content of the fantasy]At least as far as I can tell, you're paying no attention to why the fight might matter, what might motivate the PCs (and, indirectly thereby, the players) to think that this is something worth doing. And you seem to be ignoring the contribution that the players make to answering these questions, which in turn might shape the way a GM sets up the game. Which is the whole point of my Orcus example. If the player wants to play a game about his/her PC confronting Orcus, and the GM wants to GM that game, why would we all waste our time faffing around with rust monsters?It's nothing to do with being a "mewling pantywaist". It's about playing the game that you want to play.I know that I can't, using the AD&D mechanics, have a viable story about a PC confronting Orcus in battle if the PC doesn't have a +3 weapon. I know that, in 4e, I can't have a story about a PC confronting Orcus if the PC doesn't have an epic-tier weapon. These are mechancial facts about the game.Loss and death are red herrings. A PC who confronts Orcus might lose. Might die. The point is that it will be significant and worthwhile to the participants in the game.Two things. First, there is a difference between building an encounter, and resolving it. So even if the players of a game built all the encounters, that wouldn't be the same as scripting the game, because the encounters would still have to be resolved.Second, I play in a style which strongly emphasises the role of the GM in building encounters - among other things, this allows aspects of the gameworld that are unknown to, or unexpected by, the players to be brought into play. But I do my best to build encounters that will be interesting to my players, and that will let them take their PCs in the directions that they want to take them.If my players handed me a list of monsters that they weren't interested in having their PCs fight, I'd be happy to take account of it.At the start of my current campaign, I told all the players that they had to build PCs who had a reason to be ready to fight goblins (because I had a module, Night's Dark Terror, that I wanted to use, and it is premised on goblin-fighting). As it happened, all the players were happy with this instruction. If they hadn't been, though, for whatever reason, then I would have happily talked it through to work out what sort of campaign set up they were interested in playing that I was also in a position to run.I don't think so. This is why a unity edition has to support multiple playstyles - which is what I posted upthread.If by "dictating their own challenges" you mean designing the encounters that their PCs face, I've never played this way myself, and I think it <a href="http://isabout.wordpress.com/2010/02/16/the-pitfalls-of-narrative-technique-in-rpg-play/" target="_blank">faces some difficulties</a>, but I think the most obvious reason for doing it would be that the game would be guarnateed to focus on the things in which the players are interested.But if by "dictating their own challenges" you mean things like deciding who a PCs principal enemy will be, then that is pretty standard to a whole lot of RPG play. I assume you are aware of game designs which allow players to choose particular enemies of their PCs as part of the PC build process. In some games, like HERO, this is considered a disadvantage, because it gives the GM an excuse to lean heavily on that PC. In other games, like Burning Wheel, it is considered an advantage that the player must pay for, because the GM is going to lean heavily on everyone in BW, but at least if you pay for your enemy the GM is obliged to give you the story that you want. Either way, it is a player getting to choose his/her PC's adversary.Railroading is one way to make sure that the players don't get to contribute to the story in the way that they want to. For certain sorts of play, in certain systems (eg 4e, 3E and to a lesser extent AD&D), using encounters that degrade the PC build is another way.</blockquote>

Verification