*
*
Home
Help
Login
Register
Welcome, Guest. Please login or register.
July 22, 2014, 05:40:17 PM

Login with username, password and session length
Forum changes: Editing of posts has been turned off until further notice.
Search:     Advanced search
46709 Posts in 5588 Topics by 13297 Members Latest Member: - Shane786 Most online today: 138 - most online ever: 429 (November 03, 2007, 04:35:43 AM)
Pages: [1]
Print
Author Topic: [Poison'd] I don't use NPC Brinkmanship  (Read 2012 times)
Graham W
Member

Posts: 449


WWW
« on: October 21, 2008, 12:00:03 AM »

The only thing NPC Brinkmanship does is decide whether the GM can escalate, right? The rules, as written, are:

1. Roll two dice. Take the higher for Brinkmanship.
2. If the GM wants to escalate, roll Brinkmanship dice, and you need X successes to escalate.

See, as far as I can see, it's just randomness upon randomness. First, there's the random determining of Brinkmanship; then, the rolling of Brinkmanship to see whether I can escalate; finally, my attempt to escalate might randomly fail.

So, I don't bother with that. I just escalate when I want to. And I don't have to worry about Brinkmanship for NPCs.

My question is, is there any practical difference in doing this?

The differences I can see are:

1. The probabilities are slightly different. Oh well.
2. If I escalate and fail, we're at a higher level of escalation; whereas if I'd rolled NPC Brinkmanship and not been allowed to escalate, we'd still be at the lower level. So the consequences to my NPC are greater.

As far as I can see, this makes no real difference, so I might as well just escalate when I want to.

Graham
Logged
lumpley
Administrator
Member
*
Posts: 3656


WWW
« Reply #1 on: October 21, 2008, 05:27:57 AM »

Personally as gm I HATE deciding whether an NPC captain escalates. Hate it hate it hate it.

The only practical difference I see is that rolling for it means that I don't have to decide. If you'd rather decide, by all means.

-Vincent
Logged
Graham W
Member

Posts: 449


WWW
« Reply #2 on: October 21, 2008, 08:29:47 AM »

I see where you're coming from.

I wonder if it could be simplified, though, to remove that Brinkmanship stat? Say, the GM rolls one die and, on a success, may escalate? (The probability there is about the same as the one in the rules). Or just specify that the GM must always escalate.

I don't know. I just see an opportunity to skip some steps, first in NPC creation, then in combat. The step in combat is  a bit of bother: when I might escalate, I have to find four to six dice, then roll them in such a way as to keep them separate. This is a bit of a pain in the arse. Rolling one die would be better; or specifying that I must always escalate would be better still.

Graham
Logged
Arturo G.
Member

Posts: 333


« Reply #3 on: December 10, 2008, 04:58:07 PM »

Sorry for coming back to this. I have been completely swallowed by work for a couple of months.

I'm on the same page as Graham. In the ashcan NPC's brinkmanship was working pretty different. I prefer to choose when I'm escalating or not. So far so good; as Graham I think I can skip it with no real pain to the rest of the rules. But, I still like the feeling of brinkmanship as a measure of the risk the character is happy to face.

Thus, I still like the ashcan idea of using brinkmanship as starting dice for NPCs. But, modified by profile as in the new rules. The only trick is that Brinkmanship is typically lower than the fixed six-dice used in the new rules. Thus, I'm thinking on adding one (or two) when generating brinkmanship. Sometimes I'm also choosing brinkmanship instead of randomly generate it.

My question: Is there something important I'm missing? I mean, some other reason to drop brinkmanship from its original role in the ashcan-version fight?
Logged
Eero Tuovinen
Acts of Evil Playtesters
Member

Posts: 2775


WWW
« Reply #4 on: December 10, 2008, 07:13:59 PM »

Poison'd is a bit challenging to run, and this thread you brought back sort of inspires me to understand why: it combines defined procedures with significant GMing tasks. I play a lot of games with defined procedures and a lot of games with plenty of GM responsibility, but combining the two is a pain in the ass. In something like Solar System I have no problem at all stripping and simplifying the GM side of the equation to whatever level I find comfortable. (For example, I've stopped tracking NPC stats in that game to the degree that I can keep anything I need in my head.) In Poison'd any deviation from the rules reads differently - I'm not just finding my own ideal method of play when I mess about with the GM tasks in Poison'd; I'm actually breaking the rules. Thus the need to ask Vincent to confirm the sagacity of any changes in the GMing procedures we might wish to make, which is not something we usually do with other games with a strong GM.

For what it's worth, the couple of times I've played the game have usually had the NPCs benefit minimally from escalation. Doesn't seem like a big deal, this. If anything, making it a GM pregorative to determine whether to escalate should help the GM control the pacing of the game a little bit better. Makes for more sensible NPC action, too, as the NPCs escalate or fail to escalate with some tactical sense.
Logged

Blogging at Game Design is about Structure.
Publishing Zombie Cinema and Solar System at Arkenstone Publishing.
Arturo G.
Member

Posts: 333


« Reply #5 on: December 11, 2008, 05:30:45 AM »

it combines defined procedures with significant GMing tasks. [...] In Poison'd any deviation from the rules reads differently - I'm not just finding my own ideal method of play when I mess about with the GM tasks in Poison'd; I'm actually breaking the rules. Thus the need to ask Vincent to confirm the sagacity of any changes in the GMing procedures we might wish to make, which is not something we usually do with other games with a strong GM.
I don't think this is what Vincent intended. I think he gave us clear procedures and rules that produce the kind of play he liked for this game. But he has not created a fixed system which clearly changes so much or get broken when we adapt it. I would say it is coming mainly from the tutorial tone of the rules, that make them feel a little like fixed stone-rules, as in a board game. It is highly instructional and easier to grasp for people not so used to play with this kind of games. It conveys a kind of old-times child-awesome feeling on me when reading them.

If anything, making it a GM pregorative to determine whether to escalate should help the GM control the pacing of the game a little bit better. Makes for more sensible NPC action, too, as the NPCs escalate or fail to escalate with some tactical sense.
That's exactly my feeling. However, I can see that the game does not really need it, as it is not the focus of play. It is just a matter of taste on actual play.
Logged
Graham W
Member

Posts: 449


WWW
« Reply #6 on: December 13, 2008, 05:46:29 PM »

I think "always escalate" would be a better rule than the one in the text.

Graham
Logged
watergoesred
Member

Posts: 12


« Reply #7 on: December 13, 2008, 10:13:08 PM »

I'm with not having to decide when to escalate but I'm not keen on always escalating. Here's my one dice solution: escalate if you roll brinkmanship or less on a 1d6, but not rolling for Brinkmanship 1 of course.

I roughly worked out the probabilities of escalating using the method in the rules - roll the same number of dice as Brinkmanship and escalate if at least 2 dice are a 4, 5 or 6.
Brinkmanship 1 = 0%
Brinkmanship 2 = 25%
Brinkmanship 3 = 50%
Brinkmanship 4 = 69%
Brinkmanship 5 = 81%
Brinkmanship 6 = 89%

These percentages can be closely estimated on a 1d10 or 2d6 or 1d6. Here are their probabilities as I worked them out.
(escalate if you roll number or less:probability)
1d6 - 2:33% 3:50% 4:66% 5:83% 6:100%
2d6 - 3:25% 6:50% 8:66% 10:83% 11:92%
1d10 - 2:20% 5:50% 7:70% 8:80% 9:90%

I like the 1d6 method myself because it's easiest to remember and use. The 1d10 is statistically closest of the 3 but I'd probably need a table or to memorise. Avast!
Logged

oli
Pages: [1]
Print
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines
Oxygen design by Bloc
Valid XHTML 1.0! Valid CSS!