Disclaimer: Like the above, much of this post will be highly obvious to people who have designed simulations and games before, or thought about them in a practical way before. But for people who have not, I hope it serves as an interesting overview of the abstract aspects, and I hope that a discussion of the specific practical choices that I made for the game might be interesting to both groups.

In any "simulation game," there are a limited subset of possible variables that are tracked. In The Oregon Trail (1985), this includes oxen, food, clothing, ammunition, spare parts, and money. The player’s quantity of such items are stored in the game’s memory, and the game’s logic uses these in different ways (food is decreased as a function of time, for example, and spare parts can be used if the wagon breaks down during a random even).

In OR83, food is also tracked as one such variable (but water, however, is not — for the sake of simplifying things as much as possible), because finding adequate stockpiles of food would be a major concern in the first few weeks after such an attack, and its availability or lack thereof would be one of the things that distinguished the circumstances of certain locations from others. But if you are going to track something like food, you have to answer the question: what happens if you run out?

In real life, when we run out of food, we get hungry. This then progresses into starvation, a state that imposes increasingly taxing and unpleasant physiological effects over time, and ultimately, if not addressed, leads to death itself. If we modeled this as simply, "when food = 0, the player dies," it would not feel particularly realistic. Moreover, it would change the nature of food as a variable from real life: it would cease to have much correspondence to the reality of food, and turn it into a totalizing focal point of the player's activity in the game. Which is not what this game's gameplay is meant to be about.

And, on the opposite extreme, if you run out of food and nothing happens to the player or the game, then it is pointless to even track it: it is a variable without meaning, a distinction without a difference.

In between these poles are a wealth of possible options. If one plays games, then several alternatives have already probably come to mind. One that we explored early on was a system of “health points,” often what are called “hit points” in many games. The idea is deceptively simple: create a new variable, called health, and subtract from it while the player is without food, and perhaps replace it when the player consumes food. If it ever reaches 0, the player dies.

This model is an obviously simplification of how reality works, but could be made into a good-enough model with some careful attention to how it is set up. It emphasizes that the hazard of being without food is a prolonged and reversible one, and if one set it up well (the rate of loss and gain), you could imagine it working adequately for hunger. If you wanted it to be more realistic, for example, you might not want the rates of loss and gain to be constant and linear. You might want starvation to be exponential: starts off slow, rapidly speeds up. You might want the rate of recovery to be similarly tailored to the situation being recovered from — perhaps someone who was close to starvation will be slower to recover health than someone who just missed lunch.

But things get messy with the above if you also are modeling other health effects. Radiation exposure at relatively high levels, for example, can produce illness that would synergistically impact the effect of starvation. Should our post-apocalyptic game also model contagious diseases, wounds suffered from misadventures, infections, waterborne parasites? And in what self-respecting homage to The Oregon Trail could one not allow the player to die of dysentery?

These are choices for the game designer, ones with obvious benefits (more realistic, more ways of communicating the education message of what the health and social effects of nuclear war would be) and detrimental (escalating complexity for both the programmers and players).

In Jon Peterson's expansive 2012 history of TSR’s Dungeons & Dragons, Playing at the World, he has an extended discussion of the development of "hit points" as a concept in gaming.2 I found it extremely useful for thinking through the gameplay design issues described above. Many games, like Chess and Checkers, have no such concept: if a knight takes a pawn, the pawn is simply removed from play, “dead.” Hit points first emerged from war gaming simulations that tried to use singular pieces to represent composite units (e.g., a single piece representing a platoon of soldiers) and wanted a way to represent a fractional fighting strength.

As games centered around individual pieces that contained a higher player investment emerged — "hero" pieces in wargaming simulations — the stakes of a piece being "killed" also increased. So "hit points" were used to keep important pieces alive longer than your standard pawn: they are one of several means invented by game designers to help a player “avoid death” in games where a too-easy death makes the game un-fun to play. As anyone who was raised on the early Nintendo games can attest, one-hit kill games are inherently harder than games where your character can soak up a little damage before dying!

Thinking about these matters eventually led me to looking for a very different approach than “health points.” I considered the specific goals that I wanted out of the "health system" of the game:

• flexible-enough to model many different sorts of health impacts, including synergistic effects (e.g., radiation poisoning can make otherwise survivable conditions fatal)

• detailed-enough to give a sense of the progression of a given disease or health condition

• intuitive-enough so that a player would not need to be tracking actual numbers that would not be available to them in the real world to have a sense of their situation and its probable outcomes

• accurate-enough that it would not come as a surprise if their character (or an NPC) died or survived a health condition

The above is an admittedly tall bill of order, especially given the desire to keep it intuitive (which argues against high complexity) and also flexible (which argues for high complexity). But it is much easier to design a system built for flexibility if one starts with that goal from the beginning, as opposed to trying to add complexity later to a system that was designed around simplicity.

In thinking about other kinds of “health” systems, one that I found useful is the one in RimWorld, an open-ended science-fiction space colony simulator game (which takes place on a random planet on “the rim of known space”) that is designed around flexibility in the aim of producing emergent behavior. RimWorld’s creator describes it not as a “game” — you cannot “win” in any real sense — but as a “story generator,” in that it creates unusual and unexpected circumstances based on many fairly-complex, non-linear systems that then get a healthy dash of randomness added into them. That’s not quite what OR83 is, but the inherent flexibility of RimWorld’s systems makes it a useful reference point.

In RimWorld, the “pawns” (the games’ “inhabitants”) all can have different sorts of “status conditions” that include injuries, illnesses, mental states, and so on. These status conditions might be permanent, or only apply if the “pawn” is carrying a certain weapon, or has suffered some kind of condition in the past, or could just be a passing affliction. Each of these conditions has its own set of internal logic to it, and can impact other systems in the game. So “flu” (to just pick one example) is a disease that can affect “pawns” randomly. It normally progresses from 0% to 100%, where 100% is fatal. The “pawn” has an immune system, though, that also counts from 0% to 100%, where 100% is “immune” (which causes the flu’s progress to start counting down). So the disease is really a race between the two counters. By resting and consuming medicine, the “disease” counter’s rate of rise can be slowed, to the point where (ignoring all other possible factors), the “pawn” will gain immunity before the disease kills them. But as the flu’s “disease” counter rises, though, the disease itself has more and more impact on the “pawn,” adding pain, tiredness, lack of coordination, a foul mood, vomiting, and so on. These secondary effects (symptoms) themselves can cause other problems — a “pawn” who vomits while cooking can give other members of the colony food poisoning, for example, and a “pawn” with too foul a mood can have a mental break that causes them to stop responding to the player’s commands (like going to bed and resting).

But one of the main differences between RimWorld and what I wanted to make is that in RimWorld there is an assumption that the player wants to be awash in data and complexity and act upon it very specifically. There are a lot of numbers. With OR83, I wanted something that would have almost no visible numbers, but still make a lot of sense to a player, and allow them to be able to make choices based on the information they do have, without worrying about “gaming” the system underneath it. Which is tough, if you have a system (like RimWorld’s) where the numbers aren’t entirely intuitive (at least, they aren’t for me).

For OR83, what evolved out of all of this is really two systems. One is a generic system internally called the “check” system, which is what runs after any time has passed in-game. So if an event has occurred that caused 30 minutes to pass, that time is sent along to the “check” system, which then takes care of a number of time-based subsystems, like checking on whether the player or NPC is hungry-enough to eat, adding any accumulated radiation to their internal counters, checking if they need to sleep, and so on.

One of these systems that falls under the “check” system is the “conditions” system, which monitors the progress of different health or status conditions. Each of these “conditions” is a little code module that tracks how the condition should be changing over time. So, for example, the “food” system might determine that a certain amount of time has passed since the player last ate, and that it is an appropriate time of the day to eat again (so the player can ration food if they want, and not just continuously be snacking every time they get hungry), and if they have food to eat. If everything lines up correctly, they eat some amount of food and that resets their counter for having eaten. (There is more that can happen here — e.g., if you have set it to only eat half as much food, it might only reset it by half.) If they don’t have food, it adds a condition called “hungry” to the player’s internal state.

The “hungry” condition doesn’t do much at first, but can add a small status icon that indicates that the player (or NPC) is hungry. If the actual human player investigates the status of their character (or NPC), there will be a line of text that notes that they are hungry.

As more time goes by in-game, the “hungry” code updates its own internal counter. After it meets a certain threshold, “hungry” removes itself and adds “star” in its place. To be “starving” is much worse than being “hungry”: as it progresses, it goes through different “stages” that are taken from standard medical texts about the actual stages of starvation. Every time a new “stage” is reached (each “stage” is defined by some number of hours), a warning message is sent to the player that describes the sensations associated with the starvation. Additional variables, like a general “natural healing factor,” can be negatively impacted by different stages of “starving” (which can affect other health conditions). An NPC’s mood can be negatively affected, too, leading to other effects (if an NPC gets too low, they can do a variety of things, depending on how they are programmed, ranging from abandonment to, uh, murder).

And if “hungry” or “starving” detect that a player has eaten food, however, then they can remove themselves. But it’s all arbitrary code, so you can have a disease that, say, only removes itself after a certain amount of time, or never removes itself, or requires antibiotics, or randomly goes away, or even spreads to other NPCs in your group.

Rather than have some kind of hard cutoff for how a disease kills a player or NPC (a simple counter approach), OR83 uses an internal variable called “severity” that all conditions contribute to every time its “check” code is run. After all conditions have been “checked,” the “severity” contribution from all of them is summed, and is a number between 0 and 100. This is not a linear counter to death, but rather is a probabilistic measure of the odds of them dying on a given day. A severity of 0 always means that they have a 0% chance of dying, and a severity of 100 always means they have a 100% chance of dying, but the other probabilities are distributed on the basis of an exponential equation that uses a constant to determine the probability of death. With a “severity constant” of 10,000, for example, this is warped in a way so that until “severity” is equal to at least 50, the chance of death per day is effectively 0%. After that, the chance starts to rise: about 1% at 60; 3% at 70; 10% at 80; 32% at 90; 56% at 95, etc. With different constants, you have a different mapping:3

What I like about this exponential approach is that it seems like it reflects reality a bit better — you can have a lot of little things chipping away at someone, and they might die from the sum total of them, but the odds aren’t super high in any given day that this might occur. But if they are really suffering from either a major health problem, or a combination of factors, then that chance might rise. (And in the “check” function, this “probability per day” is of course translated into whatever unit of time is being “checked.”)

We’re still tweaking these numbers, but I appreciate (as a not-very-mathematical person) that with an equatin like this, you can jus change one constant to easily tweak the probabilities. So if it turns out that the health system feels unintuitive (goes from “nothing” to “dead” too quickly), the whole thing can be shifted as a whole, or individually for any given “condition.”

How this will all work out in the final version (or even beta version) remains to be seen, but the process of thinking through how to model all of this was very generative for me, and led to a framework that feels like it could lead to outcomes that would feel intuitive for a player, as well as giving enough flexibility and modularity that, as a programmer and designer, it can be adapted to all sorts of different outcomes.

Despite spending over 20 years thinking about nuclear weapons pretty much full-time, I have only had two “apocalypse” dreams that I can remember. One of them was not long after the 9/11 attacks, when I was still an undergraduate. At the time I was living in a “mother-in-law” unit attached to a house on a hill above the campus of the University of California, Berkeley. In retrospect, it was a somewhat eccentric and arguably anti-social living situation. It was within walking distance to campus, but the hill was so steep that it made for quite a hike, and the road was so narrow and winding that on the way up, one passed a large sign that warned that if a fire started in the hills, there would be no guarantee that any emergency aid could reach you. But it was intensely beautiful, had a panoramic view of the Bay, and was “natural” enough that deer and hummingbirds would pass by my entrance routinely, and, all-importantly at the time, I had managed to secure a lease on it for a reasonable rent, which was no mean feat even back in the early 2000s (and in retrospect, it feels like an impossible find).1

All of which is to just give some context to the dream, the climax of which I still remember vividly, in which I walk out of my little apartment, look across the Bay, and see a blood-red mushroom cloud rising over the city of San Francisco. And shortly after, I woke up.

Then and now, the “meaning” of the dream seemed pretty clear to me: clearly that sense of vulnerability that was created by 9/11 had seeped into my subconscious pretty deeply. This was during that early period after 9/11 when it still wasn’t clear if it was the beginning of something that was going to escalate or repeat, and when one felt that any large-enough city or landmark could be a target.

The other dream was more recent, only several months ago. In this dream, some kind of hellish disaster was unfolding. In retrospect, the dream seems like it was set in “dream San Francisco,” an impressionistic version of San Francisco that I sometimes dream about,2 and I was inside some sort of large building with many other people. It wasn’t at first clear what the disaster was: perhaps a massive earthquake, or some kind of nuclear detonation, or some other kind of massive attack. At this point in my life, I have been far more steeped in disaster response literature than I was during my first dream, so I had some idea of what I was “meant to do,” and, like the hero I sometimes dream myself to be, I was trying to help other people by giving instructions. So I was directing people towards what felt to me like safer places to hunker down and wait it out.

But then, at some point, it became clear to me that this was not any kind of normal disaster, but it was really some kind of extraterrestrial attack. Massive “spikes” were jutting out of the ground, destroying building in their wake, as explosions were going off all over the place and who-knows-what was raining down from the heavens. And I remember thinking, “well, I truly don’t have any guidance for what you’re supposed to do in this situation!” And then woke up.3

And while I’m not reading too much into that dream, I did think it was somewhat amusing. “Oh,” my dream conductor seemed to say, “you think you know what to do in the event of a major disaster? Well, what about THIS? What now, smart guy?”4 Fair enough!

Dreaming about doomsday is hardly a new thing. Lord Byron’s post-apocalyptic poem “Darkness” (1816) opens with the evocative line: “I had a dream, which was not all a dream.” Dreaming about apocalypses is so common that there is a small psychological literature on the subject. Mortimer Ostow, in his “The Interpretation of Apocalyptic Dreams” (1992), for example, discusses the idea (derived from Freud) that apocalypses are fundamentally “death and rebirth fantasies,” and suggests there is an “apocalypse pattern” to dreams that could be considered a clinical category of analysis.5

I don’t personally find Freudian dream analysis very compelling, especially when they get into specifics, but I do think there’s something to the idea that these kinds of themes are pretty well-ingrained in human culture and thus human minds, and so it’s not surprising that they show up the way they do. It’s not that radical of an idea that whatever the “grant anxiety” of your particular culture, that it would show up as a possible source of imagery in one’s own anxiety dreams.

One of the current systems in Oregon Road ‘83, the post-apocalyptic video game I have been working on with students for several years, is a “resting” system. The idea is that one cannot stay awake indefinitely, and must take some specific time to sleep. From a gameplay perspective, this introduces another factor of things to “keep track of,” hopefully not in an overwhelming way, and adds “stakes” to deciding when and where to rest, as some places may be better than others. Failing to rest can result in falling asleep at random while driving, which is a bad thing. And while sleeping, things could happen to you: you might wake up and find you have been robbed, as one unpleasant possibility.

Programming this system was not very difficult — it’s just a matter of keeping track of how many hours since you last slept, and coming up with a suitable model for how much sleep a person needs. When you have extended “over” your threshold time for being tired, there is basically a function which determines the odds that you could fall asleep at random; it is exponential in nature, so the odds start out quite low but after a certain amount of time, the chance of mishap approaches 100%.

But a message that simple says, “you are asleep” is not very compelling, by itself! So of course I felt the need to jazz it up a bit, with a little “eyelid” overlay that would close over the whole scene. And then, once that happens… what else? Well, of course, I thought, the player ought to dream.

But dream of what? Well, anyway. In the game, your character has survived a great disaster. Perhaps they will dream about that? Perhaps they will dream of the time before the war? Perhaps they will dream of those lost and gone? Perhaps they will dream of long-lost pets? Perhaps they will dream the kind of nonsense dreams that we all dream?

And so, in one of its most minor systems, there is a “Dream System” within Oregon Road ‘83, in which catalogues of dreams are kept in a small database (the evocatively named “dream pool”), and there is a small chance of any one of them being retrieved at any given time. It started as a very simple system, of course, but in the way of these things, it was built out somewhat. You can see a version of it in action above. Each “dream” generally consists of a short sentence or two, but it could be as complicated as one wants. Other events can add dreams to the “dream pool” (so one might dream of a narrow escape some time later), and one can have a recurrent dream that changes over time (the game keeps track of what dreams have been dreamed, so they can reference each other). The dreams do nothing more than contribute to the narrative (a bad or good dream cannot help or hurt you), although one can imagine using dreams as ways to act as unconscious signals (e.g., if you have recruited someone untrustworthy, perhaps that fact is revealed in a dream).

I’ve tried to keep all of the dreams in the game so far short and deliberately gnomic. It is well-known that most people find the dreams of other people uninteresting, and in the case of the game, I don’t want to “over-attribute” too much to the player character’s thoughts and backgrounds (so that the human player can “fill in the gaps” with whatever makes sense to them). But I’m also open to the idea that longer, more specific dreams might be interesting as part of the world-building experience.

What do you think you would dream about, if you were the survivor of an apocalypse? If you would like to actually contribute a dream idea to the game, I’ve made a little Google Form for just that purpose. All dream ideas will be read — they may or may not be used (or inspirations for other ideas). If you submit an idea, you are offering it up willingly and free, without expectation of authorship, ownership, or credit (but if I can, and if you want, I may find a way to credit you).

As I think the above makes a bit clear, I find dreams a very rich part of my life, even if I don’t attribute to them a lot of objective meaning. I find it a little interesting that I haven’t remembered more than two apocalyptic dreams (much less any truly post-apocalyptic ones), despite ingesting more than the usual amount of such things over the years. But perhaps that’s for the best…

In a nutshell, Oregon Road ‘83 is a video game in which you play as a survivor of a full-scale US-Soviet nuclear exchange in the fall of 1983. In the game, you are tasked with traveling from Independence, Missouri, to the Willamette Valley in Oregon, in the weeks after the war. In the process, you will need to find adequate resources to continue your journey (you have limited food and fuel), keep track of your radiation exposure (you have a Geiger counter and dosimeter), and navigate the roadways and cities of this new, damaged Western United States. You’ll meet people of different backgrounds and experiences, some of whom mean you well and some of whom mean you ill, and will have to make hard choices about how to spend your time, your resources, and what kinds of situations you are willing to get into.

The gameplay is half Oregon Trail and half Choose Your Own Adventure book. The world is, as much as I can do it, a “grounded” depiction of what I think such a world could have looked like, based on a reasonably plausible Soviet “war plan” and capabilities and what we know about the state of the US survival plans, but obviously there is a lot of room for interpretation as to what these things would mean in reality. By setting the game several weeks after the actual attack, we avoid a game that is just about the immediacy of The Day After, where the fallout radiation has decayed to less acutely-dangerous levels, but before any kind of “post-nuclear order” has really crystallized.

So that’s the premise. But why do this, at all? Why Oregon? Why 1983? Why anything?

The immediate idea for Oregon Road ‘83 came to me in 2015. N Square, an NGO that I had worked with for awhile, launched a video game design competition for games that would raise awareness about nuclear security issues. I thought it was an interesting challenge. How do you make a game about nuclear weapons that does not fall into the control fantasy? The most obvious approach, it seemed to me, was to make a game that was from the perspective of nuclear survivors, not nuclear war planners. There are, of course, some nuclear war survivor-based video games — notably the Fallout series, which I was very familiar with. But Fallout is deliberately silly and makes no attempt at accuracy, and as a consequence (for better or worse) has essentially no educational value that I could see.

What would a more grounded, realistic video game about the aftermath of a nuclear war look like? This was the line of thinking that started me on this path. What then game to mind for me was a joke I have been making for years when teaching about nuclear war and nuclear fallout. I’ve long been struck by this graphic from a 1990 FEMA report showing one hypothetical late-Cold-War fallout pattern:

When I teach with this, I use it to point out what the consequence of having so many dense missile fields in the midwest are for those who live downwind of them, as it was assumed these would be targeted by Soviet forces quite densely and with fallout-producing ground bursts. The above is of course based on somewhat speculative ideas about what the Soviets would target and how, and the report takes pains to point out that the fallout distribution would depend on a number of metrological conditions, including wind patterns. So it is just a “sample” pattern, as it says — not a definitive prediction, but something to give you a sense of the nature of fallout as a threat.

An obvious joke to make when looking at this image is to point out that clearly, the correct interpretation of this map is “move to Oregon,” as it is the only state that is totally untouched by fallout. Oregon does not, in fact, get off scot-free from FEMA’s hypothetical nuclear exchange, but benefits from the fact that the targets that FEMA believes it may have contained were few and far between, probably targeted by airbursts, and because of its location in the northwest, favorably disposed to avoid the fallout plume from Seattle.

This map came to mind when I was thinking about the game proposal. From there it was an easy and immediate jump to a game that was basically an adaptation of MECC’s Oregon Trail (1985) but for a post-nuclear world.

But which post-nuclear world? The post-nuclear world of 2015 would have looked very different from the post-nuclear world of the Cuban Missile Crisis (1962), for example: different targets, different capabilities, and a different America. Here is a similar sort of fallout map from 1963, as adapted from a Department of Defense graphic by the Saturday Evening Post:

This particular map is based on a very different set of targeting assumptions — a Soviet arsenal of very different composition, and a United States with no vast missile fields, yet. They also clearly assume (rightly or wrongly) that there would be far more surface bursts assumed than the FEMA map.

If one is basing a game on Oregon Trail, then it made aesthetic sense to base the game’s nuclear war in the 1980s as well, I reasoned. This also aligned very well with more historical considerations. The early 1980s was a period in which the US and Soviet Union were in a state of strategic parity, more or less. While a lot of people seem to imagine that the arms race was always a somewhat “matched” thing, the US had a huge nuclear advantage over the Soviet Union until the late 1970s, in terms of number of nukes and capability to deliver them. Whether this “matters” (if they can still nuke most of your major cities, what does it matter that you can also nuke their minor ones?) is a separate issue, but the point is that a nuclear war in the 1980s is probably as “bad as it gets” in terms of damage to the United States.

This was not lost on the people living at that time. Consequently, the early 1980s in particular was a renaissance of sorts for cultural productions about or containing nuclear war: The Day After (1983), WarGames (1983), Threads (1984), Testament (1983), Terminator (1984), to just name some of the more iconic films. 1983 is when the idea of “Nuclear Winter” was first published (in Parade magazine, of all places); it is was when a West German pop song about an accidental nuclear war, caused by a faulty early warning system, could reach the top 10 internationally. It was when “Survivalism” — the predecessor to modern “Preppers” — hit its peak.1 Some of the largest public protests of all time took place against nuclear weapons in the United States and in Europe, because of the perceived threat of imminent nuclear war.

It was also a very dangerous period, historically. Historians today tend to consider 1983 one of the “close call” periods for the possibility of nuclear conflict, ranked perhaps just underneath the Cuban Missile Crisis. The conditions were tense, and the technologies and organizations underneath it all (on both sides) were error-prone. The Soviets feared that the US might have the capability for a decapitating nuclear attack that would preclude any attempt at retaliation, and (to debatable degrees) were worried that Reagan intended to do such a thing. They built a massive, deliberately hair-trigger nuclear arsenal, and kept a finger hovering over the metaphorical button. They scoured not only the skies, but newspapers and stock prices and other complicated sets of data, for signs that the US was preparing to make a move.

The US was seemingly oblivious of the seriousness of their concern, and did many thing that encouraged these fears, like deploying fast, accurate Pershing II missiles in West Germany (which the Soviets feared could target Moscow), and conducting a large-scale, more-realistic-than-usual NATO exercise simulating what they would do if they were initiating a nuclear attack against the Soviets. Against this backdrop, “normal accidents” happened: a Soviet early warning system thought sunlight reflecting off clouds were incoming missiles; after repeat airspace incursions by US military planes, the Soviets accidentally shot down a South Korean civilian airliner.2

One can (and some people do) debate how “close” any of this came to war, but my own sense is that it certainly came closer than most people realize, and that it is very easy to imagine a world in which nuclear war was precipitated in this period. There are, I think, deep historical lessons from this period about the nature of risk of nuclear war, about the dangers of raising tensions to a fever pitch in a world of sufficient complexity, whose technological capabilities and limitations were both extreme — missiles whose flight times were measured in minutes, but for whom detection of launch was fraught with false positives on both sides.

So, to return to the game, setting a post-nuclear apocalypse game in 1983, based on a game that came out in 1985 (Oregon Trail), seemed to me like a pretty natural thing. Setting it in the early 1980s would give me a lot to “work with” in every respect. It also added a little historical distance from the present, which felt useful. It could be retro but still relevant. As an educational tool, it could do a lot of potential “work,” both as a work of “history” (even if it was a form of counterfactual history, the nuclear war that did not happen) and as something that was oriented around the realities of nuclear weapons and their effects. There would be no giant radioactive ants, no super-mutants, no people living in fallout shelters for centuries, etc. This would be as “grounded” as one could try to make it, at least within the limits of my imagination and my judgments of what was plausible, as someone who studies this stuff for a living.

So that was the pitch. I called it Oregon Road as a deliberate homage to Oregon Trail and Cormac McCarthy’s The Road. I later added the ‘83 because it coded its retro-nature better, and made it slightly more intriguing on the face of it.

But my pitch didn’t get funded. It got an honorable mention, which I did appreciate. I did not take it hard; I was busy enough, and the fun part was thinking it over and writing it up. In retrospect, I’m very glad that it didn’t get funded, because the game I proposed would have taken a lot longer to make than was plausible, and would have been much more limited than the game I have been actually making. There is no way that the game company N Square had contracted with (who would have had to, you know, finish on a deadline and pay employees) would be able to build out what I had in mind in the time they were willing to commit to it. If it had been completed at all, it would have been massively truncated and of much lesser value and interest.

But the idea for the game stuck in my brain for several years. Over that time, I read more about game development, made connections with people in the educational-games “world” (like Games for Change), co-taught a course with the dubious title “Video Games for Civil Defense” with a game designer, watched about a zillion “game design” YouTube videos of varying quality, and started a couple other, smaller-scale game projects which did not get beyond the initial planning/proof of concept stages, but allowed me to get my feet wet, as they say, in what is involved actually making a game and the often quite organizational difficulties in coordinating the different kinds of work involved.

My university has a couple extremely “honors” programs that are essentially meant to lure high-performing students to enroll here and not elsewhere. Among the “perks” they get is a stipend to work with professors on research projects over the summer. The professors gets nothing but the students’ labor (and we are not paid in the summers by default), but I’ve been hosting such projects for years because, unlike grants from other parties, it allows me to employ students to do weird, exploratory, and otherwise “risky” endeavors. The honors program doesn’t really care about any “deliverables,” they just care about the student having an interesting and hopefully enriching experience, so if we set ambitious goals and don’t meet them, it doesn’t really matter most of the time. Many of the projects I’ve started with these kinds of summer projects eventually evolve into later, externally funded projects, because they give me the opportunity to explore the “space” of something before committing to it. And even those that appear to come to “nothing” often turn out to be useful experience later, or at least help me rule out some idea as impractical.3

During COVID, all of these research programs went online and remote. I had the realization that a video game project could be an ideal remote summer research project. Video game development requires a lot of different skills which have to interact and come together: overall game design, writing, artwork, programming, music and sound, and, in the case of this kind of game, research. Give me an enthusiastic student, of any background or skill set, and I can find something for them to do on such a project. Most of the individual work is remote anyway, and coordinated through things like shared drives, Github, and so on. Meetings on Zoom are a drag, but we’d gotten used to them.

So each summer, starting in 2021, I’ve had groups of students, of various sizes, working on the game. It’s gone through a number of key changes, in terms of its technical backend, its gameplay, its story, etc., which will be subject of future posts. Most of this has been funded through my university’s Pinnacle and Clark honors’ programs, but the Outrider Foundation also provided some funds to give me a little more flexibility in hiring students.

We’re very close to a playable alpha — if you’re interested in playing it, just stay tuned here, as we are getting close to a dedicated game website where people can enroll to try it out. The exact timeline is as appropriately squishy as you would imagine from something that is very much an amateur labor of love, but it’s happening, it’s happening. If it wasn’t, I would be keeping quiet about it!

So why do this? This isn’t a traditional work of academic history, obviously. I do a lot of things other than what counts as traditional works of academic history, of course. And I am tenured, so I can do anything, or nothing. I’ve learned a lot of “traditional academic history” things in the process of working on this, to be sure. I am also interested in games as a form of education, as noted. But it’s also scratching a creative itch for me. It’s a project that is at a fascinating midpoint between fiction and non-fiction, a historical world that didn’t exist, but could have. I struggle to articulate what it is that feels so special and unusual about working that space, and how different it is from, say, writing works of non-fiction (which are, to be sure, also works of creativity). It’s a fun challenge — even if it involves creating a very un-fun world.

In its most basic form, Oregon Road ‘83 is a game that tries to think through and simulate the experience of a full-scale nuclear war. You can think of it as one part Oregon Trail and one part Choose Your Own Adventure book, set after a full-scale nuclear exchange between the Soviet Union and the United States in 1983. In other posts, I’ll explain more about the different aspects of the game and its inspiration (like “why 1983?” and “why a video game?” and “what does this even look like in practice?”).

But to get the ball rolling: in the game, you, the player, are traveling from Independence, Missouri, to the Willamette Valley, Oregon, a week or two after the war has taken place. (You have your reasons.) Along the way, you will need to find and procure adequate food and fuel. Depending on the route you take, this will require traveling through several thousand miles of a recently-devastated country, in which a huge fraction of the population was recently killed, and which is going to likely be still experiencing a total breakdown in every aspect of modern society.

What would that look like? That is the challenge of the imagining the game. One can imagine different “poles” of possibilities, ranging from the Civil Defense planners’ dream (an orderly return to national unity) to your Cormac McCarthyian nightmare (roaming gangs of cannibals). The world of the game exists somewhere in between these two extremes.

In future posts I will describe the various “models” that go into the underlying structure of the game, including our “target set” (what got nuked, with what kind of nuke), the fallout model, the resources (food and fuel), weather and climate, even the model of travel impassability. One of the things I’ve found most stimulating about the game, personally, is that in trying to make it plausibly “grounded,” it has forced me to examine a lot of details that are typically overlooked in thinking about nuclear war, but to do so at a very “functional” scale. I’m not trying to do a perfect simulation, but I need something that is “good enough” for the kind of game I am making. The level of complexity needs to be enough to be useful and nuanced, but also simple-enough that it is neither ruinous to try to implement it, nor so overly complicated that a player would find it taxing to understand.

As a basic example of this, one of the questions I’ve spent a lot of time contemplating is: What is the fate of an individual city within this world? Most people tend to assume that all cities would be instantly glassified, but this is not a very realistic assumption, just based on the capabilities of the weapons or what they would be aimed at.

In some parts of the country, a model of “totally destroyed, totally ruined” applies to large metro areas, for sure. Look, as just an example, of how FEMA conceptualized the possible nuclear attack threat to the New York City metro area in 1990:1

Now, one could get into what exactly this is meant to represent, and whether it is in any sense “accurate,” but the basic point has been made, I think. If you want to consider the above “totally destroyed, no hope for survival,” I’m not going to contest it. This is one of several reasons why game of this sort set in the Northeast would be very different from one set in the West.

Here is FEMA’s overall target map of the country for their 1990 report:

I’ll write more about this particular FEMA report — its origins, assumptions, issues, etc. — in the future. I don’t take it as gospel, at all. But I’ve found it very useful as a way to conceptualize how US emergency planners thought about what a full-scale nuclear attack against the United States during the late Cold War might look like.

For example, a few salient features from the map above jump out:

1. You have some regions, like the Northeast, where the concentration of urban targets is incredibly, almost unimaginably dense. E.g., the Boston-NYC-Washington corridor, the industrial centers of the Great Lakes regions, the major coastal regions of California, and the Gulf Coast cities.

2. There are also a few zones of dense targeting in the center of the country. These are ICBM fields, where the FEMA assumption was (rightly or wrongly) that individual missile silos and their launch control centers would be targeted by the Soviets in an attempt to possibly preempt the US ability to retaliate. In the above image, there are six such bases; in 1983, when the game is set, there would be additional Titan II bases. The FEMA model assumes quite explicitly that these would all be surface bursts, targeting hardened silos, and so would necessarily create a lot of fallout. They give a “sample radioactive fallout pattern” which makes this quite clear:

3. While the number of possible targets is very high, there are also a lot of places that are not targeted. FEMA did not think (again, rightly or wrongly) that the Soviets were trying to target every city in the country. Most major metropolitan areas are targeted in the FEMA model, either directly or because they contain other “strategic” targets within them. But there are many small and mid-sized cities that would not be directly targeted.

Even large cities that would be directly targeted in such an attack would not be 100% destroyed. There would be survivors, to greater and lesser extents depending on the circumstances (area of the city, population of the city, number of weapons targeted at it, yield of weapons targeted at it, location of ground zeros, etc.). I say this not to underplay what the horrors would be. At Hiroshima, around 25-50% of the population were immediately killed or injured by the atomic bomb, depending on the estimates one goes with of pre-attack population and numbers of dead, and that was more than enough to make it a hell on Earth. But there were survivors, and it is their stories that we tell. For a game that is trying to model the state of survivors after a nuclear war, this is important to keep in mind.

For Oregon Road ‘83, I wanted to come up with a pretty simple model for thinking about how the fate of any given city in our targeting scenario would translate into conditions in the city a few days-to-weeks after the attack. In particular, how this would impact resource availability, particularly the two resources we are having the player track during the game: food and fuel (gasoline).2 The area the player will be capable of traversing through in the game is approximately this part of the map:

Because one is primarily taking highways, one will be forced to pass through or near a lot of cities. Some of them will have been directly targeted, some of them will not have been. Some of them will have been in the path of significant amounts of fallout, some of them will not have been.

So as a very rough model for thinking about the fate of these cities, I came up with the following metric.

Each city in the game has a population and a population_density variable, from which a rough area can also be derived. These are derived from the 1980 census and reflect its pre-war state.

The game has a “target model” within it of every nuclear detonation that we are imagining took place in our hypothetical war, meticulously plotted on the map. Because we also have a sense of the city’s size (from the area variable), we can use the number of weapons in or in close-proximity to the city to derive a damage_level, which reflects the direct physical (blast, fire) damage to the city during the war. Right now, this is very simple:

• 0 = No nuclear weapon went off in or near this city.

• 1 = Very few weapons went off near the outskirts of the city, and the city was of sufficient size that we would expect only part of it to be damaged, with the other parts being essentially functional. People might reasonably ask, is this even possible, to have “minor” damage from a nuclear weapon? It depends on the size of the city, the size of the weapon, and the target of the weapon.

• 2 = One or two nuclear weapons went off in the central area of the city, and the city’s area is small enough relative to the size of these weapons that mass destruction would be expected. Or, the city is quite large, but sustained multiple nuclear detonations throughout it.3

You can think of this, clearly, as “no damage,” “low damage,” “high damage.”

There is also a separate variable, fallout_level, which tracks the amount of radioactive fallout the city would be expected to have received. This is derived from out fallout model (which I will describe in a future post), which itself is derived from attack model. Our city model takes the raw fallout intensity calculations and, as with damage, simplifies them down to a simple scale:

• 0 = No significant fallout. By “significant” we mean “likely to have had, or have, significant, acute health impacts.” So we are imagining that this place had a total exposure dose < 100 rem.4 This is a somewhat arbitrary cutoff, but 100 rem is around the area where people who did not have adequate shelter would suffer from radiation sickness, but probably not die, so for areas less than this we would not expect widespread, immediate health impacts from fallout.5

• 1 = Some significant fallout. The people in such areas would have possibly gotten sick if they did not take adequate shelter. Some may have died, but not a lot. We are imagining a place where the total exposure dose was >=100 rem and <=500 rem. Again, these cutoffs are recognized as somewhat arbitrary.

• 2 = Considerable fallout. If the people in this place did not take shelter adequately, most of them will be either dead, dying, or sick. Total exposure dose >=500 rem and <=1000 rem.

• 3 = Extreme levels of fallout. Even with shelters (of the sort built by and available to civilians), the radiation levels are high enough that illness is likely and death is possible. Without shelter, death is inevitable and probably has already occurred. Total exposure dose >=1000 rem.

So the state of a given city is reflected in the combination of these two variables, damage_level and fallout_level. They are not necessarily correlated. Consider this detail from the Missouri map from the FEMA report:

Kansas City would clearly have a damage_level of 2. Lots of targets in and near it. But what is its fallout_level? If those weapons targeting it are airbursts, then they might not be generating much fallout directly. But if Kansas City is downwind of surface bursts, then it might be a problem.

Consider, as well, the differences between Columbia and Jefferson City. Jefferson City is a pretty small place (a population of around 10,000 in 1980), but had something in it that FEMA thought might be a target. (In this case, I suspect it is either its airport or national guard base that FEMA thought would be a target, here.) Jefferson City is probably small-enough that any nuke is going to put it into the damage_level of 2, but we could imagine larger cities with a similar sort of target on the outskirts that might have a damage_level of 1.

Columbia, in FEMA’s model, is not targeted at all.6 So it would have a damage_level of 0. It had a population of around 60,000 in 1980, and so would have significantly more people than Jefferson City.

But both Jefferson City and Columbia are extremely downwind of those silo-targeting nukes to their west, at Whiteman Air Force Base, so it’s easy to imagine that their fallout_level would both be in the 3 (extreme) territory.

So how would these three different cities vary in their outcomes? Let’s start with the smaller cities. Jefferson City would suffer a lot of physical damage for its size, and also extreme fallout. I would assume very few of its population survived the combination of the two. I also would expect that its small size probably meant that any “reservoirs” of resources (markets, gas stations, etc.) probably were destroyed, as it didn’t have that many of them to begin with. So if the player were to visit Jefferson City, they would find it pretty “dead,” and pretty “empty.”7

Columbia, on the other hand, is unscathed from direct damage. But it has suffered heavy fallout. How many of its 60,000 residents had adequate shelter available to them, and properly took it? This is a complicated question, and I’ll come back to it when I write about our fallout model, but my personal guess is not that many. If that were true, Columbia would be pretty “dead” but — and this is important — not “empty,” in terms of resources. Its markets and gas stations might be relatively “full,” because the starting capacity was relatively high, did not get physically destroyed by the attack, and might not have that many “consumers” in the days after the attack… because the area would be acutely dangerous to anyone trying to “consume” such things in that time.

The Kansas City metro area had a much larger starting population and area than the others, at over 1 million people in 1980. Its damage_level would be extreme, however. Let’s just imagine, for the sake of argument, that 80% of the population was killed by the attack within the first week. That would leave around 200,000 people in the KC metro area — still quite a lot. The physical damage would be extensive enough to destroy a lot of the stored food and fuel sources. Our model would assume, however, that the starting amounts of both (pre-war) were pretty high. But with that much damaged supply, if the fallout exposure was not acutely dangerous, one would expect the number of resource “consumers” in the area to be pretty high. Thus by the time our player arrives, the total available resources would be pretty low.

Thus we end up with a somewhat nuanced, but still not too complicated, model for thinking about the fates of cities. There are interesting and somewhat unintuitive consequences for this model, ones that are present in some of the more fine-grained government studies of nuclear war. For example, consider a city with a damage_level of 0 and a fallout_level of 0. One would think this would be an ideal situation, totally unscathed, right? Except that we are assuming in our model that food and fuel supply logistics were totally disrupted by the attack, so this is a place where the number of resource “consumers” would be very high. So this is where starvation and deprivation are going to be the worst, and from our player’s point of view, perhaps the most dangerous kind of place to pass through.

Of course, this underlying model will be hidden from the player. But the goal is that its impacts on the “world” can be conveyed in numerous ways (through experience, through conversations with survivors, etc.) that will be discovered through play. Because ultimately, the goal here is not to create a simulation for its own sake, but to create a game that can, through intuitive play, lead to deeper and more concrete imagining of what a nuclear war would really do. Because aside from being untrue and overly simplistic, the “everything would end in a flash” model that most people tend to have in mind is an active inhibitor, I believe, for taking seriously the weapons, the possibility of their use, and the consequences of their use.

The game is still in active development — we are pushing this summer to have it ready for a state where we are able to open it up to some early players within the next few months — and so the above is still subject to change. If you have thoughts on it, let me know.