Fix throwing #25410
Fix throwing #25410
Conversation
|
forcing to wield the item would make things like my hand grenade bandolier pr and the already released javelin bag more viable instead of just saving your inventory space, as activating both makes you wield the item anyway. |
|
Force wielding seems like more keypress for tedium. |
|
Movecost is then calculated as if you wield them first then throwing of course. |
You've misunderstood how this is implemented I think. If you're not wielding something and press 'T' to throw, you will automatically wield it and throw it. No additional keypresses required. Now, if you're already wielding something then you need to choose what to do with it, which would be no different than what you're suggesting. Your suggestion does not improve the number of keypresses required to throw something and the only additional keypress required after this change is if you're wielding something already. |
|
While throwing might be in need of a nerf does lowering the damage per attack for a close range low skill character from 15 to 0.9 (a factor 16) and at range 5 from 0625 to 0.015 (a factor 41!) bring it rather to far in the other direction? and that without taking into account the need to wield the items now... Unless there there is some other factor that is not clear from the table this seems to bring throwing from op to completely useless in the early game? With this wont it essentially be impossible to level throwing through actually using it, forcing the player to find a skill book to actually make the skill useful? Well, either that or gaming the system by kiting a zombie around in a circle forever to grind throwing against it... |
Your concern is shared and others have convinced me it still needs work. This is WIP. |
mlangsdorf
added
Game: Balance
Just to point one thing out, the damage-per-hit is unchanged, the damage number is the average per throw, so when missing a lot it drops a great deal. The ideal niche for early-game throwing IMO is that you use it to soften up an enemy as it approaches, but have little to no chance of killing it with just throwing attacks. That is the goal of this PR, because as stated in the description (and the linked issue), the current status quo trivializes early game encounters with zombies as long as you stock up on rocks first. Later on, it could be used to safely deal with weak enemies at a bit greater than arms length, and soften up tougher enemies, but it should never be a main weapon (at high skill levels a sling becomes somewhat formidable, but it never approaches the effectiveness of a gun). This PR doesn't do anything for that scenario, it's substantially unchanged. |
|
So how does it work in the game? |
|
The interface is completely unchanged, this only adjusts chance to hit and the wield on throw thing. |
The goal here is to:
a) give the statistics class more flexibility
b) enforce some strictness in how the class is used in future tests
c) try to automatically do the right thing depending on type
This does this foremost by giving the class a template definition such
that you must tell it what type of stats you're trying to take so that
when, for example, you take the margin of error, it uses the appropriate
function.
This also now provides the ability to specify a Z-level for the
particular stat you're taking. The default is 99.9% confidence, which
was the previous behavior.
Lastly this provides a few new helper functions and structs which should
hopefully encourage more appropriate use of the statistics class and
eliminate code duplication. There's a number of existing tests that
could likely take advantage of this new functionality but due to the
complexity of the some of the tests, it's better to refactor them
independently of this.
This adds a set of tests to model the current behavior of the throwing skill.
Currently you can throw stuff without wielding it. This fixes it so that you must be wielding whatever you're trying to throw. This makes more logical sense and nerfs throwing a bit.
Now that there's tests to model the current throwing behavior, we should modify the test to match the behavior we want. Here that is a simple matter of changing the range on test_player_kills_monster from 10 to 1 which will cause it to fail until the behavior is fixed.
The main thing we want to solve here to simply make a survivor with no skills and no plan and just a pile of rocks not viable. This solves this by tweaking the dispersion values according to skill such that zero skill will have a higher chance of missing, but if you master throwing there's a small boost. This also modifies the damage boost applied with strength depending on skill. This forces throwing to scale more heavily with skill.
Now that intentional changes have been made to fix throwing balance, the other tests need to be fixed to reflect the new values.
alanbrady
force-pushed
the
fix-throwing
branch
from
c93c09e to
4219dd4
Compare
|
I just realized the way I implemented the wielding thing has problems and I need little bit more complicated solution with how the thrown item gets removed. The |
|
That should do it. EDIT: Nooope one more time. |
alanbrady
force-pushed
the
fix-throwing
branch
from
0dd20c5 to
3c4c0f4
Compare
We remove the item after checking for wield which can invalidate the 'pos' index we're using to remove an item. This could at best cause the game to remove a random item and at worst cause a crash.
alanbrady
force-pushed
the
fix-throwing
branch
from
3c4c0f4 to
e0628e6
Compare
|
Neat travis failed on the scenario test. Apparently more nerf is needed. EDIT: EDIT2: I fixed it, travis managed to fail on something unrelated. Calling it good here. |
Somehow travis found a way to make this test fail once so I'm tweaking it down slightly further.
|
Weird, I'm getting a crash: Program received signal SIGSEGV, Segmentation fault. |
|
Simple fix: |
|
Ah ha, thanks. Dunno why it wasn't triggering for me, I'm guessing the ordering of tests happened to be slightly different from when I last rebased this. |
|
It didn't happen on travis either, I have no idea what sets test execution order. |
Summary
SUMMARY: Bugfixes "Fix OP throwing"Purpose of change
Throwing is OP on the low end. A survivor with base 8/8/8/8 stats and zero throwing skill can fend off some zombies with nothing more than a pile of rocks. This should not be possible.
The end result of the changes here essentially re-orientates the throwing to be more heavily weighted on skill. This causes a decrease in damage output with zero skill and gives a significant boost to accuracy on the high end, without also increasing damage output significantly.
This PR also slightly changes the throwing dynamic by forcing you to be wielding whatever it is you're trying to throw.
Describe the solution
This is a multi-facet solution that is actually more about adding some basic tests and drawing a baseline for the current state of throwing. We know that on the very low end, throwing is over powered, beyond that there's some flexibility in interpretation and further balancing, but at a minimum we should address this case.
This addresses the problem by first templatizing the
statisticsclass. This allows us to better utilize the great functionality in the class and extend it further. Most notably we can now gather regression stats on continuous data, not just discrete binary data. This also reinforces the class with some strictness to help prevent it from being using improperly in the future.From there, we can create some baseline tests that model the current statistics for throwing.
Once complete, I tweaked the scenario test from range >= 10 down to 1, where it should be thus causing it to fail. From there I made some small modifications to the core model to then pass the scenario test. I then needed to redo the modelling tests to reflect the new values.
After fixing the tests, rebalance is complete.
Describe alternatives you've considered
More balancing may be required in the future since I did not attempt to do any kind of major overhaul and instead focused on addressing the greatest offender. However, now with tests in place and better infrastructure for statistics, this should be easier in the future.
Additional context
Accuracy
Before
After
Damage
Before
After
*including misses
Closes #20414