OREGON (Trail): BASIC Game Design from the Teletype Era

2026-01-20

In 1971, three college roommates developed an educational computer game. Titled OREGON, it was a simulation of westward migration along the Oregon Trail and proved to be a hit among the students. One of the designers, Don Rawitsch, later carried a copy of the source code to his new employer, Minnesota Educational Computing Consortium (MECC). From 1975 to 1983, OREGON was MECC’s most popular courseware on their timeshare service. When MECC decided a new version was merited, which became The Oregon Trail, they mandated the design team to “preserve whatever made the original so popular.” With the availability of the source code for the 1975 and 1978 versions, we explore the design and implementation of OREGON and why it was popular and memorable.

Contents

• Timeline
• Background and Developers
• Development and Production Environment
• OREGON: 1975 Version
• OREGON: 1978 / Creative Computing Version
• The Journey to 1985’s The Oregon Trail
• References

Timeline

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):

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:

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.

We know of the following limitations/alterations in OREGON Illustrator versus a real HP Timesharing environment:

1. 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.
2. PRINT output is misaligned (column-wise) in some cases.
3. We edited lines 405 and 2005 to use an ahistorical MULTSET command to initialize multiple variables rather than implementing the ambiguous = assignment/equality operator.
4. We removed “bells” (auditory signals) from lines 1755, 4015, and 4020.
5. 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:

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

Popularity

In the mid-70s, educational software tended to be fairly simple quizzes or drills. Even the contemporary PLATO network, which supported graphics and multiple users, advertised individual “lessons” that tended to be straight-forward exercises or simple physical simulations. In contrast, OREGON is replayable, as narrative events change each playthrough, and the iterative game loop allows students to test different strategies. Furthermore, the game features an actual, developed theme which helps engage the player’s imagination (particularly important given the lack of graphics).

Popular entertainment also contributed to student’s interest. Although the American West was less popular as a setting on television than in the 1960s which featured Wagon Train, Bonanza, and Gunsmoke, Western movies were still a staple in theaters and the pioneer drama Little House on the Prairie started its nine year run in 1974.

The mid-1980s saw large investments into educational games and new franchises were born such as Math Blaster! (1983), Reader Rabbit (1983), and Where in the World is Carmen Sandiego (1985). However, historical simulation/roleplaying educational games appear to be rare. Seven Cities of Gold (1984) is a notable counter-example but was sold as an edutainment title, not educational software. Since OREGON had a teacher’s manual and advice for integrating into a lesson plan, OREGON was solidly positioned as courseware or educational software, even if the home market broadened MECC’s market positioning.

Thus, even up to the 1985 re-design, OREGON filled a niche with few competitors, featured a popular theme, and could be approached as a game rather than a computerized drill.

OREGON: 1978 / Creative Computing Version

Provenance

Using a scan of the May/June issue of Creative Computing (Rawitsch 1978), we extracted a textual version of the source code via Google Gemini. The scan was not high-quality. We then visually checked the extracted source code against the scan and the 1975 version. We found 24 errors in the output. About two-thirds of the errors were character-level—individual characters swapped with similar looking characters or digits. The remaining errors included broad logic changes (e.g. 3120 M=M+20 rather than the correct 3120 GOSUB 4120, 3560 D1=D1+1 versus 3560 RESTORE, and INT(D3) rather than ;D3;). Twenty-four errors out of 686 lines is an error rate of 3.5%. This is a reminder that researchers should be cautious about LLM translations of scanned historical source code.

The source code front-matter states a version of 01/01/78. Since the 1977 user manual has a sample run that includes features seen in the 1978 version, we know that some of the alterations were made prior to this date. Since MECC ran a Univac 1110 for a number of years, we suspect many of the changes were first made on a now-lost Univac BASIC version.

Delta from 1975

We used a parallel reading approach to compare the 1975 to 1978 version. The 1978’s line numbers have been renumbered, so a straight-forward file diff was not an option. The 1978 version targets “CDC CYBER 70/73-26 BASIC 3.1”.

The game design, probability functions, and narrative events are unchanged between 1975 and 1978. The update includes some minor changes:

• Date handling is extended into December
• Spelling corrections
• Swaps HP’s unusual GOTO OF syntax with the more common ON GOTO syntax
• Drops the LIN(2) print function and instead uses two PRINT statements
• Arguments passed to RND function changed to reflect CDC semantics
• Some player messaging (PRINT statements added or dropped)

The most significant change is the shooting sub-routine. At the start of the program, the player is asked how good a shot they are. When a player is asked to shoot, rather than always asking them to type ‘BANG’, they are randomly prompted with ‘BANG’, ‘BLAM’, ‘POW’, or ‘WHAM’. CDC Basic did not include the ENTER statement, so the system clock is checked before and after an INPUT to record user latency. Measured latency is adjusted by the user’s chosen shooting skill, providing an additional challenge to the game. The source code includes a helpful comment describing how the approach may be tailored depending on the computing environment.

Why was this published?

Commercially, it seems odd that MECC would allow its most popular program to be shared via a magazine article. At this point in history, though, MECC was not a commercial organization, but rather a quasi-public consortium. MECC was expected to provide public goods and this was an inexpensive way to share one of their successes.

Furthermore, MECC’s revenue was based on a subscription model paid by their client schools. While a competitor could add OREGON to their own timesharing network, the marginal value of a single program was unlikely to woo subscribers away. Client schools saw MECC as both a “production” system as MECC provided space and language interpreters for students and staff to develop new programs, as well as a “consumption” system with existing courseware.

Westward Ho!

Independent of MECC, David Ahl remade the 1978 version of OREGON as “Westward Ho!”, one of ten simulation games published in his 1986’s book BASIC Computer Adventures. Ahl updated the program code to Microsoft BASIC syntax and redesigned some of the logic, shortening the code. (HP Timesharing BASIC did not allow compound statements.) However, the majority of the game is the same, including the narrative events and their probabilities. The existence of ten simulation games, many with historical context, is a counter-example to the claim of OREGON’s uniqueness. However, these games were not commercially competitive.

Later re-released in a 25th anniversary edition and ported to Small BASIC, these type-in books served as intermediate training books in programming. The text explains the game design and program design and, through this form, many programmers may have had their craft improve by studying the implementation. Without sales data, however, we have a difficult time estimating the impact.

The Journey to 1985’s The Oregon Trail

By the late 1970s, a Minnesota school might have had a small number of teletypes, enough for classes to form teams. However, students and schools both desired each student to have their own computer interface. MECC saw that microcomputers would replace terminals in the near future and re-aligned the company to that vision.

In 1978, MECC purchased five Apple II computers for experimenting with the new platform (LaFrenz 1995, pg 26). Anticipating large purchases, they issued an RFP to the prominent microcomputer manufacturers of the day, including Apple, Radio Shack, Atari, and Commodore. Apparently seeing the market as too small, Radio Shack replied with a non-compliant bid for the TRS-80 and refused to correct it. As MECC is subject to government acquisition law, they rejected the bid. Atari and Commodore failed to respond by the deadline. Apple submitted a compliant bid within the deadline, so they won. MECC focused on creating software for the Apple II. (ibid, pg 27)

In 1979, MECC finishes porting OREGON to the Apple II and uploads a copy to their timeshare network. In 1980, OREGON is one of five titles included on Elementary Volume 6. The game has been updated with a graphical map, the scrolling text is now fixed text on a screen, and the shooting game features some animation. MECC is mixing the Apple II’s support for graphic and text modes, but they aren’t yet taking full advantage of the machine’s capabilities (Bouchard 2016, pg 78).

In 1983, MECC shuts down their timesharing network. OREGON continues to live on via the Apple II port.

With increasing competition, MECC decides to refresh the game from scratch rather than incrementally improving the shooting subgame yet again. In 1984, a new development team, with Philip Bouchard acting as the designer, implement a new game, The Oregon Trail. We recommend reading Bouchard’s book You Have Died of Dysentery for a thorough discussion of that game’s design, implementation, and business history.

References

(Bouchard 2016) Bouchard, R. Philip. 2016. You Have Died of Dysentery: The Creation of The Oregon Trail – the Iconic Educational Game of the 1980s. http://www.amazon.com/dp/B01B8JMKMC.

(Carleton 1969) “Carleton College Academic Catalog 1969-1970.” 1969. July. https://contentdm.carleton.edu/digital/collection/ACAT/id/59245/rec/21.

(Dillenberger et. al. 1972) Dillenberger, Paul, Ken Ruge, Bill Heinemann, and Don Rawitsch. 1972. “City Teaching vs Mother Carleton.” Letters. The ’Tonian, January 20. https://archive.carleton.edu/Detail/collections/146482

(Hendricks 2020) Hendricks, Kevin D. 2020. “Bill Heinemann: Oregon Trail, Creativity, & Chess.” Interviews. West St. Paul Reader, December 14. https://weststpaulreader.com/2020/12/14/bill-heinemann-oregon-trail/.

(HP 1975) HP 2000/Access BASIC Reference Manual. 1975. Hewlett-Packard Company. https://bitsavers.org/pdf/hp/2000TSB/22687-90001_AccessBasic9-75.pdf.

(LaFrenz 1995) LaFrenz, Dale. 1995. “An Interview with DALE LAFRENZ.” April 13. https://hdl.handle.net/11299/107423.

(Morgan 1963) Morgan, Dale. 1963. Overland in 1846: Diaries and Letters of the California-Oregon Trail. Vol. 1. University of Nebraska Press.

(Rawitsch 1977) Rawitsch, Don. 1977. Oregon: User Manual to Accompany Programs in Timeshare Library. MECC (Minnesota Educational Computing Consortium). https://mecc.co/software/timeshare/oregontrail_manual_timeshar.pdf.

(Rawitsch 1978) Rawitsch, Don. 1978. “Oregon Trail (1978).” Creative Computing, June. https://archive.org/details/creativecomputing-1978-05/page/132

(Staff 1972) Staff. 1972. “Carls’ Teaching Experiences Verify Irony.” The ’Tonian, January 13. Volume 91, Number 8 Edition. https://archive.carleton.edu/Detail/collections/146481

(Wong 2017) Wong, Kevin. 2017. “The Forgotten History of ‘The Oregon Trail,’ As Told By Its Creators.” Vice, February 15. https://www.vice.com/en/article/the-forgotten-history-of-the-oregon-trail-as-told-by-its-creators/.

(Wrede 1971) Wrede, Jim. 1971. “Games People Play.” The ’Tonian, May 20. Vol 90, Number 18 Edition. https://archive.carleton.edu/Detail/collections/146471