Updating GM Guide and other minor fixes

[LockerM]

Major overhaul of GM Guide in progress. Working on following issues:

• Damage, Weapons, Refined Enemy HP and Phases  #33
• Boss Dealer Damage Phases Mechanic #34
• Epic Event from GM perspective #61
• 'Legendary Action' naming/rules #53
• Does DR + Mod on report make sense? #59 (adding in addressing this in the GM Guide, Player Guide Brief and Full)
• Missing: Tools #100
• Economy/Cost in GM Guide #102
• Modify Poisoned Condition to affect Stamina instead of HP #73
• Discard Mechanic revisions #78 (Partially addressing - renaming to 'Burn Mechanics')
• [IDEA] - Stamina instead of HP Mode #69 (Partially addressing - explicit naming of 'Fatigue' as a Status Condition)

Other minor fixes include:

• Update to CONTRIBUTING doc version reference

[CBroz1]

Started reviewing, up to gm guide Line 363. Will continue later.

[LockerM]

I put some comments in the text to respond to in-line comments but pulling them out here for ease of reference:

1. New-GM vs. DofA Specific for Combat GM Guide (Line 550)

• LOCK: If we keep it all new-GM vs. DofA specific we'll lose some of the 'section' based value of the GM guide. Talking through combat more holistically is helpful here - do we strip it out entirely from DofA specific and make 'Combat' its own main section?

2. Why draw new TC during Boss Phases (Line 637)

• LOCK: I pictured a 5 phase boss fight. The Players have made great progress on the Boss' HP, but if they've been aiming at the same TC for the last 10 rounds of combat they are going to be way less likely to keep hitting. Drawing a new TC for each Phase keeps the odds fresh and prevents a Player from feeling like they 'wasted' a card that would have been a hit during Boss fights

[LockerM]

Updated GM guide with TOC links, tables, refinements, across the areas that are not commented out in the TOC.

Still more to be done to create a 'final' GM Guide, but the scope of what's covered here should be enough to move us into v1.0.0a4 once merged.

[LockerM]

Made proposed changes to the language in Player Guides around DR + Mod on Report after playtest feedback. Saving other issue resolution for Player Guides for a future PR that would move us from v1.0.0a4 to v1.0.0b1.

[LockerM]

Before merge and after approval, let's delete the comments currently in there that were resolved.

[CBroz1]

Finished review of changes to

1. Player Guide Brief
2. Player Guide Fill
3. Contributing

Larger docs in subsequent review

[CBroz1]

I recommend always saying "one" when instead of "a". Also, one card doesn't seem like much here. Much less significant than an HP.

Suggested change

	they discard a card. The Poisoned Status Condition can stack.
	they discard two cards. The Poisoned Status Condition can stack.

[LockerM]

In my vision of this, the Poison Condition being able to stack is really what makes it dangerous here. If you get one level, sure discarding one card isn't too bad (plus the forced vitality check, plus if something else forces you to do that check at Lower Hand now it's 3 cards per round even at a 1 stack), but if a Dealer or multiple Minions/Environmental effects cause Poison and now you're at Poison (3) your stamina can start to drain FAST. If you think it would have more teeth starting at 2 cards discarded that works for me, and stacking adds 1 additional card per failed Vitality Check.

[CBroz1]

Either way, it needs playtesting. For a playtesting philosophy, it might feel better to start harsher and ease off then start weaker and add

[LockerM]

Sounds good, I agree. I added it in a commit to start at 2 cards discarded and made it more explicit that each additional stack adds +1 card to the discard.

[CBroz1]

1. What term do you want to use for "no thanks"? The GitHub default is "wontfix".
2. Is "Integrated" needed? If something is closed and not labeled "wontfix", that means it's integrated.

Suggested change

	An Issue will be tagged as "Under Consideration", "In Development", "In
	Playtesting", and "Integrated" to establish where it is in the development
	cycle. Not all ideas will make it to the Integrated step, but every
	Contribution and comment from the Community is valued.
	An Issue will be tagged as "Under Consideration", "In Development", or "In
	Playtesting", to establish where it is in the development
	cycle. Not all ideas will make it to the Integrated step, but every
	Contribution and comment from the Community is valued.

[LockerM]

I think if we're leveraging this for public community visibility we'll want something a bit softer than the default "wontfix". The goal here is visibility, and transparency, so if we want to go with closed and not labeled "no thanks" as the way of highlighting "Integrated" that's fine, we'll just want to make sure the community knows this is how it's resolved and indicated what's resolved versus what's being passed over/disregarded. I was envisioning some status to indicate it was merged into the main rules so we can go back to the Issue submitter and say "congrats, your Issue was [INTEGRATED]. You can view the closed issue [here]"

[CBroz1]

That sounds less like issue labels and more like a public project board where someone can see how their issue is moving though the integration process

[LockerM]

Hm this might be worth discussing further in that case. Part of why setting it up as Issue labels made sense to me to start is because we will want to be driving community members to engage with Issues - to add comments, create new issues, and keep tabs on outstanding issues they're passionate about or interested in. If we create a public project board it may help for visualizing the development process, but driving people to view that project board feels more passive "hey go to the project board so you can check out what we're working on" versus saying "hey go to Issues, add comments and submit your own so the community can keep updating and refining the game".

Definitely open to a bigger discussion around how we want to approach this, I think starting with Issue labels and seeing how it goes from there might be a good starting point for heading into Beta, especially given that those issue labels can be folded into a project board for tagging/tracking in the future without us needing to make and maintain a full additional project board at this point when it might not be needed at this stage.

[CBroz1]

Reviewed individual commits for edits related to changes from fork PR

Edits on newly added sections to follow

[CBroz1]

Regarding the comments on sections for New vs. experienced DMs: maybe the current gm guide is GMGuide_Full and it could/should be accompanied by GMGuide_Brief which is barebones targeted at experienced GMs (who already know how what it means to work with players and balance and encounter). For example

1. Cards not dice
2. Set DR, hit TC. Apply Mod to DR
3. For all values, aim for <10. e.g., split boss health to phases

Just enough to run a level1 session in 30m, Good for words to ctrl+f in the full doc

[LockerM]

Regarding the comments on sections for New vs. experienced DMs: maybe the current gm guide is GMGuide_Full and it could/should be accompanied by GMGuide_Brief which is barebones targeted at experienced GMs (who already know how what it means to work with players and balance and encounter). For example

1. Cards not dice
2. Set DR, hit TC. Apply Mod to DR
3. For all values, aim for <10. e.g., split boss health to phases

Just enough to run a level1 session in 30m, Good for words to ctrl+f in the full doc

Added Issue #103.

[CBroz1]

Examples below are bold entity name. Change to reflect same here?

Suggested change

	##### Name
	**Name**

[LockerM]

I think we can leave it as ##### h5 as originally stated, sorry I didn't update that in the last pass. Making a commit to update that now - I think we should stick with h5 as a naming convention in other docs for NPCs or stat blocks so we can render these specifically uniquely in the HTML/Website render side of things rather than bolding it.