We're encouraged around here to say "yes, but..." in response to player activities. I thought this was a pretty insightful injection of context into that encouragement:

http://www.madadventurers.com/angry-rants-yes-and/

I find the whole "Angry DM" schtick to be tedious to the point of being nigh-unreadable. The ostensibly useful information is hard for me to process because I just don't care for the style of being angry about everything and every post being about how gaming is stupid and players are dumb and GMs are idiots, etc, etc.

Here's an episode of "Ken and Robin Talk About Stuff", which discusses "yes, and" in the context of gaming:

http://www.kenandrobintalkaboutstuff.com/index.php/episode-36-a-scuba-diver-walks-into-an-ice-cream-shop/

It's probably just a coincidence that it features an improv scene about an ice cream shop.

Anyway, it features a couple of very mild-mannered GMs (who aren't angry but who have actually got a decades-long track record of making games people enjoy) discussing some of those same points.

Deleted

I agree with Progressions on the writing style. That being said, I also have some issue with the content as it applies to this particular game, as opposed to D&D.

When we talk about "Yes, but." in this game (and it's relatives, "Yes, and", "No, but" and No, and") we're often talking about the interpretation of die rolls, not just scene setting by the Players. He is specifically talking about how the use of the improve technique has limitations to it's application in D&D, we're talking about using the two-axis die system to create a simulation of simultaneity and opportunism not available in a binary system.

So basically, we're here talking about witches and whiches.

(Also, he clearly neglected the option "Yes you killed the orc, but he fell into the pie, splattering it everywhere." which you'd get with success & despair on that arrow.)

In my first session or two of GM'ing I ran into an issue with the "Yes, but.." thing. I had a computers type check that was 1 computer terminal, that had one keyboard. So obviously my Players wanted to NCIS the scene and have 1 player "do the work" and the other "assist" ... I tried to think how it was logically possible and couldn't so I asked "if you can explain how you can have 2 people work together on one screen with 1 keyboard I will allow the assist". They could not think of a method except the moronic NCIS "2 hackers 1 keyboard" BS so I said, sorry nope.

They felt a bit like the rules said they could assist but I reached back to the situation and couldn't find a logical method.

The idea that a GM can't say no is stupid. Though in more recent endeavors I just up the difficulty of crazy ideas to where I think they belong. Want to arm wrestle a rancor? sure why not, Pretty sure that hits the definition of an impossible roll. Want to have 2 people hack from the same terminal? Okay, boost is added, but difficulty is increased as you dodge each others fingers on the keyboard and a Destiny flip to have any despair end up in a fight.

I think the only set in stone rule of being a GM is don't be a jerk and even that can be broken if the Players are jerks (Then again why are you playing a game with jerks? games are supposed to be fun).

Assisting on a computers check, even a slicing one, could be as simple as looking over the shoulder of the person at the keyboard and offering tips. It could be reminding the person doing the task about things they ran into last time they attempted a similar task. Etc. It doesn't always have to be physical assistance. Though I like that use of despair!

I didn't start this thread to discuss the merits or lack thereof of AngryDM's writing style. It's not a style everybody appreciates, that's understood.

When we talk about "Yes, but." in this game (and it's relatives, "Yes, and", "No, but" and No, and") we're often talking about the interpretation of die rolls, not just scene setting by the Players. He is specifically talking about how the use of the improve technique has limitations to it's application in D&D, we're talking about using the two-axis die system to create a simulation of simultaneity and opportunism not available in a binary system.

So basically, we're here talking about witches and whiches.

(Also, he clearly neglected the option "Yes you killed the orc, but he fell into the pie, splattering it everywhere." which you'd get with success & despair on that arrow.)

I think it's accounted for, though not referenced directly. The heart of the article is that "yes, and..." and its relatives are about the injection of premise. One point of view might be that the EotE dice system and the philosophy of GMing it supports is a premise-injection machine. In your example, that nobody gets the pie is a new premise, which can lead to or set up a new scene. Granted, he didn't think of that outcome, but it doesn't invalidate the larger point.

I'm not going say I wholeheartedly support his point...per your example, EotE is filled with lots of opportunities for "micro-premises" which he doesn't account for...but I appreciated the discussion of improv and how premise-overload can kill the experience.

Doesn't matter what i had here people missed the point.

The "yes, and/but" concept works best when the player interjecting an idea works with you as GM to elaborate on the scene and introduce something new. When it all falls apart is when you see a player introduce new ideas with a clear goal of "winning" in mind. If you've been GMing for a while you can usually tell when a player has had a brilliant idea and tries to slip in two or three extra concepts in a scene that, when combined, allows him to "win".

The problem is to communicate to your players that the first option is good while the second will be nixed in its inception.

I liked that article. I think it made a really good point.

If you didn't read it, the basic idea is that "yes, and..." isn't needed once you have a scene/encounter set up, because adding more premises can bog it down and make you start running in circles. Conversely, "yes, and..." is great for creating new encounters/scenes/adventures.

I remember someone trying to do this in real life... it isn't as "assisting" as it sounds and it gets in the way. I was saying it was not possible from experience.

While I can't speak for hacking a computer, I'm a software developer, and I often have to look over my director's shoulder (who is a far superior developer than I am) while he shows me how to do something in code. It's not often, but occasionally I do catch him doing something incorrectly or inefficiently. That's a perfect example of assisting with a computers check where there's one monitor and one keyboard.

I don't really have a "Yes, and.." issue when if comes to story. I do have a problem when people want to use it to change/ignore a rule or when used in an attempt to Munchkin a PC or equipment. I haven't encountered it much in games I run but it has come up occasionally in games I play and it more often than not breaks the suspension of disbelief. I also see it often on boards like this to try and justify Players, or GMs, desires to have more powerful PCs. This kind of use of "Yes, and..." makes me angry.

In my first session or two of GM'ing I ran into an issue with the "Yes, but.." thing. I had a computers type check that was 1 computer terminal, that had one keyboard. So obviously my Players wanted to NCIS the scene and have 1 player "do the work" and the other "assist" ... I tried to think how it was logically possible and couldn't so I asked "if you can explain how you can have 2 people work together on one screen with 1 keyboard I will allow the assist". They could not think of a method except the moronic NCIS "2 hackers 1 keyboard" BS so I said, sorry nope.

They felt a bit like the rules said they could assist but I reached back to the situation and couldn't find a logical method.

The idea that a GM can't say no is stupid. Though in more recent endeavors I just up the difficulty of crazy ideas to where I think they belong. Want to arm wrestle a rancor? sure why not, Pretty sure that hits the definition of an impossible roll. Want to have 2 people hack from the same terminal? Okay, boost is added, but difficulty is increased as you dodge each others fingers on the keyboard and a Destiny flip to have any despair end up in a fight.

I think the only set in stone rule of being a GM is don't be a jerk and even that can be broken if the Players are jerks (Then again why are you playing a game with jerks? games are supposed to be fun).

Assisting on a computers check, even a slicing one, could be as simple as looking over the shoulder of the person at the keyboard and offering tips. It could be reminding the person doing the task about things they ran into last time they attempted a similar task. Etc. It doesn't always have to be physical assistance. Though I like that use of despair!

I remember someone trying to do this in real life... it isn't as "assisting" as it sounds and it gets in the way. I was saying it was not possible from experience.

I used to work at a job where 8 hrs a day, I was on a computer looking at customer orders. Due to the nature of the business, and the sheer variety of options, these could be very complicated. It was VERY COMMON for two people to look at and "dissect" a single order, on a single computer. I was on the receiving (someone looking over my shoulder) and giving (looking over some one else's) end of this multiple times. It only didn't work when the person helping didn't know what they were talking about.

Considering this is a game though and the players don't (or shouldn't) have to say actual real things that would be said (the hacking is imaginary), it could work just fine. At least it does in my games

Asisting hacking on a computer: "Swordfish." That is all.

Asisting hacking on a computer: "Swordfish." That is all.

I don't think that was meant to be an assist. It was more of a test under "pressure."

I guess it needs to be mentioned that the "Yes, and..." principle makes the assumption that your players are not trying to meta game it to get around rules. "Yes, and..." is not a rule, so there are no specifics and rules in its use. If a player told me "But you're supposed to say 'Yes, and...' when I ask a question like this" my response would be... "Yes, and you're a idiotic jerk."

The "Yes, and..." has a very narrow application in my opinion. It is there to guide the GM when a player wants to do something that you no plan for, no idea of the consequences, or is just totally blue sky, off-the-wall, etc. "Yes, and..." should not be applied when the question can be reduced/translated to "Can I break the game?"

Assisting on a computers check, even a slicing one, could be as simple as looking over the shoulder of the person at the keyboard and offering tips. It could be reminding the person doing the task about things they ran into last time they attempted a similar task. Etc. It doesn't always have to be physical assistance. Though I like that use of despair!

I remember someone trying to do this in real life... it isn't as "assisting" as it sounds and it gets in the way. I was saying it was not possible from experience.

I had the opposite experience, it worked really well. I was new to Java and was paired with an expert. There were three or four other such pairings in the development team, while others continued solo. I know as pairs we had faster development time and overall fewer bugs. But management just couldn't wrap their head around the idea, so sadly the concept died.

I remember someone trying to do this in real life... it isn't as "assisting" as it sounds and it gets in the way. I was saying it was not possible from experience.

In “Real Life”, it’s called “Pair Programming”, and is actually one of the most effective methods of doing software development.

It’s also crazy-expensive to do for long periods of time, and most places are not willing to spend twice as much on having twice as many developers, and yet only one of each pair is actually “developing” at any one time.

What those companies are missing is that it is easier to fix problems the earlier you detect them, and by having an extra set of eyes on the problem from the very beginning, and for each developer to have to be able to explain to their partner as they go along, that helps eliminate a wide swath of typical types of coding issues.

Feel free to Google for “Pair Programming”. It really Is A Thing.

In my view, the "Yes, and" (or really for RPGs, "Yes, but") principle in gaming is designed to mark a shift from the style of storytelling where all the significant details are defined by the gamemaster, and the players just make use of those elements.

It's designed to encourage a player to say "In this town square, what if there's a grumpy old Aqualish with a food cart whose cart gets hit by that blaster shot which missed with a Triumph. The Triumph means the wriggling little octopus-type creatures he's selling start squirming all over the ground and get in the Stormtroopers' way."

With some mindsets, this wouldn't be possible, because the players and GM might consider it the GM's job to determine whether there were food carts and if the GM didn't say there were food carts, there aren't any food carts.

Deleted

Fatedtodie, I've been following this thread, and I don't think anyone was being rude. You could be projecting a tone that simply isn't there.

It sounds like everyone has different experiences with what they think is true assistance and what they think may be a hindrance. Which is telling that there simply isn't a true answer to your example. In this case, you made a call that you felt was right for your table based on your experiences. Others of us who have performed the real life equivalent of a computers check and have had a differing experience, and we chose to share them for the benefit of debate.

Deleted

It wasn't rude. You're reading sarcasm where there was lighthearted banter. I guess I shouldn't speak for bradknowles, but it seemed pretty plain to me.

You might also consider that your original post on the matter was to state your opinion unequivocally as if assisting was impossible and ridiculous. If you're that married to your opinion then any contrary experience is going to look like an attack.

Of course, now you've edited that original post... *sigh* ... oh well.

The whole point of the Advantage / Threat / Triumph / Despair mechanic is to rationalize the improvisation and narrative elements, inserting them specifically into the game while providing limits.

Having said that, this system is flexible enough to allow everything from the strictly improv style of "yes, and..." to more structured encounter->resolution stories that the Angry GM there prefers. Ultimately, it's whatever style works best for the table.

Yeah, I wasn’t intending to be sarcastic, but I must admit that my wife has sometimes called me “The Great Sarcastimo”, so maybe I sometimes sound like that without meaning to.

In this particular case, I felt like there was an example being provided for the game which didn’t fit with my own experience, and so I wanted to let people know that sometimes it does actually work that way.

I certainly wasn’t trying to put anyone down or anything, just share an alternative view.

Deleted.