Edge Case Doomvortecco

That was super helpful. Far better than what I found through googling and wikipedia... You've got a serious knack for summarizing - Now I know exactly which editions are worth looking at and maybe attempting in my own tabletop group. 😮 As for better understanding BRP, I'll check out RQ2 and RQ3 back-to-back to better understand the rules. I can't believe it's taken me this long to finally discover this system... feels like discovering a hidden passage in your house that opens up a whole wing you never knew was there, full of stuff to dig through 🙂

I'm thinking it might be easier to have a sort of "ask for forgiveness instead of permission" attitude with regards to projects like this... If we build one, and get slapped with a cease and desist about it, it at least means they have a working example of the system that makes it a lot easier to "officially" integrate into foundry. Either they kill it and it dies, or - it means they take over responsibility and control of the project (which could be sad, but at the end of the day I don't really care who makes the system, I just want the system in there lol). I've seen plenty of examples of companies saying "we don't wanna build the thing, but since you've already done the majority of the work for us, here, we'll take it and put it in, nice job guys!"

From what I'm gathering about BRP in general, it looks like to better understand these rules, I'd need to also read the rules on RuneQuest... A lot of things seem to be holdovers from those systems, so that's likely where I'll get some added context to my confusion. In a game I'd run using this system, I like the idea of declaring your actions, but I think I'll fudge the rules on the resolution phase. Even then: declaring your action can be intentionally vague to allow for reactions to situations, so that sounds like the loophole. I don't really see the point of having a "resolution phase" at this moment (as opposed to just resolving each action individually before the next action, in sequence), but maybe it'll make sense with more playtesting.

Ahhh ok, I really should read the RuneQuest rules. Problem is there are so many editions (by several names even) it's difficult to know where to start haha. This definitely answers the question though, so thank you.

I've also been tooling around with building a system in foundry, although I've been building it using the Custom System Builder system. It's been a fun little project for what it's worth, but I'd really like to know how to build an actual system instead of trying to hack this one to work (for example, I'm using math and ridiculously long and repetitive ternary operators to check for conditions when certain options are turned on or certain conditions are met, and it's just super messy - I'd rather have the full power of javascript at my disposal instead of math.js evaluations). Sounds like we've got 2 other people in this thread who'd like to build it too, and I'm wondering if we could combine our efforts. Foundry says all you need to know is html, css, and javascript... but in my attempt at figuring it all out, they forgot "oh yeah, you also need to know css preprocessors like less and sass, and you need to know how templating engines work, and you need to understand how to write hooks and event listeners, and-" and the list of advanced concepts of web development go on from there. Understanding syntax isn't enough... Anyway - point is if anyone would like to collaborate (if for no other reason than to help catapult me out of my "legacy" knowledgebase of php and jsp web development) I'm super motivated to add my hand to the project 🙂

In the Big Gold Book, page 252, the arbalest and crossbows have an odd "SR" (strike rank, I'm assuming? The tables on all other missile weapons use "RF" aka rate of fire, but this one table breaks convention. "SR" means strike rank on all other melee weapons, perhaps a typo?). They have a "SR" of 1/4MR, 1/3MR, or 1/2MR... On page 257 it attempts to clarify all the possible values that field could have... such as 1/CR meaning it can only be used once per combat round, or 1/SR meaning it can be used once on your DEX, and again on DEX+3. But it makes no mention of what "MR" means... I checked all the erratas and they make no mention of it... what is MR?

I'm trying to make sure I understand the combat rules here, and the only way I can explain my confusion is by illustrating my understanding through examples, so... apologies for a long-winded post. Note: I know Strike Ranks change the flow of combat... I'm more concerned with trying to understand the basic rules first. Combat phases in the big gold book are broken down by: Phase 1: Statement of Intent Phase 2: Powers (which is basically the same phase as actions, they just happen sooner because spells happen at the "speed of thought") Phase 3: Actions (as mentioned, casting a spell is an action) Phase 4: Resolution Ok, so... let's assume we have 2 people fighting each other: Dave and Bob. Is this how it's supposed to work? Scenario A: Phase 1: Statement of intent Dave announces his intention to attack Bob with his sword. Bob announces his intention to attack Dave with his axe. Phase 2: Powers ... no spells cast, moving on Phase 3: Actions Dave attacks Bob with his sword. Bob attacks Dave with his axe. ... just like they said they were going to do in the announcement phase. no rolls are made yet. The point of this step, I guess, is to illustrate precisely when everything happens, but without a resolution happening here at this point, it effectively just becomes a retread of Phase 1 doesn't it? Phase 4: Resolution Dave rolls sword skill. success. Bob rolls to parry. success. Bob rolls axe skill. success. Bob rolls damage. Scenario ends. Here's another scenario... Scenario B: Dave, Bob, Skeleton A, Skeleton B. Phase 1: Statement of Intent Dave announces his intention to attack Skeleton A with his sword. Bob announces his intention to attack Skeleton A with his axe. (focus fire!) Skeleton A announces his intention to attack Dave with a rock. Skeleton B announces his intention to attack Dave with his own arm that he's ripped off. Phase 2: Powers ... Phase 3: Actions Dave attacks Skeleton A. Bob attacks Skeleton A. Skeleton A attacks Dave. Skeleton B attacks Dave. everything happens in the order it was announced, for simplicity's sake. Phase 4: Resolution Dave rolls. He hits. Dave does X damage and kills Skeleton A. Bob rolls. (But the skeleton is dead dude). He hits? (hits a dead thing?) He does X damage. (to the already dead skeleton...?) Skeleton B rolls... he misses. (boy it sure would've been nice if Bob could've attacked Skeleton B upon seeing Skeleton A fall in battle...) Scenario ends. This is not how the quick play rules illustrates combat in their "combat example", nor is it illustrated this way in the big gold book's "combat example"... If I could describe the way they illustrate it, they do away with phases altogether: Player with high dex announces what they're doing... if the action doesn't fire off on a lower dex, they get to act on it and resolve it right then and there. Next player in the list does the same thing. NPC had low dex, so they do the same thing last... Almost as if the "Actions" phase contains within it a resolution phase of its own for each action, rather than splitting everything into one big "resolution" catch-all phase... This certainly makes sense to me, as now scenario A would play out as: Dave attacks bob with his sword. he rolls to hit. success. Bob reacts: rolls to parry. success. no damage. Bob attacks Dave with his axe. he rolls to hit. success. Dave reacts: fails to parry. Bob rolls damage. End scenario. The rolls here all happen within the same area they're being announced... we never got to hear what Bob was going to do because it wasn't his turn yet, and Dave got to just attack and finish all four phases of his turn before Bob could take his turn. This is how the examples illustrate it, specifically in the quickstart rules - a direct contradiction to the rules as written. Scenario B would also change: Dave attacks skeleton A with his sword. he rolls to hit. success. rolls damage. Skeleton A is killed. Bob, seeing skeleton A is dead, attacks skeleton B. he rolls to hit. success. rolls damage. Skeleton B is hurt (or killed or whatever). End scenario. Once again, this makes way more sense to me... and surely I can change it to that, but I'm just trying to make sure that I'm understanding the rules as written... And yes, I can fix this with homebrew rules, but I want to make sure it's not broken first. Is this the same understanding you all have of the phases, or did I misread somewhere? Is there a rule clarification somewhere later or earlier in the book that sheds more light on this?