Throw Urgency

[Woodweaver]

Quote: Originally Posted by clemson99

Check my catcher out on this play

That appears to be a bug with the cover logic and/or tag. Although this example has nothing to do with throw urgency, you should report this in the bug database.

[Woodweaver]

Quote: Originally Posted by tjhamstar

I know you can preload when contact is made which is what I do and have done in the many years I've played this game.

If you see it again, please provide a video if possible.

[Spokker]

It seems like there should be a better explanation for how all these mechanics work. When I was a first-timer, fielding was the most mysterious aspect of the game. Perhaps there should be an interactive tutorial for 2016 with examples of the various combinations of pre-loads and throwing strengths.

Although I knew to pre-load, this is the first I've ever heard the term branching in relation to this game. I think explaining that concept will emphasize the importance of pre-loading. Also, it's important to know where the throw is probably going before the pitch.

[Woodweaver]

Quote: Originally Posted by Spokker

It seems like there should be a better explanation for how all these mechanics work. When I was a first-timer, fielding was the most mysterious aspect of the game. Perhaps there should be an interactive tutorial for 2016 with examples of the various combinations of pre-loads and throwing strengths. Although I knew to pre-load, this is the first I've ever heard the term branching in relation to this game. I think explaining that concept will emphasize the importance of pre-loading. Also, it's important to know where the throw is probably going before the pitch.

There have been multiple tutorials over the years. One of the past video tutorials was referenced earlier in this very thread. I myself have posted explanations multiple times on OS concerning the branching animation system. I believe this feature was "on the back of the box" for a couple of iterations too. Maybe we need to do a better/different job of emphasizing the mechanic if it is still a mystery...?


And, yes, it makes good defensive sense to know where you will be throwing the ball before the pitch. You can begin your throw input as soon as the best fielder is selected (i.e. before he has even begun his catch animation).

[Spokker]

Quote: Originally Posted by Woodweaver

Maybe we need to do a better/different job of emphasizing the mechanic if it is still a mystery...?

I just erased everything I wrote and I have one question (it's never just one question) that will answer everything for me.

Is it right to characterize the game this way. "MLB The Show is a simulation with a graphical representation of that simulation on top."

In other words, when you throw to first, is the outcome of the play determined the moment the player throws the ball, or the moment the ball reaches the first baseman's glove? I think the former because no matter how hard you throw the ball to first, if David Ortiz is lumbering down the line, it will be a casual throw. It appears (I know nothing and this is just perception) that the game is not going to let me throw hard to first in that situation and let me look silly.

Bonus question: When bugs occur, is that the simulation and the graphical representation of that simulation going out of sync? Meaning, in that video where the catcher refuses to make the tag, in the absence of that bug, the runner would be out anyway? The game already calculated what should happen, but the graphics failed to represent it correctly?

[capa]

My opinion is as long as a human is controlling the player, it can't be a simulation that has already had the outcome defined and the graphics just represent that outcome...if that is what you were asking.

For example, on a clean single to CF, I could make my CF run away from the ball so he never picks it up which allows the runner to circle the bases. In a sim mode where graphics just display the outcome,, the batter would get a single and the CF would throw the ball into second.

Is that what you mean?

[Spokker]

Quote: Originally Posted by capa

Is that what you mean?

At it's core, my question is about the age-old debate between arcade vs. sim. For example, no matter how accurate you are with your placement and timing while batting, the game will not let you bat over .500 for a full season.

The Show seems like a balance between simulation and interactivity, and that's the way I like it. The opposite of The Show would be a game in which the physics are all calculated as the ball hits the bat, and whatever happens happens. If the player bats .800, so be it.

I prefer The Show, but a purely physics-based baseball would be neat to see.

Bottom line, The Show is such a work of art in representing such a complex game that it's no wonder people have so many questions about what goes on under the hood.

[Woodweaver]

Quote: Originally Posted by Spokker

I just erased everything I wrote and I have one question (it's never just one question) that will answer everything for me. Is it right to characterize the game this way. "MLB The Show is a simulation with a graphical representation of that simulation on top." In other words, when you throw to first, is the outcome of the play determined the moment the player throws the ball, or the moment the ball reaches the first baseman's glove? I think the former because no matter how hard you throw the ball to first, if David Ortiz is lumbering down the line, it will be a casual throw. It appears (I know nothing and this is just perception) that the game is not going to let me throw hard to first in that situation and let me look silly. Bonus question: When bugs occur, is that the simulation and the graphical representation of that simulation going out of sync? Meaning, in that video where the catcher refuses to make the tag, in the absence of that bug, the runner would be out anyway? The game already calculated what should happen, but the graphics failed to represent it correctly?

I don't want to get too far off topic here. But to answer you question quickly, yes and no. There are a finite number of animations we have to represent a game of infinite possibilities, and we are trying to make it appear like you are watching a MLB caliber game. So, often times the players input is scaled within specific parameters to make sure nothing ridiculous is going to happen, but nothing is predetermined until the player gives his/her input.


Using your specific example: Depending on how your fielder makes the play on Ortiz's hit (based on your input), the catch used, the time delta between your throw and Ortiz's time to 1B, and the situation on the field (i.e. other runners on base), the types of throw animations will be limited to provide an accurate MLB simulation. But, whether you miss your branch point while entering your throw input, commit an error, or throw the ball 50mph or 70mph (this range depends on your fielder's attributes among many other factors) to 1B is all based on your input in the moment. Not to mention the additional calculations that go on at the other end to see if the 1Bman actually makes the catch.


This is a simplification, and you can already see how complicated representing something as ostensibly simple as throwing a ball to 1B can be when trying to encode it. And, all of these points only encompass your one specific case!


And since we are already way off topic, I'll have to be even more brief answering your bonus question...no, that is not what caused that bug.