The Mills · Games

oregon

An overland-trail game — mills/oregon

The Oregon Trail in a terminal

Summary

oregon is a port of the 1971 MECC overland-trail game — the one before the green ox-and-wagon graphics, when the whole game was prompts and consequences. Your family of five sets out from Independence, Missouri in 1847 with $700 left after paying for the wagon. There are 2,040 miles to cover before winter. Each turn is a fortnight — two weeks. You decide how much to eat, whether to hunt or push on, and whether to stop at a fort. The trail answers with riders, breakdowns, blizzards, and bad water from a sixteen-entry misfortune table. When the game tells you to TYPE BANG (or BLAM, POW, WHAM), type it fast and press Enter. How quickly you type is your marksmanship, exactly as it was on the teletypes this game was born on — printing terminals with a keyboard and a paper roll instead of a screen.

The Original

The Oregon Trail is a trademark of Houghton Mifflin Harcourt. This mill is an independent educational port of the 1971 MECC program, not affiliated with or endorsed by the trademark owner. See THIRD-PARTY-NOTICES.md.

The Oregon Trail was written in 1971 by three Minnesota student teachers. Don Rawitsch conceived it for his eighth-grade history class, and Bill Heinemann and Paul Dillenberger wrote the BASIC. They worked on a teletype connected to a timeshared minicomputer — one shared computer that many keyboards used at once. Rawitsch later brought it to MECC, the Minnesota Educational Computing Consortium. MECC's statewide network put it in front of a generation of schoolchildren, and made it arguably the most-played piece of educational software ever written. The BASIC listing this mill is ported from, oregon.bas, travels in the folder beside the port. Diff them — compare the two files line by line — if you're curious how 1971 control flow maps onto a language with no GOTO at all.

Running It

bin/mill run mills/oregon/oregon.shoddy

or, from mills/oregon/, use the wrapper — ./build.sh, or ./build.ps1 on Windows, same subcommands:

./build.sh          # run the game (also: ./build.sh run)
./build.sh test     # run the headless model checks

It's a plain console program — prompts in, text out, no window — so it runs anywhere the mill does. The only timing in the game is the shooting. The program reads Ticks() around a blocking Input — one that waits for your answer — and scores you on the difference. That is the same trick the original pulled with its CLK function.

It also ships on the Shoddy Reckoner's games shelf: a scrolling transcript with the platform's own input line beneath it, answers travelling the pipe — the same woven program, unmodified.

How It's Built

The game is split in the standard mill shape. The pure model is oregon-core.shoddy: the Trail record, the outfitting and eating arithmetic, the date table, the fourteen-day travel formula, the rider encounters, the misfortune table, the mountain crossings, and the arrival-date computation. It includes nothing, so it runs headless — nothing printed, nothing asked — and is checked that way by test.shoddy. The console half is oregon.shoddy: the instructions, the Input prompts, the timed shooting, and the turn loop. Each turn is a pipeline of phases. Every phase starts by standing aside if the Trail's fate is already sealed, so a death anywhere falls straight through to the funeral. The loop's only recursion — a function calling itself — is a genuine self tail call, a call made as the function's very last act, which the compiler turns into a loop.

Two design points are worth stealing. First, randomness arrives as a parameter wherever a roll decides a branch — did riders appear, which misfortune struck, did the shot miss. That way every branch is reachable deterministically from the tests: a test can steer to it on purpose. Only rolls that merely jitter a magnitude call Rnd directly. Second, the original's one-letter variables map one-for-one onto named Trail fields (M is Miles, B is Bullets, D9 is Skill…). So the port can be audited line-against-line with the BASIC.

Why More Than One File

The 1971 original is one BASIC listing. The port is two files, and the seam is drawn exactly where the effects are. Everything the game is — the Trail record and every formula and misfortune — lives in oregon-core.shoddy. That file includes nothing and touches nothing: no Print, no Input, no clock. Everything the game does to you — prompts, the timed shooting, the turn loop — lives in oregon.shoddy on top.

The payoff is test.shoddy. Because the core is pure and every branch-deciding roll arrives as a parameter, the whole ruleset runs headless under test. You can deterministically summon any of the sixteen misfortunes, fail any mountain crossing, and check the arithmetic of each. No amount of playing the interactive game could do that reliably. The split is also the language's own convention — effects kept at the edges — applied at program scale. The shell is the only place an effect happens, and it is deliberately too thin to hide a bug in.

The Machines It Uses

MachineWhy
mathIncluded by the console shell for exactly one word: Pick, which chooses uniformly which of BANG, BLAM, POW, or WHAM you must type when the game demands a shot.

That's the whole list — and the shorter fact is the better one: the core includes no machines at all. The 1971 game needed nothing but arithmetic and a random number. The port keeps that honest, calling the Rnd builtin directly for its magnitude jitters.