You Have Died of Dysentery:

The Making of the Oregon Trail

Appendix 2: What I Would Have Changed

I have sometimes been asked what I would do differently if given another chance to design The Oregon Trail. However, there are many ways to ask the question, which produces different answers:

  1. If I could do it all again, and start the project over again from scratch in October 1984, what would I do differently?

I would approach the project in essentially the same way as before, because my approach worked well. However, I would try to ensure that all of the essential components are clearly identified and underway in a timely manner – to eliminate the issues we had with the Columbia River rafting game and the bargaining module. And I would attempt to provide a more sympathetic ear when programmers express concern about the mountain of work I constantly give them. (I don’t regret giving the programmers so much work – but I regret that I may not have shown enough empathy for their concerns about the amount of work.)

  1. If I had the opportunity to design a completely new version of The Oregon Trail TODAY, what would it be like?

It’s hard to give a precise answer, because I would go through a process of successive refinement – which means I don’t know up front exactly what I would do. But I do know that the product would have a completely different interface, to make effective use of modern devices. I know that I would do a lot of research before diving into the new design. I also know that I would pay a lot of attention to ensuring good gameplay again. And I would certainly increase the opportunities for a player to investigate interesting questions, thereby increasing the educational value of the product in a subtle way.

  1. Suppose I had been allowed to do a minor upgrade to The Oregon Trail in 1986, a year after it came out. In this scenario, I am given a relatively small budget and a short timeline, thereby restricting me and my team to the most important changes. As before, it will be an Apple II product. However, this upgraded version would be distributed on a 3.5” floppy, thereby greatly increasing the amount of available disk space (compared to the double-sided 5.25” floppy). How would this hypothetical 1986 version differ from the real 1985 version?

Now this is a question that I can answer in detail. While I cannot be 100% sure what I would have done in 1986, I am reasonably sure that I would have done the following, or as many of the following as my budget and timeline would allow:

1.   Enhance the trading module, allowing the user to select what he wants to obtain.

If the player is stranded because he needs a wagon tongue, then he should be able to specify that he wants a wagon tongue. If the player is out of food, then he should be able to select food as the item he wants. After making this design change, I would need to retune the trading module, because otherwise it would be too easy to obtain the desired item.

Each attempt to trade will take a day, just as in the existing module. To tune the gameplay, there will be four possible outcomes for each trading attempt that you make:

  1. There will be a 30% chance of the message “You waited all day, but no other emigrants passed by on the trail.”
  2. There will be a 20% chance of the message “Some emigrants passed by today, but they were not interested in trading.”
  3. There will be a 10% chance of the message “Passing emigrants have taken pity on your situation, and have given you [the item] for free.” This is a reversal of the Good Samaritan feature that I had originally wanted to include – where the player encounters someone in trouble along the trail, and is given the opportunity to help out. In this case it is the player who is in trouble, and the Good Samaritan is the passing emigrant. This feature is especially important in those cases where the player has little of value to trade in return for the broken part (or other crucial item).
  4. There is a 40% chance of the message “A passing emigrant is willing to trade you [X item1] for [Y item2]”, where item1 is the item that you want, and item2 is chosen randomly. The exchange rate is randomly chosen in the range of 1 to 3 times the actual value of the item you want. In other words, they might be asking a very high price. Furthermore, you might not actually have item2, or not enough of it if you do. If you do have enough, then you must decide whether or not to accept the swap.

Note that I would not include a full bargaining module here, which would be overkill for this situation. Therefore you can either accept the deal or reject it – no counteroffers.

2.   Change all menus to work with arrow keys, instead of requiring the user to type a number.

About the time that I was working on The Oregon Trail, I wrote up a new standard design pattern for menus of options. Instead of the player typing a number to select a menu item, the player presses the arrow keys to move a highlight up and down the menu. When the correct item is highlighted, the user presses the Return key. I recommended that all future MECC products use this new design pattern. And indeed, we soon made the switch and used the new pattern on all subsequent products. But we did not have time to go back and fix this on The Oregon Trail. This change would make the product easier to use – but equally important, it would also make it easier to do other improvements, such as item #3 below.

3.   Encourage users to do more activities at landmarks, such as talking to people.

The user interface (UI) in the 1985 version of The Oregon Trail seems to encourage kids to skip right past the landmarks. I would like to replace it with a UI that subtly piques the user’s curiosity, to make it likely that the user will indeed talk to people or perform other tasks. I’ve got several ideas as to how I could have made this change, including the use of graphical menus, and giving the player a choice as to which people to talk to. A few years later, I used several of these improved techniques in Lewis & Clark Stayed Home. (For details, see Appendix 4: “A Different Journey to Oregon”.)

4.   When the user talks to someone at a landmark, show that person.

If the product is distributed on a 3.5” disk, then we’ll actually have room for the pictures of the people. It will be a hassle to create all the pictures – about 50 in total. But it would certainly add interest, and it would definitely increase the odds that the user will talk to people. An added bonus is that this feature would raise the profile of Native Americans in the product – because some of the people you can talk to are American Indians.

5.   When your party is dying of starvation or freezing, put up a warning message.

In my ongoing, informal user testing of the product, after the new travel screen was included, I noticed an issue. When the food dropped to zero pounds, some kids were not noticing. I realized that we needed to explicitly point out when the party was dying of starvation, and likewise when the party was freezing to death for lack of sufficient clothing. This feature had always been part of the project plan, but due to some complicated issues, it never got done. But in this hypothetical upgrade, I feel that we could overcome the complications and include the feature.

6.   Improve the Columbia River rafting game.

The rafting game in the 1985 was too stripped down. I would enhance it a bit – not as much as in the original concept for this activity, but more than what we ended up with. I would brainstorm with the team before making a final decision as to which enhancements to pursue.

Most likely we would replace the Applesoft BASIC code with assembly language code, which would make the game much smoother and give us a great deal more flexibility. We would certainly include a more varied set of rocks and other obstacles in the river. The amount of damages you suffer when running into a rock would be determined by how squarely you hit the rock – a minor glancing blow would not do much damage compared to hitting the rock full square on. And I would really like to do some interesting things with the river banks, so that in some places the banks are rocky and dangerous, and other places the banks are soft earth or sand – and therefore not dangerous.

7.   Allow multiple chances to repair a broken part.

In the 1985 product, you get exactly one chance to try to repair a broken part. The effort costs you a day, and there is a 50% chance that you will succeed. I would change the algorithm so that the player can make unlimited attempts to fix a broken part, but each attempt costs a day of time. If a part breaks, then the first attempt to fix it has a 35% chance of success. The player then sees the message “You were not able to fix the broken part. Would you like to try again?” The second attempt has a 25% chance, and all subsequent attempts have a 15% chance of success. In other words, if the player keeps trying long enough, eventually he will succeed in fixing the part – but at the cost of much time and a declining food supply. If he has a spare part, he’ll probably use that instead. If he does not have a spare part but he has plenty of items to trade, then he may decide to trade with passing emigrants instead.

8.   Include an option to “Check status” or “Check health” in the landmark and travel menus.

In Chapter 11, I showed the planned screen for “Check health”. This option would have appeared in the landmark menu, right after “Check supplies”. It would have also appeared in the menu that appears when the player stops between landmarks. This screen provides detailed information about the current health of the party. Later on I combined this idea with the concept of “Check trail conditions”. The combined screen would have been called “Check status”, but for a variety of reasons it never got put in.

There are two main difficulties with this idea:

  1. The menu is already too long, especially at forts, where there is an additional menu item. Another menu item will not fit. And besides, at its current length, the menu is already hard for the user to scan. However, if we were to switch to a graphical menu, as I later did in Lewis & Clark Stayed Home, then the idea might work.
  2. Some of the data that I’m asking to display is not currently tracked by the program. For example, when someone gets sick, the program currently remembers how long the person has been sick, so that it knows when the person is well again. But the program does not currently remember which disease the person came down with. However, it should not be difficult to add a few more state variables to track this information.
9.   The Shoshone guide will recommend waiting if the river is too dangerous to cross.

At the Snake River, hiring a Shoshone guide greatly reduces your chances of tragedy when attempting this crossing. However, as currently implemented, he always chooses to cross the river immediately, even if the river is currently in a dangerous state. I would restore the missing feature where the guide recommends waiting a few days if the river is too high.

10.   On the travel screen, update the terrain color once a week.

As currently implemented, the color of the terrain (green, orange, or white) is only updated at landmarks or when the player stops between landmarks. As a result, the landscape color might reflect conditions that have long passed, instead of the current conditions. I would like to include a tiny feature that, if the landscape has not been refreshed in the past 7 days, then it checks to see if the landscape color ought to be updated.

11.   On the map, put a black dot at each of the river crossings.

As currently implemented, the map has a square to indicate the location of each fort, and a black dot to indicate the locations of all other landmarks – except for river crossings. I believe that the map would be more understandable if the river crossings also had black dots.

12.   At the river crossings, indicate the type of river bottom.

The program already knows what kind of bottom each river has – muddy, rocky, or sandy – so it would be easy to include this information on the same screen that tells you the river depth. The player might consider this information before choosing to ford the river. Then, if the wagon overturns on a rocky bottom, it makes sense. If the wagon gets stuck for a day on a muddy bottom, it seems less random.

13.   Remove the songs from the landmarks.

I would be sorely tempted to remove the music from all the landmark screens. The songs are far more annoying than they are entertaining or educational. I say this despite all the work I personally did to put the songs in. (Shirley Keran and I divided the effort of researching and selecting the songs. Bob Granvin and I divided the effort of coding all the song files.)

I think that’s about it. The assumption in this scenario is that I am given a relatively small budget in 1986 to make a modestly improved version, to be distributed on a 3.5” floppy disk. I would not attempt to include any of the really big features that we dropped from the product plans – such as the Barlow Road game. Except for the pictures of people at landmarks (item #4), I’d do exactly these same changes if we continued to distribute on a 2-sided 5.25” disk.

*** End of Appendix 2 ***