Subscribe
Share
Share
Embed
Digital learning games have shaped what happens inside and outside of classrooms. They've led to some of the game industry’s most fascinating successes and failures. And they have important lessons for us about teaching and learning. Join learning game maker Brian Alspach as he covers the history of this influential videogame genre and the classic titles we've played to learn.
If you grew up 80s or 90s and went to an American public school like I did, you probably remember the computer lab. At my elementary school, the lab was a former classroom space – don’t ask me what it was used for before it became the lab. It was outfitted with several rows of PCs of the day: Apple II’s in all their two-color, green-and-black glory in my case.
We went to the lab maybe once a week as one of our “specials”: you know, things like art or music or library. Sometimes we went for a few days in a row out of our regular class to work on a special project that tied into what we were learning. I don’t remember much of those trips, to be honest. What I do remember are the things we did during the weekly “special” visits.
I got my first exposure to programming, in the form of programming in BASIC on those Apple IIs. My friends and I took to this like the proverbial ducks to water and soon we figured out how to do stuff that went above and beyond what our teachers would have liked. Most of it they, in fact, did not like. One of our favorite tricks was to write a little three-line program that would keep printing consecutive numbers on the screen until the computer’s memory filled up, then set it running just as we were leaving at the end of the period, much to our teachers’ consternation. And if you’re thinking that’s the single dorkiest example of childhood rebellion you’ve ever heard of… you are correct.
Besides programming, we did other things: skill-and-drill math, some light word processing… but the other thing we did was play educational games. These were the early years of PCs and of the push to get them into schools. And it was also before the Internet, so software was distributed on physical media: floppy disks. As a result, most schools, like mine, had limited program and game libraries. But one title that was in almost every 1980s school computer lab, and the one that was our favorite, was The Oregon Trail.
The Oregon Trail is forever connected in my head with the cinderblock walls and fluorescent lighting of that late-80s computer lab at James A. McDivitt Elementary School in New Jersey. But it turns out the game’s origins go back nearly two decades, fittingly to another classroom, this one halfway across the continent.
In Episode 4, we saw that the first educational videogame, The Sumerian Game, grew out of an academic research project, and that it was a teacher-created game. The Oregon Trail is also a teacher-created game, following a very different, though equally intriguing course of development. Whereas The Sumerian Game grew out of a group of educators’ interest in seeing if videogames could be used to teach; The Oregon Trail grew out of one teacher’s desire to teach something specific in a new way, and his buddies’ desire to help him to do it. The result is one of the most widely-played and influential games in history, one that has been enjoyed in new forms by generations of kids, going way back to that school in Minnesota where it all began in 1971.
As I like to do to kick off the discussion of a game, let’s set the stage by talking about the state of the computing state in 1971. Actually, the state of the state isn’t all that different from where we left it in the late sixties with The Sumerian Game. We’re still talking about a pre-PC era, so no one has a desktop or laptop computer in their home or business. They don’t exist yet. The places that have access to computing power at this time – government, businesses, universities and, increasingly, public school districts – have access to it in the form of minicomputers. For all intents and purposes, minicomputers functioned like the earlier mainframes we talked about in Episode 4, being distinguished from mainframes by their smaller size and greater power, enabled by increasingly smaller and more powerful components.
“Powerful” and “small” are, of course, relative terms. “Powerful” means “more powerful than the prior generation of computers” and “small” means “being approximately the size of a large bookshelf” rather than the size of small room like many early mainframes.
When an organization had a minicomputer in this era, the computer itself sat in a room somewhere, usually in a central location. In the case of a school district, this might be in a particular school or maybe the district headquarters. Users in other locations accessed the computer via old-school, analog phone lines and dial-up modems. And they interacted with the microcomputer not via keyboards and monitors like we do today, but rather by using teleprinters.
Teleprinters are another subject I touched on in Episode 4, but to describe them briefly: a teleprinter is a device where a user provides remote input to a mainframe or minicomputer via a keyboard – more or less like keyboards of today – but instead of the computer’s output being displayed on a monitor, it’s printed on a continuous roll of paper for the user to read. This means instead of the user providing input and the computer responding by updating a display in real time, there’s a naturally turn-based rhythm to the human-computer interaction. The user types something, hits enter and waits. The computer responds, then it waits for the user to provide the next bit of input. And the cycle repeats. And both the user’s input and the computer’s output are entirely textual: no graphical interfaces (those have been demoed at this point but aren’t available to consumers), and no controllers or mice.
We’ve previously talked about how the very earliest videogames were more like modern games in this respect: they did have video displays that updated in real time, so you could have action games like sports simulations or space battles. But teleprinters don’t support action mechanics: there’s no concept of FPS if games are entirely text-based and the gameplay unfolds in turns, rather than continuously.
Put another way, the designers of teleprinter-based games had to operate under a specific set of constraints. It’s no different in principle than, say, a modern designer having to operate under a different set of constraints if a game’s input mechanism is a touchscreen versus a controller: it’s just that the specific constraints are different. Working within those constraints, designers had to figure out what kinds of games they could make with just text and the back-and-forth human-computer interaction.
In the late sixties and early seventies, computer-enthusiasts-turned-game-designers were just beginning to experiment with creating fun gameplay within those constraints. Oregon Trail was one such proejct, but there were other folks independently working on the same problem with non-educational games. One of these other earlier attempts, which, like Oregon Trail, was released in 1971, was a game called Star Trek, based on, and completely lacking a license from, the original 1960s Star Trek TV series. In Star Trek, developed by Mike Mayfield and Bob Leedom, the player commands the starship Enterprise on a mission to destroy a fleet of invading Klingon ships. The player can take actions like move about the 64-quadrant galaxy and fire on the Klingon ships with different weapons. All information is provided to the player through text (or via ‘ASCII art’ where text characters are used to create rudimentary images) and all interactions are turn-based. For instance, in combat, the player attacks the computer-controlled Klingon vessels during his turn, and the Klingons counterattack during the computer’s turn.
The pattern Star Trek laid down is the same one used by Oregon Trail and many other early computer games that are variously called “teletype games,” “text-based games” or “text adventures”:
• The computer is aware of the entire game state at the start of each turn, for example in Star Trek, the location of the Enterprise and all the Klingon ships, their remaining hit points and fuel, and so on.
• At the start of a turn, the player gets information about the game state. It’s almost always a subset of the full game state the computer is aware of, usually localized to what would be in the player’s immediate awareness within the narrative context of the game. Again, in Star Trek, this might be what shows up on the Enterprise’s sensors for the sector she’s currently in and the immediate adjacent sectors, but not the whole galaxy.
• The player issues commands that alter the game state. In Star Trek, this might be the Enterprise firing a torpedo or warping to a new sector.
• The game has what’s called a rules engine: a subsystem that takes the game’s state at the start of the turn, plus the player’s commands, and applies a pre-programmed set of rules to update the game state. For Star Trek, if the player fires a torpedo, this might mean flipping a simulated coin to see if the torpedo hit or missed, then applying damage to (and potentially destroying) the Klingon vessel if it did.
• If the computer is controlling NPCs, they get to take their turn, following the game’s rules and the AI routines the developers have given them, like simulating the Klingon captains’ behavior. This data is then subject to the rules engine and a final game state for the turn is calculated.
• The game displays information about the outcome of the turn, then the process repeats for the next turn, then the next, until the player either wins or looses.
This text-based, turn-based paradigm can create pretty rich, compelling gameplay, even in the absence of graphics or realtime interaction. Game designers typically made up for those deficits by creating rich, complex simulations that interestingly captured the real-world things they were trying to represent, or by providing rich narrative descriptions as the player navigated and interacted with different game environments, or both. There’s certainly something to the idea of letting players use their imaginations to translate text into mental pictures that plays to the same human capacity for thinking visually and imaginatively as reading a novel does. At any rate, so engaging was this style of gameplay that it survived the transition from teleprinters to text-based monitor displays and even coexisted with graphical games into the PC era. If you’ve heard of classic games like Adventure, Rogue and Zork, these are all text-based games. And so, too, is The Oregon Trail.
Back in 1971, a college senior majoring in history at Carleton College in Northfield, Minnesota, Don Rawitsch, was doing his student teaching in an 8th grade history class at Jordan Junior High School in Minneapolis. Rawitsch’s supervising teacher assigned him the task of developing a lesson on American westward expansion in the mid-19th Century. Rawitsch wanted to do something unconventional, so he decided to develop a board game instead of a traditional lesson. He chose as the specific content focus a well-known pioneer trail used by thousands of American settlers leading from Independence, Missouri to the Pacific Northwest, known to history as the Oregon Trail.
After a week of research and prep, Rawitsch was laying out a map of tiles depicting the trail’s route on his apartment floor when his roommates noticed the cartographic disruption and asked him what was up. Fortunately for the history of videogames and of education, Rawitsch’s roomates – Bill Heinnemann and Paul Dillenberger – were also Carleton students and had student teaching experience. But unlike Rawitsch, Heinnemann and Dillenbergers’ field of study was math, not history. As a result, they both had some experience programming.
When Rawitsch described his design, Heinnemann and Dillenberger recognized that it could be implemented – and maybe implemented more effectively – as a computer game. In particular, by using a computer, the game’s simulation could be made more sophisticated and realistic. For instance, instead of determining the player’s success by dice rolls alone, a computerized rules engine could consider a whole range of factors, for example the state of the player’s resources. Rawitsch was intrigued, but also reluctant: his lesson was due in two weeks.
Dillenberger and Heinnemann were undeterred by this narrow deadline. I get the sense that this may have been a case of them not knowing what they didn’t know. There really wasn’t any information available, nor any models, for what developing a game would be like or take. Remember: there was no such thing as a game industry at this point. There were just a handful of titles developed by amateur enthusiasts. But apparently they were confident enough to convince Rawitsch, and the three roommates agreed to give it the literal “old college try.”
Being a larger school district, Minneapolis had access to a reasonably state-of-the-art minicomputer, the HP 2100. Heinnemann and Dillenberger were able to access this computer from the junior high school at which they were doing their student teaching. Over the next two weeks, Rawitsch did the historical research and game design while Heinnemann and Dillenberger did the programming, in BASIC. They did that programming over teleprinter, and I can’t imagine how tedious and difficult that was. And while Rawitsch was, as I say, the primary game designer, like on most game teams, Heinnemann and Dillenberger contributed to the design, with Heinnemann coming up with the hunting minigame, for example.
By the end of the two weeks, the team had a playable version of the game and began testing with students. Among the students who got to try the game at this early stage was a young man named Prince Rogers Nelson who you probably know by just the name ‘Prince,’ or, if you’re a bit older, ‘the artist formerly known as Prince,’ or, if you’re older still, also just ‘Prince.’ When the game debuted to the broader school community at the end of 1971, teachers initially questioned its value, but students loved it, literally lining up around the corner to play. The teachers ultimately got behind it to, offering advice to Rawitsch on how to improve the depiction of Native Americans in the game and finding, as Rawitsch later put it, “flimsy excuses” for their students to get a chance to play.
In an article I read, Rawitsch notes that his supervising teacher was kinda checked out by this point in the semester, so he isn’t even sure that he ever saw his lesson. But with his student teaching project complete and storage space being at a premium, at the end of the project, Rawitsch had his developers print out the 800 or so lines of the game’s source code and delete the program from the minicomputer. At this point, that literal black-and-white paper printout was the only form in which one of educational gaming’s most influential titles existed.
We’ll come back to the story of the game’s development and legacy at the end of the episode, but let’s switch gears and talk about gameplay. I think one of The Oregon Trail’s greatest strengths is the variety of game mechanics it not only includes but integrates into a cohesive whole that somehow manages to give you a sense of what life on the trail was like, even in the early, totally non-graphical teleprinter version. In talking about the player experience, by the way, I’m going to reference both the original version and the later graphical versions, like the one I remember from grade school, which added more depth beyond just the visuals. But I’ll try to make clear which versions I’m talking about throughout.
In the original version of the game, you play a single settler traveling the Oregon Trail from Independence to the Willamette Valley in Oregon. In later versions, you play the head of a family group of settlers and even get to name the members of your party. This, in and of itself, was a source of endless fun for us back at McDivitt school, where we would name our party after TV characters, or superheroes or, more frequently, our classmates, largely because it was amusing when that annoying kid Nick later died of dysentery.
At the start of the game, you are given a budget to spend on the various things you’ll need on your journey, $700 in the original version. In that original version, your purchasable resources consist of oxen (to pull your wagon), food, clothing, ammunition and a category of miscellaneous supplies that includes things like medicine and spare parts. As you travel the trail, you’ll have opportunities to buy, or in later versions sometimes trade for or find, more of certain of these supplies, so there’s also a question of how much cash you want to hold in reserve.
After you’ve played the game a few times and start to understand the relationship between your supplies and what can happen to you on the trail, these opening budgeting decisions become surprisingly compelling and anxiety-provoking. Especially in later versions, the game admits of multiple strategies for resourcing depending on your skills and playstyle. A good example of this relates to the hunting minigame, which is present in the earliest version (though it changes form in later ones). If you’re good at the hunting minigame, you can pretty consistently replenish your food supply while you’re out on the trail. If you’re not, or don’t want to bother hunting (or losing time to hunting), then you’d better be prepared to spend more of your budget on food.
Once you’re equipped, you set off on the trail, and the game’s core mechanic becomes one of resources management. Again, using the original game as an example, once you’re on the trail, you start to deplete various resources. These include the resources you purchased, but also other “hidden” ones, most notably time – you’re in a race against the clock because you don’t want to get stuck in the mountains when winter hits – and the health of your character (and in later versions, all your party members).
Some of these resources deplete steadily, like time ticking away or your food supply dwindling. You usually have some influence over the rate of depletion: you can drive your party harder to move faster. You can have your party eat meagerly, moderately or indulgently.
Other resources tend to deplete more discretely: you use up ammunition when you hunt, but not if you don’t. And some resources can do both, for example your party’s health, which can be influenced by your pace and how well fed your party is, but can also take a big hit if, for example, stupid Nick gets his foot run over by a wagon. As I mentioned with the food example, some resources can be replenished. Others – notably time – get used up with no opportunity for recovery. Such is the nature of our mortal existence.
What makes The Oregon Trail so good is the cleverness and attention to detail with which these resources, and other gameplay elements, interplay. I’ve already given some sense of that: driving your party hard saves you time, but at the risk of your party’s health. And, of course, what good is getting over the mountains before it snows if you’re already dead when you get there? Such is the nature of our mortal existence.
Another thing the game does a really spectacular job of – both narratively and in interaction with the resource management elements – is make use of random events. There’s a tremendous richness to the things that can happen to you out on the trail. Like many game designers, both digital and non-digital, the original team was well-aware of how chance elements, and having to deal with them, can enrich a simulation game. One of the team’s great insights was to tie the chance elements to events that both interacted realistically with the resource systems and integrated with the narrative. You’re more likely to encounter bandits or Native Americans – friendly and hostile -- away from settlements. You might encounter a blizzard at high altitudes where it’s colder, and so on.
The prime examples of this, which didn’t appear until later versions of the game and are permanently etched in the minds of players because they were so harrowing, are river crossings. At each major river crossing, you’re presented with a varying menu of choices about how you want to get to the other side. Safest, and therefore most desirable, is taking a ferry when one is available, though this costs money, so hopefully you’ve budgeted for it. If the river is shallow enough, you can try to ford it, but this risks some supplies drifting away. Most risky – and sometimes the only option if the river is deep and no ferry is available – is caulking your wagon and floating across. But this is a risky proposition: it frequently fails and, if it does, you stand to lose a great many supplies and possibly the life of one or more party members.
In fact, resources, lives and entire games are not-infrequently lost to random events. In a lot of other games, this would seem unfair and torpedo the fun. But in The Oregon Trail, it feels earned and sometimes poignant, because it gives you a visceral sense of how risky crossing an untamed continent in a covered wagon must have been. It’s frustrating to lose your game to a random event, especially when you know you’ve been making all the right moves. But you can easily restart a game. Imagine really losing the life of a loved one to a random event. Heck: imagine setting out on the journey, or any journey, with your family, knowing that you shouldn’t necessarily expect all of you to be there at the end.
Game designers talk a lot about balancing a game: tuning the game’s difficulty so that it’s challenging enough to keep the player engaged, but not so challenging that the player gets frustrated and gives up. Being so unchallenging that it’s boring is bad thing, and so is being so challenging or unfair that it’s frustrating. The Oregon Trail does something unique: it somehow makes unfairness, and frustration at that unfairness, fun, and elevates them both into learning mechanics that align perfectly with the subject matter.
Another advantage of frustratingly fun failures is that they encourage experimentation and promote replayability. In prior discussions of games-as-systems, we’ve talked about good simulations being good teaching tools for the systems being simulated. Experiencing failures – including seemingly random ones – in a fun, rather than frustrating way, stimulates players to try again, but to try again in a way that’s different to see if that works. This, in turn, promotes testing the limits and identifying the so-called boundary conditions of the simulation. This all contributes to a greater understanding of the system dynamics which is great learning. And from a gameplay value perspective, strong replayability gives you a lot bang for your buck, generating lots of fun and engagement: which is a big win for a game with a small codebase.
All this also contributes to the game’s authenticity.
It probably won’t surprise you that a nerd like me is a fan of The Lord of the Rings, both the book and the Peter Jackson films. One thing that that the films – and I think most great literary adaptations – do well is not trying to mimic the book. Instead, they try to capture what’s great about the book in ways that play to the unique strengths of film as a medium. It would have been a mistake, in my opinion, for Jackson to try to capture the word-building and almost-Victorian-travel-log-like prose Tolkien uses to describe the environments the characters journey through by adding a narrator. Instead, Jackson captures the richness and beauty of Middle Earth with cinematic techniques: production design, costuming, cinematography, and so on.
The Oregon Trail does this too, playing to the unique strengths of games a medium, even though that medium was just barely getting off the ground and the technologies at the team’s disposal were, by today’s standards, primitive. It reinterprets the real-world experience of traveling the Oregon Trail using videogame techniques to create an experience that feels visceral and authentic.
The use of chance mechanics is just one example. The fact that the game consists, fundamentally, of a series of minigames that are connected through a shared resource management system gives you a sense of the range of skills a person or party had to have just to survive: budgeting, managing resources, hunting, constantly conducting cost-benefit analysis, and so on.
Particularly in later, graphical editions of the game, the visual presentation makes a big contribution to the authenticity. While the teleprinter version of the game is relatively abstract – you track distance traveled and encounter things like generic, unnamed forts; graphical editions get more specific, referring to and depicting actual places. It was exciting to see even the simple graphical representation of a landmark like Chimney Rock suddenly rise out of the digital prairie. When a party member dies, there’s a genuine moment of pathos as you watch the digital gravestone that marks the place where they fell slowly retreat towards the right side of the screen as your wagon moves left, before it finally disappears off the monitor’s edge, never to be seen again. This isn’t my area of expertise, or the focus of this podcast, but outside of its importance in the history of educational games, I think you could make a pretty good case that The Oregon Trail is also an early demonstration of what games as an art form can do. The poignancy is the key reason the game is often considered an early, maybe the first, serious game – that is: a game intended to get its audience to engage with the richness and nuance of a challenging topic – in addition to an educational one.
I have a history teacher friend who used to go on a favorite rant against the conventional style of teaching history, which he thought was too concerned with names and dates. “This is history,” he would say, “’Story’ is literally in the name. People love stories! And, by its nature, it’s the story of the most interesting and important stuff that has ever happened to people! Yet somehow, we find a way to make it boring!”
My friend’s frustration speaks to the question: why, really, ought we study history? And, no, it’s not just because if we don’t, we’re condemned to repeat it. Fully exploring that question is way beyond the scope of a humble podcast about videogames, but I think at least part of the answer involves understanding how people in times and places different than our own, lived. The genius of The Oregon Trail is that it does this, through play that has captivated generations of students.
A few years after his student teaching, Don Rawitsch got a job at the Minnesota Educational Computing Consortium, or MECC, a state-funded organization that developed classroom software for Minnesota schools. With Hiennemann and Dillinberger’s blessing, Rawitsch created an updated version of the game for MECC. He used as his starting point the printout of the original game’s source code, but updated it as he went along, in particular by adding new random event types and updating the random event probabilities to be more historically accurate, based on additional research. His updated version was released in 1975 and made freely available to schools throughout Minnesota, who had access to MECC’s mainframe where it was housed. This is also the earliest version you can still play today, and I’ve linked to an online version in the show notes.
Soon after 1975, the transition from mainframe and minicomputers to what were then called microcomputers – desktop PCs, essentially – began. By 1978, MECC was encouraging schools to purchase microcomputers, in particular the Apple II that would become a fixture of 1980s computer labs, like the one at my school. An MECC developer named John Cook ported the game to the Apple II, but this wasn’t the Apple II version I remember from about a decade later. It was still fundamentally the same text-based game, though Cook introduced some graphical elements, like an interstitial screen that showed the player’s position on a map. He also replaced the earlier text-based hunting minigame with a graphical one in which animals cross the screen and the player must time his shots to hit them. If you’ve never seen it, the original minigame involved the player rapidly and accurately typing the word “BANG” to get his shots to hit home.
This 1975-with-minor-graphical-embellishments version was later ported to other computers of the era like the Commodore 64 and Atari’s 8-bit computers (these were Atari devices with keyboards that could play cartridge-based games, but were general-purpose computers, not just game consoles: one of these, the Atari 600XL, was the first home computer my family had). The game was still made available to Minnesota schools for free, but by the mid 1980s, MECC was distributing games and software nationwide, charging schools outside of Minnesota $10-$20 per title and providing the games to them on floppy disks. Oregon Trail was, hands down, MECC’s biggest seller.
Its continued success prompted MECC to develop an updated version that was released in 1985. This was the first fully graphical version of the game – which some historians of gaming consider to be a successor to the text-based version, rather than a new iteration. But this is the one that introduced many of the new mechanics I’ve mentioned, and it’s also the first version I remember playing. It was designed by a fellow named R. Phillip Brouchard. MECC made it available to the school market and, for the first time, the consumer market.
To rewind slightly to 1978, Rawitsch did something else that seems surprising by today’s standards, but was, at the time, quite common within the small community of computer enthusiasts: he published the game’s source code, along with some of his historical material, in a magazine called Creative Computing. In the pre-Internet era, print magazines like Creative Computing and Byte were the most effective way of widely sharing code. And publishing source code of even relatively robust software of the era, like Oregon Trail, in print form was feasible, since, as we’ve seen, programs like that were still only hundreds of lines long. For comparison, the engine code for something like Unreal Engine or Unity – so this is just the under-the-hood stuff that makes a modern game work before you factor in anything specific to a particular game – has 2-5 million lines of code, just slightly more than could fit into something the size of Cat Fancy magazine.
This isn’t a perfect analogy, but sharing your source code in a print publication was the 1978 equivalent of open sourcing it on GitHub. By doing so, Rawitsch was giving other developers the ability and at least tacit permission to recreate his game, and to create derivative works based on it. So even as MECC was porting and enhancing the game in the early 80s, unauthorized, modified and “enhanced” potyd were already out there. It’s also why, to this day, you will find multiple versions of the game with slightly different features and implementations from different developers on different platforms, and often versions from multiple different developers on the same platform. But MECC held the official IP rights to the game, and ultimately developed other titles, including an Oregon Trail II in the mid-90s.
In the late 1990s and early 2000s, there was a massive round of acquisition and consolidation of formerly separate educational game companies, many of which made significant contributions to the history of learning games going back to the early 80s. We’ll talk about those events when we get to that time period, but as a result of one of these acquisitions, MECC ceased to exist as an independent company in 1999. Through an extremely convoluted chain of acquisitions – one of which is frequently described as the worst business deal of all time -- the Oregon Trail IP currently sits with Harper Collins, which is itself a division of NewsCorp. In recent years, Harper Collins has partnered with game developer GameLoft, and it’s their editions for platforms like the iPhone and iPad that represent the most recent authorized versions of the game. It’s hard to know exactly how many people have played the game because of the various authorized and unauthorized editions, and because statistics I could find are all about a decade old, but the consensus is that the official editions have sold upwards of 65 million copies. For comparison, the Halo franchise has sold about 81 million copies as of 2021, and that’s the whole franchise, not just one title.
Because of the subsequent legacy of other developers working on various editions and the quasi-open sourcing, Rawitsch, Heinnemann and Dillenberger’s status as the original game creators wasn’t widely known for much of the game’s first twenty years of existence. Before it got absorbed in 1999, MECC made an effort to correct this. In a 1995 ceremony held, in fitting Minnesota fashion, at the Mall of America, MECC recognized them as the original creators of the game. Heinnemann brought with him the printout of the original source code, which he and the others refer to as “the sacred scroll.”
The Oregon Trail is widely recognized as one of the most successful and influential titles in videogame history, not just educational game history. It frequently makes the top ten on lists of most influential and best games of all time; and was officially inducted into the Video Game Hall of Fame in 2016: the earliest and one of a very small number of educational games to be inducted to date. It’s spawned affectionate parodies like 2010’s zombie-themed The Organ Trail by indie developer The Men Who Wear Many Hats (that’s an awesome description of indie development, by the way). And it has given generations of kids a taste of what it was like to cross a continent: and a pathological fear of dying of dysentery.
If you’re enjoying the podcast, be sure to check out the Substack at historyoflearning.games, where if you subscribe, you’ll get each episode in your inbox along with show notes that include bonus info not covered in the podcast, like images of games discussed. I also post transcripts of each episode separately.
If you’d like to support the show, the best thing you can do is leave a review on your podcast platform of choice. If you’re so inclined, I would be truly grateful.
Thanks for listening and I’ll see you next time.