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