Food and farming have been a bit of what one might call a “sticky issue” in Clockwork Empires. New players have a heck of a time figuring out how to grow enough food to feed their colony. They have an intuition that one is meant to feed people, that food is grown in farms and cooked in a kitchen, but how much do you need, and when? And what factors control these qualities? Hardcore players have created detailed charts out of data collected obsessively over hours of experimental play. They’ve cracked the system and learned how to optimize production.
There are two problems here. One, farm mechanics are effectively in a state of incomprehensible over-simulation. Two, the logistics of moving the food objects into the kitchen to be cooked is really the biggest time sink in food production.
The Logistics Problem
It’s simple: If you chart the total time a colonist spends executing a cooking job, the majority of that time will be in walking to the raw food, walking back to the oven, then carrying the cooked output to a drop-off. Logistics time compounded if there are multiple ingredients required.
The current best solution is to optimize stockpile placement by placing a food stockpile near your kitchen so that raw food can be dropped there for cooks to find and cooks can rapidly drop off cooked food after they finish production. This also requires that raw food by put into the stockpile which requires, ideally, a dedicated hauling crew.
Commodity hauling is performed by a workcrew with no other pressing task. The problem: players, particularly new players, tend to queue up a LOT of jobs – tree chopping, land flattening, terrain clearing, gabion building, construction, etc – so there is never a workcrew free for hauling. Therefore the entire food production chain bogs down as the cooking workcrew is forced to spend most of their time in logistics.
There are various possible solutions here we are examining, including more strongly signalling that hauling is indeed an important job category. Basically, it’s a UX problem around signalling to the player what is important and why then giving them controls to do something about it.
In the short term, starting at patch 47D or so, we decided to take the Sid Meier balance approach and simply doubled food output from workshops. This effectively halves the detrimental effect of excessive logistics, easing the situation for new players. Hardcore players find it much easier, but we’ll be providing … new challenges, let’s say.
The Farm Simulation Problem
I was really excited about making this system, uh, back in 2014 as per this blog post. Let’s revisit the crop-growing process discussed there:
- Plant crops in farm plot
- Wait until next growth stage timer triggers
- – this creates the “tend crops” job
- If job is not performed within period equal to the growth stage trigger timer, become spoiled
- If job is performed within the allotted time, go to next growth stage and start the next time
- (repeat growth stage / tending cycle until reaching the harvest stage)
- Harvest crops
This ends up as rather a more complex system than one might imagine. It was fun to implement from a simulationist perspective, but what does it mean from the perspective of the player?
There are several variables controlled by the player and several not. Let’s list them:
- field size (via placement of the field zone)
- number of workers (via worker assignment)
- overseer skill level (via choice of which overseer to assign)
One intuitively expects that increasing each of these values should increase production. Unfortunately this is not always true, and the effect can be far from linear. That is, 4 workers total is not simply twice as productive as 2 workers total. The change in productivity per worker can’t even be charted on a known curve (which would be almost okay), but can vary greatly due to the number of farming jobs available. What controls the number of farming jobs available?
- available farm jobs being executed, controlled by
- size of field thus number of crop objects
- delay between crops requiring farm jobs executed (varies per crop)
Further, every moment a crop is standing with a farm job available on it that it is not being worked, it’s actually adding to the total time required to complete harvest of one raw food commodity.
So that’s a pretty complex set of, collectively, highly non-linear factors that is in no way expressed by the UI. We added a concept of “labour required” vs. “growth speed” vs “yield”, but the effects of these qualities does not seem to be explained reasonably. See also how cabbage was a farming trap that stuck new players into a relatively high-labour requirement relatively low-yield food source. How is one to make sense of it? Well, by watching the simulation very closely and making careful charts of course! (This is not, by the way, an acceptable answer for UX. It was also suggested that we put such charts into the UI; also not acceptable.)
The question should become, what is the adherence to simulationism in crop growth adding to the game and what is it subtracting from the game? If it is subtracting more than it adds, then it must be excised. (See also: subtractive design.) So that’s what I did.
Restate our assumptions.
What do we want farming to do, what choice variables do we wish to provide to the player?
- Choose crop type
- Choose field location
- Choose overseer
- Choose worker allocation
The latter three choices are baked in to gameplay mechanics systems already at play in Clockwork Empires: there’s a concept of objects in space, of overseer assignment, and of worker allocation to overseers to form work crews.
You will note here the absence of field size – I think (now) that the idea of capping the possible rate of labour through field size was unintuitive, unsignalled, and generally a bad idea in the context for this game. We don’t have to lose this concept entirely however: we can make things really interesting by rolling field size into the first choice, of crop type. This makes crop choice a spatial problem to be solved: maybe wheat fields must be 20×20 while cabbage fields must be 8×8. This makes cabbage easily defensible, able to be placed densely, and logistically lighter. But perhaps the output per labour input is less. Maybe that’s made up by clever spatial placement — ah, now we are giving the player something interesting to work with! And all relevant factors can be expressed clearly to the player.
As for the field itself, let’s drop the idea of per-crop growth timer that stalls when it isn’t being worked on. The field itself is a black box. You put labour units into it until you hit the number required for harvest. Then the field dumps out a set amount of raw food. Simple. The only variable is how long it takes between harvests, and you control that through labour assignment, overseer assignment (thus skill), not letting the field burn down or get eaten by animals, … and some extra fun stuff that we’ll add later.
But all factors are on the table. All factors are easily controlled. No hidden timers, no hidden cap on worker employment. Let’s list the relevant factors to be displayed to the player:
- Number of generic “farming” jobs required to bring a field to harvest
- The number of raw food commodities output by a field’s harvest
We can easily derive some statistics from the above to give the player some useful information, such as:
- Average labourer input to the field per day (using previous day)
- Average number of harvests in units per day that this rate of labour will yield
These can be displayed in the farm UI and with this information the player can make the decisions required to feed their colony.
We also clear a ton of space out of the UI by putting crop choice into the building commands menu – that is, to set a crop field to a type, you build a “Wheat Field” or a “Cabbage Field” rather than selecting crop type after placing the field. This is necessary anyway due to fixed field sizes.
So that’s farming. This was far more straightforward to implement than the previous system, and it’s going to be absurdly simpler to balance. It’s almost there and will be released in Alpha 48B.