Re: Dropped third strikes.
Breaking down what happens when the third strike is dropped, the batter-runner would do one of the following. The batter-runner would probably:
(a) takes off to 1B, either sprinting or jogging based on how he think of his chances of making safely to 1B.
(b) looks around to check how far the dropped ball bounces/rolls away from the catcher before deciding to do (a) or (c)/(d)
(c) is unaware of the dropped third strike, heading to the dugout or stand still in the batter's box giving up.
(d) is aware but indifferent to the dropped third strike, being frustrated of striking out and busy making that feeling visible.
The batter-runner in The Show currently always do (a), which is admittedly not what guys in MLB do these days (even though they should probably be trained to always do so purely from a strategy view point).
Being able to see all these possibilities above would be nice, but I think just one thing that would add significantly to the situation, in my opinion, is adding animation for making (b) happen. The reason why the catcher always end up throwing to 1B instead of tagging the batter-runner to complete the strike out is because the batter-runner always takes off immediately, and the CPU catcher thinks that he cannot catch up to him and tag him out. Keeping the batter-runner a bit closer to the catcher a while longer makes the tagging happen.
I think this is a good thing to make happen even for online play, since one "exploit" HUM would use with runners on base, if the catcher always has to make a throw to 1B to complete a strikeout, is to take extra base(s) on a dropped third strike. If tagging is reasonably easier, there is a decision to make on such a play, and create more variety in what could happen on dropped third strike.
I think this is still there, I don't know which condition is used to distinguish sprinting and jogging, but there are times the batter-runner jogs to 1B instead of sprinting.
For a user-controlled batter runner, I agree that some mechanism like suggested here would help prevent the user from feeling cheated, when the (auto-controlled) batter-runner does not react the way he feels he should. It could even be pointing to the batter-runner with L3 down and with the circle button to instruct him to run to 1B (or simply pressing L1), which is seamless integration of how the controlling runners is currently done.
Breaking down what happens when the third strike is dropped, the batter-runner would do one of the following. The batter-runner would probably:
(a) takes off to 1B, either sprinting or jogging based on how he think of his chances of making safely to 1B.
(b) looks around to check how far the dropped ball bounces/rolls away from the catcher before deciding to do (a) or (c)/(d)
(c) is unaware of the dropped third strike, heading to the dugout or stand still in the batter's box giving up.
(d) is aware but indifferent to the dropped third strike, being frustrated of striking out and busy making that feeling visible.
The batter-runner in The Show currently always do (a), which is admittedly not what guys in MLB do these days (even though they should probably be trained to always do so purely from a strategy view point).
Being able to see all these possibilities above would be nice, but I think just one thing that would add significantly to the situation, in my opinion, is adding animation for making (b) happen. The reason why the catcher always end up throwing to 1B instead of tagging the batter-runner to complete the strike out is because the batter-runner always takes off immediately, and the CPU catcher thinks that he cannot catch up to him and tag him out. Keeping the batter-runner a bit closer to the catcher a while longer makes the tagging happen.
I think this is a good thing to make happen even for online play, since one "exploit" HUM would use with runners on base, if the catcher always has to make a throw to 1B to complete a strikeout, is to take extra base(s) on a dropped third strike. If tagging is reasonably easier, there is a decision to make on such a play, and create more variety in what could happen on dropped third strike.
I think this is still there, I don't know which condition is used to distinguish sprinting and jogging, but there are times the batter-runner jogs to 1B instead of sprinting.
For a user-controlled batter runner, I agree that some mechanism like suggested here would help prevent the user from feeling cheated, when the (auto-controlled) batter-runner does not react the way he feels he should. It could even be pointing to the batter-runner with L3 down and with the circle button to instruct him to run to 1B (or simply pressing L1), which is seamless integration of how the controlling runners is currently done.
Comment