Imagining the New 1985 Design

By R. Philip Bouchard

Gearing Up for the Redesign

When MECC released the first Apple II version of OREGON in 1980, as part of Elementary Volume 6, the company had every reason to be proud of it. The product soon became hugely popular in schools, and MECC became nearly synonymous with the Oregon Trail. At the time, most educational software for the Apple II was exceedingly simple – designed and programmed by amateurs using very simple tools and techniques. MECC’s early software was no exception. But in 1982, educational software for the Apple II began to appear in retail stores, created by several new startup companies. This trickle soon became a flood, and by 1984 a huge number of companies had entered the market, including giant media companies such as CBS. The entire competitive landscape had changed completely. Most of the best new software was now being created by teams of professional designers and programmers. By 1984 it was no longer acceptable to sell software that looked like the products from 1980. OREGON was now so technologically outdated that it had become an embarrassment for MECC. Furthermore, MECC – which until this time had sold its software only to schools – now had its eye on the home market, and it needed to create a product that could do well in retail stores. The company finally decided that it was time to create a new version of its most famous product.

In October 1984, I was chosen by the MECC’s management to be the lead designer of a brand new version of The Oregon Trail, targeted primarily to the home market. I was delighted by the news, but I was even more amazed by the details of my mandate. I was told to take the original concept and run with it. I was to expand upon the original idea, building a much more elaborate and robust game. I could do so in any way that I saw fit, provided that I met three criteria:

  1. Preserve whatever magic made the original so popular.
  2. Create a great product for the home market.
  3. Build it for the Apple II.

My mandate to re-envision and redesign The Oregon Trail was almost overwhelming at first – the possibilities were endless, yet I had to get it absolutely right on the first release. For 13 years, from 1971 to 1984, the OREGON game had remained essentially unchanged. A few small details had been tweaked along the way, but never had the product been completely re-imagined and redesigned. Never had the underlying models been changed – the structures, algorithms, and assumptions upon which the game is based. For the very first time, we were going to throw out everything – including all of the existing software programming, which dated back to 1971 – and start completely from scratch. Every detail was up for reconsideration. Furthermore, I needed to create a much richer and more elaborate experience than the original OREGON – and this would require a great deal of new, original thinking.

Because I was designing a home market product, I knew that I had to create a game that was highly entertaining, in addition to being clearly educational. I felt that it was possible to do both, without seriously compromising either – but I had to strike a careful balance in the details. In particular, I felt that both the educational value and the entertainment value would arise from immersing the player in a historically accurate experience.

From the very beginning, I saw that this project presented many challenges, but two of these challenges seemed especially difficult:

1)   Space constraints

The new game needed to have a rich set of color graphics, but the graphics would require a lot of space – both on the floppy disk and in the Apple II RAM (memory). I also hoped to add many new details and gameplay aspects, all of which would require space. Unfortunately, I was designing for a computer that had only 64K of RAM. Furthermore, the product would be distributed and played on a double-sided 5.25” floppy disk – providing a total of just 280K of storage space. (Note that the Apple II did not have a hard drive, only a floppy disk drive.)

2)   The game framework

I needed to invent an appropriate framework upon which to build the game design. The new game needed to provide a richer experience than the original, with more opportunities to explore and to make decisions. Furthermore, I wanted the game to include the real geographic details of the Oregon Trail – a factor that the original game model could not accommodate. I would have to envision a complete new framework for the game – but initially, I had no idea as to how I would do this.

As the project began, our core team consisted of five people. In addition to me (Philip Bouchard), there was also John Krenz (lead programmer), Charolyn Kapplinger (lead artist), Shirley Keran (research), and Bob Granvin (additional programming). All five of us played active roles in the early brainstorming and planning for the product, although MECC eventually moved Bob to a different project that needed his attention. And so the five of us began a project that became MECC’s biggest effort to date, lasting a total of 10 months, from October 1984 to the end of July 1985. By the end of the project, our team (which had grown to include additional members) had created what soon became the most famous educational software product of the 1980s.

Left to right: Charolyn Kapplinger, John Krenz, Shirley Keran, & Philip Bouchard (1985)

Imagining the Framework of the Game

As we began work on the project in October 1984, it soon became obvious that my most pressing challenge was to invent a strong underlying framework for the game. My first step was to decide what to retain from the original game, and I soon chose five essential features: hunting, the risk of dying, resource management, random events, and purchasing supplies.

However, the new framework needed to support a game that was much deeper than the original. In particular, it needed to support two principal changes from the original game:

The original OREGON was based on the concept of “turns”, where each turn represents exactly two weeks of real time. In each turn the player decides whether to hunt and how much to eat. Then some random events occur, and the next turn begins. This simple framework was well-adapted to its original purpose – a text-based game played on a teletype – but it was poorly adapted to the needs of the new game.

First of all, I could not see how to tie a 2-week game cycle to the real geography of the Oregon Trail. Because the speed of the wagon varies with the circumstances, the player could be anywhere on the trail at the end of two weeks. With literally thousands of potential stopping places along the 2000-mile trail, I could not possibly present a realistic geography for all of these places – much less an appropriate gameplay for each place. And even if I could do so, there was no way to store all of this on a 280K floppy disk. Furthermore, the 2-week cycle made it hard to present a rich set of opportunities to make decisions. If the player can only make decisions every two weeks, and none of the decisions can be tied to the geography of the trail, then the set of meaningful decisions is severely limited. Therefore I knew that I had to throw out the old framework and invent a new one.

Hypothetically, one solution to my dilemma was to design a 40-minute game where every step of the game had its own design and programming. Designing this game would be akin to writing a novel, where every chapter was completely unique. But the resulting game would never fit on the disk, and it would require far too much time to design, program, and test. Therefore I needed to invent a framework that employed reusable pieces. However, each module would have to provide a different experience with each use – otherwise the game would be repetitious and boring.

Three of the modules would be inspired by features that were already present in the original game: 1) initial purchases, 2) hunting, and 3) visiting forts. I saw that the new hunting activity could be a great example of a reusable module, because the player might hunt many times during the 2000-mile journey. If I connected the hunting experience to the real geography of the Oregon Trail, then there could be different landscapes and different animals along the way. Furthermore, I could use randomization to mix things up each time that the player went hunting – so that the landscape would look different each time, and the animals would be in different places.

However, I needed to invent a lot more modules than just these three. I pictured the modules like beads on a string, with each module based on a key activity – but first I had to invent a meaningful sequence of activities.

Further complicating the matter is that I planned to base the underlying engine on a complex resource-management model. I somehow needed to connect this engine to the activity modules. The underlying engine would not only compute the current level of every resource, it would also control the passing of time. Whenever the player engaged in any activity, time would pass and the quantities of resources would change. I also imagined that in many of the modules, the player would make forward progress on the trail. But none of the modules that I had envisioned so far allowed for progress on the trail.

So I kept thinking, examining the problem from many different angles. For real travelers on the Oregon Trail, what did they look forward to along the way? What would break the journey into smaller pieces? As it turns out, many of the travelers did indeed anticipate upcoming points on the trail – publicized through word-of-mouth stories and commercial guidebooks. From my research, I concluded that there were three main types of waypoints that the travelers would anticipate:

  1. Major obstacles, such as river crossings
  2. Forts
  3. Interesting geographic features, such as Chimney Rock

Now I was starting to see how I could make it work. I would divide the journey into many smaller pieces, with a specific destination (a landmark) at the end of each stretch. Taking into account the 40-minute gameplay I was targeting, along with the 280K limit on disk storage, I soon decided that the journey to Oregon would consist of 16 segments, of varying but similar lengths, each ending in a landmark.

This was a major breakthrough in my thinking about the design. It was the landmarks – not the activity modules – that would be like beads on a string. Each landmark could have several different activity modules, many of which would be optional.

I was finally forming a workable vision for the framework of The Oregon Trail, but the vision was still missing something crucial – how to deal with the travel time between landmarks, which could range from a few days to a few weeks. I did not want the game to simply jump from one landmark to the next. On the real Oregon Trail, all kinds of incidents might happen between landmarks – such as running out of food – and these incidents should appear in the game. Furthermore, the resource tracking engine – monitoring your supplies and other resources – should run continuously, not just at landmarks.

This line of thinking led to another major breakthrough. I could not rely solely on a landmark-based cycle to drive the game. I would also need to design a daily cycle which ran independently of the landmark cycle. In other words, the game engine would be based on two distinct cycles, operating simultaneously. From the viewpoint of the player, the main cycle would be the journey to the next landmark – and this cycle would repeat 16 times, with key differences in each cycle due to unique data. Within this landmark-to-landmark cycle there would be a daily cycle, where the program computed your current speed, your location, and the state of your wagon and party – every single day of the journey. Random events could occur on any day of the journey, at any point between two landmarks. And wrapped outside of the landmark-to-landmark cycle, there would be a set of terrain zones. As you reached certain landmarks along the way, the terrain and climate would shift to a different set of data.

I was now getting very close to having a complete, coherent, and workable framework for the game. Still, my vision was missing one last essential piece. I wanted the player to be able to do all kinds of things between landmarks – such as resting or checking the status of supplies. But I did not want the program to halt every day and ask the player “What do you want to do now?” That would result in 150 halts in a typical 5-month journey. I started exploring alternatives. What if the program paused every 50 miles between landmarks? What if the program paused every 4 days between landmarks?

And then it occurred to me – the final breakthrough concept to complete the framework. Between landmarks, the journey should proceed automatically, with the days ticking by, and a daily status update appearing on the screen. But the player can pause the journey at any time by pressing a key – in order to rest, check the status of the supplies, change the food rations, or change the pace. If something dire happens to the player’s party between landmarks, or a noteworthy random event occurs, then the journey pauses automatically, just as it does at each of the landmarks.

I still had not completely settled on what gameplay modules to include, but now I had a framework for organizing those modules. Except for the modules at the very beginning and end of the game, every activity module would be accessed from a landmark or by pausing between landmarks. And in a major break from my earlier thinking, I decided that there would be only one module that moved the player forward along the trail – a single data-driven “travel module” for the journey between landmarks:

After the initial purchases, the player enters the landmark-to-landmark travel cycle. In a successful game, this cycle repeats approximately 16 times. The player goes back and forth between the two primary modules – the travel module and the landmark module – each of which provides access to many other modules (labeled A through L in the diagram). After 16 cycles, the player concludes the game successfully by arriving in Oregon. But if the player dies before completing all 16 cycles, then the player experiences the “died on the trail” conclusion.

In short, there were seven key concepts that allowed me to envision a completely new framework for The Oregon Trail, setting it apart from the earlier versions, and allowing me to create a much richer experience for the player:

  1. The journey consists of distinct segments, each ending at a unique major landmark.
  2. A set of activity modules is available at each landmark. In many cases there is a key activity tied to the landmark, such as crossing a river or purchasing goods at a fort.
  3. Most of the activity modules are data-driven and contain randomization, providing a different experience each time that the module is used.
  4. In addition to the landmark-to-landmark cycle, there is an independent daily cycle, which includes all of the resource management computations and the random events.
  5. The landmarks are grouped into distinct geographic zones, each with its own data about climate, terrain, and animals.
  6. Between landmarks, the journey proceeds automatically, but the user can pause at any time. Furthermore, the journey pauses automatically if a major event occurs.
  7. Pausing between landmarks provides access to another full set of activity modules.

My effort to invent a new framework for the game had often been frustrating – but now, to my great relief, I had produced a solid framework on which I could design the new, re-imagined game. In stark contrast to the original game, my new framework was intimately tied to the geographic features of the Oregon Trail. My new framework supported a rich set of opportunities for decision-making, and also supported my goal of giving the player a great deal of flexibility as to which activities to pursue. And the framework made it easy to incorporate any combination of activity modules – some of which might be inspired by the original game, and many of which might be completely new.

Imagining the New Activities and Features

Having imagined the new framework for the game, I now needed to imagine the activities and features. During this brainstorming phase, I frequently met with my teammates Cheryl, John, Bob, and Shirley to kick around ideas. After discussing some promising possibilities, I would then pursue the ideas in more detail, first writing up a concept paper for each proposed feature or module, and then eventually creating the full design specifications for each one.

Designing and building this completely new version of The Oregon Trail was not a straightforward, linear process. In my early design documents, I proposed and considered all sorts of ideas, only some of which made it into the finished product. By the time we released the game, the following innovative new features had been incorporated:

  1. Real geographic details. Unlike the original game, the new game was rich with geographic details, all mentioned by name and illustrated with attractive color graphics.
  2. Landmark-based travel cycle. The new game divided the route into approximately 16 segments, each beginning and ending with a famous landmark. Several game features are accessed only at landmarks, while hunting is available only between landmarks.
  3. Continuous daily cycles. The journey to Oregon typically takes about 150 days. The original game proceeded by 2-week intervals. In the new game, crucial events can occur on any day. The game continues on “auto pilot” between landmarks, allowing players to monitor the daily status update, and to stop at any time to do activities.
  4. Choices as to the route. Instead of a single continuous route, the new game included several branch points, requiring the player to choose between taking the left fork or the right fork.
  5. River crossings. The original game had no rivers. I made river crossings a major feature of the new game. At each crossing, the player must make crucial decisions, based on the current conditions, which are strongly affected by the recent weather, which differs with each play of the game.
  6. A re-imagined hunting activity. Our goal was to turn the hunting activity into a bona fide skills-based arcade-style game, incorporating the actual terrain in which you are hunting, such as prairie, mountains, or desert. Likewise, the species of animals you find reflect where on the trail you are currently located.
  7. A point system. In the original OREGON there is no point system. In order to build a high level of replayability into the product, I designed a point system that is closely tied to the difficulty level you choose. Furthermore, as another motivator, the high-score list is pre-populated with a set of historical names covering a wide range of scores.
  8. Family members. In the original game, there is little mention that other people are traveling with you. To make the experience more personal, my design requires each player to provide four additional names as traveling companions. If you make bad decisions or encounter a streak of bad luck, then members of your family will die.
  9. Talking to people. There is no conversation system in the original OREGON. In my new design I allow the player to talk to people along the way. This is an important method for obtaining helpful hints and discovering historical and geographic details of interest. Furthermore, it makes the game seem much more human.
  10. River rafting game. The original game does not mention rafting down the Columbia River, which I felt was a fascinating bit of history, as well as a great opportunity to include another arcade game in the product. Therefore we built the river rafting game, albeit a simpler version than what we had originally intended.
  11. Tombstones. Another famous feature we added is the ability to create a tombstone for yourself after you die. This humorous interlude compensates for the player’s failure to complete the journey. But the real hook is that we store the tombstone data on the game disk, so that the next player who uses the same disk can see the tombstone.
  12. A detailed health model. The original OREGON does not track the player’s health from turn to turn. My new design included an ongoing health model for the entire party, along with tracking individual illnesses and injuries. The weather, food rations, and pace all have cumulative effects on the party’s health, which can improve or decline over time.
  13. A detailed weather model. The original game did not include a true weather model, with seasons and data tied to several distinct climate zones. (The original had only two climate zones and no seasons.) In the new game, the program computes the weather every day, based on the current month and location. This in turn affects many other factors — such as health, river crossings, availability of water, and so on.
  14. Robust resource management. My new design provided many new ways to manage resources, including: 1) adjust the pace of travel, 2) purchase specific types of spare parts, 3) rest at any time to improve the party’s health, 4) barter with other travelers to acquire essential resources, and 5) buy additional oxen at forts.
  15. A captivating travel screen. The travel screen in the 1985 product — featuring a tiny animated ox and wagon — has become the iconic representation of the entire history of The Oregon Trail game. The combination of elements on this screen is both highly memorable and highly effective.
  16. Matt’s General Store. In the original game, you never interacted with people. In the 1985 design, we introduced Matt’s General Store. Matt is the friendly store proprietor who assists you with your purchases, providing helpful advice as to what you should buy and how much you should buy.
  17. Specific diseases. In the original game, if you get sick, then the disease is never named. (After you die, then pneumonia might be mentioned.) For the new design, I incorporated five diseases or symptoms often named by travelers on the Oregon Trail: typhoid, cholera, measles, dysentery, exhaustion, and fever. Oddly, one of these five has captured the popular imagination and become a ubiquitous meme. (“You have died of dysentery.”)
  18. Difficulty levels. To encourage replay, I built three difficulty levels into the game. I chose three distinct professions to represent the three difficulty levels: banker, carpenter, and farmer. These choices have also become a meme.
  19. Trading with people. At any time between landmarks, the player can attempt to swap items with passers-by. This can be quite helpful under certain circumstances, especially if a crucial wagon part has broken. However, this module is a pale shadow of the trading system I had intended to include. I later included the full, robust trading system in the game Lewis & Clark Stayed Home.
  20. Options to rest or change the pace. The player can choose to speed up or slow down the pace, or to stop altogether for a few days of rest. These decisions represent a major tradeoff between the health of the party and progress on the trail.
  21. Period music. At each landmark along the way, you can hear a different melody. Furthermore, every melody is an actual tune that was popular at the time of the Oregon Trail. Unfortunately, this innovation can be more annoying than helpful, especially on the Apple II, which has no volume control.

Taken together, these 21 innovations resulted in a very different experience compared to the earlier versions of the game. The new game was longer, with a much richer set of opportunities for decision making. It also allowed players to succeed in more than one way — by using various possible strategies and gameplay techniques. This was essential for my goal of making the game just as appealing to girls as it was to boys, as well as appealing to a broader range of tastes. In the end, the new game proved to be immensely popular with an exceedingly wide audience.

Where to Go Next?