View Full Version : Handling varied AC and stats

January 15th, 2011, 06:07
Hi all,

I love the fact that my players can drag and drop attack roles on to the NPCs and find out if they have hit or missed. And the same for me in return. But it leads me to a question: how do you handle any of the variations which occur with feats/special abilities etc.

On the player side it isn't as cumbersome in many cases - for example if a player casts a Cat's Grace spell they alter their dexterity and the AC takes care of itself. But how do your barbarians handle their rage?

And (from my perspective) how do you handle NPCs/monsters with these types of abilities. For example, if I were to use a Lycanthrope in my campaign - do I create the same NPC 3 times, once for each form and swap them out as the lycanthrope assumes different forms? And what if I have a human NPC barbarian? When I want to have the NPC rage do I have to manually modify all the appropriate stats? Or again, is it a matter of swapping out a pre-set alternate NPC which has all the stats in place?

Is there a wish list item for multiple states of NPCs so it can remain a single NPC in the library?

January 15th, 2011, 16:36
I use the d20_jpg ruleset, so I've just set up modifers for all the common stuff (Cat's Grace, the bard's Inspire Courage, Bless, Prayer, etc.).

For something like rage, I think I'd encourage the player to set some hot keys to add modifiers to their rolls rather than make them edit their character sheet.

As for NPC's, I have a generic modifier hotkeys (+2, -2) that I can use on their attack and damage rolls. That takes care of most of my in-combat needs.

For lycanthropes and the like I'd go with multiple NPC sheets. I think the vanilla ones already come that way. Having multi-state NPC's would be cool, but apart from modifying the ruleset you'd also have to update all the existing NPC's (i.e. 3.5 Monsters, the complete SRD, and all the commercial modules), since the layout of the XML would have to change. I don't see that as a project that Smiteworks would find to be worthwhile. We all would have to do the same with all the NPC's we've created as well.


January 16th, 2011, 05:42
If I recall my XML, then you would just have to set the additional fields as optional in the schema and then everything that currently exists would continue to exist as normal. So you could use the new multi-state NPCs for all new NPCs but leave everything else the same.

Of course, I'm certain is much more complicated than that ...

January 16th, 2011, 13:24
While xml could do what you're suggesting, the way control binding works in fg2 would not support without the changes phystus says (unless the fg2 engine itself were modified to shift node sets invisible to the ruleset, and even then it wouldn't work because most rulesets have no way to get notified of data changes that would occur when you shift from one character variant to another [e.g. propagating changes to a combat tracker]). This is a huge undertaking to do what you're wanting, and I'd opt for the multiple character sheet option.

January 17th, 2011, 06:12
Fair enough. I was curious how it was handled by most DMs because I've been coming across lots of situations (probably due to the nature of my campaign) where the NPCs have a much more varied set of ACs (for example) than simply the three which are available.

For example, use of Dodge would affect only one combatant, Combat Expertise is something which could vary from round to round, a barbarian rage modifies AC for the duration of that effect etc.

I think I have my answer, thanks for the help. I certainly understand that it's complicated to track.

January 17th, 2011, 12:43
I'm hoping that your AC situation will be solved when Moon_wizard finishes the mod to the 3.5/d20_jpg ruleset and imports all the 4e stuff. While I don't play 4e, I think the more sophisticated effects handling there would be able to do what I think you're talking about on AC.

January 17th, 2011, 14:25
When the barbarian PC in my campaign rages, I quickly change the relevant items on his character sheet. The frustrating thing about this is that changes to Strength don't affect weapon damage, so you have to remember to change that separately!

With NPCs, I make multiple versions of the characters in their different states.

Moon Wizard
January 17th, 2011, 22:02
I'm working through the effects subsystem right now, and it's part of the reason that things are taking a while. The way that 3.5E system links ability buffs and rolls is challenging to code.

For example, while there are standard abilities that affect a given roll, there are many feats that change abilities used for AC, attack rolls, etc. So, when an effect applies DEX: -4, how do you know which rolls it affects? For PCs, you have to provide the ability for the player to specify on their sheet, but for NPCs, they're more difficult to determine which ability they are using but I'm going to try using monster type info to track.

I think the one big difference between 3.5E and 4E ruleset will be that there will not be an in-ruleset text parser for abilities/spells to auto-populate the possible "rolls" and "effects". The text in 3.5E is just not standardized enough, unlike 4E power text.


January 17th, 2011, 23:07
Well, JPG, what about if some of the users here modify the srd text to provide that standardization that we need? I'm sure you'd have some takers on that if we knew we were getting an awesome ruleset.

Moon Wizard
January 18th, 2011, 02:09
The problem is not only the text, but building the in-ruleset parser. The 4E one grew over a couple years to get where it is today. It's just beyond the scope of what I can tackle for the next release, especially given that it's behind the schedule I wanted to keep.

Since most of the content used is SRD anyways, others in the community should be able to put together modules with the rolls and effects pre-built, or maybe we can get someone in the community to build for sale in the FG store.


January 18th, 2011, 02:31
Well, perhaps it can evolve over time just like 4e, and in the meantime, the modification library can substitute. The only thing we need is a mechanism to support these mods. That is, where you can put in a round countdown timer for a fixed time mod or the ability to set the timer as the effect goes on the CT. I think this would tide us over just fine, and we could wait for the more sexy auto-mods (I could personally wait a long, long time for that).