Hamurabi

Long before anyone thought of a computer game, Hammurabi ruled Babylon. His name survived through one of history’s best-known law codes, a record of a society trying to make trade, property, debt, agriculture, family and punishment legible through rules.

Thousands of years later, with one “m” missing, the name appeared on computer terminals.

Hamurabi is difficult to impress anyone with visually. There is no world to explore, no soundtrack, no character model, and hardly an interface. The machine prints numbers and asks questions. How much land will you buy? How much grain will you feed the people? How many acres will you plant?

Then it tells you what your decisions did.

I first encountered the game not by playing an original terminal version but by reading a BASIC listing. That mattered. The entire kingdom was visible as code. Population, grain, harvests, rats, land prices, random events: the political universe of the game could fit into a program short enough to study.

I typed part of it in, changed a number, and immediately made the kingdom absurd.

That was educational in a way the game itself had not intended.

Simulation is the art of deciding what reality may safely be ignored. Ancient Mesopotamia contained religion, war, irrigation, class, family, trade, disease and a thousand other things the program does not model. Hamurabi reduces rulership to a few variables, yet those variables interact strongly enough to produce recognizable pressure.

Grain is the center of almost everything. It can feed people now, remain in reserve, or support the next harvest. Land looks like wealth, but land without labor and grain can become a liability. Population growth sounds like success until the new population has to be fed.

The game therefore teaches something more interesting than optimization.

Growth creates obligations.

Modern software systems do the same. More users sound good until they require more capacity. More features sound good until they create more interactions, tests and ways to fail. More data creates more value and more responsibility. Expansion changes the shape of the problem.

Uncertainty gives the simulation its tension. A sensible plan can still meet a bad harvest. Rats may destroy reserves. Plague can reorder the population. You cannot control the next event; you can only decide how fragile the system will be when it arrives.

That is why a resource is more than an amount. It is stored possibility.

Spend it now and one future becomes available while another disappears.

Early programmers worked under constraints that now seem almost impossible. They could not hide weak design behind spectacle. If a game consisted mostly of text and arithmetic, the arithmetic had to matter. The player had to care about the numbers.

Somehow Hamurabi manages this.

A good harvest feels like relief. A starvation report feels like accusation. Nothing is drawn, yet the player begins to imagine a kingdom behind the printout.

I still like the austerity of it. Modern strategy games may contain thousands of assets and systems, but beneath them is often the same ancient question.

You have limited resources.

The future will not cooperate.

What do you do this year?