Instructions for Hansa, A Game of Comparative Advantage

Hansa is a game designed to teach economic concepts—in particular, the idea of comparative advantage. The game is modelled after "conquer the world" games such as Strategic Conquest (© PBI Software) or Empire, with one essential difference. What the player is building is not an empire but a trading league. Cities are added to the league not by conquest but by being shown evidence that they will be better off in than out.

I will start by explaining the mechanics of production, trade and consumption within an existing league. I will then describe the process by which a league may expand (or contract). I will then explain several alternative ways in which the game could pit a player against either other players or the computer. Finally I will explain the mechanics of play for the current version (v 0.6).

A league is made up of cities located on a map. Each individual city has a population, a production function, and a utility function. The production function uses one input, labor, to produce any of several goods. Producing one unit of a good requires a particular amount of labor, and using N times that amount of labor will produce N units. The cost per unit will be different for different goods within one city and for the same good in different cities. Cost for a particular city is partly but not entirely determined by the surrounding terrain.

A city's utility function represents the total happiness of the inhabitants; it depends on the goods they consume. The additional utility from consuming one more unit of a good decreases as the amount of that good consumed increases and increases as the amount of any other good increases. The utility function is identical across cities. A city’s “autarchy level” is defined as the highest level of utility it can achieve without trade.

Cities within a league can trade with each other. Transportation costs (in labor) depend on the particular city pair; typically transportation cost is larger the farther apart the cities are and is much smaller by water than by land. Transportation is instantaneous; the turn represents a year, and it is assumed that moving goods from one city to another takes much less than a year. The labor used for transportation is provided by the exporting city.

Trade, production, and consumption are organized by the player, subject to constraints described below. He instructs each city in his league how to allocate its annual labor among different goods and which of the goods it produces should be shipped to other cities. Goods cannot be stored, so consumption is production plus goods shipped from other cities minus goods shipped to other cities. Trade occurs only within a league.

A league may at any time send trade missions to try to persuade non-member cities to join. Supporting a trade mission, like producing or transporting a good, costs a certain amount of labor. A mission starts from some member city of the league; that city must provide the labor. Missions to more distant cities cost more.

A city bases its decision to join a league on its observation of the benefits that the league confers on its member cities. The probability that the invitation to join will be accepted is an increasing function of the average utility gain (utility above autarchy) of the member cities of the league, weighted by how close they are. If the invitation is refused another mission can be sent the next year.

Cities can not only join a league, they can also leave one. One reason for leaving is that a city concludes it would be better off on its own. This may happen in any year that the city's utility is lower than its autarchy level—the utility it would have if it engaged in no trade at all. The larger the gap, the higher the probability that the city will secede from the league.

A second reason for leaving one league is to join another. If a member city of a league receives a mission from a different league, the probability that it will accept is an increasing function of the difference between the weighted average utility gain of the cities in the inviting league and the utility of that city. Thus a player who wishes to defend cities on the “frontier” between his league and a neighboring league may do so by keeping them happy—arranging trade so that their utility gain from membership in his league is large.

A city that sends a trade mission may increase the probability of success by guaranteeing the city it is inviting a specified level of utility, defined as a number of points above autarchy. If the offer is accepted and the guarantee is not fulfilled–if, in other words, the new city’s utility is allowed to fall below the guaranteed level–the city is likely to secede from the league, just as a city is likely to secede if its utility is allowed to drop below autarchy.

1. Hansa is a solitaire game; the objective is to get as large a score as possible. The game starts with a league of two adjacent cities controlled by the player; all other cities are autarchic, and remain so unless annexed by the league. The score is the utility gain resulting from the league, summed over cities and time. Alternatively, the objective might be to bring all of the world into the league as rapidly as possible.

2. Hansa is an N-player game. Other players are either the computer, playing its own league, or humans, or both. Victory is defined either as eliminating all other players and getting all cities into your league, or as having the highest score (as in 1) at the end of a given number of moves.

Hansa is designed to teach three conceptual lessons, two specific and one general. One specific lesson is the principle of comparative advantage. An intelligent player should rapidly discover that it sometimes pays to ship a good from one city to another even though the labor cost of producing the good is less in the city it is shipped to. Similarly, an intelligent player, in deciding what cities to invite into his league, will soon discover that a city that is bad at producing something he is good at is just as good a trading partner as a city that is good at producing something he is bad at—indeed, correctly understood, the two situations are the same. The requirement that a city's utility cannot be kept below the autarchic level for very long (otherwise it will leave the league) requires that trade really be trade, not tribute.

The second specific lesson is how to maximize output for a given production function and set of inputs—the logic that generates a total cost curve from a production function. In the context of the game "output" is utility and "cost" is the labor cost of producing inputs to consumption, but the logic of the situation is the same as for a firm buying inputs and producing a single output. In this case as in that, the correct answer is one for which marginal product is proportional to price.

In addition to teaching these conceptual lessons, Hansa is also designed to give the player some feel for the implications of pre-modern transportation technology. Relative costs of transport are loosely based on historical figures. After playing for a while, players should begin to realize that two coastal cities far apart are, in terms of transport costs, closer than either is to a city a short distance inland. Similarly, they should begin to appreciate the importance of rivers for defining trade routes.

Hansa v 0.6 is a playable game, but one that lacks some of the features intended for the final version. It will accommodate up to four players, but they must all be human; the option of having some leagues played by the computer is not yet available. A city’s decision to accept an invitation to join a league depends only on its utility and the utility (above autarchy) of the city making the invitation, not on an average over the whole league. Production costs are entirely determined by surrounding terrain. The interface, while adequate for organizing trade among a few cities, will require a variety of improvements before it can conveniently handle a large league. In addition, the game lacks a variety of ornamental features that we intend to include in the final version.

The program now includes a computer player. The code for randomly generating a map, however, does not work properly, so the game must be played on the enclosed U.S. map. The number of goods has been increased. The main improvements that remain to be made (other than fixing bugs) are ornamental, with one exception.

In the next version, the game will implement “fog of war.” When it starts, the player will see his own cities plus the terrain within a fixed travel cost, plus the location of other cities. When he invites a city to join his league, the trade mission will report on the terrain along its route. A new city brings with it information about terrain near it.

You start the game by double-clicking on the Hansa icon. You then choose, from the maps menu, either to play on a pre-drawn historical map or to have the computer generate a random map [but not in v 0.8 until we fix some bugs]. From the players menu, you choose the number of players. To start the game, choose “New Game” from the file menu. If you have chosen a historical map, you are then given a choice among those available. Figure 1 shows the map for Napoleonic era Europe. On figure, I have labeled the terrain features on the map. The situation corresponds to the beginning of the second player’s first turn. There are two cities (Amsterdam and Antwerp–labelled “Other trade league cities”) in the first player’s trade league (shown as shaded circles) and two in the second (and current) player’s league (black circles–labelled “Starting cities”).

Terrain is important for two reasons. First, it affects transportation costs. Second, the terrain adjacent to a city affects its production costs for different goods. Cities adjacent to the ocean tend to be good at producing fish; cities adjacent to mountains tend to be good at producing iron.

By double clicking on a member city (black dot), you bring up its production window; an example is shown as Figure 2 below. The window shows information for the city of Antwerp at the end of the first move. Scroll bars show quantities produced of wheat, fish, iron, and silk. Antwerp cannot produce silk or iron, so those scroll bars are blank. For each of the other two goods, the number of asterisks next to it shows how many units of labor it requires to produce one unit of the good.

Antwerp is currently producing 48 units of wheat and exporting 19 of them. It produces no fish, but imports 6 units. 1.81 units of labor are unused. Utility is 21, slightly above the autarchy line, which shows the highest utility Antwerp can get without trade.

When the window was first opened, before labor was assigned to production, the labor bar was black, there were 50 units of unused labor available, total consumption quantities for all goods and total utility were zero. To set production, the player adjusted quantity produced (and consumed) of each good by clicking on the right arrow of the corresponding scroll bar (increasing consumption by 1 unit) or clicking in the shaded part of the scroll bar to the right of the scroll box (increasing consumption by 5 units). As he did so, unused labor decreased and utility increased accordingly.

The player sets the production of each of his two cities; it is instructive, but not essential, to start by getting each city up to its autarchy level. He then returns to the map by clicking on it, clicks down on one city, drags over to the other (moves the mouse while holding down the button), and releases, thus opening a trade window to show trade between the two cities. In the trade window, he can increase one city’s consumption of a good at the cost of decreasing the other city’s consumption (and using up a little labor). At any point, the player can go back to a production window (by double-clicking on the corresponding city, or by clicking on the production window, or by clicking on the production button for that city in the trade window) and readjust production, then return to the trade window. The obvious strategy is to increase each city’s production of the good(s) in which it has comparative advantage, in order to export some of the output to the other city, and reduce production of other good(s), importing them from the other city. Figure 3 below shows a trade window.

Quantities for each city are shown as quantity produced/quantity imported. Thus Amsterdam is producing 10 units of wheat, importing 19, and consequently consuming 29. Clicking on the right arrow for, say, wheat would increase by one unit the amount of wheat consumed in Antwerp and decrease by one the amount consumed in Amsterdam—or in other words, it would decrease by one the quantity exported from Antwerp to Amsterdam. It would also increase the available labor in Antwerp by .01, since that is the labor cost of transporting one unit of wheat.

Looking at the trade window, we observe that Amsterdam is at the autarchy level and Antwerp above it; the two cities are gaining by trade. A player could, if he wished, end the turn at this point. He would receive points for the utility above autarchy, and both cities would remain in the trade league.

A better strategy is to expand the league. By clicking on a member city and dragging to a non-member city, the player gets a message telling him how many units of labor are required to send a trade mission to that city. He then readjusts production and trade in his member cities to free up an adequate amount of labor for the trade mission. Repeating the click-and-drag gives a message asking whether he wants to send the mission. If so, he is then gets a window letting him set his offer–the level of utility above autarchy that the trade mission guarantees to the city if it joins the league. The city to which the mission has been sent turns a dark grey. If the city ends up accepting the offer and joining the league, its production and trade windows will show a dotted line on the utility bar, to the right of the (solid) autarchy line, representing the guaranteed utility level.

Once trade has been arranged and any desired missions sent, the player selects “end turn” from the file menu. Only at this point do decisions about production and trade become final. The computer shows the score. The player clicks the mouse to indicate that he has read it, and his turn ends. Any cities that missions have been sent to either join the league and turn black or reject the offer and go back to their original color (white if they were not in any other league, light grey if they were). Cities in the league that had utility below autarchy may secede and be out of the league (turn white).

Immediately after the end of one player’s turn comes the beginning of the next. If it is a multi-player game, the cities of the player who has just finished his turn become light grey, and the cities of the player whose turn it now is become black. Play continues until either all cities in the world are in one league or all leagues but one drop to zero cities. If they prefer, the players can agree to end the game after a fixed number of moves, or when the first player reaches some predetermined score.

The version of Hansa on this web page is an advanced prototype, not a final version. If you observe any bugs we would appreciate hearing about them, with as much information as practical about what kind of Macintosh you were using, what version of the system software, how much memory, under what conditions the bug occurred, whether you were able to replicate it, etc.

We would also be interested in any comments from people who try playing Hansa as to what they do or do not like and what improvements they would like to see. Improvements that we expect to have in the next version include substantially faster updating of the production and trade windows, end-of-move and beginning-of-move reports to the players, and an improved interface that will make it easier to figure out who is currently shipping what to whom, what cities are at, above, or below their autarchy levels, etc.