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 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:
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)
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 (such as food and health), 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:
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 about 16 segments, of varying but similar lengths, each ending at 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, go hunting, 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:
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.
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:
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.
