Advent of Computing - Episode 57 - Simulated Sumeria

Episode Date: May 30, 2021

Where did educational games come from? According to some, the practice of using games in classrooms started in the early 60s with the appearance of the Sumerian Game. However, the story is more complicated than that. This episode we dive into the Sumerian Game, some of the earliest educational games, and the bizarre legacy of a lost piece of software. Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and bonus content: https://www.patreon.com/adventofcomputing

Lost software is something I come across often, or rather, stories of lost software. It's more rare to find software that's been deemed lost. The simple fact is that a lot of important sources, be that actual source code or just notes and papers, well, they don't seem important in the moment. When was the last time you shredded or recycled some used paper? Did you stop and think that someone in 50 years may need those documents to answer pressing questions? Probably not. The same thing can happen with software.

Sometimes you write a program that wasn't actually meant to go into production. Or maybe you write a demo program that gets forgotten after its intended purpose is served. you write a demo program that gets forgotten after its intended purpose is served. One thing I don't run into often is a program that disappears not once, but twice. The Sumerian Game, an educational program written in the middle of the 1960s, is one of those weird cases. At least two distinct versions existed at the same time, but no one has ever been able to track down their source code. On its face, that sounds like a little wrinkle in a deep rabbit hole of research. But the story gets more interesting. You see, the Sumerian game was one of the first educational computer programs. It predates the Oregon Trail by a good margin.

What makes this all the more interesting is the fact that the Sumerian game, despite its quiet disappearance, despite no one outside of its creators seeing its source code, well, it would spawn a lineage of remakes and clones. So, are we dealing with the secret origins of games and education? Or is there still more to the secrets of Sumeria? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 57, Simulated Samaria. Today, we're looking at a series of games. Well, I guess series is the closest thing to a name we could call this. In the early 60s, a group composed of educators and IBM employees joined forces to create a program known as the Sumerian Game.

It's one of the first text-based computer games, kind of, and it's one of the first computer strategy games, kind of. There's some weird caveats to everything that make this story really fascinating to me. The team thought they had come upon a fantastic way to engage students. And working on grant money, they were able to bring computers into classrooms in rural New York, thus building a new way to teach. But they had also stumbled upon something else. In the coming years and decades, the Sumerian game would be remade, updated, and emulated. The idea of the game spread via word of mouth initially,

eventually leading to Sumerian-like games popping up on mainframes around the country. A combination of fun gameplay and relatively low complexity made the game a tempting project for programmers, and in a fitting twist, many would learn to program by copying the Sumerian game and its descendants. The other huge factor that made me interested in this topic is on the more personal side. A while back, I produced an episode on The Oregon Trail, another educational game that started life on mainframes. Both games have text interfaces, both were used in classrooms, and both eventually spread and saw remakes. Both were used in classrooms, and both eventually spread and saw remakes.

However, the Sumerian game is a good deal older than the Oregon Trail. Oregon Trail was developed in 1971, while the Sumerian game was first played in 1964. Despite that, in my research on the Oregon Trail, I didn't come across any reference to the Sumerian game. Not even a passing mention. Recently, recurring friend of the pod Lars pointed the game out to me. My first reaction was, well, feeling like I had a little bit of egg on my face. When I prep for these episodes, I hit the paint pretty hard. While my research isn't always totally exhaustive, I try to dig as deep into as many varied sources as possible. I like to be thorough. Missing the Sumerian game while working on my Oregon Trail

episode made me feel like I must have made a mistake. Once I got over myself and started thinking deeper on the subject, I realized I wasn't really dealing with some huge oversight here. As near as I can tell, this is another case of parallel or at least isolated evolution. I'm hedging that a little because I can't prove a negative. I can't 100% say that the team in Minneapolis that wrote the Oregon Trail knew nothing about the New York crew that wrote the Sumerian game. I'm willing to bet that's the case, but let's just leave the door open a crack for safety. Anyway, parallel evolution is something squarely in my wheelhouse, and it's more interesting than an episode of Corrections. So today, we're going to dive into an even earlier text-based education game. We will look at how

the drive to create new methods of teaching led to the Sumerian game, and how existing context made that project possible. We'll close out by looking at how it spread outside the classroom. Along the way, we'll see how it's possible that this game flew under the radar while similar developments happened in parallel. Our story starts, as with any good research project, with a call for proposals. This round took place in the summer of 1962 during a summer teaching workshop. IBM, the massive mainframe we know and love, along with the Board of Cooperative Educational Services in New York were hosting this event. Despite expectations, Bosa's actually had little to do with computers. The group was primarily concerned

with rural education. In general, the board manages and helps set up schools in rural communities, and this specific board was centered in rural New York. The specific workshop was held in West County, New York, away from the state's metropolis. The goal of the workshop was to brainstorm a new coordinated curriculum. In other words, trying to find a way for IBM to coordinate with classrooms. As near as I can tell, this is one of those cases where IBM and BOCES were trying to figure out how teachers could actually use computers in their classes. There isn't much explicit explanation of the initial meeting in the sources. What we do know is that the workshop yielded results. The attendees included Dr. Richard L. Wing from BOCES, the one in charge of developing new

curriculums for the school districts that they supervised. From IBM was a small contingent of programmers, and there were also 10 primary school teachers. That last contingent is crucial. IBM and BOCES were essentially out looking for a problem to solve. This is something that we come across a lot in the history of computers. This is something that we come across a lot in the history of computers. Those in the know understand that digital technology can do just about anything. So they really want to find new and exciting ways to show it off. It leads to progress, but also to a lot of awkward attempts and weird applications.

In this case, it seems that the digital devotees were looking for a problem in rural education, so they needed to convince some kind of teachers of the practicality of computers. 1962 probably just sounds like an abstract year, so just for some context, let's check in on the larger state of computing. In 1962, the first computer science department was founded at Purdue University. Basic, the language designed to teach students how to program, wouldn't be developed for another two years. One of IBM's more popular offerings in 62, the 7090 mainframe, would run you in the neighborhood of $2.9 million. So, we may not be at the exact beginning of the computerized world, but we're at a really early stage of adoption. The ranks of digital devotees were still on the small side,

but those same ranks were destined to grow. And in that 1962 workshop, at least one new convert was minted. By the end of the session, Mabel Addis, one of the teachers in attendance, proposed a problem that could be solved with computers. Going further, she even proposed a solution, the Sumerian game. IBM and BOSES jumped at the idea, grant funding was secured from the Department of Education, and this project started to take shape. The best sourcing on the game itself comes from a 1966 report submitted on the project. It was prepared by Wing, so while not in Addis' own words, it does come as close as we can get. In it, Wing describes the problem that Addis and the larger team identified thusly.

Quote, that Addis and the larger team identified thusly. Quote, Although philosophers of education agree that reform is needed in the direction of individualizing instruction, the present educational system is constrained by the fact that we have produced instead relatively rigid, sterile, and insensitive procedures. Simulation is one method of organizing learning environments to provide for individualization in a broad sense. New technologies have been invented and, to a limited degree, explored for educational use." That new technology was, of course, the computer. The core idea here was to develop a program that would guide students through a simulation. A student would make choices, work through a series of problems,

and hopefully learn something new in the process. Essentially, the learning portion would be hidden under the guise of a fancy digital game. The important thing to keep in mind when it comes to the Sumerian game was that we aren't looking at some project to create a final product. The report makes it explicitly clear this was an experiment. It was carried out with scientific rigor. Fun was a happy side effect. The main goal was to test a computerized simulation model and see if it could help students learn better. simulation model and see if it could help students learn better. So that's the very broad brush anyway. The general idea was proposed by Bruce Moncliffe initially, part of the IBM delegation. Addis filled in the specifics, turning the general outline of some simulation on a computer

into the Sumerian game. The targeted goal, beyond just some educational experience, was to teach simple economics to a class of 6th grade students. To accomplish that goal, Addis designed the Sumerian game as an empire-building simulation. The game revolves around managing resources, growing the population, and eventually growing the kingdom of Sumeria. growing the population, and eventually growing the kingdom of Sumeria. To pack in as much educational content as possible and to try to give some flavor and context to the gameplay, Attis decided to set the game in ancient Sumeria. Students would take on the role of King Luduga I, II, and III in successive phases of the game. From that lofty position, choices were to be explained as decrees passed down to the kingdom. Of course, this wasn't coming out of a total vacuum. During

undergrad, Ada studied ancient civilizations, so she already had a pool of information about Sumeria to draw on. There was also this prevailing notion that history courses in the states were a little bit too heavily focused on history that occurred in Greece and after Greece, so going with Samaria, a much earlier culture, would help correct that in some small way. What's more interesting though, at least for me, is the context around the game's broader design. That is, the idea of an economic simulation. I know, putting it that way makes it sound pretty dry. You may have to just trust me that things will get a little bit juicier here. Some of the articles I've ran into on the Sumerian game, at least some of the more surface-level articles, will just throw out that it was the

first text-based computer game. Others will say that it was the first computer strategy game. And that's not entirely true. It turns out it wasn't even the first educational game. All this goes into why Moncrief brought up the idea of an economic simulation game, and why Addis' proposal was so easily accepted. Wings Report, the main, big, collected source on the Sumerian game, actually breaks this all down. Not to cast any shade or name any names, but if you're going to call anything a first, make sure you read a few primary sources. Anyway, the document has a detailed section that discusses related research. This isn't all that exhaustive, basically a list of other computerized education projects.

For our purposes, this section basically just shows that there were other contemporary projects working in a similar field that the Sumerian team knew about. The more interesting crumb actually comes right before this dedicated section. It's tucked away in an introductory section discussing the rationale for the project. Wayne gives a few short examples of simulations used in education, a paragraph about tabletop wargame simulations, then this, quote, Business and management games are used by universities and corporations to train executives.

Examples of this are economic games of Dill, the IBM game, and the Univac game, in which competitive business situations are simulated and the decisions made by the players are So, you know, that sounds like maybe the most boring application of a computer, but it also sounds a lot like some games that are text-based, educational, and focused on strategy. IBM itself actually had a strong tradition of these so-called business games. By the late 50s, Big Blue was running executives and marketing folks through simulated sessions. Initially, these were pen and paper affairs. From what I've read, it sounds something like business management dungeons and dragons, which, honestly, I'm kind of there for. It could be fun in the right situations. Anyway, more specifically, the quote-unquote Dill game

that Wing mentions is where everything starts to fall into place for me. William Dill was a researcher at Carnegie Mellon University. In 1960, he wrote a paper titled, quote, the Carnegie Tech Management Game. Shortly after, he presented on the same topic at an IBM-hosted conference. The Dill Game, better termed the Carnegie Game, was probably the most boring video game ever written. At least, it sounds really boring to me as not a business person. The entire point was to simulate running a large business, and use that simulation to train the higher-ups of real-world companies. The player took on the exciting and exhilarating role of a manager for a packaged detergent company. The goal is to beat

the computer, which is also running its own slate of packaged detergent companies. Each turn, the player chooses how to allocate funds, where to send detergent, and if they want to buy new raw materials. Money can be spent shipping product, improving detergent formulations, or even developing new products. The goal is, of course, to make as much money as possible. What's interesting here is that players work in teams, each member assuming a different role. The program lets you simulate working in marketing, production, and finance. Each type of play gives you access to a different part of the simulation. Someone on the financial part of the team gets to deal with allocating funds, while product handles more logistical affairs. Dill's article emphasizes the complexity

of the simulation. One of the goals that he brings up again and again is that the game shows the interdependency between departments at an organization. To accomplish this, the Carnegie game uses an underlying mathematical model. Each round, the players are presented with the current state of the model. How much inventory they have on hand, how much money, what kind of products they have in the works, and so on. By making a series of choices, they modify the inputs to that mathematical model. Then, a series of equations are crunched, the state of the model is updated, and the cycle continues. Eventually, you end up creating the best detergent in the world and dominating the market. The resulting game may be a little bit dry,

but we are dealing with an educational simulation game. The paper doesn't go into detail on the actual interface, but with the era, text mode was really the only mode. So is the Carnegie business game the first text-based computer game? It very well could be. The bottom line, regardless of who came first, is that by 1962, there is already plenty of precedent and past research that suggests simulation games could be useful for education. And the basic core of these games, a mathematical model that responds to player choices, was already a well-known quantity. The big step that Addis and her IBM collaborators took was to adapt this idea to primary education. The final complicating factor before we get into the details of the Sumerian game is Addis herself.

You see, Addis wasn't a programmer. She was a schoolteacher. At the time of the IBM BOCES conference, she was teaching fourth grade in upstate New York. So she didn't program the Sumerian game. Instead, she designed it and wrote the English components of the game. Then a colleague at IBM, William McKay, did the actual programming. Here we are looking at a really early case of specialization. As near as I can tell, this makes Addis the first computer game designer. Usually in this time period, the people who design programs, or early games in this case,

are the same people who program them. Only programmers touch computers. This type of specialization would become more common over time, so I think it's really interesting to see it show up at the dawn of computer games. It makes Addis' contribution to the field all the more interesting. Anyway, like I touched on before, the Sumerian game revolved around managing the resources of a Sumerian kingdom. Carnegie's complex and hyper-realistic detergent management simulator wasn't really the best suited to children, so Addis mixed and reduced the general idea into something more

reasonable. To start with, there is only one resource to manage. Grain. A player starts off with a set number of bushels of grain, a set population, and acres of farmable land. The goal is to grow the population as much as possible. Each turn, you're presented with a status report that lists the current population, the amount of cultivated land, amount of grain in storage, and amount of freshly harvested grain. From there, the player chooses how much grain to store, how much to plant, and how much to allocate for feeding the citizens. During this first phase of the game, the player assumes the role of King Ludugo I, and only really has to worry about grain allocation. The more grain planted, the more grain will be harvested next season, up to a point.

The amount of grain you harvest is dependent on how much land you have for farming and how many farmers are working. The number of workers you have on hand are a set fraction of the number of citizens in your kingdom. The amount of grain you allocate to food rations determines population growth. But people can only eat so much food, so if you put too much grain into rations, then you wind up wasting some. So we're looking at a simplified system, but this is still a mathematical model built out of interdependent equations. The final option that the player gets as Luduga1 is how much grain to put into storage, and I think this is actually the most interesting option. It highlights an important mechanism at play,

It highlights an important mechanism at play, randomness. If everything was just running off set ratios, then gameplay wouldn't be very interesting. There would be one single way to win. Just memorize the right amount of grain to sow and eat, and you're done. To prevent that, and to make the Sumerian game more realistic, Addis introduced a little bit of random variability. This comes in the form of random events that shake up the ironclad math model. Each turn, the player gets their status report. They choose what to devote their precious grain to, and then hand down their mandate to the citizens.

Then, depending on how the random number generator is feeling, an event can pop off. These range from good to bad to literal disasters. A handy flowchart gives all the random weights and possible outcomes in the paper. Harvests can be reduced by 10, 20, 30, or even 40%. Locusts can devastate fields. Flood can do the same while taking citizens away with them. There's even an enigmatic block on this disaster flowchart just labeled as God's Wrath. I can only assume that's the worst case scenario.

This is where stashing grain comes in handy. By keeping a store of grain on hand, the player can hedge against disaster. In this version of Sumeria, the storerooms are somehow flood, locust, and deity-proofed. But storage isn't that simple. It's not just some inert room where grain goes to live out its life. The Sumerian game tracks how old batches of grain are, and depending on the age, rot can set in. This part isn't random, there are set equations for calculating the rate of grain rot. Grain that's only been in storage one season doesn't really rot much. But grain from three seasons ago degrades at a much higher rate.

So even if you make aggressive use of storage, you have to be smart about it. Every choice you make has some downside. There was also a good series of events that could occur. Through good gameplay, the report is pretty vague about the exact conditions, the player could receive so-called innovation events. The report basically says that these events occur when the player manages grain well or accepts special innovation reports at the end of a round. Essentially, these events represent breakthroughs in technology. If the player did well, then they could upgrade their storage conditions, thus lowering the incidence of rot, or fields could be better utilized, thus increasing harvests. That's the gist of phase 1, the Luduga 1 level. After 30 rounds

of grain management, you're fast-forwarded to the reign of Luduga 2, and a more sophisticated kingdom. Sadly, the report only has tables and detailed flowcharts for level 1, so the descriptions of the reigns of Luduga 2 and 3 are a little more vague. From what's described in phase 2, the player gains control over more resources and manages how workers are allocated between farming, logging, and other industries. Luduga 3 sounds the most interesting. It introduces trade between kingdoms, civil infrastructure, and even warfare. But, like I said, the report doesn't give deep detail. I can only assume Luduga 2 and 3 followed their own math models with a similar text interface. The Sumerian game was first used in a 6th grade class in 1964.

After which, Addis and the team made some tweaks. Some gameplay elements were revamped, in-game text was changed, and multimedia was added. Now, this wasn't a graphical update to the Sumerian game per se. It was still very much text mode. Instead, Addis developed a series of tapes and projector slides to use alongside the program. The tapes were pre-recorded lectures presented as briefings from the King's advisors. These would be played at certain points during gameplay to give instructions and hints to students. Slides were also projected to add some sort of visuals. It's a simple solution that

overcomes an issue with this early digital medium. You may have noticed that I've been a little bit unclear about some aspects of the Sumerian game. That's for good reason. The program itself hasn't survived into the modern day. In fact, it didn't survive very long at all. After revisions, the updated version was used in a classroom in 1966. Then its hundreds or maybe even thousands of lines of Fortran seemed to disappear into the sands of time. So why did such a complicated program, one that was even developed with government funds, just disappear? Why did no one keep a copy of the code around? I think a big reason is that the Sumerian game wasn't really the project's final

result. This gets back to the root of the IBM-BOSEZ collaboration. The initial proposal was to study if a computer game could help teach students economics. The Sumerian game was just part of the experiment design. Once the study ran its course, the game didn't really matter as much as the data. I think a contributing factor was probably computer access. During the study, students were bussed out to an IBM office to actually play the Sumerian game. Once the study was completed, the rural school just didn't really have access to IBM's computers. It's not like many school districts at this point in history could afford their own computer. Adding on to this, the Sumerian game was quickly superseded by other, somewhat similar, educational games. The wing paper I keep citing actually covers three such games,

with the Sumerian game being the earliest of this catalog. Over the coming years, more games were added to the same overarching project, so the Sumerian game really just became a jumping off point. The net result is that we don't get to know all that much about the game itself. result is that we don't get to know all that much about the game itself. The best we have are printouts of gameplay from Luduga 1, and supposedly some scanned slides preserved in the Museum of Play's archive. But that's pretty much it, not a lot to go on. What we do have is the study's final results, and this is where we can get back into some more positive territory. What's so unique about the Sumerian game, and, well, really this entire package of early games, is that they were rigorously studied. A group of 6th grade students were selected. They were then

given a pretest on economic principles. Based on this, a control group and an experiment group were put together. Both groups had a roughly equal average score on that pre-test. One group was taught using more traditional lectures and in-class exercises, while the other group took a field trip to play the Sumerian game. The study itemizes its results into a lot of little categories, but this can all be summarized down to three major points. Point one, students liked the Sumerian game. It was fun and it kept their attention. Point two, the Sumerian game improved test scores more than traditional teaching methods. The raw numbers show that the Sumerian Games group test scores increased by more than twice as much when compared to the control.

And point three, students, even 6th grade students, can easily learn to play this type of computer game. I'd call that an unqualified success. The IBM BOSES team had really went searching for a problem to solve. And they found one. For the time, this was a huge step forward. Sure, the Sumerian game wasn't the first educational program, but it was really early in the field. Perhaps more importantly, the study provides clear evidence of the value of computer games in an educational setting. The software is lost, but basically everything else about the process is documented. Wing's final report, this 200-page behemoth,

even has the worksheets and tests that were administered to students. This is the scientific method in full effect. If you wanted to, and probably with a little extra programming, you could recreate this study. The final piece that I have to bring up is the matter of the computer game, or video game, as a medium. I always like to examine early games through this lens, basically taking a look at how well a game is using the new digital medium. I always like to examine early games through this lens, basically taking a look at how

well a game is using the new digital medium. Computers were a totally new way to create a game. We're still at a stage in the early 60s where that hadn't been explored in a whole lot of depth. Usually when I do this kind of analysis, I pull out my handy-dandy yardstick. That is, does the game in question allow a player to do something that would be impossible without the aid of a computer? To put it another way, does it matter that the game is digitized, or would it be the same without a computer? That guiding idea was in the back of my head as I dug into the report on the Sumerian game. And as it turns out, Wing, Addis, and McKay were way ahead of me. The report explicitly answers this question, and it does so in a few places. It's most well stated in this passage, quote,

Simulation enables tests to be made under controlled conditions which would be difficult or impossible in real life. Simulation also permits the compression of time. For example, by the use of time-lapse photography, a 24-hour incubation of bacteria can be shown in a few minutes. The environment in which a student learns contains many features which can be represented by pictures and recorded sound. Laboratory equipment is an example. End quote. In the real world, a student can't get a crash course in economics by founding a new dynasty. The Sumerian game takes place over three generations. That's more practice than a human can accrue in a lifetime. You could play the Sumerian game with pen and paper, but that would be really difficult. We're not talking about

just Dungeons and Dragons where you roll some dice and add some modifiers. This is a pretty complicated sounding mathematical model. By moving the game into the digital realm, immediate feedback is possible. That's a big plus for its educational value. It also gives a controlled and consistent environment where students can learn. That's what makes studying a game like this in a scientific way possible. Plus, in theory, kids could use the game without a teacher around, so that helps out. All those attributes are possible thanks to the new digital medium. So, that's it, right? The Sumerian game existed for a brief few years.

Then the code disappeared. It only survives as stories and an academic paper. End of episode, yeah. Well, not quite. There's a strange twist that keeps this game alive, in really an unexpected way. The Sumerian game started leaking out into the wider world before the 1966 report was finalized. The first instance is actually mentioned in the paper itself. At some point, a grad student from John Hopkins named Jimmer Leonard re-implemented the Luduga 1 stage of

the game. This was done for public demos. However, that also ends up disappearing. There's very little information about this second version of the game except for a brief mention in the 1966 paper. There was also supposedly some press about this game and its study, but I can't find any of the articles in question, so that's a little bit dubious to me. The next big jump takes us in a totally different direction, and it takes us outside of the realm of education altogether. At least traditional education. In 1968, DEC, the computer manufacturer, was just polishing off a new in-house programming language called Focal. For the period, this wasn't really that out of the ordinary.

Fortran did start out as an IBM-exclusive language, after all. Focal was being sold as a shiny new programming environment for all DEC users. It ran as a full interactive environment, similar to BASIC, so we're dealing with a one-stop-shop kind of programming package. But as the project neared release, there was something missing. Actual programs written in Focal. Now, this is inevitably one of the first issues any new programming language faces. You have to have code examples to show that this language is actually practical enough to use, and to show off what an actual program in this language looks like. It's all well and good to just be like, oh, hey, here's my reference manual,

but no one wants to sit through that, especially if there's no programmers who already know the language. So why are we talking about a somewhat obscure programming language? Well, the connection all comes down to a deck employee by the name of Doug Diamond. I've kind of cobbled together this part of the story from the book They Create Worlds by Alexander Smith and an article on a website called A Critical Hit. Both of these texts cite an unpublished article on the Sumerian game written by one Devin Monans.

I can't find that unpublished paper and haven't been able to find any primary sources on the matter. So we're dealing with a bit of a maze here. There's a little bit of an interview with Diamond, but we're still in an ethereal space, to say the least. I bring this up because the specifics of the Diamond connection are, I bring this up because the specifics of the Diamond connection are, well, they're bizarre. Anyway, They Create Worlds relates the story like this. In March 1968, Diamond was giving a talk about educational software. At the time, Deck had been trying to get more into the educational market, so this was a work-related trip.

to the educational market, so this was a work-related trip. After the talk, he was approached by some mysterious woman who described to him the Sumerian game. It's unclear who this woman was. It's unclear how she knew about the Sumerian game. It's unclear exactly in how much detail the game was described. Upon Diamond's return to the office, he decided that this so-called Sumerian game would make a good demo for the new Focal environment. So he grabbed a keyboard and set to work. Diamond re-implemented the first phase of the Sumerian game based off what he heard at that conference. But there were some constraints. At the time, deck machines running Focal only had 4 kilobytes of available RAM for code. That simple fact changed the purpose of the program considerably.

Diamond recalled in the interview with A Critical Hit, quote, The whole point was to squeeze as much functionality into a 4K computer as possible, and I used every shortcut and programming trick I could think of to do so. That had a huge impact on the final project. When all was said and done, the new game, renamed King of Samaria, weighed in at exactly 4 kilobytes. King of Samaria, weighed in at exactly 4 kilobytes. The game didn't have any of the complexities or deep vision of Addis' original version. Partly this was because there just wasn't enough room for everything. While we don't have the code for the original Samarian game,

its description leads me to believe that it was a pretty beefy program. If nothing else, just the in-game text would have taken up a lot of space. So corners had to be cut as Diamond built his 4k rendition. Part of this reduced implementation was, more than likely, thanks to the fact that Diamond had never actually seen or played the Sumerian game. This was all transmitted by word of mouth at a conference. Even if there was more space, he may not have made that many changes. King of Sumeria just re-implemented the grain management portion of the Sumerian game. At its core, it was a mathematical model, but an apparently simplified one. Unlike the Sumerian game, we actually still have source code for Diamond's version. The only issue is that the code is cramped and not all that easy to read.

Diamond wasn't kidding when he said that he didn't care about legibility. But from what I've been able to see, this new game is certainly reduced. You're still dealing with managing grain and citizens, but in Diamond's version, you can also buy land using spare grain. And I think that's interesting. It leads me to believe that he at least heard a mention of the Luduga 2 phase. Anyway, grain can be sown, given out as food, stored in silos, or used to buy new fields at a variable price per acre. The choices made in King of Samaria all have trade-offs that we would expect.

Grain in storage can be eaten by rats, but the game doesn't track how old stored grain is. Lack of food will cause citizens to starve. If you play well, then new citizens will immigrate. If you play poorly, your steward, the in-game character that carries out your decrees, will quit and the game will end. There aren't random events, but there is some random variance introduced to harvests, population changes, and how much grain rats consume. There is still a somewhat complex math model used to run the show, but as we can see, it's a lot more streamlined.

A large reason for that is the reduction that had to be made to keep everything within 4 kilobytes of memory. The actual chunk of code that runs numbers is only 4 lines, albeit everything is kind of smooshed together to save space, so we're talking maybe a dozen very short equations. The other interesting feature of King of Samaria is that Diamond, for some reason, changes the name of the player's character. You're no longer a king of the Luduga dynasty. Instead, you play as some unnamed ruler. Your steward, the nameless worker that carried out Luduga's orders in the earlier game, has been recast as Hammurabi. But, you know, space is tight, and times are a little rough in Sumeria. Hammurabi is more correctly spelled with two M's, but to make the

game fit in 4K, Diamond dropped one. This leads to some confusion and a few issues that have really been the bane of my existence researching this game. Anyway, King of Samaria had a pretty fast development cycle, because, you know, it was just a demo. In 1968, the game started being shared around as an example of practical Focal code. It was, very literally, the largest program that you could write in Focal at the time, and that same year it makes a few appearances in the Deck User Society catalog. And this is where we get to another confusing part of the history. The listing for the game reads like this, quote, this is a simulation program slash game which will run on a minimal PDP-8 system. The economy

of a Sumerian city in the year 3000 BC is simulated in the fashion of a modern day business game, end quote. So far, not that bad. What's interesting to note here is that the game is described as similar to existing business games. That's some good evidence that simulation games were common enough that at least avid computer users would know about them. The confusion here is that the game is listed as the Sumerian game. It's the correct description, and it's credited to Diamond, so it's the same game. We're dealing with a piece of example code, so we run into this annoying problem where it was never on a very official footing. Making things even more confusing, by this time there was also a French translation going by the name Sumer, and some

versions were just called Hammurabi after the only in-game character, complete with both spelling variations. The net result is that King of Sumeria, or whatever you want to call it, lives in this weird ephemeral space. On the surface, this is just an annoying artifact, but there's a reason for all the name confusion. You see, there wasn't really one single version of the game. At least, not exactly. For many deck users, King of Samaria was the first focal code they ran into. For many, it was the first source code they ever saw at all. It was a fun and simple game, and even though its source code is a little illegible, it's relatively simple. Everything's small enough to fit on one page, so you could literally just

mail it off to a friend. Programmers quickly took up the task of exploring the software, translating it to French as one example, but people also created more derivative works. Perhaps most importantly, some programmers cut their teeth by writing their own versions of King of Samaria from scratch. This last part is really interesting to me, especially as a programmer. Now, it's notoriously difficult to teach computer programming. At first gloss, you'd assume that it would be just like teaching lower division math. Programming is just following a set of rules, chaining together instructions, and creating some syntactically and lexically correct code, right? Well, that's just part of it. Programming takes a lot of real-world practice and experience, the kind you can't really simulate in a classroom easily.

You can know all the syntax in every keyword in a language, but without practical experience, and even just without practice, you can't really produce useful code. Of course, it's different for everyone, but I know for me, working on projects has always been the best way to improve my programming skills. When I was first getting really into programming, you know, beyond just working examples from books, I decided that I'd write a small operating system myself. Did I think I'd produce something on par with Unix? No, not at all. The point was to set a goal and learn new practical skills along the way. For me, every step

towards a working operating system was a new lesson. I was, through my own work, learning more than just the dry formulary part of programming. I was actively practicing the craft. I bring this up because what we are seeing with the King of Samaria is, almost accidentally, an ad hoc continuation of the original Samarian game study. Aspiring programmers were using King of Samaria as an educational game, just not in the sense you would expect. The educational content was the program itself, its code and its design. The problem with covering this part of the phenomenon in depth is that most of these

programs were probably never preserved. However, some examples would survive. In a strange way, the Sumerian game just refused to stay lost. For the Sumerian game to travel any further, it needed some new technology. And luckily, as the 70s rolled along, so too did a new type of computer user. If the first phase of the Sumerian game's life can be attributed to researchers and the second phase to programmers and enthusiasts, then this third wave can be attributed to home users. As with most of the field, the microprocessor really changed everything. By the early 70s, King of

Sumeria was gaining traction on DEC computers. DEC offered systems on the smaller side of things, often called minicomputers instead of their larger mainframe computer counterparts. But we're still in the era of institutional computing. The physical technology is one part of the equation, but so is the software. Remember that the original Sumerian game was pretty much immediately lost. In this period, King of Sumeria and its derivatives are surviving as a lineage, and those games were all written in Focal. This matters because Focal environments were only available on DEC computers. So if you were somewhere with a PDP-8 or similar system, then you could run the Kingdom of Samaria for yourself. But if

you only had access to an IBM mainframe or some other kind of machine, you probably wouldn't even know the game existed. This lack of compatibility kept King of Samaria from gaining much popularity. That could have ended the dynasty right there. But to the rescue comes the newest wave of educational software. The person up to the task was Dave Aul. In 1970, he was hired by DEC while still finishing up his PhD in educational psychology. He was soon put to work trying to sell PDP-8 computers to the educational market. These were still early days for that, despite the decades-plus of work trying to integrate computers into classrooms. Aal was initially just trying to

sell what Dick had on hand to offer, but soon he decided on a more improved plan of action. Aal's approach to this was a three-act tactic, composed of hardware, software, and resources. The hardware was, well, the PDP-8. For the time, it was a relatively affordable and capable computer. Software was where things broke from DEC's normal dealings. All decided to drop Focal and replace it with the more popular Dartmouth BASIC. Although associated more with home computers, BASIC started out on larger systems. Now, there were some big advantages to BASIC over Focal. I'm not going to dive deep into another programming language analysis this episode,

since that kind of thing merits its own time and space. From my limited experience though, Focal and BASIC are relatively similar languages, at least syntactically. They look close enough. The key point here is that BASIC was far more popular and it wasn't restricted to DEC hardware. In fact, it was on most other major platforms of the time. All really saw which way the wind was blowing. I mean, it would have been a mistake not to. Supposedly, DEC customers had even been asking for BASIC by name. So, BASIC became the go-to choice for this new educational initiative. That's two acts sorted. The final act, resources, flowed nicely from the choice

of software environment. By 1970, there were already educational resources available for BASIC, as well as libraries and libraries of BASIC code and example programs. In a move that IBM would be proud of, all just outsourced all of this to save time and money. A contractor was brought in to implement BASIC for the PDP-8. Existing BASIC resources were scrounged up. This three-part package, which All called an edu-system, was then marketed by DEC as a ready-to-run computerized classroom. To further the overall project of getting DEC into schools, Ahl's team also started a newsletter. Simply called EDU, it was something of a community newsletter for educators interested in computers. From what I can tell, it carried letters,

announcements, and new chunks of basic code to try out. The assumption was that this would just be a nice bit of support for DEC customers, but that assumption proved to be wrong. All recalls, quote, Educators with non-DEC computers needed the very same information, so they subscribed too. I realized, too, that people used EDU to help decide whether to buy at all, end quote. to help decide whether to buy at all, end quote. Digital education was becoming a more viable option just in general. So besides moving edu systems,

All also moved a lot of newsletter subscriptions. And this is where we get back to the episode's main thread. You see, in the early days of All's career at DEC, he was still trying to sell computers running Focal to educators. When he made his pitch, he showed off some demo programs. One major program in that demo reel was King of Samaria. As Aal's team shifted things over from Focal to BASIC, a lot of these early demos were rewritten in the new language. Sometime in this period, tradition holds it is 1971, but there's some wiggle room, all would rewrite King of Sumeria. Now in basic, it got a new name, Hammurabi, with one M, of course. It's also assumed that during this time period, the game made its way

into more public venues. Sources are light on the particular details, but Hammurabi was either distributed as part of DEC's edu system, printed in the EDU newsletter, or both. None of that documentation has been archived, at least as far as I've been able to tell, so we don't get a specific point when Hammurabi made it outside of DEC. Once 1973 rolls around, we get onto a more well-beaten path, at least source-wise. That year, Ahl would write his first book, 101 Basic Computer Games. Published by DEC, it was a compilation of basic program listings. Some games were from the pages of the EDU newsletter, while others were new, and smack in the middle of the book, listed as HMRABI, is Aal's interpretation of the Sumerian game. Now, I think this is the right place to stop and talk about the distribution method here.

Mainly because, well, software doesn't really come printed in books anymore. Some notable exceptions include 2600, shout out to my favorite magazine, but you don't really go buy software by picking up a new book. It seems to have been a practice that was particularly popular in the basic era of computers. The general idea was that instead of buying software on disks or downloading it over a modem, you could just pick up a book or magazine that was full of source code listings. After you made your purchase, you had to type the code into your computer or terminal line by line. It took some time, but it had a few huge advantages. For one, it was really cheap to

get software this way. Usually, you'd see magazines with a few dozen different programs listed, or books with many more. For just a few dollars and some extra time, you could get a whole library of programs up and running. That's some extreme value. The other important piece here is the educational angle. This comes back to what I was saying about learning programming through projects. To get one of these printed programs working, you had to type the entire program into your computer. That meant that you were reading someone's source code and, That meant that you were reading someone's source code and, hopefully, learning to understand it. At the very least, anyone buying these magazines and books was exposed to BASIC.

So sure, you could just copy in a program and call it good. But you also had a jumping-off point to tinker. In this sense, we're looking at another one of these unorthodox educational programs. The final program itself may not be educational. The text the source code is enshrined in isn't explicitly educational, not always. But the act of using these programs had an educational tinge to it. All's text isn't the first example of this type of software distribution. With the history of digital printers going back so far, I think it would be hard to find the first time a program was shared via printout. That said, All was early to the mass publishing side of things. 1973 was right on the cusp of a massive shift in computing. When 101 Basic

Computer Games was published, the target audience was running basic over a terminal. They would be in a classroom or somewhere with terminal access to a larger mainframe. In the following years, things changed on a profound level. As usual, we quickly hit our milestone of 1974. From then, moving forward, home microcomputers become a growing force. With few exceptions, these new, smaller computers all booted straight into a basic environment. It would appear that Ahl had made the right choice when he moved away from Focal. Ahl didn't stay at DEC all that much longer. A few years after publishing 101 Basic Computer Games, he left the company, and he was able to get the rights to his book to boot. In 1978, a revised version was published. By the time the second edition was out of print,

over a million copies had been sold. Al had tapped into something huge at just the right time. sold, all had tapped into something huge at just the right time. But what about Hammurabi? How did it change from focal to basic? Well, we're essentially just dealing with the King of Samaria, but in a new format. That's why I haven't really agonized over Hammurabi's details. You can buy and sell land, villagers immigrate or starve, and there are no random disasters. What makes Hammurabi different is the context around it.

We aren't dealing with a game that stands on its own, really. At least, not in the 101 basic computer games formulation. Hammurabi is wrapped up as part of a larger package. The important part of that package, and what I want to close with, is that Aal's book isn't interesting because it preserves a footprint of the Sumerian game. In a very real way, 101 Basic Computer Games is the legacy of the Sumerian game. Hammurabi may be a somewhat direct successor, but that's more of a cool footnote. The work done by Addis, Wing, and the rest of the crew working on the Sumerian game paved the way for future projects. 101 Basic Computer Games is, well, a book full of somewhat fun educational games.

You don't get that, and you especially don't get that in any widely accepted way, You don't get that, and you especially don't get that in any widely accepted way, without hard-won academic work. No kid's gonna sit down and read Wing's 200-page report on the efficacy of simulation games in primary education. However, they may be more interested in typing Hammurabi into their computer and taking a trip back to Samaria. Alright, that does it for our dive into the Samarian game, and King of Samaria,

and the Sumer game, and Hammurabi, and Hammurabi, and Sumer. You get the picture. No matter what you call it, this game had a long life. From research projects, to focal demo, to classrooms and home computers everywhere. The bizarre word-of-mouth spread is interesting on its own, but the Sumerian game's first phase

of life is what I find the most curious. Throughout my research for this episode, one of the things in the back of my head has been, how is this different than the Oregon Trail? Of course, after listening to this whole episode, I'm sure you have a few answers of your own. But for me, the crux of the matter lands in the IBM BOSES research project. The Oregon Trail started out as a fun way to engage students, but the Sumerian Game took a more rigorous approach to its fun. It wasn't just a group of teachers trying out something new in their classroom. The Sumerian Game was a straight-up scientific endeavor to understand how computers could fit into an educational environment. This type of research was crucial in proving that computers had a much

wider application than initially thought. At the expense of sounding overly dramatic, the research around the Sumerian game was one break in the road towards the ubiquity of the computer. Thanks for listening to Advent of Computing. I'll be back soon with another piece of the story of the computer. And hey, if you like the show, there are now a few ways you can help support it. If you know someone else who'd be interested in Computing's past, then why not take a minute to share it with them? You can rate and review on Apple Podcasts.

And if you want to be a super fan, 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 all of that on my website, adventofcomputing.com. And if you have any comments or suggestions for a future episode, then shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.