Not breaking out the tinfoil, but... - Page 2

battists · 06-29-2015, 06:36 AM

And honestly, when you talk about trade AI etc., you're getting into areas that simply have to be near-impossible to make truly realistic. Building a sim engine to produce statistics in a certain way is one thing. In a way it's just one big math problem, but the whole thing of trading has so many freaking variables, and so many of them are "fuzzy"... What is "good value"? What is more important, short-term or long-term? Etc. etc.

It's impressive to be sure.

Biggio509 · 06-29-2015, 11:41 PM

Quote:

Originally Posted by ConStar

Anyway, this is either a failure in the way the PBP was communicated back to me, or a guy with a 14 OF arm rating is really Bo Jackson.

Only "Bo Knows"

Bo knows astroturf!

mainstreet · 06-30-2015, 09:37 PM

Quote:

Originally Posted by The Wolf

Has anyone else noted what tiny (and often imaginary) things people are complaining about these days? The only exceptions I can see are the trade AI, the defensive AI, and the in-game AI, and we veterans were complaining about those things back in the days of version 6.5 and will probably be complaining about them in the days of version 26.

The quality of the game is just amazing. Simply amazing.

I have taken to playing as a neutral and always managing both teams any time I play out a game because of bad AI decisions as manager, yeah.

Trading is always going to be odd, because ultimately, the AI has to set values of players somehow, and you will almost always be able to find a way to beat it with enough effort. Very hard helps this, but that tends to also shut trades down that the AI would benefit more from. It's just the nature of value setting having to be constant and not being able to cover all possibilities of what the teams are. As such, I find no issue with the trade engine. Don't like abusing it, just don't make abusive trades.

BradC · 07-03-2015, 01:28 PM

RE the trade engine: As Steve says, it's a pretty amazing piece of work. Also, it's a computer that's making unemotional decisions based on ratings and statistics. A lot of times when people react to trades in real life, they're reacting to the names involved and having a knee jerk reaction based on that. How many people read about a trade and then go look up the players' stats and try to make a reasonable assessment of the transaction based purely on numbers? Sure, professional baseball writers do, but most fans don't.

Which, of course, leads to the way people react to trades they see in the game.

RE the PBP not always matching what the game engine produces: Let me see if I can explain this. Steve (or anyone else), feel free to correct me here, since I think you have a better technical background than I do. (The extent of my programming experience is 30+ years old, when I learned BASIC on a TI computer.)

The game engine produces a result, which in this case is a long fly ball. The engine goes to the PBP to randomly produce a line of text from the "long fly ball" batch. In this case, it happened to pull one out that described the outfielder going back against the wall.

Now the engine says, "Okay, runners on base. Guy on third will tag up and try to score. Give me a PBP line for that." So, again, it randomly pulls one out.

At this point, I assume the engine is essentially rolling dice and consulting tables, to put it in terms those of us who have played dice-and-card games (as well as D&D) understand. It rolls the dice and, in this case, it comes up with a more rare result that says the outfielder will try to throw the runner out. (More often than not, a long fly ball results in the runner from 3rd scoring without a throw, but in this rare instance, a throw happens.)

The game takes the runner's speed and the outfielder's arm and rolls more dice. Well, what do you know: He threw the runner out at the plate.

For each of those steps, it's again going to the PBP part of the game and asking for a random line of text from the appropriate container.

And then the game knows that a long fly ball with a throw to the plate will allow the other runners to advance, it grabs that piece of text. (I assume there are no dice rolls here.)

Unfortunately, as Steve said, the engine has no idea that the piece of text that was randomly produced in the first place described the outfielder going up against the wall, so it doesn't know that the resulting PBP is going to look a little wonky.

I suppose once we have 3D players running around on the field, we'll need a true physics-based game engine, rather than a dice-and-tables one, that will know *exactly* where each ball is hit and will produce a realistic-looking result because it knows where every element -- the ball, every fielder, and every runner -- is at every second of the play.

And then that will have to match the PBP, which will be interesting. I'm sure that's something Markus is currently wrestling with.

D-BacksJosh · 07-03-2015, 01:56 PM

Quote:

Originally Posted by Biggio509

Only "Bo Knows"

Bo knows astroturf!

Damn straight!

Dyzalot · 07-03-2015, 02:01 PM

Could the pbp part be "fixed" by not having it pick a "random" line of text for a flyball until it knows if the flyball will result in a play at the plate or not? The same could be done for groundballs that do or don't result in double plays and base hits that do or don't result in a runner trying to go from first to third.

Tram2Whitaker · 07-03-2015, 02:47 PM

Quote:

Originally Posted by Dyzalot

Could the pbp part be "fixed" by not having it pick a "random" line of text for a flyball until it knows if the flyball will result in a play at the plate or not? The same could be done for groundballs that do or don't result in double plays and base hits that do or don't result in a runner trying to go from first to third.

Like the lines "leaping" or "diving" grab would have -3 probability assigned to them, so then the next dice roll would have to be extra rare.

Dyzalot · 07-03-2015, 03:15 PM

Quote:

Originally Posted by Tram2Whitaker

Like the lines "leaping" or "diving" grab would have -3 probability assigned to them, so then the next dice roll would have to be extra rare.

More like the dice rolls would all be calculated to come up with the play result before lines of text are selected to produce the PBP. Then the PBP could be tailored more to how the play actually turns out.

BradC · 07-03-2015, 06:20 PM

My guess is this would depend on how the game engine works. Doing that could require extensive rewriting of the code, which probably wouldn't be worthwhile just to fix those uncommon situations like the one the OP described.

I'll ask Matt to check out this thread and chime in, if he has any thoughts.

Quote:

Originally Posted by Dyzalot

More like the dice rolls would all be calculated to come up with the play result before lines of text are selected to produce the PBP. Then the PBP could be tailored more to how the play actually turns out.

Dyzalot · 07-03-2015, 06:46 PM

Should only affect the timing of when PBP text is generated. Don't see how that would take extensive rewriting of the code but I'm not a programmer either so...

Le Grande Orange · 07-03-2015, 06:51 PM

Quote:

Not breaking out the tinfoil, but...

I'm shocked—shocked!—to see this level of disrespect aimed at tinfoil!!!

Matt Arnold · 07-03-2015, 07:20 PM

The PBP is tailored to the play result, but only to a certain point. We do generate whether it's shallow or deep, what part of the field it goes to, and even how difficult a catch it is. In this case, we must have just squeaked through our random number cases to get the guy out at the plate. Maybe we're not strict enough in saying "anytime it's very deep and very hard catch, score a runner from 3rd", but that code is very complicated, and we certainly always have to be sure that we have the right number of players tag up.

The main flaw now is that we essentially generate the FB, grab text for it, then check to see if runners are moving, then grab the text for that. It's probably a fairly decent rework to know what happens to all the runners before grabbing the text for the fly. Whenever we end up doing major work on the game engine, we can certainly see what we can do to make sure that the text lines up more closely with the plays on field.

ConStar · 07-05-2015, 01:23 AM

Quote:

Originally Posted by Matt Arnold

The PBP is tailored to the play result, but only to a certain point. We do generate whether it's shallow or deep, what part of the field it goes to, and even how difficult a catch it is. In this case, we must have just squeaked through our random number cases to get the guy out at the plate. Maybe we're not strict enough in saying "anytime it's very deep and very hard catch, score a runner from 3rd", but that code is very complicated, and we certainly always have to be sure that we have the right number of players tag up.

The main flaw now is that we essentially generate the FB, grab text for it, then check to see if runners are moving, then grab the text for that. It's probably a fairly decent rework to know what happens to all the runners before grabbing the text for the fly. Whenever we end up doing major work on the game engine, we can certainly see what we can do to make sure that the text lines up more closely with the plays on field.

Thanks to all the staff posts and time spent to answer this for me.

While I'm on it, the only other instance I can think of where the PBP is lacking is on scratch infield hits when the ball dies in the area somewhere between the catcher and the pitcher. In my experience, even very slow-footed runners seem to reach base an inordinate amount of time. I'm left to believe there's something we're not seeing because of limits regarding PBP text line possibilities.

In my opinion, if you simply add new lines of PBP text possibilities with each version, you'll eventually cover up both these problems.

This has been the only part of the game that has had an actual effect on the way I play. I had to assign baserunning decisions to my actual manager (I play out all the games, with myself in a GM/manager role) because I didn't feel I could trust the PBP engine to give me a realistic account of exactly what was going on in the OF.

06-29-2015, 06:36 AM	#21
battists Hall Of Famer Join Date: Jul 2004 Posts: 18,506	And honestly, when you talk about trade AI etc., you're getting into areas that simply have to be near-impossible to make truly realistic. Building a sim engine to produce statistics in a certain way is one thing. In a way it's just one big math problem, but the whole thing of trading has so many freaking variables, and so many of them are "fuzzy"... What is "good value"? What is more important, short-term or long-term? Etc. etc. It's impressive to be sure. __________________ Come check out my dynasty report, Funky Times!

07-03-2015, 01:28 PM	#24
BradC All Star Starter Join Date: Jan 2011 Location: northern CA Posts: 1,886	RE the trade engine: As Steve says, it's a pretty amazing piece of work. Also, it's a computer that's making unemotional decisions based on ratings and statistics. A lot of times when people react to trades in real life, they're reacting to the names involved and having a knee jerk reaction based on that. How many people read about a trade and then go look up the players' stats and try to make a reasonable assessment of the transaction based purely on numbers? Sure, professional baseball writers do, but most fans don't. Which, of course, leads to the way people react to trades they see in the game. RE the PBP not always matching what the game engine produces: Let me see if I can explain this. Steve (or anyone else), feel free to correct me here, since I think you have a better technical background than I do. (The extent of my programming experience is 30+ years old, when I learned BASIC on a TI computer.) The game engine produces a result, which in this case is a long fly ball. The engine goes to the PBP to randomly produce a line of text from the "long fly ball" batch. In this case, it happened to pull one out that described the outfielder going back against the wall. Now the engine says, "Okay, runners on base. Guy on third will tag up and try to score. Give me a PBP line for that." So, again, it randomly pulls one out. At this point, I assume the engine is essentially rolling dice and consulting tables, to put it in terms those of us who have played dice-and-card games (as well as D&D) understand. It rolls the dice and, in this case, it comes up with a more rare result that says the outfielder will try to throw the runner out. (More often than not, a long fly ball results in the runner from 3rd scoring without a throw, but in this rare instance, a throw happens.) The game takes the runner's speed and the outfielder's arm and rolls more dice. Well, what do you know: He threw the runner out at the plate. For each of those steps, it's again going to the PBP part of the game and asking for a random line of text from the appropriate container. And then the game knows that a long fly ball with a throw to the plate will allow the other runners to advance, it grabs that piece of text. (I assume there are no dice rolls here.) Unfortunately, as Steve said, the engine has no idea that the piece of text that was randomly produced in the first place described the outfielder going up against the wall, so it doesn't know that the resulting PBP is going to look a little wonky. I suppose once we have 3D players running around on the field, we'll need a true physics-based game engine, rather than a dice-and-tables one, that will know exactly where each ball is hit and will produce a realistic-looking result because it knows where every element -- the ball, every fielder, and every runner -- is at every second of the play. And then that will have to match the PBP, which will be interesting. I'm sure that's something Markus is currently wrestling with.

07-03-2015, 02:01 PM	#26
Dyzalot All Star Starter Join Date: May 2008 Posts: 1,740	Could the pbp part be "fixed" by not having it pick a "random" line of text for a flyball until it knows if the flyball will result in a play at the plate or not? The same could be done for groundballs that do or don't result in double plays and base hits that do or don't result in a runner trying to go from first to third.

07-03-2015, 06:46 PM	#30
Dyzalot All Star Starter Join Date: May 2008 Posts: 1,740	Should only affect the timing of when PBP text is generated. Don't see how that would take extensive rewriting of the code but I'm not a programmer either so...

07-03-2015, 07:20 PM	#32
Matt Arnold OOTP Developer Join Date: Jun 2009 Location: Here and there Posts: 16,254	The PBP is tailored to the play result, but only to a certain point. We do generate whether it's shallow or deep, what part of the field it goes to, and even how difficult a catch it is. In this case, we must have just squeaked through our random number cases to get the guy out at the plate. Maybe we're not strict enough in saying "anytime it's very deep and very hard catch, score a runner from 3rd", but that code is very complicated, and we certainly always have to be sure that we have the right number of players tag up. The main flaw now is that we essentially generate the FB, grab text for it, then check to see if runners are moving, then grab the text for that. It's probably a fairly decent rework to know what happens to all the runners before grabbing the text for the fly. Whenever we end up doing major work on the game engine, we can certainly see what we can do to make sure that the text lines up more closely with the plays on field.