A City-Building (Computer) Game, Part 1

This isn't for tabletops.

A couple years ago, I made a little game like Caesar III or Pharaoh (of the so-called 'City Building' series) where you made an industrial company town. Games of this kind have you place buildings connected to houses by roads, on which you have these little distributor characters follow random paths to give resources to houses they pass-by.

My own game took this format and also simulated an industrial capitalist economy following a super simplified (really, pseudo) understanding of Marx's analysis of capital, where the production rates of your company and other companies were compared with respect to individual types of goods--coats, bread, chairs, etc. The time it took to produce one such type on average impacted that good's worth on the market. Anyway, that's my background with this whole thing. I was really into that series of games and wanted to put my own spin on it.

Earlier today, I was thinking about some arguments between people who preferred 'random walker' games versus 'radius' games. A radius game is one where each building has a certain radius of effect, or houses have a certain distance they can access buildings within. Instead of optimizing pathways for random distribution by walking characters, you optimize the distance between houses and buildings. One game like this was CivCity: Rome. Some people thought it led to more realistic city-building, whereas others thought that radii are gamey and frustrating in their own way. I prefer random walkers myself only because that, to me, is a more compelling puzzle as far as laying out a city goes.

Still, I thought of a possible 'solution' to radius-based city builders. Why not, instead of having a single discrete radius, have ranges of radii that make a building more or less expensive to access? CivCity: Rome let you set the length of a working day. Longer working days produced more goods (I think), but made workers unhappy. The detriment is fair, but it seems like an arbitrary trade-off for something that could also have direct consequences on denizen lifestyle. In this post, I suggest defining resource accessibility as a function of how much free time a denizen has to travel across town, and how far away places are from their house.

The Time Factor

• h, a house
• B, a list of closest amenity buildings that h visits, each being of its own amenity type
  
• n, number of elements in B
• d[h, i] is time to travel from from house h to B[i]
• t[h] is time available for house h to visit buildings

Ideally, the sum of d[h, i] for i from 1 to n is equal to or less than t[h]. In other words, the resident living at the house should have all amenities within a reasonable amount of time to visit all of them.

Assume that B is ordered by priority, such that the amenity at B[i] is higher priority for h than B[i+1]. We want to find the maximum index k for which the sum of d[h, i] for i from 1 to k does not exceed t[h]. If k < n, then each amenity at B[j] for j > k is inaccessible to h. In other words, the house will choose only highest-priority resources given limited time to acquire them.

Let’s assume the working day is set to 8 and each resident sleeps for 8 hours so there are 8 hours of free time. We can let t[h] = 8 under this basis.

Amenity Accessibility

We can also assume 8 categories of amenities. The assumption is that the perfect house will have all 8 amenities in close proximity, with a base 8 hours of time to access them. I’m going to copy some of the categories from CivCity: Rome as examples.

1. Water
2. Meat
3. Tunics
4. Olive Oil
5. Beds
6. Religion
   
7. Bread
8. Entertainment
   

However, there do not necessarily have to be 8 amenities. We can scale time units according to how many we want a house to have, say 4. For example:

1. Water
2. Food
3. Goods
4. Entertainment

Then we can divide the scale of time by 2 such that one time unit is 2 hours: the working day becomes 4 TU, sleep 4 TU, and free-time thus 4 TU. The literal time isn’t important; I'm just rationalizing the abstractions and putting them in perspective with other possible mechanics.

Each house has a radius r, equal to how far its resident can 'walk' in 1 TU. If a well is within r, then it costs 1 TU to access. If it within 2r, then it costs 2 TU to access. This is fine if a house only wants water and food, supposing both are 2r away. However, then the house does not have time to access goods and entertainment (2 TU + 2 TU <= 4 TU).

Amenity Selection Algorithm, Part 1

Amenities can be selected according to a sort of knapsack problem where each amenity is prioritized using values that are powers of 2. This way, when summing them up into a total binary score, the components of the score are mutually exclusive with respect to what bits they occupy.

• Water: 8 (B1000)
  
• Food: 4 (B0100)
  
• Goods: 2 (B0010)
  
• Entertainment: 1 (B0001)
  

We know a house with score B1010 has water and goods, and a house with score B0110 has food and goods. We want to maximize scores while keeping their total distance at or below t[h]. Having water is prioritized over entertainment, and so are food and goods. Although the knapsack problem is NP-complete, the values here are so small that I feel like you can get away with a simple dynamic programming solution or even a greedy one (at the expense of the player’s sanity).

House levels can be defined as having certain thresholds for advancement.

• Level 1: Threshold 0
• Level 2: Threshold 8 or B1000 (Water)
• Level 3: Threshold 12 or B1100 (Water + Food)
• Level 4: Threshold 14 or B1110 (Water + Food + Goods)
• Level 5: Threshold 15 or B1111 (Water + Food + Goods + Entertainment)

The effect is that, for example, you cannot gain Entertainment before Goods and still advance your house, since the combination would then be 8 + 4 + 1 = 13. Houses will also prefer having just water over having food, goods, and entertainment.

When it comes to making the actual decision, I think it’s fine for houses to select and pay for non-threshold expenditures. Just because I can’t afford a house doesn’t mean I won’t eat avocado toast, or whatever.

Weighing by Path Distance

Although this post focuses on adding nuance to the radius system that often shows up in city-building games, we can also weigh different amenity sources according to how close they are in terms of distance-units rather than by radius. For example, if a building is 12 squares away from a house, it ‘weighs’ 12 squares. This would require higher values for t[h], say 5 for each TU (to be adjusted according to play-testing).

A house then with 4 hours of free-time can access buildings that are in total 20 or fewer squares from the house’s own square. Then, the ideal situation is that such a house has all necessary amenities within 5 squares or less on average. Again, if that turns out too stringent, you can increase t[h] per TU.

You can calculate distance as Manhattan length, or you can straight up find the shortest path between the house and each building. The latter might be too intensive if every house is calculating it once per game-week or whatever.