While playing on my Palm this afternoon and messing around with some save games, discovered something interesting (although I'm not sure how this can be used for any benefit).
Apparently, the computer "decides" the pitch sequence for a hitter when he comes up to bat. Try this (it works on NesEm on the Palm, I assume it works in other emulators as well) - save the game just as your player comes up to bat. Watch a few pitches go by, don't swing, but make a note of what kind of pitch (slow, fast, regular), where the pitches is on the rubber, and where it crosses the plate.
Now load the saved game. You will see the exact same pitch sequence, including pitcher and pitch location. It would therefore appear that there is some kind of pitch "logic" in use, rather than just a random selection for each pitch. This much I'm sure about.
Less sure about this part - I've also noticed that I tend to get the same results from swinging on a given pitch. If I swing at the first pitch each time, and time the swing pretty much the same, I'll generate an identical result - the ball will be hit the same way (grounder, line drive, fly) with the same velocity and the same location. Using the Tettleton vs. not using it does seem to affect this, or intentionally swinging very early/late to try to direct the ball, but that's about it. Is it possible that the outcome of a given swing is determined before the ball is even thrown? As in - if you hit this, it will be a flyout to the right fielder at the wall, or you can not swing and wait for the next pitch.
It would be quite interesting to see if other people see similar results.
Could it be something with your palm's random number generator?
Curious if this works on the NES emu.
Can any1 verify?
Dryden: First Part: What you observed in pitch consistency is most likely a function of the two 'unknown' numbers that are given to each pitcher. I think that the strategy or 'pattern' of computer pitches is determined by these numbers. Your experiment seems to confirm that there is a mathematic pattern to the approach of a pitcher. Check the numbers out in nightwulfs rom editor. This is very nice work Dryden. This could be a window into making the computer pitcher actually somewhat challenging. If the mystery numbers do what your experiment suggests, then maybe one could manipulate the computer pitcher into a 'tough' pattern. Now, if only we could change the computers awful defense ....
Second Part: I really really doubt this. The result of a swing is determined by a number of factors that are not worth going into (due to length). Check out a post i did on contact and some of nightwulf's work on the subject.
What you observed does make some sense though. Pieces of shit like Danny Gladden and Jose Uribe tend to hit crappy grounders that end up with them running back to the dugout bawling. So if you used players like them as test examples it is logical that you would observe similar, pathetic results. But this is not as much a function of RBI 'destiny' as it is of a number of other factors (power, contact, rating, pitch speed, etc ...).
Good work
Here are some related posts on the subject
http://forums.dee-nee.com/index.php?board=3;action=display;threadid=2987
http://forums.dee-nee.com/index.php?board=3;action=display;threadid=2752
When I get time, I might test this also, additional interesting test would be to PH for the batter the next time, and see if the pitch sequence changes.
I thought it might be something to do with the Palm random number generator as well, hence why someone would need to test this elsewhere...
There do seem to be a couple of circumstances where the pitcher will change approach a little bit, most noticably when there are already 3 balls to the batter (there tend to be strikes thrown, obviously).
What I was saying about the result of the swing is this - If you make the exact same swing on the exact same pitch, you will get the exact same result. You can intentionally time the swing to change the result (using the Tettleton accomplishes much the same thing, as does moving up/back in the box while swinging) but the result will be identical if the swing is. Again, this may be a result of the palm random number generator, but if not, there is some pre-determined aspect to how the ball is hit (ground, line drive, fly). The direction and power are obviously controllable, to a degree.
I'd love to see what other people can uncover about this.
This is all very good stuff, and needs more testing. My lazy ass hasn't been doing any RBI stuff lately, but someone take the control of testing on the NES emulators...
It might not just be the Palm random number generator - I'd guess that a random number seed is created when the virtual NES boots up, and that's probably preserved in the save state file, so that when the state is loaded, things progress just as they were before.
I always thought the pitch sequence was pseudo-random. It seems like if they throw a ball for the first pitch, they will throw the next two pitches for balls.
Can anyone verify this type of thing?
Hardware differences between emulator platforms won't make any difference. Remember that the NES had no hardware to generate random numbers. It's all done in software. From the "BOPs explained" document:
Random number generation in RBI Baseball:
Three locations in RAM, $15, $16, and $17, are used in random number
seeding and generation. All three are initialized to $00 on reset, and
$17 is reinitialized to $FF shortly thereafter.
These three locations are constantly changing. The subroutine at $EE67
is responsible for this. I believe that this subroutine runs on every
scanline, but I'm unsure of this. An easy way to see how frequently these
numbers change is to watch them change in real time (using Nester or FCEU).
The numbers are constantly changing, literally too fast for the eye to
catch.
$EE67> A5 16: LDA $16 ;
$EE69> 0A: ASL A ;
$EE6A> 45 15: EOR $15 ;
$EE6C> 49 80: EOR #$80 ;
$EE6E> 0A: ASL A ;
$EE6F> 26 15: ROL $15 ;
$EE71> 26 16: ROL $16 ;
$EE73> A5 17: LDA $17 ;
$EE75> 0A: ASL A ;
$EE76> 0A: ASL A ;
$EE77> 38: SEC ;
$EE78> 65 17: ADC $17 ;
$EE7A> 85 17: STA $17 ;
$EE7C> 45 15: EOR $15 ;
$EE7E> 45 16: EOR $16 ;
$EE80> 60: RTS ;
This subroutine performs a variety of binary math functions on the three
addresses ($15, $16, and $17), and ultimately exits leaving a "random"
number in the accumulator.
The behavior will be the same in any emulator on any platform.
Nightwulf