A City-Building (Computer) Game, Part 2

Other conditions can be slapped onto acquiring amenities. For example, there can be different qualities of each amenity category, costing more money. An additional 'weight' for goods is a whole other can of worms, though. In this post, I'll just be talking about how to treat the different qualities themselves.

We can represent tiers of amenity types mathematically. Before, the value threshold for house advancement could be represented using 4 bits (e.g. first level is 1000, second level is 1100, third is 1110, etc.). In a 16-bit unsigned short integer, then, we could have up to 4 tiers of 4 amenities, or some other combination.

However, the way in which things are prioritized (and thus how our threshold values for house advancement are defined) depends on factors such as whether higher quality tiers replace lower tiers or are added onto them, or whether higher quality tiers should be prioritized over total number of amenity types.

Single Bit Assignments

To simplify the problem, let’s say there are just 2 tiers (1 & 2) and our 4 previous amenity types (W, F, G, E). In practice, not every amenity needs the same number of tiers. The methods below assume that acquiring amenity A of tier X means that the bit assigned to AX = 1, whereas all other A bits are 0. This does not have to necessarily be the case, as will be discussed.

Method 1: [W1] [F1] [G1] [E1] [W2] [F2] [G2] [E2]

Tiers are successive. A house will prioritize getting entertainment E1 over getting higher quality water W2, for example. I think this method is the most straight-forward, but not necessarily rational (at least not for water, where you’d be okay with just one source of it, but would still want higher quality over lower quality).

Method 2: [W1] [W2] [F1] [F2] [G1] [G2] [E1] [E2]

Tiers are successive, but getting higher-quality amenities is prioritized over getting more types of amenities. A house will prioritize getting higher-quality water over getting entertainment, but (presumably) it is not only preferable but necessary to first acquire low quality water before or in addition to high quality water. That’s sort of weird.

You also can’t use thresholds the same way since W1 + W2 exceeds the threshold W1 + F1, so unlocking food becomes less significant than getting higher quality water.

Method 3: [W2] [W1] [F2] [F1] [G2] [G1] [E2] [E1]

Highest quality water is prioritized over any water. This is nice, but it breaks thresholds the same way as method 2 if not in an even worse way. Having W2 trumps any threshold below its own value.

None of these solutions really work the way I want them to.

Multi-Bit Assignments

However, we can have our cake and eat it too by letting higher quality water not only set its own bit, but also that of lower quality water. Looking at Method 1 in the previous section, each tier of amenity is assigned a power of 2:

• W1: 128 (B10000000)
• F1: 64 (B1000000)
• G1: 32 (B100000)
• E1: 16 (B10000)
• W2: 8 (B1000)
• F2: 4 (B100)
• G2: 2 (B10)
• E2: 1 (B1)

To account for higher-tier amenities that substitute their lower-tier amenities, include the value of the lower-tier amenity with that of the higher-tier one.

• W1: 128 (B10000000)
• F1: 64 (B1000000)
• G1: 32 (B100000)
• E1: 16 (B10000)
• W2: 136 (B10001000)
• F2: 68 (B01000100)
• G2: 34 (B00100010)
• E2: 17 (B00010001)

The effect is that having just W2 scores a house as B10001000 which is enough to meet the threshold B10000000, but not the threshold B1100000. At the same time, it is necessary to have W2 in order to meet the threshold B11111000, since you cannot get W1+F1+G2+E2 (B11110000) and meet it.

The issue becomes, when maximizing scores, a house might prefer to have both W1 + W2 over W1 + F1, since W2 > F1. The solution then is, instead of taking the sum of scores, find their bitwise disjunction. W1 | W2 = B10001000, whereas W1 | F1 = B11000000. Water and food is then prioritized over water without food, no matter the quality of the water; at the same time, higher quality water is still prioritized over lower quality, and having one is mutually exclusive with having the other. Therefore our priorities are (W1 | W2 | F1 == W2 | F1) > (W1 | F1) > (W2 | W1) == (W2) > (W1).

In Combination

You can have a combination of single-bit-assignment amenities and multi-bit-assignment amenities, to represent amenities that are accumulated across tiers versus tiers that replace their lower-valued versions. Consider a listing like below:

• W1: 128 (B10000000)
• F1: 64 (B1000000)
• G1: 32 (B100000)
• E1: 16 (B10000)
• W2: 136 (B10001000)
• F2: 4 (B00000100)
• G2: 2 (B00000010)
• E2: 17 (B00010001)

W2 can substitute for W1, sharing the bit that makes W1 a priority over other amenities. However, F2 does not substitute for F1, but it exists beside it; it is more valuable to have F1 | F2 than to have either individually. In the above listing, water and entertainment are amenities that you get just one of, whereas food and goods are amenities that you want multiple types of (each with their own priority).

A house with access to {W2, F1, G2, E2} has a score of B11101011. This is really nice, but it’s not the score you need to meet the threshold B1111100. You still need G1 and F2, and you don't need G2 or E2.

Multiple Types of the Same Amenity

In Pharaoh, your people try to acquire multiple types of food. They will prioritize certain types over others, e.g. grain > meat > lettuce, but it’s not a matter of possessing more and better types of food as much as it is just possessing more types of food in general. More is better.

This requires some extra logic to integrate into our existing algorithm. Assume there are two sources of food, a bakery and a butcher. Instead of one being assigned to F1 and the other to F2, we first set F1 = 1 for one of the sources if F1 = 0. If we have F1 = 1 already, then we set F2 = 1. The effect is that F becomes a category like W where you just get better (i.e. more) food, rather than getting more and better food. In other words, more food is better food.

I think that Emperor accomplishes something like this but it abstracts it, since markets collect individual ingredients but distribute meals of various qualities depending on how many types of ingredients they possess. One ingredient results in poor meals, whereas two ingredients results in better meals, et cetera. Since the house knows what quality of meals it has but not what ingredients made up those meals, the determination of meal quality seems totally abstracted. This is extremely convenient for both the developer and the player.

For a radius-based game, you can replace food-types with meal-qualities and have meal-sources emanate quality of food rather than different types of food. Therefore we can have values like the following:

• W1: 128 (B10000000)
• F1: 64 (B1000000)
• G1: 32 (B100000)
• E1: 16 (B10000)
• W2: 136 (B10001000)
• F2: 68 (B00000100)
• G2: 2 (B00000010)
• E2 : 17 (B00010001)

Where whether a market offers F1 or F2 depends entirely on what ingredients it has, and this is abstracted from the house who doesn’t know or care. All it knows is that F2 is better than F1, and so it can pick that one.