Advent of Computing - Episode 139 - HUTSPIEL

Episode Date: September 15, 2024

The early history of computer games is messy, weird, and surprising. This episode we are looking at HUTSPIEL, perhaps one of the oldest games ever played on a computer. It's a wargame developed to simulate nuclear conflict... and it's 100% analog. Join us as we find out just what tax dollars were being used for in 1955. Selected Sources: https://archive.org/details/hutspiel-a-theater-war-game - The HUTSPIEL paper  

On July 8th, 1955, the Soviet Union launched a daring surprise attack into West Germany. Contact with the NATO-held sections of Berlin were immediately lost. The first wave of troops and armor columns went almost entirely unopposed. Soviet forces swept the German countryside in a single day. NATO was taken completely off guard. The engagement was totally lopsided, with the Soviet troops outnumbering NATO forces two to one. Their advance was only halted when they reached their first natural barrier, the Rhine River. That's when NATO was able to mount a counterattack.

It's also when the atomic bombs started to fall. At least, that's one possible and planned-for scenario. When it comes to warfare, nation-states tend to have a countless number of plans and scenarios schemed out. It could be a simple matter. The greatest military minds in each country just get together and put their worst fears and maybe even their best countermeasures down on paper. That's a really sterile and easy to understand picture. The reality, though, involves a lot more horsing around than you may think. Allow me to introduce the war game. These are, as the name suggests, games. They range from simple to devilishly complex. They're also the historic origins of tabletop roleplaying games like Dungeons & Dragons,

if you can believe it. The scenario I presented, with some dramatic flourish, is the starting point for one such game. That game was called Hutspiel. It was designed in the very bowels of the military-industrial complex, paid for by the taxpayer, and was one of the first games ever played on a computer. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 139, Hutspiel.

Long-time listeners may know that I tend to work in long chains of thought. The saga continues, as it were. I get into these weird ruts where one episode leads me to some tangential source that I use as the scenario for the next episode, and so on. So, that's kind of what's happened this time. Allow me to explain. Last episode, we were looking at type-in programs. That, inevitably, led to the discussion of type-in games. That led me into the archives looking for discussion of computer games prior to 1964. That may sound oddly specific and probably clues you into part of my process here. I was trying to find sources about games prior to the creation of BASIC, and then to see if those sources had source code. Now, I'll be the first to admit, I don't know everything about

the history of computing. That's why I find the study so interesting. If I knew everything, it would be a pretty boring field. But that said, I like to think I know the broad strokes. Let's just quickly go over the history of the computer game. I think that's fair enough, right? We all know that. In 1962, Space Force starts running on a PDP-1 at MIT. That's usually cited as the first video game, but that's not entirely accurate. There are some earlier Pong-like games kicking around in a few different labs. There are some special-purpose NIMH and Tic-Tac-Toe machines that existed way back in the 1940s. Then we have business games. During the 1950s, there were a number of these weird business-themed games that were played on mainframes and actually used to groom and train

executives. Now, I thought that was just about the entirety of the story. The early days are a little fuzzy, there is some debate over what's actually a video game, but there's not some huge part of the story that I'm missing, right? I figured that my search for pre-basic games was going to be routine. I'd find some papers on business games at best, scan for some code, and call it a job well done. Nice little background research for a paragraph or two. But once again, I was proven very wrong. It turns out I was wrong about business games, and I was missing a whole genre. First off, business games were a much more established tradition than I first assumed. There are actually entire books about

the effectiveness and analysis of these games. That points to a thriving field, and that's something that I need to carve out some time to read and learn about. Second was the missing genre, war games. I really have no right to have missed this, and I don't know how I did. Aaron Reid, the author of 50 Years of Text Games, both the blog and the book, has a whole entry about one of these games. of text games, both the blog and the book, has a whole entry about one of these games. I've even had him on the show and talked about weird early games. So either I just missed that post, didn't see that in the beginning of his book, or somehow it just slid off my gray matter. What better time to rectify that omission than right now? Today we're going to be jumping into the world of simulation games. Specifically, we're going to be jumping into the world of simulation games.

Specifically, we're going to be looking at one specific war game called Hutspiel, and how that fits into the larger picture of war and simulation gaming. How does that connect to computer games in general? Is this a missing ancestor that we need to pay more attention to? Or is this a tradition that's totally isolated from modern games? And along the way, I really want to look at the specifics, because Hootspiel, as it turns out, is a very, very bizarre beast. It's likely that humans have been playing war games as long as we've been prosecuting acts of war. Both playfulness and violence are pretty core to the human experience, for better or worse. So,

this stuff goes way back. Roger Smith, US Army PEO for Simulation Training and Instrumentation, speculates that cavemen were probably simulating warfare with piles of sand and rocks back in the day. Once we reach the era of record-keeping, we start to see the emergence of games like Go, Chess, and their early predecessors. Even at the earliest epochs, these games served three purposes. Entertainment, education, and research. Games in all forms are fun. At least, that's the goal. I know I've ran into many games that aren't too enjoyable, but fun is part of the point. It's clear to see how a game of strategy can be fun. There's a reason folk have been playing Go for thousands of years. The education aspect here is slightly more abstract.

A strategy game can be thought of as a model. Here I mean a mathematical or conceptual model, not little figures you paint. You use rules and interactions to model something in the real world. For Go, for instance, you're modeling encirclement of armies or movements of troops. The model in this case is very abstract. You're just placing tiles on a board, but there is this connection to reality. A game like Go can be used to teach about strategy within that model, and then how that strategy can be applied to the real world. As you learn to play Go, you learn, in abstract, how a group can be applied to the real world. As you learn to play Go, you learn, in abstract, how a group can be encircled, and how an opponent may attempt to prevent that encirclement. The player builds up

a mental model of how to approach different strategies. Hence, there's a didactic value. As for research, well, that is yet more abstract. This involves trying to figure out something new from the model, then applying that discovery to the real world. Maybe you play a million games of Go and start to realize there's a certain way to turn a flank that's particularly effective. Then you go out and you use that on the battlefield to great success. That's the basic idea, but we're going to be getting back to the research aspect of models as we move on. Okay, we're about eight minutes in, and I think that's the right time to introduce the word of the day.

And it is abstraction. When you hear that word, scream. Abstraction is why war games are valuable, and also where they run into issues. You can't really model an entire war. You'd have to find some way to model combat with realistic units, the random chance of weather and geologic events, even whole economies and how propaganda could affect the industrial output of certain sectors within a country. To do so would require a truly huge amount of data, a huge amount of time, and would probably become so complex as to spawn its own non-simulated conflicts.

So we turn to models, and we turn to abstraction. It's possible to work up a model that's close enough to simulate real-world events, or to restrict a model to just one small aspect of the real world. Maybe you're only concerned with how tanks travel under specific terrain conditions, or how rail systems can be affected by aerial bombardment. So you take your specific area of interest, figure out what about that can be modeled, you assign some values, do some math, and you work out from there. The big downside is that models will always have some inherent error. You can't capture everything. Sometimes your assumptions and decisions aren't true to life. You just make mistakes, or you have misconceptions. Or maybe you just put in bad data way at the beginning of your project.

The upsides, however, are well worth this danger. How do you train military units without exposing them to an actual conflict? How do you teach commanders how to command troops if there are no conflicts to play out? By pulling out these models, militaries can get some of the benefits of experience without any of the risk and at much less expense. There's also an aspect of time compression to consider. Using war games, a new commander could be exposed to hundreds of simulated battles in the course of a year, or maybe even a few months depending on the technology at play. That wouldn't be very possible in real life, especially during peacetime. As I said, us humans have a long history with

these kinds of games. But to summarize, things change in the early 19th century when Prussian army officers and rich boys invent dungeons and dragons. To be clear, I'm only joking a little bit here, actually. For this, I'm pulling heavily from Peter Perla's The Art of Wargaming. Also, to be clear, this source specifically focuses on the tradition of wargaming in Europe. So, caveats as always. in Europe. So, caveats as always. There were some attempts to adapt existing games to war simulations as early as the late 18th century. This is mainly centered around Prussia, one of the states that would eventually become part of Germany. These attempts all started from the same place, chess. The goal was to create a more realistic game model. This was done in, initially, pretty simplistic ways, expanding the game board, including terrain and adding

different types of playing pieces to represent different military units. The largest disadvantage to this approach, as explained by Perla, comes down to movement. The astute among you may have noticed that a chessboard isn't very true to real life. When you move, you don't consider the larger grid of the universe and then measure your movement in terms of the unit length of those grid spaces. This is one of those abstractions that makes a model more simple, but at the same time it makes a model less realistic. That said, this is a very discrete approach. You have set spaces you can occupy, a set number of spaces in the universe, and you can only move around in nice round numbers. Keep track of this. These kinds of discrete models, while unrealistic, are really easy to digitize. Computers actually do look at

the world in terms of some universal grid of evenly sized spaces, and do, in fact, move things around in some smallest unit of size. A shift occurred in the 1820s. The name of that shift was Kriegspiel, which translates to literally mean war game. Not an inventive name, so already we're in the proper lineage of computer things. The game was first devised by the elder von Riesewitz, and then revised by his son, the younger von Riesewitz. Kriegspiel was intended to be a much more realistic model than earlier games. To that end, it dropped the entire notion of a grid. Games were played on real-scale maps with real terrain features and full freedom of movement. Units were also made more realistic.

Instead of chess pieces, each unit was represented by a small box of the approximate correct size, all scaled to the map. So a unit of infantry would be smaller than a unit of cavalry, and so on. Also to note, each piece now represented an aggregate. When I say unit here, I mean a military unit composed of multiple folk or horses or pieces of equipment. This is also where we're introduced to the umpire, or in more modern language, the game master or dungeon master. In Kriegspiel, the umpire served as an intermediary between the players and the game world, or

the model. This is actually a huge innovation in the space. You see, players never touch their units. They don't interact with the map directly. That's not very realistic. Instead, they give orders to the umpire, who then interprets those orders according to the game's rules. Then the umpire actually moves their units. This deals with mistakes such as nonsense instructions. A player could mess up and instruct a unit to move in some impossible way. Scale a cliff, walk on water, that sort of thing.

The umpire is supposed to interpret orders as if they were a real military unit on the ground in the real world. So, if a player tells the umpire that a unit has to scale a cliff, the umpire might decide that that unit would stop and look around for an alternative route. The umpire could also deal with information that players wouldn't normally have access to. Secrets could be kept between players. This meant that surprise attacks could actually be simulated. The umpire could move around screens to determine what each player could actually see on the map, or choose to not even represent certain units on the visible map.

The umpire was also in charge of combat encounters, another innovation of Kriegsspiel. These encounters were semi-randomized and used a special set of these wild dice to determine damage. As an aside, the dice really are strange. They had different custom dice for different units and engagements. Each face had a table on it that accounted for unit strengths, different attacks, and so on. So when you roll a die, you actually consult a little physical table to decide the outcome. The idea here was that a commander wouldn't necessarily know every little detail of every combat encounter in the theater. It also hid the details of the model, so the players would focus on command decisions and not try to optimize around their plays and dice rolls. In modern gaming language, we'd say the umpire is partly there to limit

metagaming. The gameplay loop here should be immediately familiar to anyone who's played a tabletop game. The umpire introduces the scenario to the players. Scenarios are pretty flexible. One game could be a simple skirmish between forces, another may be a simulated siege, or an attack to capture some salient. From there, the game breaks into rounds. Each round simulates two minutes of real time, during which each player writes down their orders on slips of paper and passes those slips silently to the umpire. The umpire reads orders, updates the game board, and passes back any important information to players. From there, gameplay loops back and a new round begins. The game became a huge success.

Here is one review from one General Von Muffling of the Prussian army. This quote comes to us by way of Perla. Quote, the execution of good plans on realistic terrain and the ability which the game offers of presenting a multiplicity of situations makes it continually instructive. I will gladly by all means in my, assist in seeing the number of available copies augmented. If the First Lieutenant von Reiswitz has already found reward for his efforts through the approval of the Prince of the Royal Household, the Army War Ministry, and high-ranking officers who have come to know his efforts, the further distribution and knowledge of the game learned him the thanks of the whole army, end quote. Needless to say, folk really liked Kriegsspiel. In short order, Prussian

officers were, in some cases by mandate, playing and training with this game. It became a pastime and a tool. Over the middle of the 19th century, its rules were revised, updated, and expanded, and its use became truly widespread. Just to give an idea of how ubiquitous Kriegspiel became, the Schlieffen Plan was formulated and tested using this game. Or, at least, using versions of this game. So it becomes a big deal. World War I plays out how it does because of Kriegspiel. Let's take a step back and look through our digital lens. Kriegspiel does break out of the rigid discrete grid of earlier games. Units each have a maximum distance they can move each turn. And that distance, you know, you can pick anywhere along that maximum line.

That's a very analog thing. It's even measured with these little rulers. But don't be fooled. There's still something very digital at the heart of Kriegspiel. That is, the turn structure. Turns are discrete. They simulate a set amount of time. We can put this another way.

Kriegspiel uses discrete time steps in its simulation model. The gameplay loop is almost the exact same type of loop in a simulation program. You take inputs, calculate the state of the next step, and then produce outputs about that new state. Then you loop that and do it over and over again. The details are also very digital. Troops have specific numbers and groupings. Damage is simulated as an integer value. Units have hit points counted as an even integer. You even have things like hidden variables and public data, all managed thanks to the umpire.

You may even choose to look at the umpire as one of those early human computers that we talk so much about. So the jump to digital here should be clear, right? Well, that's where things get interesting. We should know what happens with abstraction as soon as computers roll along. In the 1950s, the Operations Research Office at John Hopkins University started a new project. They were trying to simulate what a land war in Europe would look like. Luckily, there was some data close at hand, but it was about 10 years old. Times had changed since World War II.

A new border had formed between NATO and the USSR. Nuclear arms were now on both sides of that border. And there's this whole thing going on in Korea to consider. It wasn't really practical for the Air Force to just drop a bunch of bombs in East Germany and measure the damage. The solution dreamt up at the ORO was a game called Hutzpiel. ORO was one of those private research outfits funded by public money. In this case, its benefactor was the Department of the Army. Grants flowed in, reports flowed out. Specifically, ORO was focused on operations research.

This is a field of study that's attempting to find the best strategies for managing resources and planning. It's all about strategy and the analytical aspect of strategy especially. It's also called management science. So there's this weird overlap here between war and business. This was initially going to be the part where I just said the ORO did some simulation work in the early part of the 50s and that leads to Hudspiel. That's about all we get from secondary sources. But hey, you know me. I got a screw loose or something. I had extra time over the weekend, and I had a bit of a lead.

So I sat down with a whole pot of coffee and started going down the rabbit hole. In the early 60s, ORO is reformed into the Research Analysis Corporation, or RAC. A pile of papers from RAC were declassified in the 1990s. A pile of papers from RAC were declassified in the 1990s. If you know where to look, you can surf these old documents. At least, many of them. That helped me put together a weird story. So, to start this off, what exactly was ORO doing in the lead-up to Hutspiel?

Well, it is classically spooky stuff, and I mean that in the federal sense. We can pull this together from summary reports on ORO's projects in the early 50s. This period also coincides with the Korean War. So many of the projects at ORO were concerned with that conflict or trying to draw larger conclusions from data gathered during that conflict. Like I said, I'm working off this big summary document that lists every project that ORO was working at in the early 50s, up to 53. It has codenames, mission statements, statuses, and any reports published under that project, plus a list of who was working on that project. Thus, it's one of those great documents for trying to tie things together and hunt for leads. Their projects in this period

fell into four main categories that I can make a heads or tails of. The first was analysis of military personnel and tactics. These reports are on everything from integration of troops to the effectiveness of helmets and body armor on troop movement and survivability. It turns out that yes, troops should be integrated, and yes, you should wear a helmet, it protects you from being shot. The second broad category was weaponry. We're talking accuracy and effectiveness of guns and missiles, studies of how effective weapons were being used, and logistics. This actually included some computational modeling. ORO at least worked up models of anti-aircraft guns and vehicle formations over terrain. There's probably also more here if you took the time to follow leads and find the classified reports that are referenced in these documents.

We also get a few long-running projects on psychological warfare and propaganda. This, from report titles alone, is the kind of stuff that should make your hair curl a little bit. a little bit. We're talking things like, to quote report titles, lessons on morale to be drawn from effects of strategic bombing on Germany, or a memorandum on terror and panic focusing upon inducement and reinforcement, and the ominously short air casting. Like I said, ORO is doing legitimately spooky stuff. This is the dark part of the military-industrial complex. The fourth category, and the one that will matter the most for us today, is nuclear warfare. These reports are a little different because they aren't working with real data.

Rather, they rely on war games, simulations, and field exercises. These nuclear arms projects are important to the story because that's where the folk that develop Hutzpiel come from. At least, the ones I can track down. The report that describes Hutzpiel has five listed authors. I've been able to identify three of those authors in other sources. All are connected to atomic weapons projects. The easiest to find here is Nicholas Smith. And I know that might be surprising with such a generic name,

but he was actually an old hand on the Manhattan Project. So it's easy to track him down. Old Nick Smith was a latecomer to the Manhattan Project. During World War II, he was working as a physics researcher at John Hopkins. He didn't start working on nuclear anything until he joined Oak Ridge in 1946. While there, he studied the effects of nuclear fallout. He worked on one of the first projects that figured out just exactly how much of a risk fallout could be globally. In 1952, he jumped over to ORO and started his career in operations research. Notably, he actually shows up in the acknowledgement sections for some early papers on the Monte

Carlo method. So he's right at the heart of simulation and nuclear research. The next researcher on the list is Lloyd Yates. He was an engineer who joined ORO in 1949. His name shows up all over these project summaries. He was the chairman of Project Red And yes, all of these projects have cool and cryptic codenames. Redleg was something to do with field artillery and tactical atomic strikes. The one paper produced was concerned with simulated atomic warfare during a military exercise. Project Tear was concerned with analyzing the effectiveness of air support in Korea. Then we have OROFEC-1, or ARFEC-1 if you want to shorten it.

Here I'm just going to quote directly from the summary. Quote, This study is designed to provide, within a few weeks, a standard operating procedure for the use of existing atomic bombs in support of ground operations. End quote. the necessary data. The study may be critically required in the event North Korean forces are reinforced by Communist China or the USSR." The Project 2 reference here is ORO-FEC2, which was concerned with close air support of troops. It's also important to note that ORFEC-1 starts around the time Mao Zedong announces support for North Korea. FEC-1 was very much looking at the possibility of a nuclear war and how to prosecute that war on the Korean peninsula and in China, specifically dropping bombs on troops.

The summary even goes into detail on how effective each bomb could be expected to be, and how many warheads would be needed to destroy different types of installations and units. Here, we're looking at the brass tacks of how World War III was being planned. From there, I think it's clear to see how Hutspiel, a simulation of nuclear combat, would be an exciting project for this research outfit. The third member of the Hutzpiel team that we have information on is Dr. Dorothy Clark. Luckily for us, Erin Reid has already done most of the digging here. Clark was a doctor of history who somehow picked up a flair for mathematics during her career. She joined ORO in 1949 and also shows up in the project summary lists. She was specifically

involved with Project Gunfire, the predecessor to Red Leg. Prior to Hutspil, Clark had worked on casualty modeling and analysis. Here, Reed's work comes in clutch. In 1954, right before Hutspiel, Clark authored a report to In that report, Clark works up these tables that show at which point units become ineffective under specific conditions. She takes into account things like the length of engagement, unit size, and what the unit is actually doing. Defense vs. offense operations are different, after all. It should be pretty clear to see how this kind of analytical work could be useful for,

say, simulating combat. The other two authors are relatively unknown. At least, I can't find any useful information about them. Their names are Archie Colby and Paul Erebe. I'm sure they show up on some list somewhere, but I have yet to see it. Those are the people and the general setting, but we're missing a bridge. That is, how this turns to wargaming. That bridge is ORO-OCAFF. I'm just going to call it ORO-OCAF. This is getting to the very edge of my understanding of militaria, so I'm going to wave my hands around a little bit.

ORACAF stands for the Office of the Chief of Army Field Forces. From what I understand, this was a group within the U.S. Army that handled some aspects of training, doctrine, and strategy for the force. If my reading of literature is correct, they made recommendations for training. Once again, out of my depth. In 1952, ORO-OCAF was established. Here I'm going to read directly from a 1954 semi-annual report about this office. Quote, The mission of ORO-OCAF is to determine, by means of war games and field experiments, the capability of U.S. forces in a two-sided atomic war. During the 50s, this wargaming work was done in four ways.

Field exercises, tabletop games, digital simulations, and analog simulations. In this period, ORO actually had a number of computers to work with. We know from reports and actually user group letters, funnily enough, that they operated a Univac 1103. That was their primary digital machine, although there are also some reports that mention early IBM hardware. They also used a Goodyear Electronic Differential Analyzer, aka Geta. You may, at first, be surprised to see anything about analog computing at such a bleeding-edge outfit. I was too. But we must remember the timeline here.

This is the early 50s we're talking about. Digital machines existed. They were even produced in numbers. But they still had a lot of faults. At the same time, some equations, specifically things like integrals and derivatives, worked better on analog computers. At least, they could be computed more quickly. This left a kind of, I wouldn't say small, but a very specific niche where analog could

stay alive. ORO had already carried out some simulations on their machines, but nothing huge. We're talking small-scale stuff, looking at single aspects of combat. That is, until 1955. That's the year that work on Hutzpiel begins, under ORO OCAP. Thus, we reach the main topic. I know this is a little disjointed, but I'm hoping that the context here is making sense. We have a team with experience with analysis and simulation of warfare, and a background in

atomic weapons. We have an outfit with plenty of computing power, and we have a military office very interested in what atomic war would actually look like. There are generals that are contemplating nuking China and North Korea. To at least some, it would seem like World War III is about to happen. So this is a crucible where it would be very valuable to work up a simulation of what we might expect. And it's where a truly wild game is born. So to start with, what exactly is Hutspiel? The short answer is it's a new type of automated war game. It replaces the umpire of Kriegsspiel and related games with a computer. That allows for quick and repeatable gameplay while also implementing a more complex model.

That model is, hopefully, more realistic. That makes Hutzpiel sound almost mundane, right? It's just a better umpire with more math. Simple, straightforward, easy to see the benefits. But think about this for a minute. We're talking 1955. Computer screens aren't really a thing. So how does mapping work? Random number generation is super new. So how do dice even function in a computer? And what kind of computer are we even talking about here? This is what I find so interesting. It's the details that make Hootspiel, well, just compelling to me.

You see, Hutzpiel ran on an analog computer. Specifically, it ran on Geta. All the usual weirdness applies here. First, is that the documents around Hutzbiel describe it not as an analog program, but a continuous variable model. That is, honestly, the more accurate term. This means that instead of using discrete variables that change from one discrete state to another, Hutzbiel's model uses a set of continuously changing variables. Not only are their values continuous, aka analog,

but their changes are continuous, as in, they don't happen in steps. Thus is the nature of analog computers. Specifically, Geta is an electronic differential analyzer. It uses electronic circuits to model and solve differential equations. Put another way, it's an analog calculus machine. It can do derivatives and integrals and all these ancillary functions that are needed for that. One interesting aspect of these machines is you don't really have a set computer. You don't sit down in front of Geta and plug in a program. Rather, you have to wire everything up, which includes external devices in some cases.

For Hutzpiel, that meant five Geta cabinets were used, three with circuits for linear equations, and two with circuits for nonlinear equations. Since analog computers physically model those equations, you actually need different physical circuits for handling different kinds of math. But this wasn't actually enough to get Hutzpiel running. The ORO team had to throw in a separate function generator and some multiplication circuits. Those were wired into Gaeta's cabinets. This left the team with a pretty sprawling setup.

There's photos of it, and it takes up about half of a room. The usual issues all apply here. Analog machines were notoriously error-prone. Accuracy was a huge issue as well, since the accuracy of an operation was determined by the physical parameters and tolerances of components. If you have a leaky capacitor, your multiplication might be off. There's also a wild lack of flexibility. You aren't loading a program, you are physically configuring a room full of equipment. Because of this, we don't actually have a preserved version of Hutzpiel. We have

equations, but you'd need something like a wiring diagram and a pile of photos to actually recreate the game with 100% accuracy. Why go to the trouble of analog at all? I mean, ORO had access to real life, real digital computers, so this was some kind of choice. The paper actually gives us a rationale for this decision, so check this out. Quote, Wargames played on digital computers usually consist of predetermined strategies, prepared before play begins, and including instructions to cover all situations. This approach is dictated because of the time required

to code instructions for the machine and to read out results to the players. The analog computer, on the contrary, is inherently good for a game relying on a series of player decisions made as play proceeds. End quote. This is, to me, wildly interesting. Digital computers in this era operated in batch mode, meaning they didn't take user inputs.

They couldn't handle real-time operations. To use a mainframe, you had to punch up cards with your instructions, then load and run those cards. This meant that digital simulations had to be run at arm's length from the machine. I'm not entirely sure which wargames they're referencing here, but I can point us to another example. That is, Rand's Business Games. Those are also operational research simulations, so the same ideas are all applicable. In those games, each turn would take an entire day or more. Players would sit down, plan their turn, and then fill out a form to pass to an operator. The operator would punch up some cards and run them through the machine when they got computer time.

Results would come back the next morning, and the next turn would start. That is a completely non-interactive game. Analog, on the other hand, offered a different kind of opportunity. An analog computer could be very responsive in specific cases. Calculations were continuous, meaning that it didn't move in steps. An equation in an electronic analog machine is modeled as a circuit. Parameters are modeled as voltages or currents on wires. To change a parameter, you just adjust that signal by, say, spinning a physical dial. That would immediately change the state of the circuit. No steps needed. Feedback could be almost instantaneous. Availability also matters here. That's kind of the secret implication lurking in the background.

Analog computers were much cheaper than their digital counterparts, especially in this era. A digital wargame would have to fight with other projects for a scheduled computer time. game would have to fight with other projects for a scheduled computer time. By contrast, it wouldn't surprise me if Geta was in much less demand. It's likely that the Hutzpiel team had the machine to themselves, so they could just go wild with the game. Hutzpiel would be played in near real time. Two players, or two teams, would actually sit at two matching consoles. From there, they could take turns directly, no operator or punch cards in between. The play loop here went like this. Each player would look at the current state of their army on a series of dials. They would then adjust a set of parameters and press a big next turn button.

Once both players pressed that button, GATA would spin to life and compute the next values. GATA could process a turn in one second, which simulated one day inside the model. This presents some huge advantages over early digital roleplaying games, and let's not kid ourselves here, these are 100% RPGs. The analog solution has almost instant feedback. You take a turn, and one second later you see the results of your decisions. Quick feedback is good because you aren't wasting time sitting around. That's one aspect. But it's also better as a teaching tool. There's this whole body of work that shows instant feedback is one of the most important things when it comes to teaching and testing. It also allows Hutspiel to simulate long amounts of time in a very short window of real-world time. You can simulate a month of

combat in 30 seconds. That's impressive even when you add in time for the human factor. It would be possible to run many multiple encounters in the space of an afternoon. That's a wild improvement on earlier wargaming systems, which, in turn, makes for interesting possibilities. Hutspiel could be used to sample a prior space. Check this out. Hutspiel wasn't played competitively. It wasn't used as a game game. It was played somewhat collaboratively. Players, really, researchers, would work together to see what different moves would lead to. They would decide together what moves to make, sometimes even ahead of time. In doing so, they could test out what impact, say, a rail system or an airway had on the effectiveness of troops in a sector.

They could actually see the results of different sets of decisions. This allowed ORO researchers to sample different possible inputs and strategies and determine their outcomes. It's kind of like a manual Monte Carlo method. That fancy word that I used, prior space. I will say I don't know if it's a real phrase, but it's the right one to use here. This is a phrase that a researcher I once worked with would use all the time. A prior space is a collection of possible inputs to a model. It's all possible prior figures or prior parameters. In this case, it's every possible troop formation, all aircraft movements, all orders sent down by commanders. You can't test all of them, but you can test some. You can take a sample of that space. You can sample the prior

space and feed it into the model, then check its outputs. That's the whole point of something like the Monte Carlo method, but with automation. Here, you're manually sampling that space. This set of putspiel to be used as an actual research tool. Think of that. A game as a solid tool for research. It had been done before with wargames, but not in the same way. With Hutzpiel, many, many different strategies could be tried. The prior space could be sampled in a much more meaningful way. Hutzpiel automated away all the tedious and imprecise work of modeling,

of being an umpire to a war game. That allowed for much faster and better sampling. But how was that accomplished? We know it was all analog, but what about the details? And can we replicate this today? We're going to start by nailing down the model here. With an analog system, the model really is the closest thing we have to a program. So this is where all the details are.

As with all wargames, Hutzpiel relies on abstractions. It hand-waves away a lot of smaller details, but the paper explains the why and how of those waves. The model simulates two sides, blue and red, for NATO and the USSR. The whole point of Hutzpil is to simulate an atomic engagement between those two factions. And this isn't just an abstract concept. Hutzpiel is actually tailored for a very specific scenario. That being a sneak attack by the USSR on NATO along the Rhine River in the summer of 1955. I did say specific, right?

This only really matters as far as input parameters. A lot of Hutzpiel is concerned with logistics, which has to account for things like starting stockpiles and location of supply depots. The specific location and time frame allowed the ORO team to start off with some real-world numbers. In the case of the Red team, starting numbers came from espionage, funnily enough. The model simulates five of what it calls target weapon components. These are ground forces, airfields, train and rail net, supply depots, and planes. There are rules that govern how these components can interact and which components can interact with

each other. For instance, planes can drop atomic bombs on everything except for other planes. Ground forces can't use nuclear arms, but they can attack directly other ground forces. Trains can attack nothing. All interactions are modeled with equations that are backed up with some kind of real-life data or logic. A crucial point here is that these interactions are deterministic. There is no random number generation in Hutzpiel. This is for two reasons. One is complexity. The team just didn't want to add randomness to Geta. That would have been a huge time sink. The other is, well, deterministic gameplay. The same set of decisions will always lead to the same outcomes. This way, the prior space can actually be reasonably sampled.

This does, however, mean a certain loss of accuracy. Dice are used in most tabletop games specifically to add that element of realism. Outcomes aren't always deterministic in the real world. In Kriegspiel, a message can be lost. An attack that looks like a good decision can randomly fail. A gun can do less damage than expected, or none at all. Those are all real-world outcomes that can happen. But in Hutzpiel, everything is preordained. That does represent a loss of fidelity. These little chips away at an accurate worldview are visible throughout the system. There were simply restrictions imposed by hardware.

And some of those are weird to think about. To quote from the report, The analog computer is especially adapted to solving problems expressed as sets of linear ordinary differential equations. Since the number of nonlinear computing elements was restricted, it was necessary to formulate the model so far as possible in terms of linear differential equations. To put that in less math terms, Guetta was only good at running one specific type of equation. But that wasn't always the equation the researchers wanted to use. As a result, researchers had to force their model a little bit

so it would actually run using those equations. The result, once again, is the model running on Geta is full of compromises. The actual math computed on the computer was different than the initial model design the team wanted. Not all of these compromises were machine-imposed. There are some cases where real-world data allowed ORO to take shortcuts. One of those examples is error on troop actions. For this to make sense, I need to add in a little bit more detail about the model. Each component had measurements for

effective and ineffective resources. Troops had an added field, casualties. Casualties represented a permanent loss of troops, but ineffective troops could recover. There's a specific equation for how many troops recover each day. In Hudspiel, aircraft sorties can't cause troop casualties. That's the shortcut. You can't kill troops with your planes. Instead, they get marked as ineffective and recover over a number of turns. This shortcut was actually backed up by data. Numbers had shown that air-on-troop action didn't cause many casualties in World War II or Korea, so that possibility was not included in the model. The game also neglects cars and trucks entirely. Your only logistics are trains. The reason for this comes from the scenario. It was believed

that trains would be the main transport along the Rhine in the summer of 55. At least, that would be the vulnerable component of the logistic network. The paper argues that railroads can be destroyed, but roads, not so much. Big military trucks can route around craters, so their effectiveness wouldn't be as impacted by bombings. So, as a result, the model mainly cares about bombing railroads. Okay, so let's talk more about play, since we're starting to get a little abstract. Hudspiel is broken into two sectors, each of which run as somewhat independent models. The idea here is, in the scenario, you'd have to hold two parts of the Rhine border, and each of those sectors along the border could fall on their own. In the event that

one sector fell, it would become harder to keep the other sector. Hutzpiel only simulates two sectors, but the math is written up for any number of sectors. In that way, I think you could actually use the same equation to create a more high-resolution simulation. During each turn, players did... well, they did something. Look, this is where the paper kind of falls apart. We know that players read dials, adjusted adjusted knobs and pressed this big next turn button. The paper isn't clear about what those knobs adjusted,

so we have to make assumptions based off the model's equations. Oh, woe be upon me. From what I understand, players would control how many units of each component were assigned to different actions. I've arrived at that conclusion because almost all equations are about the change in unit numbers under different scenarios, and those all depend on the number of units doing certain actions. To be more specific, let's say you're playing as Blue. You want to drop some atomic bombs on Red's airfields in Sector 1. So you'd find a dial labeled something like, Atomic Sorties, Sector 1.

When Geta goes to calculate how damaged Red's airfields are, it checks that knob's position, sees that Blue committed 100 planes to that specific type of attack in that sector, and then crunches the result. Now, there are some major questions here. In the model, you have a limit to how many resources are available, and that limit is dynamic. Blue, for instance, starts out with a maximum of 2,000 aircraft sorties per day per sector.

That maximum changes as aircraft get damaged or destroyed or are replaced. So how does the model limit that? Does it prevent Blue from breaking the rules and sending 10,000 planes over the Rhine? The paper gives no explicit explanation as to how those limits are applied. To be fair, it does gloss over a lot of the details on how the model is implemented. The math itself doesn't include any limiting factors either. There aren't conditionals or min-max functions anywhere to be seen. However, there are probably like a hundred scaling factors and ratios in each equation. It's a little hyperbolic, I admit, but there are constants everywhere. My educated guess is that limits are enforced there, if at all. The model

talks in terms of changes in forces in different sectors and different assignments, so it would make sense to me if the math naturally limits those kinds of operations. I'm a little fuzzy here because, well, the math gets complex. The equations themselves in isolation are simple. They're kind of all the same linear differential equation, which I swear is actually simple when you look at it. But the complexity is that each equation is linked up to others to form feedback systems. That's how the model works.

The change in effective troops is dependent on six factors. Those include troops rendered ineffective by enemy atomic weapons, which in turn depends on the number of sorties the enemy launches and the number of troops in the sector. depends on the number of sorties the enemy launches and the number of troops in the sector. Those sorties depend on the condition of enemy planes and so on. It forms these big loops. The concept here is that there is feedback in the system, as something changes that affects the outcome and options in other places in the model. It can make the mind real, but at its heart, model. It can make the mind real, but at its heart, it's a pretty simple concept. It's just that it makes the math pretty hard to read. This also takes us to one of the more strange aspects of the model. So, Hutzpiel is analog. We all know that by now. But you take discrete turns. That's a little confusing. You actually have steps.

Traditionally, in an analog system, calculations kind of just spin until they're over. You turn a crank until you hit the desired rotation, and while you turn it, some gears and disks calculate your integral or whatever you want. You don't move one step at a time. You don't do one operation after another. They all happen at once. But Hutzpiel has this concept of turns. That means that, in a manner of speaking, each turn is its own calculation. The math model is designed accordingly. Each equation is a delta, meaning a difference. You have equations for the change in effective troops, or the change in effective rail lines.

The inputs for those equations are the output from the last calculation. The change in troops cares about the number of troops you currently have. By running the calculation, you advance the model forward by a day and get the new total number of troops. That feeds into the next day's equation and so on. That's simple enough. The current state of the model is dependent on the previous state of the model, and we have equations to go from one state to the next. That's all very digital. But we aren't on a digital computer. This isn't a discrete model. As the paper describes, there are some

values that vary during the quote computational interval. What does that mean? Well, practically speaking, for my poor digital brain, pain. It means pain. Here, I'm going to just pull an equation straight from the paper because honestly, I can't think of a better way to start explaining this. You'll forgive the invocation I'm about to read. To quote, delta n equals alpha n n-bar u-bar, where alpha is a numerical coefficient, which doesn't matter, delta n is the change in friendly troops during an epoch. N is the number of friendly troops. N bar is the number of enemy troops. And U bar is the utilization of enemy troops. And just to note, those bars are the little line over a variable. This is basically saying that the change in troops is equivalent to the number of troops you start with

times how hard enemy troops are attacking you. Here, Hutzpiel uses that n-bar u-bar term to determine how, quote-unquote, hard the enemy is attacking. The big final delta n is what you get at the end of a turn, after one full second of computation. It's a snapshot of the model. But not all numbers are fixed. There is, at any time during the calculation, some intermediate delta n for you, and some intermediate delta n for your enemy. It's just that we have these set times to pause and take a snapshot of those numbers. Let's take the next step here. That means that that bar in U number, the hardness of the enemy's attack, actually changes during the calculation. Troop numbers change continuously. That's how

analog computers operate. They're continuous. This means the equation looks linear. It looks like it would just be some straight line on a graph. We know that because it's just a number times a number times a number times a number. But when you plug that into getta, it's suddenly not linear. It would make a curve, because some of the numbers are changing during that calculation. Suddenly, bar in u isn't just a variable, it's its own function. But if you look at the math, it doesn't look like that. Now, I've written a good deal of simulation software for digital machines, and let me tell you, this is a very different regime. It feels a lot different to me. The equations in this paper flat out mean something different than I

would expect. The equations are actually written to take advantage of running on an analog machine. They assume they're running in this analog regime. If you plugged Hutzpiel's equations verbatim into a digital computer, you'd get different answers than if you had the same game running on GEDA. When Aaron wrote about Hutzpiel, he speculated that someone could re-implement the game on a modern machine. That's possible. I mean, it's math. A computer can compute any equation that's computable, after all. But this analog nature, that represents a frustrating problem. Or maybe a fun opportunity? How would you do that? How would you practically take an analog program and convert it to digital? I see two options. The smart solution, the big brain play,

is to rewrite the math. You'd have to take things like that bar in u factor and turn them into nonlinear functions. That would blow up the complexity of the model, but I'm willing to bet someone that's good with math could use some tricks to reduce things down. I can actually see a lot of fractions that would probably fall out onto the page. I'm sure you could also streamline the math using a digital machine. These equations aren't just making use of analog features, they're also hamstrung by Geta. So you could touch things up and modernize the actual math. There is another option, though.

It's more ham-fisted, and it's one I kind of want to try. That would be creating a simulation within a simulation. Let me start at the ground here. How does a computer simulate a curve? And let me shatter any illusions you may have. A computer can't actually comprehend a curved line. There's a trick here. And that's that you break the curve down into much smaller straight lines. The more straight lines you use, the more little chunks you break the curve up into, the better your approximation. There's a break-even you have to think about here, since you can take a million steps or a billion steps and get a near-perfect curve, but that could take days to calculate. You can use the same approach to simulate analog operations. What I'd attempt to do for Hutzpiel is just an application of this trick. You write up the model

as written, but you add an extra layer. When the player presses that next turn button, you don't just calculate the new deltas and spit out the next state. Instead, you calculate a number of smaller changes before you reach the big final result. Basically, you take a hundred or maybe even just a dozen steps along the way. you take a hundred or maybe even just a dozen steps along the way. With this approach, you could approximate Hutzpiel. The issue, however, is always going to come down to accuracy. I don't have access to a Getter setup, I can't play Hutzpiel, and the paper doesn't have specific inputs or output numbers, so I can't test my theoretical code. This stepwise approach could capture the weird, non-linear nature of the game, but the fidelity? That could be kind of finicky to get right. I think that's

a good spot as any to end this. Can we resurrect this game? Yeah, I think so. But there's a bit of a challenge along the way. Alright, that does it for the story of Hutspiel. I think at this point I've ringed out just about all there is to find, sans, well, you know, a full reimplementation. Hutspiel gives us a fun window into a few very complicated topics. It's part of this much larger story of wargaming in general. Over time, humans have developed and refined methods of violence. That was done, in part, with simulations and games. In that lineage, Hutspiel represents a leap forward, changing what war simulations could actually do. By introducing automation, scenarios could be ran hundreds or thousands of times. Actual scientific research became more possible. Hutspiel is also a game in its own right.

It's probably one of the earliest computer games, but I'm going to resist the urge to say first. I'm always wrong with that one. It is all the hallmarks of later computer RPGs or strategy games. It just so happens to be from the mid-50s and analog. It's that last aspect, the analog part, that I think is so cool. That's the coolest part to me. Hutspiel gives us a wonderful way to look at how analog and digital computers were different and how they were used differently. Both kinds of systems are in use in this time period, and Hudspiel's paper directly

explains why analog machines had a benefit in this specific case. That is something that's so hard to find. It's the kind of comparison, it's the kind of explanation as to what was going on in this period, in this weird transitionary period, that I think is just fascinating. This is something that I did not expect to run into when I started an episode on a weird little war game. Thanks for listening to Advent of Computing. I'll be back in two weeks with another piece of computing's past. If you like the show, there are a few ways you can support it. If you know someone else who'd be interested in the history of computing,

please take a minute to share the show with them. You can also rate and review the podcast on Apple Podcasts and Spotify. If you want to be a super fan, then you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter when I am on there. And as always, have a great rest of your day.