Advent of Computing - Episode 39 - Learning Along the Oregon Trail

Episode Date: September 20, 2020

We've all played the Oregon Trail, but what do you know about it's origins? First developed as a mainframe program all the way back in 1971, the Oregon Trail was intended as an educational game first and foremost. In fact, it traces its linage to some of the first efforts to get computers into the classroom. Today we are following the trail back to it's source and seeing how the proper environment was built to create this classic game. You can play the 1975 version here: https://archive.org/details/OregonTrailMainframe  Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and stickers: https://www.patreon.com/adventofcomputing

You'd be hard-pressed to find someone who hasn't played The Oregon Trail, or at least heard of the game. It's a cherished classic, and it has been for decades. So much so that it's seeped into some pretty strange places. You can go out and buy a handheld version of the game. You can get card games that are based off the computerized classic. You can even get shirts that are emblazoned with You Have Dysentery. It's really easy to forget that the Oregon Trail wasn't developed for strictly entertainment purposes. It was meant as an educational tool. And that's a

testament to how good the game really is. You can very easily slip into the game to have some fun, and before you know it, boom, you've been tricked into learning all about the Wild West. Games like the Oregon Trail are often called edutainment, since they present educational material in a more entertaining form. There are a lot of examples, and even some earlier attempts. But the Oregon Trail has been the most successful and most well-loved of these titles by far. Just like any game, the Oregon Trail didn't come out fully formed. Most people are probably familiar with the Apple II version from 1985. It's what a lot of later iterations are based off of.

But that's not actually the original game. The Oregon Trail wasn't built for home computers at all. It was first conceived of as a mainframe game, all the way back in 1971. Only after years of use did the game make the jump into the home market. As such, the Oregon Trail doesn't trace its lineage back to early video games, or even early computer games. You see, it comes from an entirely different tradition. In fact, the Oregon Trail was the result of early attempts to bring computers into classrooms. In that sense, it's much more built for education than entertainment.

But how did it manage to become such a great game? And why is it still remembered so fondly, even though it's just a school lesson in slightly different clothes? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 39, Teaching Along the Oregon Trail. But before we get into it, I have a little bit of show news to share. Last episode ended up being a pretty deep dive into the technical side of programming languages. Now, if you enjoyed that discussion, then I have a suggestion for you. I just finished a Patreon-exclusive mini-episode that serves as a companion to my Jovial episode.

This one covers MIL-STD-1758. It's a bit of a mouthful, but it's an interesting Air Force-designed processor spec, and it was often used to run jovial code. So why not head over to Patreon, sign up and support the show, and grab a little bit of bonus content? I'm planning to release more companion episodes over on Patreon in the future, so now's a great time to get in on the ground floor. So getting back to the topic at hand, after more technical episodes, I like to switch things up. And what better palate cleanser than video games? Or, in this case, a little more accurately, computer games. I'm sure we all have fond memories of trekking down the Oregon Trail, either in a classroom or later in life.

In recent years, the game has become both highly successful and highly accessible. Part of that is due to nostalgia, but the Oregon Trail is also just a fun game. So where did the game come from and how did it end up in classrooms? It turns out that that takes us down a much older trail, pun very much intended. Oregon Trail sprang out of a long-fought process of getting computers into classrooms. Very early on, it was realized that computers and education could fit really well together. There are a number of factors that make this a really winning combination. First, you need some way to train up future computer scientists. Ideally, you should try to get them while they're young,

since children tend to have a higher capacity for learning than jaded PhD students. And secondly, if used properly, computers could be a fantastic tool for automating education. But making these plans a reality would take a whole lot of time and effort. The Oregon Trail was just one of myriad examples where things worked out really well. There were a lot of prior struggles that made games like this possible. So today, we're going to be looking at how computers made their way into education. Specifically, tracing back how the perfect environment was formed to create Oregon Trail. Along our route, we'll find out how the game actually came to be,

why it worked so well, and how it eventually made its way outside the classroom. Computers and education go way back, or rather, attempts at using computers in education go way back. In the early era of computing, no one would have dreamed about bringing kids near a machine. That may have seemed a lot closer to a nightmare. bringing kids near a machine. That may have seemed a lot closer to a nightmare. Early computers were expensive, delicate, and unique scientific tools. In a lot of cases, programmers and researchers who used them weren't even allowed in the same room as the sacred hardware. But as more computers were built and cheaper hardware became possible, people started to look for more applications for this wonder technology. Like I mentioned at the top, there were two big reasons to get computers into school curriculums. The first was a lot more practical. Computers were the future, plain and

simple. So it would be really good if children could learn about computers as early as possible. We can see that prediction coming true today. You can't really make it in the wide world without some level of competency with a computer. And increasingly, more and more jobs rely very heavily on computers. But in these early days, it was also important to try and raise the next generation of scientists and programmers that would push the field forward. If taught the basics early on, or even better if you could teach a kid how to program, this new generation would grow up to be more prepared than previous ones. So teaching something about computers in schools was in the best interest of both students and the field of computing as a whole. The other side of the

equation was using computers as teaching aids. During the first half of the 20th century, scrutiny was being placed on teaching practices in general. Teachers, psychologists, and other researchers were trying to figure out the best way to teach children. But that led to a little bit of an uncomfortable realization. It turns out that the traditional classroom isn't a very good teaching environment. One of the more cited theories to come out of this period was operant conditioning, first proposed by B.F. Skinner. His research started with animal behavior tests and later moved on to live humans. Skinner's core findings were that positive reinforcement was essential in teaching,

and that reinforcement needed to be given immediately to have the desired effect. In a one-on-one setting where a single teacher can sit down with a single student, this approach works very well. But in a classroom, it falls apart. The more students you have, the further you stray from the ideal scenario. The ultimate solution would be to find a way to improve the ratio of teachers to students, to get as close to that one-on-one teaching as you can. But that's not very feasible, and since population tends to increase from generation to generation, well, that would just never become possible. It would take a radical shift to break out of this

problem, and that shift would come with the introduction of computers, and more specifically, timesharing systems. Way back in the archive, I did a two-part series on the PLATO system, developed by Don Bitzer at the University of Illinois. This was one of the earliest attempts at computerizing education, and it gives a really good outline of how the problem was tackled. Plato was a network of terminals connected up to a single central computer, and from each terminal a series of electronic lessons could be accessed. The key feature here is that Plato shared a single computer among many students, and was done in such a way that each student could

work through lessons simultaneously. This method is called timesharing. By letting the computer switch between a series of tasks really quickly, you can handle parallel tasks. To each user, it looks like they're connected up to their very own computer, but behind the scenes, some very complicated programming is running very quickly to try to keep the illusion alive. The Play-Doh project started in 1960, when timesharing was still very state-of-the-art technology. Timesharing would warp and twist into the powerful multitasking and multi-user systems that we have today.

But for Play-Doh, it was really just a means to an end. That end was, of course, teaching. Computers are really good at teaching because, if properly programmed at least, a student can get instant feedback. Plato really leveraged this detail by providing lessons that combined digital quizzes with actual information. with actual information. This way, you could sit down at a terminal, work through an interactive lesson at your own pace, and answer questions strewn throughout and immediately be told if you got the question right. You got feedback immediately from prior stimuli.

And thanks to timesharing, the cost for the system could be minimized, since you only actually need one computer, and each terminal is a whole lot cheaper than a mainframe. It was a very well-designed solution, but it wasn't the only one. To get a glimpse of the origins of the Oregon Trail, we need to go a few years forward and take a look at the birth of the system that it was developed on. And to do that, we need to go to Minneapolis. In the 1960s, some were calling it the Silicon Valley of the Midwest. Major manufacturers like Univac, CDC, and even IBM had offices either downtown or very nearby. It made the city a hotbed for new technology. For most, that meant business opportunity. But for certain people, it created a perfect environment to push the boundaries of education.

people, it created a perfect environment to push the boundaries of education. Dale LaFrenz was one of the latter. In 1963, LaFrenz was working as a teacher at the University of Minnesota's Laboratory School. Now, this is a type of school that most of us are probably unfamiliar with. A lab school is basically an experimental classroom, usually used by a university to test out new models of teaching. Just like how a chemistry department needs a chemistry lab, a teaching department needs a teaching lab. In the 60s, LaFrenz had enrolled at the University of Minnesota's mathematical department. He had planned to get a master's in the field, but pretty soon his focus shifted to teaching math, and he found his way over to

the campus's lab school. This was a great time to be in the field, especially in Minnesota. Math and science education were being heavily funded at the national level, and with all the tech giants in town, it was only a matter of time before computers entered the curriculum. LaFrenz and his colleagues were more than eager to take up the new challenge. As he recalled years later, quote, Five others in the mathematics department were convinced that the computer was going to be an integral part of education.

In 1963, we decided that every kid needed to have computer access. We began looking around for a way to provide access. End quote. And that's where things get tricky almost immediately. In the 60s, there was no such thing as a microcomputer. You couldn't just plop a few machines in a classroom and call it a day. Computers were still expensive and highly specialized machines. They had to live in some far-off safe place. specialized machines, they had to live in some far-off safe place. Sure, grant money for teaching the sciences was really easy to come by, but it wasn't computer-level money. But a core group of teachers and student teachers at the lab school had been bit pretty bad by the computer bug.

They had to find some way to get their students access to computers. When we break it down, there were really two major problems that LaFrenz and his colleagues faced. The availability of computers was the biggest, but there was another. No one had really figured out how to teach students about computers. For just some context, the first computer science program started in 1953 at Cambridge, and the first full department was established at Purdue in 1962. The idea of teaching computing at all was barely a decade old, so there wasn't some off-the-shelf curriculum that LeFrenz could grab. So the team at U of M would have to cut a pretty new path while also finding a way to get access to computer time.

This led to some pretty strange attempts. Luckily, nearby companies were eager to lend a hand, with CDC being one of the first that LaFrenz would get in contact with. From there, he worked with Robert Smith, a CDC engineer, to try to create lesson plans. The goal was to teach kids to program, but how they went about it was less than ideal. The friends described Doc Smith's system like this, quote, He had a box of punched cards that we used with the kids in the school.

The kids put together computer programs by picking cards out of a box, and they put their programs together with Doc's pre-punched cards. They wrote their data on a piece of paper and wrapped the paper around the cards, put a rubber band on the stack, and then we'd mail it out to Doc Smith in Bloomington. He would get the deck processed, get the key punching done, put the program together, and then he would mail back the results in a week. End quote. I mean, that's certainly a way to get kids programming. The problems here are pretty evident. The whole point in using computers for teaching was that they offered instant feedback. A weak turnaround time defeats the purpose of using a

computer completely. At that point, you could have just had a teacher grade the programs by hand. At that point, you could have just had a teacher grade the programs by hand. But what makes this worse is an unintended consequence. By introducing students to programming, you also introduce them to debugging. LaFrenz estimated that 70% of programs shipped out to DocSmith just didn't work. That's 70% of the class that needs to learn how to debug code on punched cards. And with a weak turnaround time, that's going to take a whole lot of time in class. But there are a few good things here.

While access was really, really slow, the arrangement with CDC did show that companies were willing to work with the lab school. With some finagling, LaFrenz could probably get a better arrangement worked out. Another positive from this attempt was how students actually constructed programs. The idea of mixing and matching pre-punched cards is a really good one. It teaches students the underlying concepts behind programming without exposing them to all the nasty details. At this point, the bad was still outweighing the good, but LaFrenz was going in the exact right direction. The last push needed came from Bob Albrecht, another one of the lab school crew.

While he was currently earning a teaching degree, he had spent some time working at CDC, so he was probably a little more familiar with the computing scene than his colleagues at the lab. He suggested that they take a new approach, one that would bear fruit. As the 60s wore on, timesharing was becoming more advanced and a lot more common on mainframes. So much so that many companies were now offering leased accounts. This allowed anyone with a terminal to connect up to a computer for a small fee.

At the same time, a new language called BASIC was starting to gain popularity. Now, these two technologies are ostensibly unrelated. Timesharing is a very serious and complicated technology. It's used to get the most out of multi-million dollar hardware. And BASIC, well, that's a programming language that's designed to teach the basics of programming. You'd think that never the twain should meet, but stranger things have happened. And it turns out that when the world of computing is dominated by profoundly serious multi-million dollar machines, you wind up with a lot of surprises

tucked away. In the late 60s, Albrecht caught wind of a new project that could solve all of the lab school's issues. That project was called Timeshared Basic. The language was originally developed at Dartmouth as an application for their in-house timesharing system. So, with an account on one of the university's computers, you could log in and program away with relative ease. This was a perfect fit that solved both of the issues faced by the lab school. It would be substantially cheaper than buying a computer for the school, since in most time-shared systems you only need to rent computer time, and BASIC would give students a responsive environment that they could program in pretty easily.

The new language was designed specifically as an entry point for people who didn't know how to program, so designing a curriculum around the language for school-aged children would be relatively simple. At the very least, it would be easier than trying to program via punched cards and mail. When Albrecht brought this possibility up to the U of M team, it was very well received. And this is where the community stepped back in to make everything possible. LaFrenz got in touch with Dartmouth, and he found out that the university would give them free computer time if the lab school could deal with the phone line side of things. At the time, all computerized communications were still being handled over long-distance phone calls.

So to log into a remote computer, you still had to pay the same rates as a long-distance call. The lab school was able to get a grant from the GE Foundation to cover the cost of all those hours of calls, plus a classroom full of teletype terminals. LaFrenz and his co-conspirators were some of the first people to try and get computers into classrooms, and it turns out that everyone involved wanted it to succeed. Computer companies, universities, even the National Science Foundation were all willing to help. And the wild thing is that now armed with timeshared BASIC, everything else fell into place. A modest computer lab was set up at the laboratory school, probably the first computer lab outside of a university. From there, 25 students could connect

up to Dartmouth's mainframe and load up BASIC. It worked great for teaching students to program. Results were immediate, and the language was easy to use. But there was more to this than just teaching about computers. LaFrenz also developed computerized lessons, writing his own basic programs to help teach math to his class. In 1965, he, quite literally, wrote the book on teaching with computers when he published Camp. Computer-Assisted Mathematics Programming is a textbook that laid out how to replicate the lab school's curriculum. And with the programming working so well, other local companies stepped in to help. Notably, Pillsbury, yes, the food-based Pillsbury, started offering spare computer time to the lab.

The friends, Albrecht, and the rest of the U of M crew were building a new teaching environment, and building up a community that was able to support it. Getting computers into the hands of students was a big step towards reshaping education, but they couldn't have predicted exactly where it would go from there. In 1971, Don Rawitsch was just finishing up his teaching degree at Carleton College. With most of his classes done, all that was left was up his teaching degree at Carleton College. With most of his classes done, all that was left was the student teaching. After a year of gaining some practical in-classroom experience, he would graduate as a fully-fledged teacher. Raurich and two of his fellow students, Bill Heinemann and Paul Dillenberger, would be spending that year in Minneapolis teaching at a

local school. So the three moved into the city, rented an apartment together, and settled in for the coming year. Don was slated to teach U.S. history, but he didn't want to go about it the usual way. Raurich didn't really like the standard style of teaching. He wanted to make something more engaging for students. One of the ways that he tried to get students more interested was by using games. The idea was that by hiding a lesson in something fun, his classroom would get tricked

into learning, dressing up an otherwise dull subject. In early 71, he got his first chance to attempt his style of teaching when it came time to teach a unit on the American Revolution. As Don describes, quote, I actually created a little game to try to simulate the British collection of taxes from the colonies. That included the tax information, but also included a number of, uh, under-the-table activities. There were random events that could influence things. End quote. Honestly, taxation and underground markets aren't the most interesting

topic. It's not just dull. For school-age kids, it's not relatable. How does a 12-year-old think about having to pay taxes? By turning it into a game, Rawitsch was finding a way to get his students invested in something that they normally wouldn't care or even know about. Games are fun, and a kid's a lot more likely to care about Monopoly money than marginal tax rates. It's a lot easier to understand something if you can be part of it, and a board game provides a great environment to experience something that would be otherwise inaccessible, and the tax game seemed to be able to do just that. It went over well enough with the students that Rawitsch was eager to try his approach again, so when it came time to work up

a new unit for his class, Don knew just what he wanted to do. His next unit was going to cover the westward expansion of the US. Now, timing for classes worked out so that Rawitsch had about three weeks of prep time before the unit actually started. After about a week of prep work, he decided to repeat his taxation board game. But instead of tackling sales, this new game would let students travel down the Oregon Trail. Don set to work putting together his new game. Working on his apartment floor, he laid out a big sheet of butcher paper and started drawing out a map of the winding path. Pretty soon, his two roommates, Heinemann and Dillenberger, arrived home to this unfolding mess. Don explained that he was working on a game, and from there,

the Oregon Trail that we know would start to take shape. Both Heinemann and Dillenberger had a passing familiarity with programming. Carleton College offered one class on the topic, but that was enough to garner interest in the field. So when Rawitsch explained his new and complicated board game, the two roommates knew that it would be much better suited to a computer. The first incarnation of the Oregon Trail hasn't survived, but from the descriptions given by the three roommates, we can get a feel for why the transition to a program made sense. Students would play on a large map of the trail. Each turn, they would roll dice to determine how far forward their cart advanced. From there, a random event card would be pulled that could affect gameplay. Each card represented some event or misfortune that real

settlers would have faced on their path to Oregon. It's not entirely clear, but the idea of resource management was probably already somewhere in Rawitsch's draft. Now, just from that rough outline, we should already be able to see a few pain points that could be easily spirited away with the work of some crafty programming. Randomness played a big element in Don's draft of the game, both by rolling dice and drawing cards. Depending on the outcome of those random events, gameplay would change, and students would be exposed to new material. It's downright trivial for a computer to generate random events and respond accordingly and accurately.

I'm not saying that rolling dice is hard, but by offloading that type of work to a computer, well a student can just spend more time actually playing the game. It makes it easier to engage with the material instead of the mechanics. Another big advantage is that the game can be made much more complicated and, by the same token, much more realistic. If a computer is handling all of the game's random events and mechanics, then you can easily add in more stuff to do. This way, you can add something like food rationing without needing to do pen and paper math every turn. If you're a little careful with how you design things, you can give the game a lot more

depth without making it needlessly complicated for the player. I know as a kid I wouldn't really care if my rations column on my spreadsheet was dangerously low, but seeing a message shouting about my food supplies running out on a computer, well, that'd feel a lot more real to me. The idea of hiding key information also made a computer program a compelling medium. The historic Oregon Trail was long, winding, and complicated. So too was the game world, at least as much as it could be. If you were sitting down at a board with a full map, then there's no sense of discovery. Everything's already laid out for you.

Random events fill a similar role. Each game, more new events occur and are discovered by the player. So the more a student plays, the more they discover about the historical underpinnings of the game world. They aren't just looking at a board with some dice. They're experiencing the Oregon Trail. It just happens to be through a keyboard and teletype. The last big factor didn't come from the game, but rather the environment that Don, Bill, and Paul were working in. By 1971, the Minneapolis School District was a lot more heavily invested in computing. The lab school teachers at the University of Minnesota had started that process,

but over the years, it had become a much larger project. In 1968, 20 school districts in the region came together to form TISE, Total Information for Educational Systems. This organization was founded specifically to pool resources and get more computerized classrooms up and running. By 71, TISE had purchased an HP mainframe to run timeshared BASIC, By 71, TICE had purchased an HP mainframe to run timeshared BASIC, outfitted area schools with teletype terminals, and was already offering computer training to teachers. That's not to say that computers were now common in these schools,

but there was at least some access and willingness to expand. These factors combined meant that the team of roommates had a great idea for a game, and an actually great way to accomplish it. But there were still going to be issues. One of the largest problems came down to time. Don only had two weeks before his unit on westward expansion began, and the team still had their teaching duties. There would only be two weeks worth of free time to get the game up and running. And while their school did have access to the TIE's mainframe, they only had one teletype terminal. Actual programming would have to be done at the school when no one else was using the terminal. These aren't ideal working

conditions, but it was what they had to work with. Over the next two weeks, Oregon Trail came together at a blistering pace. Rawitsch laid out the basic design for the map, what events students would run into, and rough ideas of mechanics. Essentially, what he wanted his students to learn about, just tucked away in a game form. Heinemann and Dillenberger handled most of the programming. Since there was only one terminal to work on, the two wrote a lot of the code by hand on stacks of paper. Then, they'd type the code into a computer while at school. At one point, they even lugged the terminal home on the weekend so they could get a little bit of last-minute work in.

It was an arduous process, but after two weeks, the new game was ready to play. The first version of Oregon Trail is recognizable, but it's not the same as later iterations. Moving from pen and paper onto a computer gave the team a lot more flexibility and opened up a lot of possibilities. However, Oregon Trail's design was shaped and greatly influenced by the new medium. The entire game had to be played using a teletype terminal. In 71, that was the only way to really connect up to a computer. These types of terminals printed everything out on a scroll of paper, so graphics were an impossibility. The entire game used a text interface. Students typed in commands and received feedback from the computer all one line at a time. But through these lines

of text, students were transported back in time. The overall goal of the game is simple. In the words of the 1971 program itself, quote, this program simulates a trip over the Oregon Trail from Independence, Missouri to Oregon City, Oregon in 1847. Your family of five will cover the 2,000-mile Oregon Trail in five to six months. If you make it alive. Now, that last part is perhaps the most important. The historic Oregon Trail was treacherous. So too is its 1971 reimagining. The core of the game is really about surviving,

and managing resources plays a big role in that. To make it to the coast, you need oxen to drive your wagon, food supplies, clothes to keep you safe from the elements, ammunition for hunting and protection, and... miscellaneous supplies for everything else. That everything ranges from wagon repairs to medicine. At the start of each game, you get $900 to spend on these five key resources, some of which you can replenish as you travel and others you can't.

What happens next is largely dependent on your starting resources. The game plays out in a series of turns. Each turn, the student gets an update on their stock of supplies, and they can decide how much food to consume in that turn. The more food you eat, the faster you can travel. But food is a limited resource. You can replenish your stock of food by hunting or trading for more at forts. But if you run out, you lose the game. The same is true for some other items. If you run out of ammo, you can't hunt for food or protect your party from bandits. If you run out of clothes,

you can't survive the colder sections of the trail, and so on. What makes things complicated are the random events that get thrown in. Heinemann calls these misfortunes, and I think that's a pretty good name. Each turn, one of these events occur. They can range from a bandit attack, to illness, to supplies getting damaged. All of these events are examples of what could actually happen to a real pioneer on the trail, but in the game world, they add a more virtual element of danger. You don't know if you're suddenly going to lose food rations or if you need to stop traveling to rest and recover.

This makes managing your supplies all the more important. A student has to keep misfortunes in mind or else be faced with disaster. What isn't readily apparent is that the system of randomness actually isn't totally random. Heinemann implemented a waiting system that makes some incidents more likely to occur on certain parts of the trail. For instance, a snowstorm can only really occur in mountain passes, while bandit attacks are a lot more likely in the plains regions. It adds a tinge of realism, but also rewards students for paying attention over multiple games. If you know when a blizzard may strike, then you can plan accordingly. The entire resource management system is only possible because Oregon Trail is running on a computer. It's a perfect example of how the medium shaped the game. If you had to play Oregon Trail with pen and paper, then you basically need to work out spreadsheets to keep track of everything. Each turn, a student would be forced to roll some dice,

consult a random encounter table, and do some math according to spent resources. It quickly turns into something a lot more like Dungeons and Dragons than a classroom game. But by using a computer, everything is easily automated away. A student just moves on to the next turn and everything else is handled behind the scenes. Another more direct example of how this new medium shaped Oregon Trail is the hunting minigame. In later versions, hunting would be a more graphical affair, but that can't be done on a paper feed. Everything had to be done by typing. In the version of BASIC that was being used, the input command grabbed characters from a terminal, but it had another output. Every time

you got a new line of text back from the terminal, BASIC also reported how long that line took to be typed out. That simple feature gave Heinemann an idea. Quote, I thought, aha, this is perfect for hunting. I'll tell the student to type bang. If the students spell it wrong or took too long, they got nothing. The faster they typed, the more meat they got and the more positive comment they received. The same sort of thing was used when bandits or wild animals attacked too. End quote. It's a simple little feature, but it adds an element of skill and a little urgency to the game. You can't just say, I go hunting, you have to engage with the process a little bit more. And in the case of bandit or wild animal attacks, this tiny

feature can lead to some frightening fun. You have to be ready to read and type quickly, or your trip to Oregon could be over. It's simple, but hammering out B-A-N-G makes the trek feel a little bit more dangerous. Combine that with the slow and methodical resource management part of the game, and you get a pretty well-rounded package. Getting ready for this episode, I've put a good amount of time into the 71 version of the game, and it still really holds up. Getting from Missouri to the coast feels like a real accomplishment, and every time I fail along the way, it makes me want to try again. Now, that's all well and good, but how did the game actually fare in the classroom? Rawich and his co-conspirators were able to how did the game actually fare in the classroom? Rawitsch and his co-conspirators were

able to test out the game on some students before the actual lessons on westward expansion started. Initial signs were good, kids seemed to really like the game, and the team was able to make some last-minute tweaks and fixes to get things working smooth. When it came time, Rawitsch broke his class up into two groups. One was taught a traditional lesson, using textbooks and worksheets to learn about the Wild West. The second group got to sit in front of the school's single teletype and explore the Oregon Trail firsthand. Each day, the two groups switched off, so everyone got a chance to play around with the computerized trail. The game was a huge success. Students really enjoyed playing it. Rawitsch told it this way in a later interview, quote, During those first few days, I saw a lot of

interesting stuff happen. Each group found the best typist and sat him or her in front of the teletype. Another group member followed the progress by map. Another group member watched the budget report to make sure the group wasn't running low on supplies. That division of labor was something the students came up with on their own. End quote. Don's students were fascinated by the game, and even went as far as forming ad hoc teams to make the trek to the coast possible. For most, it was their first introduction to computers, so Oregon Trail served as a wonderful dual purpose. It helped students better understand American history, while also giving them a very gentle introduction to the world of computing. As far as the three student teachers were concerned, Oregon Trail was a

massive success. After his unit was over, Rawitsch left the game on the TIE's mainframe, and a few other teachers even used it in lessons. But if we zoom out for a minute, this brings us to kind of a strange question. Was Oregon Trail actually the first text-based adventure game? Now, according to mainstream consensus, the first text-based adventure game was Colossal Cave Adventure. I mean, it's even right there in the title. Adventure was written in 1976 and quickly spread over the ARPANET, becoming a favorite game for computer users of the time. In the game, a player traverses a maze-like cavern,

solves puzzles, defeats monsters, and collects treasure. The eventual goal is to find all the treasures of the cave and return them safely to the surface. Most importantly, everything takes place in a virtual world controlled over a teletype terminal. The 1971 version of Oregon Trail has pretty analogous features. You travel through a virtual world, survive combat encounters, and eventually you can win the game. You can even say that resources like food and clothes take the place of the Colossal Cave's treasures. The overall formula and presentation is markedly similar, despite the themes of the game differing. The major

difference is really the input. In Colossal Cave, you can type in sentences and commands, whereas on Oregon Trail, it's more menus, numbers, and short sentences. But despite that, it's pretty plain to see that Oregon Trail can be classified in the same broad realm as Colossal Cave Adventure. But here's where things get tricky. Oregon Trail is the older game, but wouldn't be seen outside of a handful of schools until much later. So while the game hit upon the text-based adventure idea a little bit before others, it didn't have the same reach as later games in the genre.

That being said, Oregon Trail did escape the lab school. It would just take a little bit of time. Once the school year was out, Rawitch and his companions left their student teaching positions. They soon graduated and became just normal teachers. But on the way, the trio made a fateful decision. They'd be bringing the Oregon Trail with them. Before the game was wiped from the TIE's mainframe,

they each printed off a copy of the source code that they took to calling the Sacred Scrolls. From there, the team parted ways, each moving on with their careers. The Scrolls remained untouched for a number of years, waiting to be called upon. By 1974, Don Rowich had a new job at MECC, the Minnesota Educational Computing Consortium. MECC was very similar to TIES. The consortium was established in 1973 by the Minnesota legislature to provide software and computer access to schools within the state. Schools could connect up to the central server and run educational software. MECC handled administrating their mainframe and getting teletypes and phone lines set up in schools, but they also created their own educational software. The consortium wasn't

exactly full of programmers, but many of its employees knew how to code on the side. That's where Don Rawish came into the picture. MECC was always looking for new software, and Don decided that Oregon Trail would fit the bill to a T. The Consortium's systems were really close to the TIE's mainframes that the game was originally developed on, so it was just a matter of busting out the sacred scrolls and typing up the game was originally developed on. So it was just a matter of busting out the sacred scrolls and typing up the game. But the version wasn't a straight copy-paste job. Rawitsch made a few incremental improvements along the way, and since he wasn't under a time crunch, he was able to put a little extra care into the new game. He even used journals from

settlers who actually traveled the Oregon Trail to change up the misfortunes that a player could encounter. The new and improved version of the game was ported to the MECC mainframe in early 75, and it quickly gained a following. Oregon Trail was played in classrooms all over Minnesota, and the magic of discovering the trail firsthand made it an instant hit among students. From there, the game was set to spread even further. The next big boost came in 1978, just as the home computer market was really starting to heat up. Computers like the Apple II, Commodore PET, and TRS-80 were making waves in the market. These weren't the first generation of home computers, strictly speaking, but they were some of the first successful ones. The era of the

mainframe was starting to be pushed aside, and new home systems were becoming an actual reality for a lot of people. But these home computers did have one strange similarity with their larger predecessors. Nearly every one of them ran BASIC out of the box. The language was chosen as a standard user interface for the same reason that it was used in classrooms. For non-programmers, BASIC's pretty easy to learn. The choice also had a strange side effect. Some programs, like the Oregon Trail, were already compatible with newer systems. MECC was quick to adapt to home computers. The consortium was able to work out a pretty favorable deal with Apple, and soon Apple II computers started to pop up in classrooms around the state.

These computers came bundled with a set of disk drives and a graphics display. But more importantly, MECC also shipped out disks of educational software to schools across the region. Since a lot of MECC's existing software wasn't basic, it was really easy to migrate to the Apple II. So Oregon Trail was on the fast track into the hands of even more students than ever before. But there is another milestone for Oregon Trail in 1978. That same year that MECC started to push towards home computers, Don Rawitsch published the source code for the game. This came in the form of an article written for Creative Computing Magazine. Now,

up to this point, the game had only ever existed within schools, but this marked its first appearance in the outside world. The article would serve as a fantastic explanation of how the game works. Provided next to the code is a short summary of the game's development and flowcharts of misfortunes and other events that can happen on the trail. Rawich even provides details on how he extracted event weights from period journals. But most tellingly, this is the earliest document that I've seen that describes the Oregon Trail as a simulation. Quote, like all simulations, Oregon does not attempt to replicate exactly a trip on a wagon train in the 1840s, but it does attempt to present students with some of the resources, decisions, and events

that face the pioneers of that day. Although students can find out about the Oregon Trail by reading books, visiting museums, watching movies, and similar activities, the simulation allows them to learn from actively participating in the simulated experience of people from another era. End quote. I think this is important because it shows where the Oregon Trail is actually coming from. It's not really a game, and it's not really a computerized lesson. It's a simulation, and it's meant to get students more engaged with material. Oregon Trail lets students uncover and experience a glimpse of what settling the West was like, and it presents it in a way a normal lesson or textbook just can't

do. And by publishing the game's code, anyone was able to enjoy that experience at home, at least given they had a computer and some spare time. The immediate effect was that home users could now run Oregon Trail. But with code in the wild, things started to change. Tweaks needed to be made to get the game running on new platforms. Even though a mainframe and an Apple II both run basic, they each have slight idiosyncrasies. And if you're in there making some small changes, then it's not hard for things to spiral a little bit out of your control. Over the next few years, the creative computing version of the Oregon Trail spread and morphed.

The code was ported widely to other systems, and it's circulated around by computer enthusiasts. But more importantly, it was improved. It was sometime in this period that graphical versions of the game started to appear. One notable version even replaced the hunting game with a more interactive rendition, complete with wild animals running around the screen. Just the fact that Oregon Trail was being spread around and upgraded goes to show how much people just really liked the game. The game was shifting into something more recognizable, but it would take a more centralized effort to get the Oregon Trail we most remember. Getting there would take some major changes of MECC's priorities. As the 70s drew to a close,

the consortium had become a more commercially-minded group. With microcomputers showing up in classrooms around the world, there was actually pretty high demand for educational software, and MECC already had a lineup of titles. It was really easy for them to shift from servicing Minnesota to selling software to any buyer. This put MECC in a really weird position. They were originally a group meant to facilitate education, but now they were slowly becoming a software company. By the 80s, the ragtag group of teachers was now supplemented with professional software developers, and new programs were being churned out fairly regularly. These new games were written from scratch specifically for home computers, and it really

started to show. Graphics were just one part of the equation. It was now possible to make much more complex games. The Oregon Trail was still beloved, don't get me wrong, but it was starting to show its age. This brings us up to 1984 when MECC decided that it was about time to revitalize some of its classics. Development on a new version of the Oregon Trail would start in 84, but just as a note, it would actually ship in 85. So to try and keep things simple, I'm just going to refer to the newer version as the 85 version. Anyway, this new version wasn't going to just be an upgrade. The plan entailed much more than just slapping some graphics over the game. In 84, R. Philip Buchard was a programmer at MECC.

Before joining the company, he had mainly developed simulation software for colleges. He was slated to lead the New Oregon Trail project, backed up by a team of programmers, artists, and historians. The goal was to recreate the game, complete with graphics, while retaining the magic of the 1971 version. In this way, the earlier game would serve just as a starting point. It informed Bouchard's decisions, but it didn't restrict it. As Bouchard put it, quote, Every detail was up for reconsideration.

Furthermore, I needed to create a much richer and more elaborate experience than the original organ, and this would require a great deal of new, original thinking. End quote. But even with all this freedom, there were still some issues that had to be addressed. One big change was the new games market. MECC had been shifting more towards consumer software, so the new Oregon Trail was set to be released for home as well as school use. At first, this may seem like an innocuous design choice, but it had some major impacts on the final game. In a school setting, a student would only get to

play the game for a relatively limited amount of time, so the game should be fast enough that you could beat it in a single class period. While at home, things are a lot different. You can actually sit down to a longer gaming session. Oregon Trail 85 would have to work in both environments. The easiest solution would be to add replay value. Make a single run of the game relatively fast to beat but give incentive to take things slow and play multiple times. That balancing act shows up throughout the game's design. The platform would also heavily inform the game's design. Oregon Trail 85 was targeted for the Apple II, MECC's platform of choice and a very popular computer for the time. This gave Bouchard and his team access to graphics and sound, but also some major limitations.

and sound, but also some major limitations. The Apple II can only display six colors at one time, so graphics had to be relatively simple. There were also a lot of space concerns. The computer only had 64 kilobytes of memory, and its floppy disks could only hold about 140 kilobytes of data. The 85 version could be made a lot more complex, but it still had to be relatively small. Working in those constraints, Bouchard and his team created an amazing piece of software. It's not the same game as the 71 version, but it's totally recognizable. The earlier version of the Teletype game was labeled a simulation, but the 85 trail ended up earning that title. Under the hood is a set of surprisingly complex mathematical models. Bouchard had a lot of experience with this kind of modeling,

so he applied it liberally to the Oregon Trail. Everything from weather to health, illness to river currents is dictated by interconnecting and finely tuned modeling. And I really mean this was in-depth. Just for an example, Bouchard describes the weather model as, quote, in the game, the program computes the weather every day based off current month and location. This, in turn, affects many other factors, such as health, river crossing, availability of water, and so on, end quote. But even without getting into the code, changes are immediately apparent. One of the most impactful is that the 85 version just feels a lot

more full of life. Back in the teletype days, you took the Oregon Trail roughly alone, unless you were attacked by bandits or wild animals. But with this reimagining, the trail is packed full of other humans. In fact, most screens have some sort of name or drawing of another human on them. Instead of starring off as a single player, you play the game as a party of five. And you even get to name each character in your party. And as you travel, different misfortunes can befall each member of the party. It's really easy to get emotionally invested in their survival, and that draws you a lot closer into the experience. The next surprise for a veteran of the trail is the new resource system. The 85 version has the familiar oxen, food, ammo, and clothes, but miscellaneous supplies are removed in favor

of replacement wagon parts. In the old version, this category counted as medicine and replacement parts. But in trying to keep things historically accurate, Bouchard chose to remove medicine. His logic was that medicine in the 1800s wouldn't have been 100% accurate at curing infection. Instead, a more complex system was introduced. The party has an overall health rating that's affected by things like amount of rations, travel rate, and misfortunes. This means that there are a lot more ways to die in the 85 version of the trail. If you aren't careful, you can work your party into exhaustion, something that would have been a real risk in the historic trail. The overall structure

of the game is also greatly changed. The 85 version still plays out in a series of turns, but it's presented in a very different way. For the most part, your wagon travels on autopilot, only stopping for misfortunes or landmarks. The travel screen shows a little animation of your wagon bounding down the trail and a summary of the current game status. You can even manually stop the wagon to tinker with some settings. The reason for auto-wagon comes from the core design constraint. A student has to be able to beat the Oregon Trail in one class period. You can actually beat the game in 40 minutes, and being able to auto-advance past the travel sequences makes that a lot easier. Even once you get to landmarks, you can choose

to keep traveling instead of stopping. But you really should stop and take it all in. A lot of work went into this, and the landmarks are a reward in themselves. Each landmark has its own pixelated art and accompanying music. Continuing the trend of a more human-centric game, you can also buy food from a market, trade, or even just talk to people on the trail. Well, you don't really talk so much, but you do get a blurb of text that either gives you hints on the game or some more historical context to what's going on. And of course, everything you can do at one of these landmarks is impacted by the location on the trail. It's a neat little touch that adds a lot to the overall experience.

There's even an entirely new hunting minigame. Gone are the days of banging away at the keyboard. If you choose to stop and hunt for food, you're greeted with a whole new screen. One that shows your player in a randomly generated forest, with animals randomly generated as herds. Using the keyboard, you move around the screen, take aim, and fire at the wildlife. Of course, all the flora and fauna displayed are dictated by your locale. On the surface, it's totally different than the teletype implementation, but I'd argue that it serves the same purpose. It's a way to break up the sometimes monotonous resource management section of the game, and it adds something more fast-paced. The 85 hunting

simulation just happens to be on another level and a lot more graphical than the original. So far, everything I've mentioned has just been an expansion to the 71 version. Some have been big changes, but they're all still loosely based on the source material. There are also a slate of totally new additions. While the most frustrating, at least for me, are the river crossings. These are another type of landmark, but with a slight twist. At four points along the trail, you need to get over one of these ribbons of water. You have options to either caulk and float your wagon, ford the river, or at some crossings, get a guide or a ferry. This is another place where the

mathematical models really come into play. Each river's depth and current can change depending on the weather modeling. So in some cases, you can safely ford the river, but other times, that would be a disastrous choice. The game gives you some information that you need to make a good decision, but whenever I play it, I tend to make the wrong one. There is a fifth river in the game, the Columbia River, and that introduces another final element of danger. This is on the final stretch to the coast, but that doesn't make it any less treacherous. Once you arrive, you can pay a fee to cross, or you can attempt to float your wagon downstream. Paying the fee is safe, but it's not as fun.

This is where the second minigame is tucked away. If you choose to raft down the river, then you actually get to control your wagon on the trip. In the game, you have to dodge rocks and the shore, and then land at the proper location. Just like hunting, it adds a more fun and fast-paced element to an otherwise slow game. If you survive all these trials and make it to the coast, then you get one final surprise. The 1985 version has a high score table. Your run gets a score calculated by your party's health, provisions, and spare cash. And playing further into the game's theme, the high score table comes pre-populated with

the names of actual pioneers. The scoring system, plus the minigames and overall glut of content, well that adds a lot of incentive to replay the game. Sure, you could hammer out around at school, or you could settle into a session and try to grind out a few more points. Overall, the 85 version of Oregon Trail is a wonderful game, there's a reason it's a classic. Ushard and his team were able to keep the same magic of the first iteration, while greatly improving and expanding its design. Once on shelves, the game was an instant hit. The colorful graphics, music, and addictive gameplay

made kids and students love it. The educational side of things made it a very easy sell for parents. At this point, the Oregon Trail was decades removed from Don Rawitsch's early pen and paper games. But it tapped into that same magic. The computer was the missing element. Home computers just made everything more accessible. For generations of children, the Oregon Trail proved that learning, well, that could be a lot of fun. The Oregon Trail proved that learning, well, that could be a lot of fun. Alright, that does it for this episode.

The Oregon Trail is an important game for a lot of people. Over the decades, it's had massive reach, appearing in classrooms and homes around the world. Oregon Trail is one of the most successful educational games of all time, but it didn't come out of nowhere. This game is just one part of the much larger drive to integrate computers into education. And when you get down to it, Oregon Trail is the product of an environment primed for this exact kind of software. Something like the Oregon Trail was bound to happen. The stage for the game was set all the way back in the 1960s by LaFrenze and others that saw the importance of computerized

classrooms. By bringing schools into the new digital fold, a lot of opportunities arose. Oregon Trail was the logical result of these opportunities. The mainframe version made smart use of programming in order to make learning a lot more engaging. And that mindset stuck around once the game left mainframes and made its way into the home. Ultimately, The Oregon Trail is remembered as a fun game, but it's more than that. It represents a larger process of modernizing education, one that will go on as long as computers continue to change. If you want to experience the game for yourself, the Internet Archive is, as with a lot of things, your best bet. There, you can emulate a few different versions all from the comfort of your browser.

Mainframe emulation is still a little strange even in 2020, but there's a version on the Apple II that's a port of the 1971 game. And, of course, the 85 version is also up at the archive. I'll post around some links so you can travel down the trail yourself. Thanks for listening to Advent of Computing. I'll be back in two weeks time with another piece of the story of the computer. And hey, if you like the show, there are now a few ways you can support it. If you know someone else who would like the show, then why not take a minute to share it with them? You can rate and review the podcast on Apple Podcasts. And if you want to be a super fan, then you can now support the show through Advent of Computing merch

or signing up as a patron on Patreon. Patrons get early access to episodes, a little bonus content, and other assorted perks. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.