There are two main spreadsheets that drive the core of the Baseball Situation Simulator processor. One of those files is the ‘Results Spreadsheet’. The ‘Results Spreadsheet’ ties a description of a play to a set of instructions which tell the simulator what to do when that play is selected as the next action that occurs during a game simulator. The instructions tell the simulator how many bases to award to each player on base and the hitter, how many outs to record, and how many runs to record.
The spreadsheet needs to be in the Microsoft Excel ‘xls’ 2007 format. If you try to use current Microsoft Excel 2010 format, the program will not work.
Each line of the spreadsheet is a single result such as a ‘fly out’ or ‘single’ or whatever you want it to be. The example page shows a simple set of results but you can add or remove as many as you like. The first column is the type of result and the next 7 columns are whole numbers which tell the simulator what to do with the runners on base and the hitter. Here is an example:
The first numeric column (column B) will show how many bases the hitter gets. A ‘minus 1’ is an out. The next six columns are broken into two groups. Columns C, D, and E are what happens to the base runners if there is not a force situation. C is applied to the runner on first base, D is applied to the runner on second base, and E is applied to the runner on third base. Columns F, G, and H are what happens to the base runners if there IS a force situation. F is applied to the runner on first base, G is applied to the runner on second base, and H is applied to the runner on third base.
For example, if you look at the last result ‘ground out’, you’ll see that column B tells you the batter is out. The simulator then starts with third base and applies the number of bases in either column E or column H depending on if there is a force or not. If the runner is awarded base ‘4’, it counts as a run. The simulator then move to second base and repeats the process, then moves to first base. What you might notice is that if you have say a bases loaded situation and the simulator rolls up a ground out, it would result in a triple play. What happens in that situation is that the lead runner is considered out, all other runners advance, and the hitter is out for a double play. It’s an abstraction but it’s good enough for 1000 iterations of a given offensive situation.
One important thing to note is that the result name in column A can be anything you want. If you want 20 flavors of ground balls, you can have twenty different types of ground out, though they will need to have some difference in the name (ground out one, ground out two, etc...). The trouble with that is that you will need to devise percentages for each of these results that you wish to use. More on that in the ‘PID Results Spreadsheeet’ section.
Also, just because an entry for a specific result is in the ‘Result Spreadsheet’, does mean it will come into play. It needs to be referenced in the ‘Pid Results Spreadsheet’. There’s no error if a specific result entry isn’t reference but it doesn’t come into play either.
Finally, in this current version of the software, the load process is looking for the ‘done’ entry in column A at the bottom of your results entries. I will probably eliminate that in the future but it’s there for now.
The sophistication of these result rules may change in subsequent versions of the app. For example, instead of a result entry just having seven different outcomes depending on base and force/non-force, I was considering allowing a result to link to a set of templates which enumerate each possible base runner situation and dictate a specific result. It would also be possible to have a template have several different results for a given base runner situation and pick one based on user defined percentages. However, that’s not how it works today.
So let’s look at a couple of examples.
First and Second with no outs and a ground out result is generated
Third base is empty so no outs or no advances are recorded there. Second base is occupied and there is a force situation so when choosing between D and G, G is chosen because of the force situation. The ‘minus one’ instructs the simulator to record an out with the runner at second. At this point, the ‘double play rule’ comes into play. The runner one first is awarded second base even though the ‘minus one’ in column F would ordinarily indicate an out. Then the batter is recorded out leaving two outs and a runner on second base.
Runner on Second with no outs and a ground out result is generated
Third base is empty so no outs or advances are recorded for that base. Second base is occupied but it is not a force situation so the simulator will choose column D instead column G. Column D is a zero so the runner doesn’t advance and also isn’t out. First base is empty so that one is skipped. Finally, column B indicates that the hitter is out. The final result is that one out is recorded for the hitter and the runner stays at second base.
Runner on Second with no outs and a single is generated
As you can see, there are two different singles defined in the table. I will assume that ‘single two’ has been generated. Third base is empty so nothing happens. Second base has a runner and there is no force so column D is used. The runner is awarded two bases and because the new base is base ‘4’, a run is recorded. Nobody is on first so nothing happens there. Finally, the hitter is now on first base.
