The inclusion of river crossings was one of the key innovations in my design for The Oregon Trail – a feature which had not been present in the original version of OREGON. I felt that a fully realized river-crossing module would provide a great educational opportunity, in addition to enriching the overall gameplay. And indeed, for most players of the game, the river crossings are the second most exciting part of the product, eclipsed only by the hunting activity.
As I conducted my research prior to designing the game, I learned that the overlanders to Oregon had to cross a lot of rivers. (And in some cases, when the trail went up a river valley, they had to cross the same river several times.) But from the standpoint of gameplay, it was better to include only a small number of river crossings in the game. Furthermore, after 3 or 4 crossings, there would be little educational value in including more. I eventually settled on the Kansas River, the Big Blue River, the Green River, and the Snake River – although at times I seriously considered several other rivers as well.
The four rivers differed in size – in both width and the depth – but the actual depth at the time of the crossing depended on how much rain had recently fallen in the drainage basin of the river. Therefore, as the overlanders reached a river crossing, they needed to make an assessment based on the current conditions. If the river was low and slow, then the river was typically forded. In other words, the oxen pulled the wagon across the river, with the wagon wheels rolling on the river bottom. But if the river was high and swift, then fording the river would not work. At some river crossings a ferry was available, but this cost money, and there was often a long queue of wagons waiting to take the ferry. If no ferry was available and the river was deep, then the only options were to wait for the river level to go down (provided that no additional rain fell), or to caulk the wagon and float it across the river like a boat (without the oxen attached) – a rather risky operation.
Another key factor was that at some of the river crossings on the Oregon Trail, Native American guides were available for hire. This was particularly true at the Snake River crossing, where Shoshone guides provided a great deal of assistance to the emigrants crossing the river. They not only helped in getting the wagons across, but provided even greater assistance in getting the emigrants’ livestock across safely.
There were several different problems that could occur when crossing a river. When fording a rocky river, a wagon part could break, or the wagon could overturn. If the river bed was muddy, then the wagon could get stuck. If the river was deeper at some point than the height of the wagon bed, then the wagon could get swamped – meaning that water would flood into the wagon. This would ruin some of the supplies, such as flour and gunpowder. Floating a wagon across the river was even more risky. It was all too easy for a floating wagon to overturn, and if the current was quite swift, then the wagon might even get swept away.
All of this provided a rich set of possibilities for a simulated river crossing. I was determined to make the situation as realistic as possible – both in terms of the decisions that must be made, and the likely consequences of those decisions.
In the finished game, when the player arrives at a river crossing, the first few screens provide a context to the player, and also allow the player to talk to people at the landmark, which can provide additional context and useful hints. First, while still on the travel screen, you see that you have arrived at a river crossing:
Then you see a large graphic that illustrates the place:
When you resume your journey, the river crossing begins:
To simulate the actual crossing, I needed to create an effective and realistic model for each of the rivers, and I needed to figure out how to model and represent the experience of crossing the river.
First I created a mathematical model for each of the four rivers. I decided to include four factors – the river’s depth, width, swiftness of the current, and type of river bottom. I wanted the depth, width, and swiftness to be different with each play of the game, but I also felt that the values should be logical and realistic. I was already working on a climate and weather model for the game, which would be a key part of the experience. On any given day, the chance of rain would depend upon the current month and the player’s current location on the trail. If the weather were quite rainy in the days just prior to reaching the river, then the river should be deeper and swifter (and therefore more dangerous) than usual. But if the weather had been dry in the days before a river crossing, then the river should be shallower and safer than average. So I built a river model that took into account the amount of recent rainfall on a sliding scale – the more recent the rainfall, the greater the impact.
The next step was more difficult – to build the mathematical models for the player’s river crossing experience. For each of three principal methods of crossing (ford, float, or ferry), I first wrote up a detailed scenario of possible outcomes. After discussing these scenarios with my teammates, I developed a mathematical model for each scenario. These models determined the probability of success, given the current river conditions and the method of crossing. If the crossing was not fully successful – that is, a problem occurred during the crossing – then the model also determined the extent of the player’s losses, again taking into account the current river conditions and method of crossing.
For example, here is the scenario that I initially provided for fording the river:
After reviewing this scenario with my teammates, collecting their feedback, and making appropriate changes, I created the first draft of the mathematical model (the “algorithm”) for fording the river. In this algorithm, D represents the river’s depth in feet and BT is the “bottom type” – which can be smooth and firm, muddy, or rocky and uneven:
Notice that this algorithm has two break points – at depths of 2.5 feet and 5 feet. If the depth of the river is currently less than 2.5 feet – which is shallow enough to ford – then there is one set of results. If the river is deeper than the second break point (5 feet), then attempting to ford the river results in a catastrophic failure. But if the river is between 2.5 feet and 5 feet deep, then the losses are less serious. I soon changed the algorithm significantly, eliminating the 5-foot break point. In the revised algorithm, if the river is deeper than 2.5 feet, then the risk of losses is based on a sliding (linear) scale – the deeper the river, the greater the risk of losses. This produced more realistic results than the first-draft algorithm above.
During the fine-tuning stage later in the project, I made another change to the fording algorithm to improve the gameplay: If the river depth is between 2.5 feet and 3 feet – which is the swamping scenario – then you don’t lose any supplies, and none of the oxen will drown. However, you lose a day of time to dry out your supplies.
Likewise, for floating across the river or taking a ferry, I first created a complete scenario, and then I converted the scenario into a detailed algorithm – which I later fine-tuned as we tested the results.
Now that I had precisely defined the models for the current conditions at each river, and for determining the results of any attempt to cross the river, I still had one serious issue to address. How were we going to represent all of this on the screen? I wanted to portray the results on the screen visually, rather than relying solely on text. I also hoped to incorporate some animation. And to the extent possible, I wanted to simulate all five of the possible outcomes (safe crossing, swamping, overturning, swept away, stuck in mud). I called the team together to discuss possible approaches. It was quite a spirited discussion. We needed to invent a visually compelling way to communicate the ideas above, but using a simple visual model that would be practical to build, with a limited amount of graphics and programming.
As we brainstormed and sketched out ideas, we eventually hit upon a simple but effective concept. The river would be an abstract field of blue, viewed from a 45 degree downward angle. You would see your wagon on the river, either fording, floating, or ferrying across. The near shore of the river would recede, and soon the far shore would appear. We would use a distinct animation for each of the three methods of crossing, but for practical reasons we would only animate two possible outcomes. If the algorithm decided that your crossing was successful, then you would see your wagon reach the far shore of the river. If your crossing was unsuccessful, then you would see the wagon overturn in the river.
In other words, for either the overturning or swept away outcomes, we would use the overturning animation. For swamping or getting stuck in the mud, we would use the safe crossing animation, using text to mention the issues encountered. Charolyn then began work on the graphics that John would incorporate into the animations.
So now we could put it all together and build the river crossing module. If you choose to ford the river and your crossing is successful, then the animation looks like this as you approach the opposite bank of the river:
The animation when you float across the river looks like this:
If the crossing is not successful, then you see the wagon overturn in the middle of the river, and then an announcement tells you what losses you suffered:
The animation for taking a ferry looks like this:
I still needed to create the algorithms for hiring an Indian to assist in the crossing. It was clear from my research that the Shoshone guides at the Snake River crossing were quite expert in their work, greatly reducing the risks of crossing the river. Therefore the following was my initial algorithm for hiring an Indian guide, where D is the depth of the river in feet, and S represents the swiftness of the current:
In this original algorithm, if the conditions were somewhat risky, then your guide would advise you of the risk – and you could decide whether or not to take the risk. But if the conditions were extremely bad, then your guide would refuse to make the crossing. I wish that we had been able to include these details in the actual product, but we did not have the space or the time to do so. In the final version of the game, your guide always makes the decision for you, and he always makes the best choice between fording and floating the wagon, given the current circumstances. Unfortunately, the guide does not warn you if the river current is too swift for a safe crossing. Furthermore, the guide never opts to wait a few days before crossing, but always crosses immediately, no matter how dangerous the situation.
In the original algorithm, hiring an Indian guide cuts your risks in half, and also reduces your losses if something goes wrong. However, during our testing and fine-tuning, I discovered that a 50% reduction in your risk was insufficient. Accidents were still too frequent, and players concluded that hiring a guide was useless. Therefore, during my fine-tuning of the algorithms, I changed it so that hiring an Indian guide reduces your risk by 80%. That’s a huge reduction in the risk, but it is not a foolproof guarantee of success either.
Despite the design compromises that we had to make in order to simplify the animations and programming, the river crossing activity proved to be one of the most exciting and memorable modules in The Oregon Trail, adding greatly to the popularity of the product.
