R. Philip Bouchard

Rafting Down the Columbia River

By R. Philip Bouchard

In my first month of work on The Oregon Trail, as I began to imagine other “arcade games” to include (other than hunting), I realized that a rafting game set on the Columbia River could be an excellent choice. Prior to 1846, when the Barlow Toll Road was opened, there was no way to get a wagon over the Cascade Mountains. In effect, the Oregon Trail ended on the east side of the Cascades, but the final destination was on the west side – in the Willamette Valley. Most overlanders were therefore forced to raft down the Columbia River to complete their journey, either abandoning the wagon or carrying it on the raft. But even after the Barlow Toll Road was opened, some overlanders opted to raft – either because they had no money for the toll, or because the Barlow Toll Road was known to be a very difficult route.

My initial ideas for the game, based in part on the historical research I had done, included the following details:

1. If you choose to raft down the river, then you have the choice of hiring an Indian guide, or else doing it entirely on your own.
2. The current of the river pushes the raft downstream, but the raft is equipped with equipment that allows you to steer left and right across the river, primarily to avoid obstacles. The player can use the left and right arrow keys for this.
3. The river is rapid in many places, and therefore quite dangerous. A principal objective of the rafting game is to avoid crashing into rocks.
4. There are places on the river where it is necessary to portage around waterfalls, dangerous rapids, or other impassible features. Therefore part of the game is landing in the right spots to do each portage.
5. On the real Oregon Trail, local Indians were available for hire to assist in the portaging.
6. The river current varies in strength from place to place. The current runs primarily along the axis of the river, but the current can also push the raft towards one side or the other.

My teammates really liked my concept for this game, but in our brainstorming we soon decided to eliminate point #6. In other words, for simplicity, we would assume that the current was equally strong in all parts of the river, and that it always ran parallel to the river banks. Soon after, one of my teammates created the following sketch to illustrate what we had discussed:

Then we put the concept aside for several months, as we concentrated on other key modules of The Oregon Trail. I had several reasons for giving other modules a higher priority. Unlike the hunting activity, the river rafting activity could be played only once in each session of the game. Furthermore, the rafting game occurred at the very end of the journey, and therefore was not important for the early Alpha testing. (None of the kids would get that far in the initial testing.) And finally, we had never worked out some of the key concepts for the game, especially the parts related to portaging. Therefore, despite our enthusiasm for the rafting activity, I kept postponing any further work on it, instead putting my efforts into the higher priorities. And so, when the end of March came and I was told by my supervisor to abandon all modules that were not yet in programming, the rafting game was cut from the plans.

I had mixed feelings about this. On the one hand, without this module, I was quite worried that the final leg of the journey might end up feeling anticlimactic. On the other hand, I worried that the effort to design and build the rafting module might not be cost effective. So I put my hopes in finding other ways to make the final leg of the journey feel special to the player.

As a result of cutting the rafting game from the plans, the final leg of the journey to Oregon would be handled by the travel screen and its underlying cycles – the same system that we use for every other leg of the journey. Normally, what you see on this screen is a tiny animation of an ox pulling a wagon. But if you choose to raft down the Columbia River, then the animation on this screen would be quite different. Instead of an ox pulling the wagon, the wagon would be sitting on a raft, floating on a surging river. To me, this seemed like a relatively simple substitution. I had no doubt that Charolyn could create a great little animation, and that John could put it in.

However, late in the project, as we finally began to implement this approach, we ran into several serious issues. The more that we examined the issues, the worse the problems became. Eventually, I felt that the only viable solution was to revive the concept of the Columbia River rafting game. So I went back to my supervisor to explain the problem, and to my surprise, he gave me permission to revive the game – but with strict conditions: 1) The design for the game would have to be extremely simple. 2) We would have to program the game in Applesoft BASIC, not in assembly language like the hunting game. 3) Because John was so busy already, we could not assign this module to him. Instead, Craig lent me another excellent programmer, Steve Splinter, to program the rafting game.

I did not write up any formal specs for the revived rafting game. Instead, I met with Steve and Charolyn to work out a new game concept that was much simpler than the earlier concept. In this new design, there would be no portaging around obstacles in the river. There would be no hiring of local Indians to serve as guides. Instead, the game was entirely about avoiding the rocks in the river, and then landing the raft at the correct exit point.

We also opted for an extremely simple representation of the river – an abstract, 45 degree angle view, very similar to the river crossing module. This simple view did not allow us to show any curves in the river. The only features we show are the rocks, which the player must quickly dodge. As the player floats downstream, a sign eventually appears on the river bank, indicating that it is time to land the raft on the shore.

Steve quickly put together a first cut of the game, and then we tested and refined the game in a hurried effort to tune the gameplay. As I tested the game with various players, I noticed that some players failed to see the sign that tells them to exit the river, and then they would overshoot the landing point without realizing what had happened. So I decided to include additional signs on the river bank, to alert the player to pay attention to the signs! As odd as this solution may sound, it actually worked fairly well.

In the finished rafting game, if you choose to float down the Columbia River, then you are given two screens of instructions, and the game begins. As you raft down the river, you pass by many rocks. You must use the arrow keys quickly and carefully to avoid hitting the rocks:

If you crash into a rock or the river banks, then you will probably suffer serious losses:

Finally, after you see the third direction sign by the side of the river, it is time to land your raft near the squiggly path up the river bank:

After you successfully land your raft in approximately the right spot, then the program announces your arrival in Oregon, and your points are tallied.

The Columbia River rafting game turned out to be a very helpful addition to the product. It acted as a powerful finale – at the end of the hair-raising rafting trip you arrive at your final destination, the Willamette Valley. It also added to the educational value of the product, because it communicated an important feature of the real Oregon Trail. However, I was never very happy with the rafting activity. In my opinion, it is just too obvious that we designed and built it quickly and cheaply. It certainly does not seem as polished or as well designed as the hunting game. Among the weakest attributes are:

1. Because we built the activity in Applesoft BASIC instead of assembly language, the animation of the raft and the rocks is jerky instead of smooth.
2. If we had had a little more time, then we could have jazzed it up a bit. For example, I would have preferred to see a variety of rocks in the river, of various sizes, instead of the same rock over and over.
3. The rafting activity did not get enough gameplay tuning. In particular, the losses from hitting a rock often seem excessive, and the losses from hitting the river bank seem even more out of whack.
4. In hindsight, I wish we had computed the losses according to how solidly you smash the raft into the rock. If your raft hits the rock dead center, then the losses should be huge. But if you barely nick the rock, then the losses should be minor.
5. The slow speed of the animation (due to programming the activity in BASIC) meant that we could not include any features in the river other than an occasional rock. If we had taken the time to program the activity in assembly language, then we could have created a varied and interesting shoreline on the river. We could have made it apparent that many parts of the shoreline are rocky, but that other parts are free of rocks – just soil or sand. Crashing into the rocky stretches of the river bank would be a serious problem, but bumping into the sand or dirt would be okay.

If we had started building the rafting game three months earlier – at the same time as the hunting game – then perhaps we could have gone with a more complex design, and we could have programmed it in assembly language. In that case, I think we would have addressed and solved most or all of the issues listed above. Furthermore, if we had started earlier, then we could have continually improved the game during the last several months of the project. That said, even if the rafting game seems a bit rough around the edges, it was far better to have included it than to have left it out.