Contributor Mathew Chakko flagged up that “The Sporting News Baseball” game by Epyx Software in 1988 was advertised with a panel area that had a number of differences compared to the final game. Here it is:
Now compare to the screenshot from Gamebase64:
There is a MPH meter and also what seems to be a wind direction line too? Very minor differences from what was probably just a slightly earlier build used to screenshot. Interesting though to see :)
One of the developers along with Michael Polan, Rich Unruh kindly gave some details about the game’s development (and about the Wind feature). We have added this to the piece below:
“I worked with Mike (and others) on Sporting News Baseball. My memory is bittersweet because I was laid off before the game was finished. (Why will become apparent below.) That said, I really enjoyed the work, and working with Mike.
I did the ball motion math & logic.
Regarding all of the factors: I was doing the ball motion, starting from the point of the batter’s swing at a pitch. As I recall it, Mike’s code generated the “pitch” using various statistics, etc. From that data, and the player’s swing data, the ball to bat contact was calculated. I recall:
– Batter’s swing selection and timing combined with the ball’s position in the strike zone (I think Mike’s code provided the ball position and velocity vector in the strike zone) provided info for further calculations:
– Contact point along the length of the bat in I think 32 different locations. This may have influenced the left-right angular direction of the ball, but I also recall having the bat’s “sweet spot” (google “center of percussion”) calculated and influencing the “strength” of the hit.
– Contact point up/down across the face of the bat. IOW: two round objects in an elastic collision, like pool balls. Determined the up/down angle taken by the ball off of the bat.
After the raw ball to bat contact and resulting vector were produced, batter statistics modified the hit. I remember something about “slug percentage” being an influence but I don’t remember anything specific.
The end result was a set of X, Y & Z velocities that were applied for ball motion.
If you’re interested in more technical details and background…
I was shown an earlier C64 baseball game that sucked. In particular it was only possible to have 9 different hits: shallow, middle and deep; left, center and right – “Don’t make it like that” was my specification.
At the time I had (relatively speaking) substantial programming experience “playing” with computers, but no experience with system architecture considerations like allocation of CPU load, RAM, etc. So when they said “Don’t make it like that” I took them at their word – the result was the capability to have over 4 billion different hits.
I implemented a Qn.12 fixed-point 3D coordinate system. Ridiculous overkill for the application, but the ball motion was absolutely fluid…until merged with the play logic and then it got “jumpy” due to overloading the CPU.
Regarding an earlier question about wind: I did put in wind but it was removed for CPU load and code space. I had also experimented with drag (I was earning my pilot’s license at the time so it seemed natural to me) so the ball would slow down as it flew. Between the wind and the drag (and playing with the gravity) you could make the game play like you were playing in a hurricane…or on the moon…or a high-gravity world with an atmosphere like honey. It was fun…but it wasn’t salable and didn’t pay the bills.
One final point. I worked with Mike again with a different employer. Indirectly, Mike taught me one of life’s key lessons. One day, we were having a company meeting and the boss paid Mike one of the highest compliments I’ve ever heard. The boss explained what Mike was working on and the success he had, then he said “Thanks, Mike. You put food on my table.” I’ve never forgotten it.”
With thanks to Rich Unruh and Michael J Polan for talking about the game and to Mathew Chakko for flagging up the difference in the screenshot.