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

Reply to thread

Message: <blockquote data-quote="Celebrim" data-source="post: 9197156" data-attributes="member: 4937">I understand the system quite well.  If people enjoy it, then I'm all for it.  I have long said that contrary to received wisdom, based on my experience and on surveys I've made on my players enjoy a railroad more than a sandbox.  I enjoy a sandbox more than a railroad, so I give them more sandbox than they really want, but I do know that the more linear adventures are typically the ones that are more enjoyed and that most players appreciate a certain amount of story force.  So that games which privilege story forcing behavior are enjoyed by many doesn't surprise me.But I do think we need to actually understand what is happening during play and not engage in cake eating arguments where we pretend that isn't railroading merely because we see railroading as a pejorative.  It is both railroading and functional play that people enjoy, but to pretend it isn't railroading is to deceive yourself.Because again, if what was really going on was cooking the food resulted in something that caused the group to be discovered by bandits when greater skill at cooking food wouldn't have resulted in that, then a party ought to be allowed to mitigate against the failure.  The player ought to be able to propose, "I want to prepare a meal, but if I can't find dry tinder that won't smoke or if it looks like it's going to take too long, then I'll just abandon the project."  There shouldn't be this handwave where you have to tell the player what they did and how it failed.  Bandits shouldn't have to be invented as a result of a cooking failure.  Avoiding that situation often involves very different resolution mechanics that you get in trad play.  For example, you might have fortune in the beginning where you the scene by deciding whether or not the player will fail or succeed, and then you play out the scene based on that understanding with the player leaning into the fortune guidelines to explain what the character does to fail.  And that's fine, but that's a major impact on the aesthetics of play.  Don't try to pretend that the experience of that is just better trad play instead of something entirely different.  I'm glad people brought up the cooking scene with Sam and Frodo.  There are multiple ways we can imagine this scene being created by a game.  The important thing to realize though is that in trad play, there were at least 2 skill checks made by Sam.  The first one was a cooking skill check aided by the cooking utensils he'd been carrying.  This one was a success and Frodo's morale and strength was increased enabling him to continue resisting the ring and going on with the quest.  Not only that, Sam successfully builds a stealthy fire that wouldn't be detected by the Rangers.  The second one was some sort of endurance or survival check where after the meal, Sam - contented from his meal - fell asleep without putting out his fire, resulting in it spreading to the green ferns nearby which unlike the dry bracken Sam had used produced visible smoke and attracted attention.   Now this makes sense in traditional linear play and the consequences of each check seem tightly related to the skill being tested.  Sam is a good cook but he frequently falls asleep when he should be on watch.  That's part of his character sheet.If we have non-traditional play sure we can have the seen be generated by a single roll that is "Success with complications" and we can allow the GM or the group to decide what those complications are based on what they think would make is a good story, but that act of deciding based on "what you think is a good story" is an act of railroading.  We're just privileging that through the system.  And if you are trying to run that as if it is just trad play but better, then your players do have a right to complain about the act of railroading.  It's a real thing.  It's not just people failing to understand the system.</blockquote>

Verification