Cross-Curricular Connections: Exploring the "Traveling West" Unit - Part 1

If you’re a parent of school-aged students, it’s likely you’ve played - at least once before - The Oregon Trail computer game created in 1971 and released by the Minnesota Educational Computing Consortium in 1975. You may fondly remember trying to decide the best way to cross a river - whether that was fording that river, caulking your wagon, or paying for a ferry - or trying to determine which supplies you could afford and needed most.  Even if you chose a helpful profession for your character (doctor, carpenter, blacksmith, to name a few), it’s likely you contracted dysentery or some other disease along the way that quickly ended your journey west. It was a tough game to beat, and rarely did anyone actually make it to Oregon, but for many of us, it was one of the best!

In our “Traveling West” unit in Content Library Junior, students have the opportunity to create a game similar to this beloved favorite, providing them both the opportunity to experience the game (to an extent) and the chance to learn the fundamentals of how games like these are created. While we only touch on some of the basic aspects of the game, like many Content Library Junior units, it is a more difficult unit than it appears. It is perfect for those students who are still at the elementary level, but in need of a challenge.

“Traveling West” is a two-part unit. The first submodule teaches students to write a program in mBlock that simulates The Oregon Trail game. Students then work in Tinkercad in the second submodule to create 3D objects and buildings representative of the Westward Expansion time period. Prior to starting either submodule, students spend some time learning vocabulary terms and concepts related to Westward Expansion that help set the context for the video game they are about to create. This month, we will focus on exploring the first submodule in greater depth. Join us as we highlight this sub-unit’s coding and cross-curricular concepts.

History Connection

When creating a program that relates to a specific time period in history, it is important to have accurate facts and information for your game.  This is true of any game, program or activity that is based on a realistic setting or theme. It doesn’t have to be history. It may be that your game is located in the Amazon. You would need to have an understanding of the characteristics of the Amazon, like the animals, the wildlife, and the climate, in order to ensure your game has accurate elements.

In this project, we teach two lessons focused on Westward Expansion content - one that reviews important vocabulary and one that introduces key concepts. We start by reviewing the Louisiana Purchase and Lewis and Clark’s journey; move into discussing wagon trains, landmarks passed while traveling West, and life on the trail; and end with learning about some key events that occurred in later years, like the California Gold Rush. We make it so that students who have never studied this topic before can easily understand the background in preparation for making this game, but it is also a way to incorporate Social Studies learning with programming and tackle two subjects simultaneously.

Setting Up: Thinking Backwards

Now let’s move into the computer programming concepts in this activity. Think about the basic components of video games programmers need to consider when writing the code. There are often multiple levels in the game, multiple players, obstacles, and a soundtrack. There is usually some way to increase your score. It might be by collecting coins, defeating a villain, or completing a timed challenge. All these elements need to be planned out prior to creating the game so that programmers understand their objectives. 

Now think about the very beginning of a video game. At its start, you have 0 points or dollars or whatever unit you are trying to collect in the game, and you are starting at square one. Both Scratch and mBlock have an interesting quirk where the values for variables are not reset each time the program is run.  Instead, they retain the values they had when from the previous execution.  If the game has been played before, and the program does not explicitly reset the point value and other aspects of the game, it may appear that some challenges have already been completed and the overall balance in the game will be skewed.

Addressing this issue requires some backward thinking. Not only do we need to include directions for the player to learn the game, but we need to make it so all elements are reset each time the game is played. In the first few lessons, we both set the scene and write code that will refresh all the game settings when the game is restarted, which is the equivalent of when the green flag is clicked in Scratch.

In the Traveling West unit, we select a girl sprite from mBlock’s library of sprites (though any sprite would work) to use as the main character for the game.  At the beginning of the original Oregon Trail game, the player is given a specific amount of starting money depending on the chosen profession. If the player chooses to be a banker, they start the game with $1600.  To keep our version of the game simple, we allot $1600 to all players regardless of the profession.

We need to write code to make sure that when the green flag is clicked and the game is restarted, the player’s amount of money is reset to $1600. To achieve this, we create a variable - a value that can change throughout a program - and title it “money.”  When we click Make a Variable, we ensure that “for all sprites” is selected when naming the variable. This creates a global variable, meaning it applies to all the sprites (or players) in the program.  Next, we add a set [money] to (1600) instruction to the when green flag clicked instruction so that when the game is restarted, the monetary value returns to $1600.

That $1600 and any money the player earns in the game is put toward supplies needed on the trail. Typically, players purchase supplies before the trip begins, but it’s important to save along the way in case you need to buy supplies while in transit, like a spare wagon wheel or some medicine for a sick member of the party.

To keep track of the player's supplies, students will use a list.  In programming, a list is an ordered sequence of data. (In other programming languages, lists may be called arrays.)  In this case, the data consists of the various supplies the players have.  In mBlock (and Scratch), lists are created within the Variables category. When players choose to buy certain materials, they are added to the list (which is displayed on the Stage).  To ensure the player starts with no supplies, the list must be cleared at the start of the game.  A delete all of [Supplies] instruction is added to the code, so that the list is empty and ready to be populated again at the start of the game when the green flag is clicked.

The main character will be introducing the game to the player, so she will have additional sets of instructions for this purpose.  The say instructions in the Looks category make a sprite “speak.”  The student will write code to instruct the main character to explain the objective of the program to the player and to ask various questions that will determine the the values for other attributes. 

We’ve already discussed a significant amount of the program, yet there is so much we have not yet explored. These instructions are just a portion of the beginning instructions for this unit. While the game itself may appear simple, there are many facets both to consider and to add to the code. 

Setting Up: Conditionals

In computer programming, conditionals are if-then statements that determine what happens next in a program based on a certain condition. The Oregon Trail computer game is a “choose your own adventure” type game where every decision you make affects what happens next. 

One of the many decisions you have to make is what your profession will be as a member of the wagon train. Will you be a carpenter who is handy and may be able to help fix needed items along the way?  Or is it better to decide to be a doctor and help heal the sick members of your group? Whatever you decide, the program will adjust based on your choice. 

In our Traveling West program, we teach this concept at a basic level using conditionals. There are many occupations from which to choose in the original game, but given our program is intended for elementary learners, we limit this number to three. We have the main character tell the player that the choices of occupation are a teacher, a farmer or a doctor. IF the player chooses to be a doctor, THEN the girl says “It’s great to have a doctor with us!” IF the player chooses to be a teacher, THEN she says “It’s great to have a teacher with us!” You likely have figured out her response if a player chooses to be a farmer.

We could have made it so that not only does the girl speak a line about the occupation chosen, but the player is brought to a new backdrop and experiences a different version or level of the game than a player who might’ve chosen something different. This would require more extensive backwards designing than we do in this unit, but the purpose is to introduce students to this type of thinking and highlight areas of a program where backwards thinking would need to be applied. 

Resetting the player’s amount of money, starting on a specific backdrop (which we will discuss in the next section), erasing the supplies list, and choosing a profession are just some of the many elements included in setting up this type of game. It’s important to keep in mind that we discussed just a few of the many components involved when the game is started from the beginning. When you consider it this way, it should be apparent how much thought and planning is required to create even a moderately complex game!  As we continue, we will highlight more significant learning areas within the program and provide insight as to what might make pieces of this program more challenging for even our more seasoned elementary coders.

Multiple Backdrops

When we think of traveling the Oregon Trail, we might think about the various places and landmarks where wagon trains stopped along the way. When thinking about backwards designing, we also come to realize that we need to have all the backdrops (or levels) of the game set up in the event a player’s decision requires them to move to a specific location. 

We also consider the cross-curricular connections to history in this project. Students learn about the noteworthy parts of the trail that we use as different backdrops, as well as place the scenes in the correct order of how a wagon would travel the trail.

Programming Buttons

In some of our programs, we teach students how to create a main menu from which the user can navigate to different levels. For this game, because each level should be in sequence given that you are traveling West in one direction, we simply need to create two sprites: the Next button and the Back button.

The Next button sprite’s code is what you see above, where it is as simple as including a when this sprite clicked instruction from the Events category and a next backdrop instruction from the Looks category. 

The trick is knowing when to show or hide this button, and ensuring there is an instruction that shows the Next button in every level in which it is needed. It should be displayed in every level except the last, which should only have a Back button.

In contrast, the Back button sprite should be displayed in the last level, as the player can move to a previous landmark or area of the Oregon Trail.  Similar to the Next button, this is a simple button to program.  You would need to again choose a when this sprite clicked instruction from the Events category, but this time choose a previous backdrop instruction from the Looks category. Like the Next button, you would need to ensure there is an instruction that shows the Back button in every level in which it is needed. It should be displayed in every level except the first. Students need to think across levels and consider the whole program when adding these sprites.  This task is not necessarily difficult, but it helps teach students the importance of paying attention to all details when writing a program.

Occupations: Exploring Conditionals

In the original Oregon Trail game, the player has the opportunity to choose an occupation.  Depending on the choice, the amount of starting money changes, as does the amount you receive as a bonus when (or if) you reach Oregon City. To program this, students use an "if-then" or conditional statement. IF the player chooses to be (insert whatever occupation of choice here), THEN they would receive a certain amount of starting money.

To keep our version of the game simple, everyone earns the same amount of starting money. However, we teach the basic concept of the conditional statement by having the main character say a different sentence depending on the chosen occupation.

Here you can see three different conditional statements. Depending on the answer given to the original question shown in the ask instruction, the main sprite will say a different statement.  To make this happen though, there are some bubbles and portions of instructions that need to be completed in order for the if-then statement to work.

First, the long hexagonal shape in the "if-then" statement must be filled with an Operator.  There are three comparison operators, one for less then, one for greater than, and one for equal to.  Since the program needs to determine which profession was chosen by the player, the code needs to "equal to"
operator in each of the conditional statements.

In the first bubble of the comparison operator, we add the answer bubble from the Sensing category. Since there are three possible options for what the answer might be (Teacher, Doctor or Farmer), these values are placed in the second bubble of each of the Operator instruction. In this way, the program will know which line the girl sprite should be “saying.” 

Crossing the River

Conditional statements are a significant part of the Oregon Trail game given that students pick their own adventure throughout the game. What happens next in the game largely depends on what the user chooses to do. IF they choose to travel in one direction, THEN they may run into certain scenarios that they would not have run into had they chosen a different direction.

Students continue to learn how to work with conditionals when programming the wagon to cross the Missouri River, one of the key points of the Oregon Trail. At this point in the program, we add a Covered Wagon sprite rather than continuing to use the girl sprite.  This has two purposes.  First, the group the player is traveling with will be traveling west in a covered wagon, and this is typically what is displayed when traveling to different parts of the trail in the original game.  Second, since each sprite has its own code, adding a second sprite allows us to divide the code, thus making it less complex and easier to understand.

For every backdrop, there must be a when backdrop switches to [ ] instruction, as well as a long set of instructions beneath it that are particular to that one backdrop.  While this module is intended to challenge elementary learners, it still becomes a bit too hectic to have all these instructions associated with a single sprite.  Therefore, we have students upload an image of a Covered Wagon to use as a new sprite, and  they then begin adding code for this sprite.  This is very similar to the way professional programmers divide their code into multiple files and try to keep related code together.

Because the user needs to decide whether to cross the river, the wagon should not actually cross until the user types that they wish to do so.  The program includes an ask instruction that says, “Type 'Cross the river.' to cross.”  While not asking a question, this will cause a box to pop up on the Stage for user input. IF the user types “Cross the river,” THEN we have to add instructions so the wagon actually moves. 

Next, we bring in more mathematical skills when teaching about x-y coordinates related to the Covered Wagon.  The program needs a go to x: ( ) y: ( ) instruction from the Motion category to position the wagon at a specific place on the coordinate plane. We use a backdrop from mBlock that includes an image of a river. The x and y-coordinates for the wagon, then, need to be located on one side of the river. Equally important is adding a point in direction (90) instruction so that the wagon faces the correct direction before crossing.

To move the wagon to the other side of the river, students learn first to place the wagon at the desired end location and take note of the x-y coordinates listed underneath the Stage. In order to make this learning more concrete, students could temporarily switch to the x-y coordinate plane backdrop in order to better envision the exact coordinates for the wagon’s ending location.

Most of the movement instructions that take coordinates default to the sprite's current position.  With the wagon in its desired final location, adding a glide 1 secs to x: ( ) y: ( ) instruction will cause the wagon to move smoothly across the river from its initial position.

This section of the game reinforces previously learned programming concepts, like how to use conditionals, and simultaneously teaches math skills related to the coordinate plane.

Chimney Rock

Chimney Rock is another landmark located along the trail.  At various points in the Oregon Trail game, the player has the option to restock and buy needed supplies. It is possible that your wagon needs repair, you need food and provisions, or other necessary items to successfully continue along the trail.  Of course, choosing to purchase more supplies means you will need to spend money. Here is another point in the program in which the student must apply certain math skills.

In a lesson focused on lists, we add a Supplies list to one of the backdrops.  This list will contain various materials and provisions a wagon train might need, as well as the prices of each. This is an opportunity to incorporate math skills related to money and addition and subtraction with decimals.  When buying supplies, students use the conditional statements they learned about early on in the program.  They must also use addition to determine the total cost of the supplies the player wants to purchase and subtraction to deduct proper amount from the player’s funds. Working with money and carrying out operations with decimals are two skills intertwined in this one lesson, as students continue to also learn programming skills.

Reaching the End of the Trail

At the very end of the program, the wagon moves across the screen to Oregon City. Now that students have made the wagon move across the river, the same skills can be applied here using glide instructions. This is a good opportunity to challenge them to see what they can do independently or if they can apply what they learned previously in the program to write a similar set of instructions.

A Packed Unit

This program is an excellent unit to use for students who are in need of a challenge and have already learned basic programming skills. The other academic skills incorporated are also geared for older elementary students. This unit is particularly beneficial for independent practice, as a lot of the skills emphasized at the start (like conditionals and Motion instructions) need to be utilized again in later parts of the program.

There are a wide variety of skills and instructions we did not yet discuss. Not to worry, though, as this is only part 1 of the Traveling West unit!  Cross-curricular projects are particularly important for teaching students to learn to apply their knowledge and skills to solve problems.  In the real-world, one must apply a wide range of techniques and skills to adequately problem solve. This unit drives home this concept by allowing them to recreate aspects of a game that has been a favorite for many for years.