Significance of the Study
In 1971 three students at Carleton College in Northfield, Minnesota came up with the idea to do something new with computers. Don Rawitsch, Paul Dillenberger, and Bill Heinemann were studying education and about to start work as student teachers. Rawitsch was tasked with 8th grade American history and wanted to make something more interesting and engaging than the usual lecture or boring reading. He wanted to engage the students in new and exciting ways, so Rawitsch began to prototype a tabletop game that simulated being a pioneer. It was originally played with dice, but Dillenberger and Heinemann suggested a different method. Both had received rudimentary training in computer programming, and in Rawitsch’s game they saw something that could translate well to a computer. Though none of them was an expert at code, Rawitsch described that they did have “an understanding of how an event could be simulated mathematically by setting up algebraic relationships between variables that represented the impact of user decisions, the financial value of supplies, and random events.” In two weeks, the trio was able to create a working version of a game they called “the Oregon Trail.”
First imagined in 1971 by Minnesota student teachers, Oregon Trail went on to become the longest-published and most successful educational game of all time. As of 2017, more than 65 million copies have been sold worldwide, and the game that began on a teletype machine remains popular in a version designed for smartphones.
In 1971, three Carleton College student teachers in Minneapolis created the first version of what would become Oregon Trail. While searching for a way to get his students to participate in history, Don Rawitsch decided to create a game to teach students about Euro-American westward migration in the mid-1800s. His roommates, Bill Heinemann and Paul Dillenberger, suggested making a computer game out of what was then a rudimentary board game. At the time, each school in Minnesota had a teletype machine but no other computing hardware.
On December 3, 1971, Oregon Trail debuted in Rawitsch’s class. Students played the game in groups of five; with only one machine, the groups had to take turns. One game lasted the entire class time allotted for the subject, so other students gathered around to watch.
Players begin the game by selecting an occupation for their traveler out of three choices: banker, carpenter, or farmer. They then lead a party of migrants along the Oregon Trail, overcoming obstacles, deciding when to travel and rest, and keeping track of food rations. Players win by reaching the end of the trail with travelers still alive.
The game’s popularity at the school was unexpected. Students came to class at seven o’clock in the morning and stayed until the last teacher left the building just to play the game. At the end of December, when the class ended, the creators shut the game down and took the printouts of the code with them.
That code remained unused until Don Rawitsch accepted a job at the Minnesota Educational Computing Consortium (MECC). Rawitsch was a conscientious objector to the Vietnam War, and in order to avoid the draft, he needed a job that would be of alternative service to the country.
MECC, created in 1973, was a government initiative to introduce technology to schools. After it hired Rawitsch in 1974, it held an open call for educational software that it could include in its timeshare software package. Remembering the program that he had created with his friends, Rawitsch dug up the old code for Oregon Trail with permission from Heinemann and Dillenberger. In 1975, Oregon Trail was officially added to the UNIVAC system. Rawitsch worked with the programmers to improve the game, even consulting the diaries of Oregon Trail travelers to ensure that the information was accurate.
In 1978, MECC accepted a bid from Steve Jobs and Steve Wozniak to provide Apple II microcomputers to Minnesota schools. It retooled Oregon Trail for the new Apple II machines and added the game to the software package provided to Minnesota’s public schools. Minnesota wasn’t the only state that was focused on providing technology for schools, but it did have the most organized and complete software package. Due to public interest, MECC began to sell the software to schools across the country. By 1989, almost every school district in America had a computer. That same year, at the height of the game’s popularity, one in every three school districts in the country had Oregon Trail in its classrooms.
At this point, MECC was making so much money from its software sales that it no longer required government funding. In 1991, the state of Minnesota sold it to venture capitalists for 5.25 million.
Oregon Trail II was released in 1995. The release party marked the first time that Rawitsch, Heinemann, and Dillenberger were acknowledged as the original creators of the game. The final, 1997 version of the game was the last to be released out of Minnesota and the last game to be released by MECC. Soft Key bought the company in 1995 and terminated it as a separate entity four years later.
Oregon Trail was adapted into an iPhone game in 2008, and in 2014, the original version of the game was added to the Internet Archive. In 2016, it was inducted into the Video Game Hall of Fame.
The simulation or emlannts traveline The Oregon Trail is simple enoueh ror young children to operate and enjoy. At the same time, the simulation Is rich enough to support the Interest snd involvement ot older students. It can motivate the tifth erader learnine tor the Clrst time about people moving across the North American continent by covered waion; the seventh gt’ader explorlne the signifleance or the Louisiana Purchase; or the tenth &,rader studyin&, the Westward expansion. It can motivate students ot any age to better understand the present by studying &, the put. Fiction is used in this simulation to establish time. plaee. character. and event. However, the primary intent ot the simulation Is to particularize events and details that will suggest the broader experience or not one, but many overland journeys. Simulations will also sunest the impact that over 300,000 people trekking&, overland by covered wagon to Utah, California, and Oregon had on the development of the westem state!. To enhance this broader experience. the manual Includes perspectives on the simulation and the historical trail; study guides; and a teacher’s guide correlated to student activities. A follow-up session tor teacher and students ties together the simulation and related activities with discussion questions drawn from the learning objectives listed in the manual. Appendices Include a map or the overland trails. a summary ot the model, and a list ot source materials. The Oregon Trail diskette requires an Apple U Plus with S4K, and an Apple lie or lie eomputer. While the prog-ram Is not eolor-dependent in operation. use ot a eolor monitor is suggested tor a ruler appreciation o’ the many on-screen
Chapter 2
1967
Minneapolis-St. Paul schools form TIES, Total Information for Educational Systems, to provide timesharing services to schools. TIES acquires an HP 2000A computer.
1970
Honeywell launches EDINET, Educational Instructional Network. Unlimited timeshare access for $1000/month, although schools had to supply their own teleprinters, modems, and pay for phone calls. The 1970s sees rapid growth of commercial and non-commercial timesharing solutions.
1971
Don Rawitsch, Bill Heinemann, and Paul Dillenberger design and implement the first version of OREGON within two weeks. Developed during off-hours, they use a teletype at a local high school connected to the TIES network. Students prove enthusiastic, but the program is deleted from the computer at the end of the semester to save space.
1973
MECC founded to rationalize computer use and spending within Minnesota schools.
1974
Don Rawitsch joins MECC, bringing a hard-copy of OREGON. Don makes some updates to the design and source code.
1975
MECC releases OREGON on the MECC timesharing network. The game immediately becomes MECC’s most popular timesharing program and stays that way until 1983.
After a competitive bid, MECC works to replace their HP 2000A with a Univac 1110. The transition is rocky as the Univac team misses capacity milestones.
1977
MECC publishes a user guide/teacher’s manual for OREGON. Detailing the game design, historical sources, and advice on integrating the game into a curriculum, the sample run includes the difficulty adjustment of the shooting sub-system seen in the 1978 version.
1978
CDC provides a pair of Cyber 73s to MECC to replace the Univac 1110.
Rawitsch publishes the source code to OREGON in Creative Computing. The source code has been ported to the CDC Cyber 70/73-26 BASIC 3.1 language. The article claims that MECC is serving 1,100 interactive terminals.
MECC purchases five Apple II computers anticipating the market switch from timesharing to personal computers.
1979
MECC issues a competitive bid for educational-use microcomputers. Apple wins. The other bids are either non-compliant or miss the deadline.
MECC places an Apple II port of OREGON on their timesharing network for downloading.
1980
MECC publishes Elementary Volume 6, a collection of five titles including OREGON, on Apple II diskettes. This version of OREGON (same as 1979) adds a graphical map, eliminates scrolling text, and features a limited graphical shooting game.
1983
MECC shutdowns their timesharing network.
1984 October to 1985 July
MECC develops a new version of OREGON from scratch since OREGON has become obsolete. This version becomes The Oregon Trail and MECC’s most popular school and home product.
Background and Developers
In 1971, Don Rawitsch, Bill Heinemann, and Paul Dillenberger are college roommates attending Carleton College in Minnesota. Don is a history major while Bill and Paul are math majors, but all are participating in the Carleton Urban Teaching Program as student teachers (Dillenberger et. al. 1972).
As part of his student teacher training, Don is expected to teach an eighth-grade module on westward expansion in three weeks time. Seeking ways to better engage with the students, Don spends a week designing a board game to simulate a voyage along the Oregon Trail. While playtesting the game with his roommates, Bill suggests making it a computer game. While Bill and Paul have some experience programming, Don does not, and two weeks seems too short a time to write a new program. They decide to risk it.
The three split the work. Don acts as designer and incorporates historical aspects based on his research. Bill provides the majority of the programming and program planning, including allocating line numbers for major sections. Paul writes subroutines and contributes OREGON’s trademark humor as well as testing the program (Wong 2017). (Incidentally, the 1975 OREGON source code only credits Don while the 1978 version credits both Don and Bill.)
Bill’s experience with programming comes from a five-week course at Carleton that he took while a junior. He was evidently successful as he became a lab assistant the next trimester (Wong 2017). (This course was likely MATH 13, an introduction to computer programming. In the 1969/1970 academic year, students ran programs on an IBM 1620 and used Fortran II. In the 1971/1972 year, they switched to using BASIC or FOCARL (sic? FOCAL?) on a time sharing system. (Carleton 1969, pg 70)) Bill later became a professional programmer and held that position for 32 years (Hendricks 2020). Paul had similar training.
Two weeks later, in December 1971, Don introduces the first draft of the program to his students at Jordan Junior High. Since the school has only a single teletype machine, Don separates the class into teams and each team sequentially attempt a journey. Although the program is buggy and many teams “die” during the journey, students are eager to play again. Paul, at Bryant Junior High, permits his math students to play the game after class. It is similarly a hit with students lining up for their turn (Bouchard 2016, 59).
At the end of the semester, Don deletes the program. However, the three keep a hard copy of the source code.
Although they were interviewed after their student teaching and collectively wrote a letter describing their experiences (Dillenberger et. al. 1972), neither source mentions OREGON directly. However, the interview, written by an unnamed staff writer of the student newspaper, may allude to the experiment. Karl Ruge, who was part of the Carleton teaching program and lived with the three, is quoted “The term gimmicks has a bad connotation, but it shouldn’t. Why do so many people flock to the computer lab? Working with those machines is enjoyable, and it leads people to explore things for themselves.” Don followed up with “Maybe ‘variety’ is a better term than ‘gimmick’ for the kind of teaching change we have in mind. By ‘variety’ I mean continuous experimentation in classrooms to discover the most effective way to get things across.” (Staff 1972, 3)
This apparent attitude, and lack of publicity for their work, supports their later claims that the three did not consider the commercialization possibilities of the game. Rather, they saw it as an educational experiment and part of a larger effort to interest students in the material and make the material relevant to the students.
A historical simulation as a computer game was ambitious for 1971, although computer games were in the zeitgeist at Carleton. “Games People Play”, an article in the student newspaper from May that year (Wrede 1971), writes about “demos” as means to encourage interest in computers. Carleton had recently acquired a DEC computer and it included a number of demos or games. The article notes that students and professors have written their own games to supplement those that came with the computer. While a pinball simulator had been banned due to students damaging the joysticks, a snowball fight simulator, sailing simulator, and a Star Trek battle game lived on.
In 1974, Don joined MECC. MECC saw its mission as both providing computing resources by creating their own timesharing network but also as a source of courseware and other software specific to education. MECC was thus eager to expand their catalog with Don’s copy of OREGON. An updated version of OREGON was available on the MECC network by 1975.
Development and Production Environment
Bill Heinemann and Paul Dillenberger used a teleprinter at Bryant Junior High during off-hours to type in the OREGON program. The terminal was connected via phone to the TIES educational network, a timesharing network of local schools connected to a HP 2000 series minicomputer running the 2000A timeshare system. Since access time was limited, they first wrote code on paper.
HP Timesharing BASIC (also called Access BASIC) is an expanded version of Dartmouth BASIC, adding extensions such as a string datatype and computed goto.
The 2000A timeshare system features a private workspace for each user to develop their own BASIC programs. Users can also share their programs with a group or the entire system with various protections in place. Thus, the developers could share OREGON with all students to run, but students would be unable to modify the program (HP 1975, section 8-6). (The system also supports protections such as prohibiting listing of the source code, but it is unclear if these additional controls were used.)
The 2000A limits program names to six characters in length, hence ‘OREGON’.
OREGON: 1975 Version
The source code for the 1975 version of OREGON comes via MECC.Co, a MECC software repository run by volunteers. When Don Rawitsch joined MECC in 1974, he carried a print-out of the 1971 version. Retyping the code from the print-out, Don made some software updates, including updating “hostile Indians” to “hostile riders” (Bouchard 2016, pg 74) and likely updating event probabilities based on further research. Comments in the source code date this version to March 27, 1975.
Physically, the source code is 626 lines long and fewer than 17,900 characters in length. All characters are in upper-case. HP 2000A supported 7-bit ASCII (HP 1975, section 11-3), but many terminals did not support printing lower-case characters (e.g. ASR 33). Each line fits within 72 columns which was a common teletypewriter limit.
A print-out on fan paper is about ten pages long. In Creative Computing, the listing of the 1978 version (686 lines) requires six pages with two columns per page. As a comparison, the three longest programs in 101 BASIC Computer Games (1973), CANAM, SPCWAR, and YAHTZE, have 416, 539, and 558 lines respectively. This is evidence of the team’s ambition and the complexity of their simulation versus contemporary games.
Design and Implementation
The BASIC language of the time is unstructured, but the developers impose some structure by labeling sections of code. The source code features 15 sections delimited by comments (REM statements):
| Section | Length (Lines) |
| Instructions | 43 |
| Initial Purchases | 43 |
| Setting Date | 42 |
| Beginning Each Turn | 54 |
| Stopping at Fort | 25 |
| Hunting | 20 |
| Eating | 14 |
| Riders Attack | 68 |
| Selection of Events | 115 |
| Mountains | 35 |
| Dying | 34 |
| Final Turn | 66 |
| Shooting Sub-routine | 9 |
| Illness Sub-routine | 18 |
| Variable Documentation | 30 |
The program’s front-matter accounts for the remaining lines of code.
A section does not necessarily act as a “procedure entry-point”; while the code often GOTOs to the start of the section, some sections, notably Dying, have multiple entry-points depending on the manner of the avatar’s death.
OREGON is a resource-management game with a minor typing sub-game for shooting. Players manage food, clothing, medicine, miscellaneous supplies, and ammunition resources while attempting to cover 2,040 miles before winter arrives. Each turn, random events may hinder or help their progress. The teacher’s manual (Rawitsch 1977) is surprisingly detailed. It includes the probability distributions for events and graphically denotes the game-play loop. For our purposes, however, we found it useful to build an activity diagram of the game logic, using marked sections in the code as the activities:
Activity Diagram of OREGON
Each game loop iteration represents two weeks, although the game calculates a partial two week period for the final turn. True to the memes of dying along the Oregon Trail, there are many paths to the Dying section. Players may choose to stop at a fort (which allows them to purchase supplies), hunt (which invokes the shooting sub-routine and may provide extra food), or continue (which avoids penalties to their movement speed). Players choose between three levels of eating which controls the consumption of food and adjusts their tolerance to disease. Riders may attack, with a probability based on the current mileage, which invokes the shooting sub-routine. Selection of Events selects a random narrative event, with probabilities based on real traveler diaries. Narrative events often draw down resources. If the player has reached the mountains, mountain events come into play. Mountain events are often fatal. Successfully traveling 2,040 miles displays a congratulatory message.
OREGON Illustrator
To aid in studying OREGON, we built a limited interpreter for HP Timesharing BASIC with debugger-like visibility and controls. Called OREGON Illustrator, you can play OREGON while watching the source code execute in parallel.
Screenshot of OREGON Illustrator
We know of the following limitations/alterations in OREGON Illustrator versus a real HP Timesharing environment:
- Although Illustrator slows down the pace of execution to facilitate understanding of the business logic, the pace does not match the 100 baud limits of a Model 33 nor is there an attempt to match the processing speed limits of a HP 2000 series minicomputer.
- PRINT output is misaligned (column-wise) in some cases.
- We edited lines 405 and 2005 to use an ahistorical MULTSET command to initialize multiple variables rather than implementing the ambiguous = assignment/equality operator.
- We removed “bells” (auditory signals) from lines 1755, 4015, and 4020.
- We’ve made no attempt at matching HP 2000 series floating point arithmetic with JavaScript’s standard floating point arithmetic.
OREGON Illustrator is a Typescript Preact application using tsPeg to generate the BASIC parser.
Use of BASIC Language and Techniques
Of the 626 lines, 33% are PRINT statements (n=210) and 23% are LET statements (n=141, implicit and explicit). Of the 50 comments, 29 are spent documenting the variables and 15 marking section boundaries. None of the comments are used to describe techniques or the game design. However, the prevalence of PRINT statements provides a form of documentation since most of the business logic and state changes are reported to the player.
A breakdown of statements by line count:
| Statement Kind | Count |
| 210 | |
| LET | 141 |
| GOTO / Computed GOTO | 98 |
| IF-THEN | 94 |
| REM | 50 |
| INPUT | 14 |
| GOSUB | 9 |
| RETURN | 2 |
| STOP | 2 |
DATA, DIM, END, ENTER, READ, and RESTORE are each used once.
ENTER is one of HP’s extensions to BASIC. ENTER operates similarly to INPUT, but the programmer can place a deadline on input and ENTER records how long the operator took before hitting enter. In the 1978 version, which did not target the HP Timesharing system, ENTER is replaced by calls to record the system clock before and after an INPUT to measure operator responsiveness.
With the exception of the ENTER statement and the string variables, OREGON could have been ported to the original Dartmouth BASIC. Since the program does not read any files nor call other programs, it places few requirements on the environment. While the game was ambitious, the implementation technique was not.
Observations by Section
Start of Game Loop and Setting Date
Line 700 acts as the start of the game loop. If the mileage has reached 2,040 miles or the turn number has exceeded 17, we jump into the Final Turn. (The turn number check is eliminated in the 1978 version.)
700 IF M >= 2040 OR D3>17 THEN 4000
709 REM ***SETTING DATE***
710 D3=D3+1
715 PRINT
720 PRINT “MONDAY “;
725 IF D3>10 THEN 735
730 GOTO D3 OF 740,750,760,770,780,790,800,810,820,830
735 GOTO D3-10 OF 840,850,860,870,880,890,900
740 PRINT “APRIL 12 “;
744 GOTO 910
750 PRINT “APRIL 26 “;
755 GOTO 910
…
890 PRINT “NOVEMBER 8 “;
895 GOTO 910
900 PRINT “NOVEMBER 22 “;
910 PRINT “1847”
915 PRINT
The developers use a computed goto, using HP BASIC’s unusual GOTO … OF syntax, to display the start of a two week period. Presumably for readability and to stay within the 72 column limit, the switch on the value of D3 is split into two lines.
Hunting and Shooting Subroutine
OREGON’s action scenes were very popular. Shooting is part of hunting, defending from riders, and defending from wild animal attacks. While later versions embellished the shooting subgame with graphics, the original version requires very few lines and straight-forwardly leverages HP’s ENTER statement.
Players are given the option to hunt every turn. This is somewhat ahistorical as the diaries re-printed in Overland in 1846, a source used in the game design, note how difficult it was to find game once they passed the buffalo ranges. Dale Morgan, the editor, explicitly notes that hunting was an unreliable source of food based on multiple accounts (Morgan 1963, pgs 210-211, 406-407). (The documentation for the later Westward Ho! port shows a “hunting yield” curve versus mileage graph, but the code does not use mileage to adjust food gained by hunting.)
If players type ‘BANG’ within the deadline (a random time between zero and seven seconds), they gain some food at the cost of some mileage and bullets. If the players type ‘BANG’ in less than a second, they gain more food and expend fewer bullets. Don noted that students self-organized teams around the fastest typers. The 1978 version varies the word that needs to be typed to increase the challenge.
1699 REM ***HUNTING***
1700 IF B>39 THEN 1715
1705 PRINT “TOUGH—YOU NEED MORE BULLETS TO GO HUNTING”
1710 GOTO 1310
1715 M=M-45
1720 GOSUB 4500
1725 IF B1 <= 1 THEN 1755
1730 IF 100*RND(0)<13*B1 THEN 1780
1735 F=F+48-2*B1
1740 PRINT “NICE SHOT–RIGHT THROUGH THE NECK–FEAST TONIGHT!!”
1745 B=B-10-3*B1
1750 GOTO 1800
1752 REM **BELLS IN LINE 1755**
1755 PRINT “RI”‘7″GHT BETWEE”‘7″N THE EYE”‘7″S—YOU GOT A”‘7″ BIG ONE!!”‘7″!!”
1765 F=F+52+RND(0)*6
1770 B=B-10-RND(0)*4
1775 GOTO 1800
1780 PRINT “SORRY—NO LUCK TODAY”
1800 IF F >= 13 THEN 1900
1805 GOTO 3500
The shooting subroutine reads the player’s input via the ENTER statement. ENTER is an HP variant on INPUT which includes a deadline on input (B2 in the code below), returns the time taken by the user (B1), and records the user’s port number (P). The variable P was previously used to sum all the starting equipment purchases and is now clobbered, but at this point P is a write-only variable.
4499 REM ***SHOOTING SUB-ROUTINE***
4500 PRINT “TYPE BANG”;
4505 B2=7
4510 C$=””
4515 ENTER #P,B2,B1,C$
4520 PRINT
4525 IF C$=”BANG” THEN 4535
4530 B1=7
4535 RETURN
Eating
The Eating section demonstrates the tedious nature of input validation in BASIC. The player is given three options for eating—poorly, moderately, or well. The food level (F) is decremented accordingly. Validation requires comparing the value to a range, twice, each of which can loop, and then converting to an integer. Given how many programs were menu-driven, we are surprised that a higher-level “choice” INPUT statement was not included in the early BASICs. Oddly, the Eating section also updates mileage and clears the blizzard and clothing flags, an example of how sections were not always independent concerns.
The game can soft-lock if the food level is less than 3. If F is 2, then line 1930 will cause F to become -1, even if the player is eating poorly. Line 1940 will undo the food consumption and then the game will loop back to 1900 on line 1950.
1899 REM ***EATING***
1900 PRINT “DO YOU WANT TO EAT (1) POORLY (2) MODERATELY”
1902 PRINT “OR (3) WELL”;
1905 INPUT E
1910 IF E>3 THEN 1900
1915 IF E<1 THEN 1900
1920 LET E=INT(E)
1930 LET F=F-8-5*E
1935 IF F >= 0 THEN 2000
1940 F=F+8+5*E
1945 PRINT “YOU CAN’T EAT THAT WELL”
1950 GOTO 1900
2000 LET M=M+200+(A-220)/5+10*RND(0)
2005 L1=C1=0
Eating levels were also used in the Illness Subroutine where they adjust the probability of severe illness.
The pattern of updating a variable and, if the result is negative, undoing that update with a “negative” version of the computation, is visible several times in the code. This appears to be evidence of the author’s inexperience with code maintainability as this pattern requires duplicating logic across space. The developers could have potentially used user defined functions to centralize the business logic. User defined functions are supported in Access BASIC and CDC’s BASIC 3.1.
Selection of Events
Selection of Events, the longest section in the code base, performs a weighted random choice of a narrative event. Narrative events are drawn from diary entries in (Morgan 1963); specifically, the first three diaries. Methodologically, the first three diary entries are not truly independent of each other and Rawitsch could have incorporated additional diary entries for greater variety (although not all diaries in the book are relevant to the simulation). Quibbles aside, the narratives add flavor to the game and Rawitsch is commendably transparent about his approach and the source of data in the teacher’s manual.
Programmatically, the probability distribution is stored as a DATA array on line 2535. Although the READ (line 2525) is before the DATA line (line 2535), this is not an issue because BASIC interpreters scanned all lines for DATA blocks on start-up. The code generates a random number on line 2510 and then tests the number against the cumulative probability value in the DATA block, one by one. Based on the index, the code then jumps to the specific event via computed gotos (lines 2540 and 2545).
The developers either forgot to document D as a variable or felt it was unnecessary to document as it is only used as temporary storage.
Conceptually, the narrative events could have been stored in a separate file, allowing a “data-driven” means to expand the game. While most events add or subtract resources, there is quite a bit of variety and some events invoke the shooting subroutine. Thus, it would have been difficult to codify the events strictly in data.
2499 REM ***SELECTION OF EVENTS***
2500 LET D1=0
2505 RESTORE
2510 R1=100*RND(TIM(0))
2515 LET D1=D1+1
2520 IF D1=16 THEN 3020
2525 READ D
2530 IF R1>D THEN 2515
2535 DATA 6,11,13,15,17,22,32,35,37,42,44,54,64,69,95
2537 IF D1>10 THEN 2545
2540 GOTO D1 OF 2550,2570,2590,2615,2630,2645,2660,2690,2785,2810
2545 GOTO D1-10 OF 2825,2860,2885,2970,2990,3020
2550 PRINT “WAGON BREAKS DOWN–LOSE TIME AND SUPPLIES FIXING IT”
2555 LET M=M-15-5*RND(0)
2560 LET M1=M1-8
2565 GOTO 3100
2570 PRINT “OX INJURES LEG—SLOWS YOU DOWN REST OF TRIP”
2575 LET M=M-25
2580 LET A=A-20
2585 GOTO 3100
2590 PRINT “BAD LUCK—YOUR DAUGHTER BROKE HER ARM”
2595 PRINT “YOU HAD TO STOP AND USE SUPPLIES TO MAKE A SLING”
2600 M=M-5-4*RND(0)
2605 M1=M1-2-3*RND(0)
2610 GOTO 3100
2615 PRINT “OX WANDERS OFF—SPEND TIME LOOKING FOR IT”
2620 M=M-17
2625 GOTO 3100
2630 PRINT “YOUR SON GETS LOST—SPEND HALF THE DAY LOOKING FOR HIM”
2635 M=M-10
2640 GOTO 3100
2645 PRINT “UNSAFE WATER–LOSE TIME LOOKING FOR CLEAN SPRING”
2650 LET M=M-10*RND(0)-2
2655 GOTO 3100
2660 IF M>950 THEN 2935
2665 PRINT “HEAVY RAINS—TIME AND SUPPLIES LOST”
2670 F=F-10
2672 B=B-500
2675 M1=M1-15
2680 M=M-10*RND(0)-5
2685 GOTO 3100
2690 PRINT “BANDITS ATTACK”
2700 GOSUB 4500
2705 B=B-20*B1
2715 IF B >= 0 THEN 2735
2720 PRINT “YOU RAN OUT OF BULLETS—THEY GET LOTS OF CASH”
2725 T=T/3
2730 GOTO 2740
2735 IF B1 <= 1 THEN 2770
2740 PRINT “YOU GOT SHOT IN THE LEG AND THEY TOOK ONE OF YOUR OXEN”
2745 K8=1
2750 PRINT “BETTER HAVE A DOC LOOK AT YOUR WOUND”
2755 M1=M1-5
2760 A=A-20
2765 GOTO 3100
2770 PRINT “QUICKEST DRAW OUTSIDE OF DODGE CITY!!!”
2775 PRINT “YOU GOT ‘EM!”
2780 GOTO 3100
2785 PRINT “THERE WAS A FIRE IN YOUR WAGON–FOOD AND SUPPLIES DAMAGED”
2790 F=F-40
2792 B=B-400
2795 LET M1=M1-RND(0)*8-3
2800 M=M-15
2805 GOTO 3100
2810 PRINT “LOSE YOUR WAY IN HEAVY FOG—TIME IS LOST”
2815 M=M-10-5*RND(0)
2820 GOTO 3100
2825 PRINT “YOU KILLED A POISONOUS SNAKE AFTER IT BIT YOU”
2830 B=B-10
2835 M1=M1-5
2840 IF M1 >= 0 THEN 2855
2845 PRINT “YOU DIE OF SNAKEBITE SINCE YOU HAVE NO MEDICINE”
2850 GOTO 3600
2855 GOTO 3100
2860 PRINT “WAGON GETS SWAMPED FORDING RIVER–LOSE FOOD AND CLOTHES”
2865 F=F-30
2870 C=C-20
2875 M=M-20-20*RND(0)
2880 GOTO 3100
2885 PRINT “WILD ANIMALS ATTACK!”
2887 GOSUB 4500
2889 IF B>39 THEN 2895
2890 PRINT “YOU WERE TOO LOW ON BULLETS–“
2891 PRINT “THE WOLVES OVERPOWERED YOU”
2892 K8=1
2893 GOTO 3555
2895 IF B1>2 THEN 2910
2900 PRINT “NICE SHOOTIN’ PARDNER—THEY DIDN’T GET MUCH”
2905 GOTO 2915
2910 PRINT “SLOW ON THE DRAW—THEY GOT AT YOUR FOOD AND CLOTHES”
2915 B=B-20*B1
2920 C=C-B1*4
2925 F=F-B1*8
2930 GOTO 3100
2935 PRINT “COLD WEATHER—BRRRRRRR!—YOU “;
2940 IF C>22+4*RND(0) THEN 2955
2945 PRINT “DON’T “;
2950 C1=1
2955 PRINT “HAVE ENOUGH CLOTHING TO KEEP YOU WARM”
2960 IF C1=0 THEN 3100
2965 GOTO 4700
2970 PRINT “HAIL STORM—SUPPLIES DAMAGED”
2975 M=M-5-RND(0)*10
2977 B=B-200
2980 M1=M1-4-RND(0)*3
2985 GOTO 3100
2990 IF E=1 THEN 4700
2995 IF E=3 THEN 3010
3000 IF RND(0)>.25 THEN 4700
3005 GOTO 3100
3010 IF RND(0)<.5 THEN 4700
3015 GOTO 3100
3020 PRINT “HELPFUL INDIANS SHOW YOU WHERE TO FIND MORE FOOD”
3025 F=F+14
3030 GOTO 3100
Dying
You can’t die of dysentery in OREGON 1975. You can, however, die of starvation, pneumonia, or injuries. Historically, many died of cholera or “mountain fever,” but this simulation did not attempt to be exhaustive. Family members and tombstones were introduced in the 1985 version. (The MECC Alumni Timeline claims that a Wisconsin teacher asked at the 1982 conference “Is there a way to delete names and messages entered by students on the onscreen tombstones in The Oregon Trail?”, but this date, and others on the timeline, conflict with other accounts.)
The Dying section has multiple entry points and callers may have jumped to line 3500, 3520, 3550, or 3555. Given how line numbers from 3500 to 3600 increment erratically, we suspect this section was adjusted multiple times to accommodate all the paths to death.
Setting T (cash available) to zero on line 3520 is meaningless because T is no longer used. There may have been some intent to use T as part of a scoring mechanism or possibly as a way to influence the funeral arrangements.
While the game could have used a very simple “you have died” message, the section includes some narrative dark humor and prolongs the end of the game by asking questions about burial preferences. This embellishment was due to Paul Dillenberger (Wong 2017) and we believe it adds significantly to the program’s charm.
3499 REM ***DYING***
3500 PRINT “YOU RAN OUT OF FOOD AND STARVED TO DEATH”
3505 GOTO 3600
3520 LET T=0
3525 PRINT “YOU CAN’T AFFORD A DOCTOR”
3530 GOTO 3555
3550 PRINT “YOU RAN OUT MEDICAL SUPPLIES”
3555 PRINT “YOU DIED OF “;
3560 IF K8=1 THEN 3575
3565 PRINT “PNEUMONIA”
3570 GOTO 3600
3575 PRINT “INJURIES”
3600 PRINT
3602 PRINT “DO TO YOUR UNFORTUNATE SITUATION, THERE ARE A FEW”
3605 PRINT “FORMALITIES WE MUST GO THROUGH”
3610 PRINT
3615 PRINT “WOULD YOU LIKE A MINISTER?”
3620 INPUT C$
3630 PRINT “WOULD YOU LIKE A FANCY FUNERAL?”
3635 INPUT C$
3650 PRINT “WOULD YOU LIKE US TO INFORM YOUR NEXT OF KIN?”
3652 INPUT C$
3654 IF C$=”YES” THEN 3670
3656 PRINT “YOUR AUNT NELLIE IN ST. LOUIS IS ANXIOUS TO HEAR”
3658 PRINT
3670 PRINT “WE THANK YOU FOR THIS INFORMATION AND WE ARE SORRY YOU”
3675 PRINT “DIDN’T MAKE IT TO THE GREAT TERRITORY OF OREGON”
3680 PRINT “BETTER LUCK NEXT TIME”
3685 PRINT
3690 PRINT
3695 PRINT TAB(30);”SINCERELY”
3700 PRINT
3705 PRINT TAB(17);”THE OREGON CITY CHAMBER OF COMMERCE”
3710 STOP