Hansa v 0.8:
Explanation and Instructions
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
Production, Consumption and
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
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.
League Expansion and
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.
In order for Hansa to be a game, there must
be some way of doing well or badly. The following are possible
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
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.
The general lesson is that military conquest
is not the only model for interaction or expansion. Mutual advantage
is an alternative model that is at least as interesting and
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.
Limitations of the current
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
Brief Note on Version 0.8
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
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.
Some of the interface details are now
different from the description in these instructions; if you have
problems EMail me at email@example.com.
How to Play
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
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
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.
Games are likely to be lengthy, especially
with three or four players. The file menu allows players to save a
game, and to reload a previously saved game.
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,