New Economic Model for Civ

[Mxzs]

In this thread I describe a new basis for calculating and managing city and national economies in Civilization. The new model would accomplish three things.

1. It would give the player an easier and more powerful interface through which to manage production in his cities.

2. It lays the basis for a possible extension that could unite the player's cities into a single "national market."

3. It could be used to restructure international trade, adding food and hammers as possible items for import and export. I've not developed the idea further, but it might also be used as the basis for a new system for trading resources.

Structure of the thread:

• In post 2 I give a summary description of the new interface and brief replies to some obvious objections.
• In post 3 I briefly describe the internal workings that can change the current economic system in Civilization to the new system. Again, I give brief replies to possible objections.
• In post 4 I describe a new "national" economic system that would generalize from the system described in posts 2 and 3. This system is not be a necessary part of the scheme I propose in posts 2 and 3, but a "plug in" that could be added to it.
• Similarly, in post 5 I describe a new system for conducting international trade, one that could be added either to the basic system described in posts 2 and 3 or to the expanded system described in post 4.

EDIT: I've put this proposal in its own thread, but it develops out of ideas I've been playing with in this thread.

 

[Mxzs]

The New Interface: A Summary
The proposed system is an internal function mostly invisible to the player, one that transforms (in a systematic way) the resources of Civ 4 into monetized commodities and lets the player set demand for these commodities in each city. Thus, the player will mainly experience the economic system via a new interface accessible through the city view screen. Here is a detail of how the interface might look in the city screen:

​

Through this interface the player can precisely set the food, hammer, and coin production for the city. The interface shows the amount of coin available in the city to spend per turn on food and hammers; by clicking on the +/- buttons he can order exact amounts of food and hammers for the city up to the point where either no more can be wrung from the city or until he runs out of coins. The interface also shows how many coins he is spending to procure the amount of food/hammers ordered.

This display will replace the inefficient method that has the player place workers directly on the landscape: The player ceases to be a foreman who directs workers onto specific plots of land and becomes a consumer who adjusts his demands in various ways and relies upon an invisible "private sector" to supply that demand by working the landscape. As a consequence, the city view might change, but I haven't mocked up any alternative designs.

The new system is not committed to keeping specialists as a feature of game play, but it is not committed to eliminating them either. All other features, such as production queues and happiness and health features and calculations, would carry over unchanged.

Objection: The player can already set and fine-tune his production orders by manipulating workers in the landscape. Why is it necessary to construct a new system?
Reply: It's not necessary, if your idea of fun is spending five minutes juggling workers and specialists in the city view in order to get exactly the resource levels you want. The new system lets you set precise orders with a few mouse clicks.

Objection: Won't the new system require a new basis for calculating food, hammer, and coin productivity, and thus require an enormous revision to the underlying model?
Reply: No. A few simple formulas will be able to transform the same kinds of resources currently displayed on the screen into data that can be manipulated by the interface. (See the following post.) The food, hammer, and coin units will still be a feature of the landscape and will still be visible to the player.

Objection: Is it really fair to call this a "revision" to the economics when you are only proposing a new screen tool?
Reply: At its simplest, it is only a change in screen tools. The new system, however, also uncovers efficiencies ignored by the present economic system and makes cities—at least in their early stages of development—richer and more productive places. It is also a change that can be used to implement more far-reaching changes in the national economy and international trade.

 

[Mxzs]

The New Interface: How It Works
The new interface calculates a population-based "gross domestic product" (GDP) for a city and the cost of extracting resources from the surrounding squares. The features of terrain squares remain as they are in Civ 4; e.g., unimproved flood plains continue to generate a base of 3 Food and 1 Coin. The new system, however, uses this unchanged base info to calculate per-unit costs for each resource for each square in the city radius. In essence, it uses the base terrain info (which is still available to the player) to generate two data points for each square: the cost per unit of food and hammers in that square, and the number of food and hammers that can be extracted from the square. When a player uses the interface to order a certain number of units of food/hammers, the program "purchases" the goods (using coins generated by the city's GDP) from sources in the city radius. Laborers, of the sort that used to be placed on tiles in order to work them, are no longer modeled in the game; rather they are an invisible, undifferentiated "force" that is assumed to be available to produce those resources that the player orders.

Details:

1. Each city is given a "gross domestic product" (GDP) equal to 4 times the sum of the number of citizens it contains and the central city square. This money represents gross domestic product in the sense that it cannot be saved, only consumed in a turn. In order to survive the city must use its GDP to purchase food and hammers from the surrounding countryside. Any coin that is not spent on food or hammers is consumed as research and culture. The player sets the amount of food and hammers the city purchases in the new city management interface.

Example: A city of size 3 has a GDP of $16.00, i.e., ($4.00 x (3 citizens + 1 city square)). Having a population of 3, it must purchase at least 8 Food units per turn in order to avoid a shrinkage in its food box. Any money that is not spent on Food is either spent on Hammers or expended as research- or culture-buying Coins.

2. Each square in the city's "fat cross" radius can yield up to a certain set quantity of food or hammers; modifications to the terrain can change the number of food, hammer, or coin units that can be taken from it. This is how it works in Civilization currently, and the new system will continue to use it, even to the point of not changing the yield or modifications that tiles currently have.

3. The cost of extracting each possible unit of food or hammers from a square is calculated according to the following formula: U = (4 – C) / (F + H), where U is the per-unit cost of each food or hammer unit; C is the number of coins contained in the square; F is the maximal number of Food that can be extracted from the square (in its current state of improvement); and H is the maximal number of Hammers that can be extracted from the square (in its current state of improvement). If the square contains neither Food nor Hammers, the program ignores it. The costs of food/hammer units produced in the city square are also calculated according to this formula.

Example: A unimproved flood plain contains 3 food units and 1 coin unit. The per unit cost of each food unit is (4 – 1) / (3 + 0), or 1.00. A forested grassland contains 2 food units and 1 hammer unit. The per unit cost of each food and each hammer unit is (4 – 0) / (2 + 1), or 1.33. A flood plain with a Farm on it contains 4 food units and 1 coin unit. The per unit cost of each food unit is (4 – 1) / (4 + 0), or 0.75.

4. When a player raises his demand for Food, the city interface will "purchase" each subsequent unit from whichever square both (a) has an unpurchased unit that can be extracted, and (b) is the lowest-cost source of units of that kind. Conversely, when he lowers his demand, the interface will drop the highest-cost source first.

Example: A city contains 1 unimproved flood plain and 19 forested grasslands. The player orders four food units. The interface purchases the first three units on the flood plain for a total cost of $3.00. It purchases the fourth in a forest for $1.33. The total cost of the four food units is $4.33.

5. Hammers are purchased at a price equal to the average of each unit's per-unit cost.

Example: A city radius contains three squares that contain hammers: a hill with two hammers; a forest with one hammer (and two food); and the central city square (one hammer, along with two food and one coin). The per-unit cost of the hammers from the hill is $2.00; the per-unit cost of the hammer from the forest is $1.33; the per-unit cost of the hammer from the city square is $1.00. Every hammer purchased—first, last, and each hammer in between—costs ($2.00 + $2.00 + $1.33 + $1.00) / 4, or $1.58.

6. Mines, farms, watermills, and all other improvements that change the output of squares work just as in Civilization. The formula described in point 3 above, however, will cause the per-unit cost of units to fall when their squares are improved. In effect, improvements will increase the number of units a square can produce and make each unit cheaper.

7. Similarly, forges, factories, and other city improvements that increase the city-wide production of hammers will have the effect of raising the number of hammers that can be realized within a city radius and lowering their per-unit cost.

8. Marketplaces, banks, and other city improvements that increase the city-wide production of coins will raise the GDP of the city. The percentage the GDP is increased, however, will be less than it is in Civilization. (Likely, the number will be only ¼ of the increase it is in the original game.)

9. Taxes would be laid upon GDP across the empire, rather than simply upon Coin production. For this reason, the incremental rates should probably be 5% or even 2%, rather than 10%. All other expenses and incomes, such city maintenance, could probably be left unchanged.

Objection: By giving cities "coin" up front, aren't you making them richer?
Reply: No, because they have to spend it in order to get their resources.

Objection: But coins are being treated differently than in Civ—instead of being generated by trade they simply show up in a formula. Doesn't this mean that the overall city yields will change, so that cities either produce more or fewer coins?
Reply: If a player fully works a square, its yield in Food, Hammers, and Coins will be identical to what it would yield in the old system. In the old system, a citizen works a square and produces a certain output. In the new system, the citizen enters the square with a wallet and exits with a shopping bag and a (lighter) wallet. But in each case, the citizen will exit with the same amount of food, hammers, and coin.

Example: A citizen that fully works an unimproved flood plain will exit that square with 3 food units and 1 coin. In the new system, the citizen will enter with 4 coins, spend 3 of them to get 3 food, and hence will exit with ... 3 food units and 1 coin.

Production yields will change to this extent, however: Because citizens are no longer working squares but are simply buying from the cheapest source, and because the game will always purchase from the cheapest sources first, smaller cities will be able to realize greater efficiencies. That is because they will not have to expend resources on "expensive" squares in order to get a balance of Food and Hammers.

Example: In regular Civ, the player has a city with a population of 1. He has one flood plain with a farm, one hill with a mine (producing 4 hammers), and 18 forested grassland within his fat cross radius. To get a balance of food and hammer, he would likely put his citizen to work on a forested grassland, thus producing only 2 food and 1 hammer (to go with whatever his central city square is producing).

In the new system, the same citizen would have $4.00 to spend. If he ordered 2 food, the program would purchase them first from the flood plain at $1.00 apiece. If he then ordered 1 hammer, the game would purchase it from the mine for $1.00. That would give him total expenses of $3.00, leaving 1 coin left over. (I'm ignoring the $4.00 in coin that come with the city square; I'm only comparing the performances of the stand-alone citizens.) Thus, the one citizen would emerge not only with 2 food and 1 hammer, but with an extra coin.

Basically, what's happening is this: In the new system, his workforce is spreading out to work ¼ of the hill and ¾ of the flood plain, as these are the cheapest places to get hammers and food, instead of working the forested grasslands, where both goods are more expensive to produce. He is still working only 1 square, but he is working the most productive portions of multiple squares and hence realizing savings that show up as coin. (And he could always use the saved coin to buy more goods.)

Objection: If the new system makes small cities richer, won't it make big cities even that much richer?
Reply: No, the performance of big cities under the new system will actually converge with the performance of their regular-game counterparts. That's because the efficiencies uncovered by small cities are a function of their ability to concentrated their limited resources on the most productive land. As they get bigger, they will have to bring the less productive land under cultivation. Once all the land is being produced, there will be no efficiencies to be exploited.

Objection: If small cities are more efficient than large ones, won't this encourage the creation of large empires with lots of small cities?
Reply: Like players need an incentive to spread out. The expense of maintaining cities is already a deterrent to "infinite city spread," however, and could be upped to counteract any greater efficiency shown by small cities. Moreover, the effect almost certainly cannot be magnified simply by building more cities, as it derives from bringing cheap land under development, and cheap here is an absolute term, not a relative one. All other things being equal, a small city that tries to work unproductive desert land will be less productive than a gigantic city that sits on rich agricultural bottomland.

Objection: Why are we ignoring squares that do not have food and hammers in them?
Reply: We already ignore deserts (no food, hammers, or coin in them). We ignore spaces that have only coin for the same reason: no resources to buy, and the coin that would "come" from such a space is already realized as GDP.

Objection: Why would taxes be laid upon GDP instead of on coin, as it is now? Won't laying it upon GDP burden city hammer and food production?
Reply: Taxes ought to be a burden upon hammer and food production; any government that sucks up large quantities of taxes will, if all other things are equal, so burden manufacturing and food production that shortages might occur. ("Welcome to North Korea. Hope you brought some babies to eat while you're here.") But all this is six-of-one/half-dozen-of-the-other so far as Civ is concerned. To maximize your taxes you have to maximize your coin income, and to do that you can manipulate your worked squares and specialists so that you are producing coin rather than food. Taxing GDP directly makes it quicker to achieve this result, and also quicker to back off of it. You wouldn't have to go thru and change coin production in each city unless you really needed a lot of coin in a hurry.

 

[Mxzs]

National markets
In Civ 1, you were able to construct food caravans that would transfer a certain amount of food from cities rich in food to those that were poorer in it. I'm not quite sure why the designers got rid of this feature. Possibly it was only because they got rid of caravans; but they may have had other motives.

Be that as it may, I'm going to assume that the inability to support cities in poor terrain by tapping rich food producers is a bug, not a feature, and show how it is possible to rig the system I've described above so that you could use large food-producing cities to support smaller cities.

To make this change, you would need to introduce something like the following additions/modifications to the interface.

1. The individual city screens would include "import" and "export" as part of the production interface. (If asked, I'll produce a possible sketch.)

2. A new "trade" screen would be used that would show food, hammer, and coin production, both in each individual city and across the empire. The player would be able to purchase food and hammers from individual cities, adding them to a "national" resources box.

There would be one further change to the way the program worked: When purchasing food or hammer, a city would also look at the price of any food or hammers in the national resources box and would purchase from that source first if it was cheaper than buying locally.

How this works, in brief:

Cities, in isolation, work like fully contained, self-sufficient economies. When a city "exports" a unit of food, it sells the highest-cost item of that time (at cost) and collects as payment gold coin (which in turn is accounted as an "import.") When a city exports any goods, it is not allowed to lower production below the amount of that good that it exports. It can, however, use the extra gold it imports to purchase more food or hammers.

Example: A city produces 20 food units, 3 of which are surplus. The city exports those 3 (which cost $1.33 apiece) and collects $4.00 in gold. The player can then change demand so that the city uses that coin to buy two hammers (at $2.00 apiece).

The units that are exported by a city are purchased by the government; the money would come out of the taxes that he collects and would be another expense. The food and hammers, however, could not be stored; they rot away at the end of the turn. In essence, the government would be subsidizing the city by giving it valuable coin in nominal return for food/hammers that the government couldn't use.

If the player didn't want his government subsidizing cities in this way, he would have other cities pay the government and take the excess food/hammer, which they could then use to feed their citizens or produce stuff. The government buys the items from the producing city at cost; the purchasing city would buy them from the government at cost (in coins). The net result would be a trade route between the cities: food/hammers for coin.

Example: The player founds a city in the middle of a desert. It requires four food units to simply not lose population, but there are no food-producing squares within its city radius. After founding the city, the player goes into a city with a large food surplus and has it export four food units (at, say $1.50 apiece). The $6.00 automatically comes out of the government budget. The player then goes into his new desert city and has the city demand four units of food. Because there is no food to be had within its radius, it goes to the "national" box, where it finds four food units it can buy for $6.00, which it does. The net result: The government has no excess food, and no deficit. The new city has 4 food units and (if it's not producing hammers) 2 coin. The old city has four fewer food units per turn, but 6 more coin to spend. It could use this coin to buy more food (thus offsetting the food it exported) put it into hammers, or leave it as coin.

Note, however, that it would always have to produce 4 food units, because the export "agreement" means it has to produce at least that amount for its partner city.

Objection: Wouldn't this lead to "infinite city spread" by encouraging the player to build lots of cities even in unproductive wastes, knowing that he would be able to get at least a little bit out of them?
Reply: Possibly. But again, city maintenance costs might be factored in. They might even be rejiggered, so that the cost of supporting a city is also a function of the kind of terrain that it takes within its radius. The more unproductive that terrain—the more ice, desert, tundra or whatever—the more it costs to keep that city running.

Objection: Wouldn't it lead to other unbalancing issues? Right now, for instance, it is very hard to extract all the resources from hilly terrain because you can't build the city up big enough. Now, with enough agricultural cities, you could support such cities and grow them quickly.
Reply: Why do you think that's a problem and not a solution? Anyway, the agricultural cities themselves would have to be very big in order to have a large surplus, and they would have to sit on land that is very rich. This will tend to limit the extent to which the new system could leverage up cities in hilly terrain and the speed with which they could increase in size.

Objection: Couldn't you rig this so as to concentrate hammer production in one city in order to rush-build Wonders?
Reply: Yes, you could. But if this is an objection, I need to know why the designers finally got rid of caravans, which were also used to rush-build. Was it because they were tedious? Was it because players used them as an exploit to stockpile shields for insta-builds? Or was it because they finally decided that quick builds were too powerful?

If it's the latter, then we simply cannot have a national economy in the game, and this part of the proposal would have to be scrapped. If it's the first two, then this proposal avoids the problem. There are no caravans, simply a straight transfer of goods from one city to the next. And because hammers bought by the government "rot," they cannot be stockpiled. At best, the player could only redirect all of the resources in his city into supporting the one city that is building a Wonder.

 

[Mxzs]

International markets
The idea of trade between cities can easily be extended to apply to inter-civilizational trades. This would involve trade in food and hammers, not just in resources, and it would not be negotiated through the diplomacy interface.

Instead, there would be a second, international trade screen that would show the surpluses that were being purchased by national governments but not being consumed by any cities in those empires. (These would be situations in which cities were "exporting" but no other cities were "importing.") These goods would be available for purchase by foreign civilizations at a mark-up (an export tariff) to their per-unit cost. If the player had a "trade pact" with a foreign power, he would be able to purchase any excess hammers or food that the civilization had for sale. Conversely, they would be able to purchase any that he had on hand. The civs making the purchases would then be able to distribute the purchased goods to his individual cities by having them "import" them (at cost) from his government, just as though they had been produced by his own cities.

Details (tentative):

1. There would be two ways to conclude a trade pact that would allow for the trade of food and hammers and coin. First, it would be side deal included with any agreement that involved the trade of resources; once two countries had agreed to exchange one resource for another (or for cash), they would automatically be able to purchase any surplus hammer and food that the national government had purchased from cities. Second, if the players had no such resource-trading deals, the players could via diplomacy conclude a straight "trade pact" that would allow them to buy and sell food and hammers from each other.

2. There would be no limits and no quotas on what could be bought and sold. The civ that is selling goods could, in practice, cut off the trade simply by having his exporting cities stop exporting the goods to the national government. Conversely, the civ that is buying could raise or lower the amount that he buys at his whim.

3. The actual existence of such trade arrangements should have a powerful effect on diplomacy. A civ that buys food from another civ would be highly unlikely to declare war on that civ; there's a better chance that civ that imported hammers would declare war on its trade partner, but it would still have a low probability. Civs that exported goods would not have as strong an incentive to maintain the peace; their desire to keep the peace would likely be proportional to the amount of coin they imported in exchange for the food and hammers.

Objection: How likely is it that such trades would take place? Wouldn't you be more likely to hoard your food and hammers so you could grow and produce your own stuff?
Reply: It's hard to know without play-testing. Nevertheless, there is still such a thing as "comparative advantage." If you had a choice of buying your next food unit locally for $2.00 and buying it from a competitor for $0.50, where would you buy it? Conversely, if you had food gushing out your cities and were worried about unhappiness and unhealthiness catching up to you, why wouldn't you sell it and try capturing it as coin?

 

[Joe Harker]

good yet complex idea, question how does this system work with science?

 

[Mxzs]

good yet complex idea, question how does this system work with science?

I think, though I'm not 100% certain of this, that it wouldn't make any difference. Research is a function of the amount of coins your cities generate that are not sucked up in taxes, and the new system wouldn't change that fact. In the new system, taxes would be laid on GDP, but in practice raising taxes would cause coin production to fall before food and hammer production fell, and thus raising taxes would primarily have the effect of causing research (and cultural production) to fall.

The greater efficiencies realized by small cities might make science go faster, or (alternately) let the government build up greater surpluses while science proceeds at the same rate. Here is a place where some values relating to the the cost of research (the number of "lightbulbs" that you generate) might have to be rejiggered, but I think that would handle any issues, and I suspect such issues might be minor--a matter of getting discoveries one or two turns earlier than you could get under the old system.

 

[Jerrymander]

So, a city has a workable area of 21 tiles, which are all pooled together into a "resource pond". Citizens enter with 4 coins, buy the cheapest resources, and come out with said resources?

Objection: If a tile produces more than 4 Coins or 4 Coins, then cannot a citizen get money off resources or break even, respectively?
(Such as, Financial Towns or Riverside Towns, or Dye plots, or Incense... etc)


EDIT: Perhaps fractions would be better than decimals in this system.

 

[dh_epic]

Definitely a complex idea, but I think there's a lot of potential to overhaul the economic model in Civ. Everything is currently too city focused, with very little national management. But that said, a lot of these proposals seem to be more about fixing unrealistic functions in the Civ economy.

I'd support change for the sake of change, and I think a lot of players would too. But there's necessarily a huge risk in changing such a fundamental, and it would demand a lot of time and effort to balance it. Would it favor bigger players too much? Would it favor smaller players too much? What are the exploits? How much experimentation will be required to get this just right? It's not so much that it's impossible to make it work, but that it takes a lot of effort. As you can see, the current civ economic model had gaping exploits that only recently became fixed!

So, expecting all that time and effort... what do you see as the big game play payoffs to your system? How does it improve the strategy that the player gets to deal with?

 

[Trade-peror]

I just took a quick read through your proposal and there are some very interesting ideas here. Here are a couple of questions for you:

1. Are strategic and luxury resources entirely unaffected?
2. Why is the per-unit cost equation hardwired with a 4?
3. By basing GDP on population, does this model imply that small, wealthy cities cannot exist? Or that large cities are fundamentally wealthier?

I understand that some of the above situations arise from a need to maintain simplicity, which is important, but I'd like to do some prodding and see how far this model can go.

 

[Spitefire]

Sounds like a good idea to me, and as far as i can see its only seems complex if you try to understand the mechanics the functionality of it seems simple witch is good simple for game play and little bit of a puzzle for the hardcore folks that like to min/max everything to death.

 

[Mxzs]

So, a city has a workable area of 21 tiles, which are all pooled together into a "resource pond". Citizens enter with 4 coins, buy the cheapest resources, and come out with said resources?

Pretty much.

as far as i can see its only seems complex if you try to understand the mechanics the functionality of it seems simple witch is good simple for game play.

Spitefire hits the nail on the head. The underlying resource model would be unchanged: it's still food, hammers and coins being generated, and it's the same number coming out of the same kind of squares, changing in the same way with the same kind of improvements. So that doesn't change.

Cities would also generate roughly the same amount of food, hammers, and coin that they do currently. That also doesn't change. (Well, not by much, though there is more flexibility in what you can pull out of the landscape.) As far as gameplay is concerned, the only major change should only be the new interface. If a player wanted his city to produce (say) 8 food, 3 hammers, and 2 coins, he would only have to click on the interface to get that result (or one close to it) instead of having to move citizens around various squares in various combinations until he got the numbers he was looking for.

So, the only complexity is in the "formulas" that transform the old resource base into a form that can be manipulated by the new interface—which is something that shouldn't really concern the player. Eyeballing the landscape (just as he does now) will tell him how productive a city is going to be, and whether it will be mostly productive of food, hammers, or coin.

I went into detail about those formulas in order to forestall this kind of objection:

But there's necessarily a huge risk in changing such a fundamental, and it would demand a lot of time and effort to balance it.

If I had just said "I'd like a new interface that lets you order exactly the amount of food and hammers and coins you want!" the instant response would have been, "Oh, but you'd totally have to redesign the way food and hammers and coins are woven into the landscape, and that's too big a change, and you'd have to test it to see if it unbalanced everything!" At least, that's the first response I would have made to anyone who said that. So I wanted to go out of my way to show that with a very little ingenuity you could take the current resource model and its values and transform them into commodities that could be set precisely with that kind of interface.

Would it favor bigger players too much? Would it favor smaller players too much? What are the exploits? How much experimentation will be required to get this just right? It's not so much that it's impossible to make it work, but that it takes a lot of effort.

Ignoring for the moment the possibility of knitting cities together into "national" markets, I see only two real "exploits."

The first, as noted, is the ability of small cities to realize efficiencies. These are, however, very small—in general, it appears that cities that are under the size of 6 could probably pick up 1 extra coin for each citizen that they hold. That is, roughly, a 20% gain in efficiency, but it's a percentage gain on a very small base. And, as I noted above, the larger a city gets, the closer its efficiency would converge on that of its regular-Civ counterpart. Cities with a population of 20 would have identical performances (given identical landscapes within their city radii).

The other exploit involves the ability of cities to maximize their purchases by spending all their coin. Take a look at the city in the screenshot in post 2. Those numbers in the corner are "real," in the sense that that city, with 1 citizen, could generate 5 food and 2 hammers while having 1/3 of a coin left over. In regular Civ, how would you arrange your 1 citizen to get the same result? You couldn't. Your city square would automatically generate 1 coin, for starters. And there are no squares that generate 3 food and 1 hammer, which is what you'd need to add to the 2 food and 1 hammer that are in the central square. in order to get the 5 food/2 hammer result At best, you could generate 5 food, 1 hammer, and 1 coin, or 4 food, 2 hammer and 1 coin. The new system, though, would let you spend some of your coin so that you could pick up the extra food or hammer. But, of course, that extra unit of food or hammer is not a freebie: you're trading one resource (coin that would go to research or culture or taxes) for another resource (food or hammer).

Except for these two changes at the margin, which would mostly have the effect of speeding up progress by a small amount—you could grow and improve your cities and do your research slightly faster—it shouldn't change much in the game at all. The inputs would be the same; the outputs would be roughly the same; where would the game balance issues be?

Objection: If a tile produces more than 4 Coins or 4 Coins, then cannot a citizen get money off resources or break even, respectively?
(Such as, Financial Towns or Riverside Towns, or Dye plots, or Incense... etc)

Very perceptive! I was waiting for someone to point this out. Yes, that will happen, but it's a solution, not a problem.

Consider a plot of land that generates two food and one coin. If you build a cottage on it, and work it, it turns into a town, and then the square generates 2 food and 5 coin, right? (If I've got the results for "town" wrong, just pretend it's an improvement that results in 2 food and 5 coin being generated on a square.) So, in regular Civ your citizen works it and walks out with ... 2 food and 5 coin.

In the new system, the citizen would walk into the square with $4.00 and try to buy food. Now, plug the resource numbers into the formula U = (4 – C) / (F + H) in order to calculate what he would spend. The result would be (4 – 5) / (2 + 0), or –$0.50. In other words, instead of spending money to get food, he would get each unit of food free and plus $0.50. So, the citizen who fully "shopped" that square would walk out of it with 2 food, plus his original $4.00 (because he got the food for free), plus $1.00 (50 cents for each of the 2 food units he bought). In other words, he would walk out with ... 2 food and 5 coin.

The important thing, as far as I'm concerned in devising this system, is that each square yield the same results in the new system as it would in the old. (Because I don't want to worry about rebalancing a lot of other stuff.) And that's what it does.

Is this funky? Yeah, though you can easily explain it away. In the old system, the 5 coin that you get is generated by trade. In the same way, you can describe the odd result in the new system—free food plus more money—that comes from building and shopping in that town as deriving from the fact that the town generates extra GDP that completely offsets the cost of the food that is being bought. But instead of the extra coin being modeled as GDP, it is realized indirectly as "free food plus free coinage." The net result is the same.

Would it look funky to the player? Well, if he lowered his food order sufficiently, he might notice that he is getting food for free, and that lowering his food order to zero actually causes his coinage to decrease. Alternately, suppose he has a city with a population of 1, and it has a square like I described above within its radius. When he ordered his first unit of food he would see that it cost no money and that his coin income rose by $0.50. His second food unit would likewise be free, and his coin income would increase again by $0.50. Whether this would bother him or not would rather depend upon his personality ...

Still, there is another way around this objection (see below).

2. Why is the per-unit cost equation hardwired with a 4?

I actually don't understand the mathematics well enough to understand why it works; I just know that it does. But, basically, it seems to work like this:

Each coin in a square, I decided at the start, wasn't a coin that was generated by the player. Rather, it was a coin that he didn't spend. This implied that he walked in with a certain amount of money—aha, GDP! I exclaimed—and in some cases he didn't have to spend all of that money in order to get the resources in the square. To fully work a square, normally, would be to expend a citizen's complete GDP, and if he comes out with coin it means that the resources in the square are so cheap that he doesn't have to spend everything he's got. Now, the per-unit cost of what he's buying is calculated by dividing the amount of money he's spending by the amount of stuff that he's buying; in order to figure out how much he's spending you've got to subtract the amount of money he walks out of the square with from the amount he walks into with. Hence, his GDP ($4.00) has to be hardwired into the per-unit calculations for each square.

That doesn't mean it has to be "4" in the equation. If you give each citizen a GDP of $2.00, or $1.00, or $10.00, or $1,000,000.00, and change the formula accordingly (so that the numerator is (2 – C) or (1 – C) or (1,000,000 – C), everything will still work out. In fact, if you go with a larger number (larger than 5, at least) as the at-game-start GDP** of each citizen, then you can avoid seeming absurdities like Jerrymander noted.

So, give each citizen a GDP of $10.00 and change the formula to (10 – C) / (F + H). Then the per-unit cost in a 2 Food/5 Coin square won't be a negative number; it will be the positive number $2.50. In short, the citizen will go into the square, spend $2.50 per food unit to buy two food units, and walk out with 2 Food and 5 Coin.

So why did I give the player the absurdly low number of $4.00 as GDP? First, I didn't want to scare people unnecessarily by throwing in a big number. ("You're giving him all that coin? Are you nuts? That will totally unbalance things!" Er, no it won't.) Also, the negative numbers work just as well as the positive ones at generating the correct results. Finally, since so many starting squares come with four resources (2 food, 1 hammer, 1 coin), it seemed to make sense to give the player $4.00 as a starting GDP.

** Why "at-game-start GDP"? Because the GDP will change as marketplaces and banks are built. But the formula won't change as GDP creeps up.

1. Are strategic and luxury resources entirely unaffected?

For the time being. It would be nice to monetize them somehow, in ways like I've monetized food and hammers. For starters, it would actually make trade offers between civilizations more transparent if you had some notion of the goods' underlying value. Moreover, it would be nice if the cost of a resource were a function of the amount of it a civilization had. Finally, it would be most amusing if a civilization wound up buying, say, Cows from a rival civ even though it had Cows of its own, just because the foreign Civ had cheaper cows.

But I've not done any work on that yet. I'd like to see if this stuff holds up to scrutiny first.

3. By basing GDP on population, does this model imply that small, wealthy cities cannot exist? Or that large cities are fundamentally wealthier?

Well, "wealthy" is a relative term, innit? One thing I was mindful was this: Can you split the "functions" of a citizen up and use them to different purposes without distorting the game?

Right now, for instance, a citizen is, all at once, a population unit, a consumer, and a producer. The new model splits these functions up. The GDP models the citizen as a consumer, and the "invisible" workforce takes over his "producer" capacities. But I wanted to keep things close to the original Civ model by making sure that the "workforce" associated with a citizen couldn't really "work" more than one square at a time. (It can work pieces and parts of multiple squares, but in most cases those pieces and parts add up to "one" square.) I also didn't want the workforce and the local population coming unglued. So, I had to set aside one early idea that would have had GDP being spent on the cheapest sources in the empire and not just the city radius. That's because, although GDP can range widely, I didn't wan the absurd situation in which a city with a population of 4 had the 20 farms in its radius being worked. What, were people from other cities "commuting" to work these spots? Were the 4 people in the city being 5 times as productive? It was too absurd on its face.

If we stop with the basic idea, then yes, all other things being equal, bigger cities will be wealthier than smaller cities in absolute terms. (In "per capita" terms, smaller cities will be wealthier because they are more efficient; and small cities with lots of financial improvements can be made still wealthier, both absolutely and per capita.) But improvements and Wonders could certainly alter the GDP so as to make smaller cities quite wealthy in absolute terms too.

In the case of "national" markets it should be theoretically possible to set up complementary cities such that smaller ones can concentrate on generating coin. Suppose you have several large inland agricultural cities and then found a city at the end of a hilly peninsula. Food in that city will be very expensive, as neither the sea nor the hills will generate it cheaply. However, the city could use its GDP to import food from the inland cities where it is cheap. Suppose the coastal city is able to import 10 food units at an average cost of $1.00 each. It could then support a population of 4 (10 food for 4 citizens plus the city square), who would generate $20.00 in GDP. Half of this would have to go to pay for the imports, leaving $10.00 in coin. By contrast, in normal Civ such a city would probably only be able to reach a population of 1 before having to improve the landscape, and it would only generate 3 or 4 coin.

EDIT: Perhaps fractions would be better than decimals in this system.

Why?

 

[dh_epic]

The game balance issues are never predictable. For example, have you noticed that Civilization 4 doesn't have a philosophical-industrious leader? That's probably because fast wonders and easy great people have a killer synergy. You HAVE to figure they did this on purpose. That kind of testing and thought takes time. And if every new system has even 20 of those issues, that's a lot of time invested in polishing.

I'm not trying to say that the exploits won't get resolved. I'm optimistic that they can be resolved, and if Firaxis were to go with an idea like this they probably will be resolved. I'm not really asking you to predict every exploit. To be quite honest, I can't think of many.

The question really turns to what the benefit is, and if it's worth the risk.

"I'd like a new interface that lets you order exactly the amount of food and hammers and coins you want!"

I know that since we're both critical thinkers we wouldn't want an idea to start and end here. That's why you went to all the trouble of going into more detail. But I don't think you should downplay the value of this line summary. "More control over hammers and coins" exactly summarizes the value of this idea -- for all the effort you went into describing it in detail. But does this create trivial micromanagement tasks, where you have the human worried about the tedium of their economy rather than their broad economic strategy?

Also, I wonder if "more control over hammers and coins" is exciting enough to justify such a fundamental change.

 

[Mxzs]

Also, I wonder if "more control over hammers and coins" is exciting enough to justify such a fundamental change.

Hmmmm. I think there's pithier way to phrase your objection:

It's too big a change to ever be implemented, and it doesn't really change anything anyway, so why bother?

Does that capture your thought?

EDIT: Really, I don't mean to be snarky. But while writing all this out I was deeply conscious that that kind of objection would the be among the first to be made. "Oh, c'mon, you're just giving the player a little tool. And you're messing with the stitching on the back of the needlepoint to make it. Even if you don't accidentally unravel the whole thing so that we wind up with 700 miles of code wrapped around our ankles, it won't make any difference on the front end."

To which I can only say:

(1) If the average player is anything like me, he never even moves his citizens in his cities, because that way lies madness. You start by moving one of your guys from a flood plain to a forested grassland; you end by spending twenty-five minutes each turn on each city trying to tweak it to just the right mix of food, hammer and coin and trying to find exactly where to put your workers to get that mix, and realizing that frack! i should've put a watermill and not a windmill on that one square and that means my city has been screwed for the past twenty turns and now i have reload a game from 40 turns ago to fix it ... I know there are people who argue that the patience and ability to indulge in this kind of thing is what separates the Deity-level players from the sadsacks. Well, I say the hell with that.

An interface that lets you buy each incremental unit of food or hammer or coinage won't cure the real micromanagers of their micromanaging tendencies, but it would let the rest of us at least play with the settings and get the feeling that we've achieved a solid balance without worrying that we'd do even better if, maybe, we moved this guy over here ... oh, but then we'd have to move this other guy over to here ... and now that guy should be over there ... and ...

(2) Every change has the potential to have unpredictable consequences. If that makes a change "fundamental," then every potential change is a "fundamental" change, and then the adjective "fundamental" becomes meaningless because it applies to everything. So what exactly is the "fundamental change" you see this proposal making?

 

[Jerrymander]

Fractions would be better than Decimals because (1/3)*3 = 1 BUT (0.3...)*3 = 0.9... =/= 1. However, Wikipedia claims that the last equation is, indeed, true. I just thought that it might be easier for a player to grasp.

Can extra commerce that isn't a whole number be added to overall commerce. That is:

A citizen works a Riverside-Plains-Hill-Windmill. It produces 1F 2H 2C [for sake of equating]. A citizen works this tile, getting 2H for a combined total of 2([4-2]/[2+1]) OR 2(2/3) OR $1.33. Now, this is citizen number 21, so he cannot work anything else. Do the extra 1.33 coins count as EXTRA commerce? Can the city now produce a base of 62.33 commerce? Or would the equation be FLOOR(4-[2{4-2}/{2+1}]) = 1.00?

Okay, now I'm hooked on this. We must find a way to implement it. D:

EDITz: I just reread the National Market section, and I think it is the best part of this improvement. Could City A sell three hammers @ 2.00 a piece and get from City B 1 Coin and 3 food @ 1.66 a piece? This COULD potentially make food-high areas large producers of commerce. And excess food could jsut be sold... for magical, free Coins? Or does another city HAVE to supply it?

 

[MontyLaremane]

Wow! If only I could come up with ideas like this! Alas, I am wont to critique the ideas of others instead. I hope you can forgive that

I like the premise that instead of being able to tell your citizens exactly what to do, you have to ask them for what you want and rely on some unseen labour force to produce as best it can. Perhaps, they'd be less inclined to meet the player's request to overproduce on hammers and starve themselves if they were unhappy . . . unless they were whipped?! The potential for intra/inter national markets is also intriguing.

What interests me most at the moment is the formula as it does introduce some oddities. I think the potential of free/negative cost of food/hammers can be worked around (e.g. by increasing the 'magic number' 4) and a slight extra efficiency of smaller cities welcomed (or, at worst, coped with by increasing costs elsewhere, e.g. techs).

My concern is the relative unintuitiveness (is that a word?) of some of the implications of this model. For example, it is cheaper to extract food from a mine than a farm.

Mined hill grassland has 1 food + 3 hammers, for cost per food of $1.00. Farmed grassland has 3 food for a cost per food of $1.33. So, a size two city surrounded by farmed grassland could produce 9 food + 0.66 left over coin. A size two city surrounded by mined grassland hills could produce 12 food. Therefore, a small city that wants to grow quickly is more efficient if surrounded by mines rather than farms. That is confusing, no?

I'm sure there are other similar examples as well. The extra efficiency of the small city I quite like, but I don't think it is quite intuitive enough yet. Or perhaps the model as is allows a bit too much flexibility for small cities. Perhaps I should have a think on the formula to see if there isn't a more constructive suggestion I can come up with

 

[Mxzs]

Fractions would be better than Decimals because (1/3)*3 = 1 BUT (0.3...)*3 = 0.9... =/= 1. However, Wikipedia claims that the last equation is, indeed, true. I just thought that it might be easier for a player to grasp.

I think that would probably have to come down to a programming decision. Me, I don't think I would care either way.

Can extra commerce that isn't a whole number be added to overall commerce. That is:

A citizen works a Riverside-Plains-Hill-Windmill. It produces 1F 2H 2C [for sake of equating]. A citizen works this tile, getting 2H for a combined total of 2([4-2]/[2+1]) OR 2(2/3) OR $1.33. Now, this is citizen number 21, so he cannot work anything else. Do the extra 1.33 coins count as EXTRA commerce? Can the city now produce a base of 62.33 commerce? Or would the equation be FLOOR(4-[2{4-2}/{2+1}]) = 1.00?

Hmmm. I'm entirely sure I understand the question.

Citizens do not actually work tiles in the new system. They just spend GDP and the city buys food and hammers from the cheapest sources. Any GDP they do not spend shows up as Coin. The player has it in his power to set Coin as high or low as he likes. (Except ... if he buys all the food and all the hammers that can be produced in the square, and if he still had Coin left over, and if he cannot buy or sell surpluses from other cities, then he's cannot set his Coin production any lower. There's literally nothing more to buy.)

BTW, a city with a population of 21 would have a GDP of $88.00 to start with. ($4.00 x (21 + 1 city square))

EDITz: I just reread the National Market section, and I think it is the best part of this improvement. Could City A sell three hammers @ 2.00 a piece and get from City B 1 Coin and 3 food @ 1.66 a piece? This COULD potentially make food-high areas large producers of commerce. And excess food could jsut be sold... for magical, free Coins? Or does another city HAVE to supply it?

In theory, yes, City A and City B could make that kind of trade. In practice, it depends on how expensive the highest-cost source of food and hammers in the two cities was. It might be $2.00/$1.66, but it might be more or less. It might also change in the course of the game as improvements were put in.

In practice, cities that exported food would import coin, so again, yes, they would be large producers of "commerce" (coin). But this coin would have to come from some place—either from another city or from your government (which collected it in the first place as taxes on your cities). So, cities that exported goods would suck in the coins, but these would not be "magical, free" coins. They would be coins not spent by other cities in your empire.

The biggest effect of this kind of trade would be to slow or cap the growth of the food-producing cities, and redirecting it to grow or accelerate the growth of cities that are importing the food. Instead of having mega-cities the produce lots of food and some smaller cities stuck in less productive land, you could have a more balanced population distribution.

Alas, I am wont to critique the ideas of others instead. I hope you can forgive that

Easily forgiven, especially when you're noticing things like this:

My concern is the relative unintuitiveness (is that a word?) of some of the implications of this model. For example, it is cheaper to extract food from a mine than a farm.

Mined hill grassland has 1 food + 3 hammers, for cost per food of $1.00. Farmed grassland has 3 food for a cost per food of $1.33. So, a size two city surrounded by farmed grassland could produce 9 food + 0.66 left over coin. A size two city surrounded by mined grassland hills could produce 12 food. Therefore, a small city that wants to grow quickly is more efficient if surrounded by mines rather than farms. That is confusing, no?

Yes. Yes, that is odd. I hadn't seen that.

My first thought is to uglify the calculations by dividing the money that could be spent in a square between "Food" costs and "Hammer" costs before further dividing it among the number of food and hammer to be bought. Hard to describe except with an example:

In your mined hill grassland, the $4.00 would be divided into two sets of $2.00. One set would reflect the total cost of food that could be bought in that square, and the other would reflect the total cost of hammers to be bought in that square. The 1 food would cost ($2.00 / 1) or $2.00 per unit to buy, while the hammers would cost ($2.00 / 3) or $0.67 per unit to buy. Increasing the output of a square's hammers would thus not cause the per-unit cost of its food to fall, and vice versa.

Where there is only one type of resource to be bought, the full GDP cost would fall on the one type. Thus, in the case of farmed grassland, it would still cost $4.00 to buy those three food units, for a per unit cost of $1.33.

Where there is coin in the square, the coin would be subtracted before the GDP constant is divided into food and hammer types. Thus, in a 2F-1H-1C square, the $4.00 would be cut to $3.00 ($4.00 minus 1 C), then divided into two sets of $1.50, each of which would be spent separately on food (which would cost $0.75 apiece) and hammer (which would cost $1.50).

Yyyyiiiccchhhh, as Mel Cooley used to say when looking at Buddy Sorrell.

I initially toyed with this idea when I was starting out, but rejected it as "too complicated." Probably there's nothing so complicated about it that it couldn't be realized easily in code with a few routines, but it's a pain to try describing, innit?

 

[Diamondeye]

The idea sounds very well, and I like the simplicity and complexity of it - especially the function about the villager being paid for buying food.
Still, I find that the system has one "up" and one "down" - being that, while the player can tell the city exactly what he wants from the coty, this system pretty much eliminates the possibility of creating specialists, a very progressive feature of the original civ4.

 

[dh_epic]

I wasn't saying this doesn't change anything, and we shouldn't bother. Obviously it changes a lot. The question is: to what end? Why isn't this just change for the sake of change? Adding religion or great people seems to have a neat enough payoff to be more than change for change's sake. (Even if I think religion was a waste of time to implement, and I'd like to see it cut/abstracted in the next civ to make room for another new feature. How about quantifiable resources?)

There's something a bit contradictory about what you're saying too. On one hand, the system is supposed to give you more control over your nation's coins and hammers. But at the same time, you claim it's also going to reduce micromanagement and what I like to call "math gaming" -- where you try to figure out how to turn 28 turns into 27 turns simply by minimizing the remainder in your long division. These seem to pull in opposite directions. So which is it: more, or less turn-to-turn activity? Can we even predict?

 

[Mxzs]

Well, I don't think it's a contradiction to say I want "good management" to replace a bogus choice between "no management" and "bad micromanagement." Right now, that's what the game gives me. I look at a city and wonder if it's producing a good mix of food, hammers, and coin. At that point, I can either throw up my hands and leave it all up to the city governor ("Look Ma! The machine's playing all by itself! No interesting choices at all!"), or I can spend a lot of time inside the city view, shoving citizens into and out of different squares and clicking on a bunch of plus and minus signs to adjust specialist production. But the latter is tedious and informationally opaque: I am never sure if I've got my citizens arranged in a less-than-optimal work arrangement and thereby leaving food, hammers, or coin on the table. It's a bad design, because it's hard to read, hard to manipulate, and the very devil to figure out whether you're getting your money's worth out of a city.

What I want is a system that tells me exactly how much food, hammers, and coin I can produce in a city, and how much of each I have to give up in order to get more of the others. And I want to be able to change the distribution with a few mouse clicks. That's called "management," and it's the easy-to-execute kind of management that we've already got with the Research and Culture sliders. With those I can tell at a glance how much my income will fall if I up my Research, or how much they both might rise if I cut my Culture. I don't think it's pointless or "change for the sake of change" to argue that Food and Hammer and Coin production inside a city could be managed with the same ease and transparency.

To repeat: I'm not looking for "micromanagement," I'm looking for a system that doesn't discourage even minimal management by making it tedious and fraught with uncertainty.

Moreover, I want a system that, by creating a linkage between coinage on the one side and food and hammers on the other, creates a common measurement system that would facilitate inter-city trading. Right now, each city is an economic autarky; it would be nice if they could fit together so as to complement each other's strengths and correct each other's weaknesses. That would be a place where "fundamental change" comes into the picture, but it would presuppose a more modest system like what I've proposed. So that's another place where it's not "change for the sake of change": it is designed to lay the groundwork for other changes to the way economies work in Civ.

Finally, I think that the proposal is in many ways quite conservative, because it does not presuppose a wholesale change in the way that resources are distributed, and it is designed to reproduce, as closely as possible, the overall results that cities produce currently in Civ. It doesn't do as well at meeting that latter test as I'd hoped—MontyLaremane has spotted one place where it seriously diverges from the current game (more about that in a later post)—and maybe a reconstruction would either have to accept some divergences or find more complex ways to control them. But that's a very concrete set of tests that the proposal would have to pass, and it's a set of tests I'm eager to see it subjected to.