-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different stat blocks for weapons based on attack range #15034
Comments
Hmm. 3 is still quite a lot though, and loosing chopping at melee range is a lot weirder than, for example, losing a spear's stab damage at melee range. |
I though about multiple attacks for weapons, but more in context of multiple melee attacks. While we're at statblock revisions, it would be cool to get rid of stabbing-is-cutting thing and give it a separate field. Reach attack could also become a technique rather than a flag. This would allow making it cost more or less moves, deal more or less damage (for weak ranged jabs with a quarterstaff, for example) or disabling just the bashing component of damage. I don't think halberd should get reach 3, though. It would be a really solid weapon at reach 2. |
|
True. Still pondering the best way to handle multple attacks. Reach? Technique? Some new mechanic? Not sure. |
First thing that came to my mind was to handle it (from a UI standpoint) about like you do burst fire/weapon mods. Hit a hotkey to toggle the attack type you're using. This along with allowing multiple attack styles to be defined in json (say, through an alt_attack field) would seem to give the most freedom. |
I'd prefer it to be automatic, at least by default. |
The issue i see with the automatic choice is that what is best is subjective and situational. Sure a sweeping bash with a spear will probably be more effective against a skeleton than a quick jab, but I don't want the game deciding that's the case for me when i'm fighting several things. |
Perhaps a fusion of both ideas would work best. Allow for mode switching
|
Possibly allow a weighting field on the item to determine how common the attacks are. Both to avoid having to write something to determine attack effectiveness, and to allow creators to make attacks that should be uncommon, or always be a conscious choice |
We will need that one for NPCs anyway. Letting player use it too would be a convenience. |
Good point, I wasn't thinking of that. |
Note: ignore all of the above about selecting variant attacks, that is a completely different feature, though it could share some infrastructure. The halberd remains a good example regardless of |
@kevingranade I am interested in putting this feature in but have some worries because it seems like the logical 1-range-haft-bash attack for reach weapons will be far weaker than their main attacks, resulting in a nerf for melee. Do you have any guidance on implementing this without nerfing reach weapons? Maybe something like adding knockback on the under optimal range attacks? |
It's supposed to be a nerf, you need to manuver tactically to use a reach weapon properly. |
Is this still how we want to model this? I would suggest that with how melee changes are coming along, it would probably be better to have attack modes linked to weapon range for reach weapons, and that would couple nicely with other suggested changes (eg tracking how you use a weapon to slash or stab using the framework for martial arts specials) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered. |
I've been thinking about giving reach weapons alternate stat blocks to represent different attack types. The most obvious use is allowing reach weapons like the halberd to stab at range 3, chop at range 2, and haft-bash at range 1. That's not necessarily correct, but gets the idea across.
The text was updated successfully, but these errors were encountered: