Pennant ChaseCross-sport handoutGrades 7–12

Inside the Sim Engine

Nobody played those games. A program did — thousands of them, in a few seconds, using nothing but old statistics and a source of randomness. This is how that is possible.

NameClassDate

A note on what follows. This handout describes how a sports simulation can work — the standard ideas any such program has to use. It is not a description of Pennant Chase's actual code. Treat it as a hypothesis to test against your league's results, because testing it is more interesting than being told.

Idea One

A statistic is already a probability

This is the move that makes everything else possible, and it's small enough to miss. When a hitter's on-base percentage is .350, that isn't only a description of what he did. It's an estimate of what he'll do next time: about a 35% chance of reaching base in any given plate appearance.

The same conversion works everywhere. A 47% field goal shooter has a 0.47 chance of making the next one. A running back averaging 4.3 yards a carry has a distribution of outcomes centered near 4.3 yards. A statistic that was a record of the past becomes a forecast of the future, and a program can act on a forecast.

Try it

Convert each of these into a sentence about the next opportunity:

A batter with a .275 batting average.
A pitcher with a strikeout in 22% of the batters he faces.
A kicker who has made 84% of his field goals.
A quarterback who throws an interception on 2.5% of his attempts.

Now the harder one: which of those four estimates would you trust the most, and which the least? What information would you want before deciding?

Idea Two

Two players, one number

Here's the real problem. A hitter reaches base 35% of the time. The pitcher facing him allows it 30% of the time. Both numbers are true, and they can't both happen.

The obvious fix is to average them — .325. That's not bad, but it's wrong in a way you can feel: it ignores the league. Facing a .300 pitcher in a league where the average is .320 is a much tougher assignment than facing a .300 pitcher in a league where the average is .280.

The standard solution is called the odds ratio or log5 method. It compares each player to the league, combines the comparisons, and converts back:

A = the batter's rate B = the pitcher's rate allowed L = the league average rate top = (A × B) ÷ L bottom = ((1 − A) × (1 − B)) ÷ (1 − L) P = top ÷ (top + bottom)

Worked example

A = .350, B = .300, L = .320.

Step by step
Step	Arithmetic	Result
Numerator	(.350 × .300) ÷ .320	.3281
Second term	(.650 × .700) ÷ .680	.6691
Denominator	.3281 + .6691	.9972
P	.3281 ÷ .9972	.329

So the engine gives the hitter about a 32.9% chance — between the two players, tugged toward the better one. The simple average would have said .325. Close, but the formula's answer is the one that stays sensible in a league where the average is .250 or .400.

Your turn

A .400 on-base hitter faces a pitcher who allows .280, in a league averaging .320.

What does simple averaging predict?
What does the formula predict? (Answer: .355 — show that you can get there.)
The formula's answer is higher than the average. Explain why an elite hitter gains more from the formula than a merely good one does.
Now set A = B = L = .320. What does the formula give, and why is that a good sign that the formula is built correctly?

Idea Three

Turning one number into an outcome

Knowing there's a 32.9% chance of reaching base doesn't finish the job — the engine still has to say what happened. Walk? Single? Home run? Groundout to short?

The method is a probability band table. Every possible outcome gets a slice of the number line proportional to its chance. The engine draws a random number, sees which slice it landed in, and that's the play.

A batter's outcome table — draw a number from 00 to 99
Outcome	Chance	Lands on
Walk	9%	00–08
Single	16%	09–24
Double	4%	25–28
Triple	1%	29
Home run	4%	30–33
Out	66%	34–99

Notice that the on-base outcomes occupy 00 through 33 — exactly 34%, which is this batter's on-base percentage. The band table doesn't invent the probability, it just decides how to divide it up.

Check your understanding: a better hitter faces the same table. Which bands grow, which shrink, and by how much? Write out a table for a hitter who reaches base 42% of the time and hits home runs twice as often as this one.

Idea Four

One play is a chain, not a roll

Real plays have parts. The band table above got you to "single" — but a single with a runner on second is not one event. Does the runner score? Does the batter take second on the throw? Who fielded it, and how strong is his arm?

So the engine draws again. And again. A single play might be four or five separate draws stacked on top of each other, each one using different statistics:

Baseball: outcome type → where the ball went → which fielder → did he make the play → how far did each runner advance

Basketball: who shoots → make or miss → if miss, who rebounds → if made, was there a foul

Football: run or pass → who carries or is targeted → complete, incomplete, sack, or turnover → how many yards → was there a penalty

One link in the football chain is different from all the others, and it's worth finding: the run-or-pass decision isn't determined by anyone's statistics. Down, distance, score, and time on the clock have to feed into it. That's a simulation encoding strategy rather than talent — a genuinely different kind of rule.

Idea Five

Why a game lies and a season doesn't

Give a .320 hitter ten at-bats and he might go 1-for-10. Give him five hundred and he'll land close to .320. Nothing about the player changed. The number of chances did.

Here's roughly how far from .320 pure chance can push a hitter, by sample size. The column on the right is about how far a typical season strays in either direction:

Expected spread around a true .320 rate
At-bats	Typical swing (± 1 SD)	What that looks like
10	± .148	Anywhere from .172 to .468. Meaningless.
50	± .066	A hot month or a cold one. Still noise.
100	± .047	Starting to say something.
500	± .021	A full season. Now the number means something.

Standard deviation = √( p × (1−p) ÷ n ), where p = .320

The question this answers

Your .320 hitter batted .270 for you over 500 at-bats. That's .050 below his rate, or about two and a half typical swings' worth — unusual, but not impossible from luck alone.

So which was it? Bad luck, or is the engine doing something to him — tougher pitching, a different park, a spot in the lineup that gave him fewer chances with runners on? Decide what evidence would tell those apart, then go looking for it in your league.

Unplugged

Be the sim engine

Before you trust a program to do this, do it by hand. In pairs, simulate a half-inning.

What you need

A random number from 00 to 99. Two ten-sided dice work; so does =RANDBETWEEN(0,99) in a spreadsheet, or any random number generator.
The band table from Idea Three, or one you built yourself for a real player.
Paper to track outs, baserunners, and runs.

The rules

Draw a number. Look up the outcome. Record it.
Move the runners: a walk or single advances everyone one base, a double advances two, and so on. Keep it simple — you're modelling, not officiating.
Three outs ends the half-inning.
Play nine half-innings. Log runs scored each time.

Half-inning log
PA	Draw	Outcome	Bases after	Outs	Runs
1
2
3
4
5
6
7
8
9
10
11
12

Then answer these

How long did nine half-innings take you? Estimate how long a 162-game season would take by hand. Now consider that a computer does it in seconds — what does that change about what's possible?
Pool the whole class's results. What was the average runs per half-inning? Compare it to your own. Whose number should you trust, and why?
Your table was the same every time. Real baseball changes the pitcher, the park, and the defense. Pick one of those and describe exactly what you'd change in the table to represent it.
You simulated a batter who reaches base 34% of the time. Across all your plate appearances, what fraction actually reached? If it isn't 34%, is your simulation broken?

What you now think the engine is doing — in your own words

Teacher guide

Teaching the primer

What this is for

The primer works as a standalone probability unit and as the extension to any of the three draft activities. Students who have already been asking "how does the computer decide?" arrive motivated, which is the whole reason to run it after a season rather than before.

It touches simple probability, complementary events, weighted outcomes, expected value, sampling variability, and the law of large numbers — usually without a student noticing they've left sports.

Answers to the worked problems

Idea Two, question 1: simple averaging gives .340.
Question 2: numerator (.400 × .280) ÷ .320 = .350; second term (.600 × .720) ÷ .680 = .635; total .985; .350 ÷ .985 = .355.
Question 3: the formula works in odds rather than percentages, and odds grow faster than rates at the extremes. A student who says "being twice as good doesn't mean twice the rate, it means twice the odds" has it.
Question 4: setting A = B = L returns exactly L. A formula that didn't do that would be broken, and checking a boundary case is a habit worth naming out loud.
Unplugged, question 4: the observed fraction will rarely be exactly 34%, and the point is that this is expected. With 12 plate appearances the typical swing is about ±14 percentage points. Not broken — just small.

Where classes get stuck

The formula as magic. Students will plug numbers in without a sense of what it does. The fix is the boundary check in question 4, plus asking them to predict whether the answer will be above or below the simple average before computing.
Randomness as unfairness. "The sim cheated my team" is the most common complaint of the entire unit. Idea Five is the direct answer, and the class-pooled data in the unplugged activity makes it concrete in a way an explanation can't.
0.44 and other constants. If students have come from the basketball activity they'll ask where numbers like that come from. Empirical estimation is a legitimate answer, and "somebody measured it and this fit best" is worth saying plainly.

Extensions worth the time

Spreadsheet version. Have students build the band table with RANDBETWEEN and VLOOKUP and run a thousand plate appearances. Watching the observed rate converge on the true rate as the sample grows is the law of large numbers in one screen.
Build your own engine. For a CS class, this handout is a complete specification for a simple baseball simulator in whatever language you teach. Fifty lines gets a working half-inning.
Break it on purpose. Ask students to design a table that produces obviously wrong baseball — a league where nobody ever walks, or where a third of plate appearances end in home runs. Simulating it teaches more about which numbers matter than any correct model does.

Setting up a league

Email guy@pennantchase.com for a free class league. Send a spreadsheet of student logins to have accounts created in bulk — the site blocks repeated sign-ups from a single IP address, which is what a class on a school network looks like. Note that some school district mail servers block mail from pennantchase.com, so if no reply arrives, ask IT to allow the domain or write from a personal address.