Workin’ the farm.
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 noble test plant! It tastes awful.
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.
Testing crop spawn positioning on revised farm code using generic shrubs as placeholder models. (Getting the visuals right is important! We have a lot of beautiful art and I still want to show it all off.)
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.
I hope the “extra fun stuff” includes some malfeasant claw bulbs. I really miss those things.
Poking away at crops and cooking for 18 months and then just throwing the complexity out is not a good solution. The changes you’re talking about sound awful, frankly.
Cooking takes forever right now because people are preparing one meal at a time. If you’ve ever seen a long line at an omelette bar, you’ve seen the problem in CE.
If you want to remove hauling as the bottleneck, increase throughput. You still have the same ratio of input to output, but inputs are increased. So instead of a person picking up one item of food and cooking it, let them pick up X items and cook them all at once. That lets you turn transport time way down per food item cooked.
The hauling bottleneck is actually a symptom of the larger issue: the logistics time (defined here as time characters spend moving from place to place) is too high for the system with the simulation of growth times of individual plants.
Characters need to walk to the plant (logistics time) and perform an action for each step of the growth of the plant. The action time is a very easily controlled variable, but the logistics time is *extremely* varied.
Increasing what they can haul in a given trip as you describe is actually a less effective version of the solution we proposed above, where you intend to batch together a bunch of the “actions” so that there’s only one unit of logistics time.
In the solution described above we’re similarly batching together a bunch of individual “crop maintenance” jobs into a single “work field” job in a very similar way, so that there’s only one unit of logistics time taken to reach the field rather than the 10 or 12 required to path to each crop.
There are a lot of very interesting game design philosophies going on under the surface here, but essentially we have found ourselves in a situation where we’ve inadvertently trained hardcore players to perform a series of obscure actions that make their farms extremely efficient, and by trying to balance that back we’ve created a system where a new player arbitrarily designating farm sizes and allocating workers typically ends in failure and starvation.
It’s what I would describe as a performance-reward gap that is way too big. We need to narrow the reward gap between mediocre planning and exceptional planning, and in this case, simplifying the simulation is the way to do it.
We’ll be adding more complexity from here, but this is where we’re starting.
(To add/clarify to this- )
There are actually many “crop tending” jobs done on a farm, not just one per harvest, but their assignment position is mostly random so the logistics overhead for that part averages out to match the size of the field. The key “fix” here is that there is no longer an arbitrary (and unknown to 99% of players) job cap that causes delays. Visually it looks about the same – and perhaps more lush, even, than before.
The logistics problems with raw food and kitchens and batching that stuff is a separate issue from the crop field changes. We actually agree on what would be a good idea with logistics; the farm revision and idea of job batching are not mutually exclusive developments. Farm revision, however, is incredibly cheap in dev terms compared to logistics revision, so that’s why it got done now.
So on to logistics: The suggestion regarding batching and carrying multiple items is something we have been considering on an ongoing basis. Implementation however is highly non-trivial. (Nor would it alone address the problem of the incomprehensible relations between crop timing and crop jobs etc etc. available in the old system.)
Hmm, hmm… interesting.
There are definitely some potential early-game implications of your proposed “black box” (well a farm with no crops is a black box) field design. Time for a big post perhaps.
Sounds great. I was going to try to respond to comments here, but the forum is better for an ongoing discussion.
Posted on:
https://community.gaslampgames.com/threads/17038/
I really don’t like the idea of removing complexity of farming by locking down the farm plot size. I’ve been lurking since the very beginning, and I felt this was important enough of an issue to actually speak out about for the first time.
I don’t know what a good solution would be though. Maybe show an estimated number of people a plot can feed based on the plot size, crop type, and assigned crew.
Very interesting! I very much appreciate your use of subtractive design, and seeing your thought process leading you to simplifying the feature was very insightful! Thank you for this post.
My only concern with simplifying features in any game is that it might reduce the possible depth some hardcore players might like to take with the feature. However, I think you made a great, educated choice with your simplification of the farming feature, particularly as it allows more amateur players to not get bogged down in the previously overly-complicated relationships at work in the feature.
Keep up the good work!
Yeah, I think “simplify” is a dangerous word to use when it comes to stuff like this. We hate it when stuff is “simplified” and “dumbed down” because it’s for noobs etc etc.
The problem here is essentially that there was a highly simulationist system that did not provide information about why anything was happening, thus creating lots of frustration. There’s a design maxim that is something like “if players can’t tell your simulation from a random number generator, then your simulation has a problem”. I believe that applies here.
So rather than “simplify” I’d say this is more like taking a system that was highly complex but totally inaccessible and incomprehensible (unless you looked through the code or did detailed studies) and replacing it with a system that tells the player what’s going on, gives useful stats, and lets interesting decisions be made. And THAT is fun!
A better verb for it is probably “gamify,” where one might observe a simulation-game axis and nudge it more towards one end rather than the other.
(what would the opposite be called? “simulatify?”)
“Streamline” has been used but over time all these terms get eroded into effectively euphemisms and have to be replaced.
“for tractability” would be one (gotta make the terms longer and longer)
I found the use of field size pretty obvious. One work crew per field, so if field is big and work crew is small, wilting happens. But I’m up for seeing what the new system plays like.
I watched a CE stream last night with Mike Laidlaw, and it looked like multiple times the citizens would walk over to pallets and pick up a food item and move it over one square to combine it with another food item of the same type. Sure this consolidates space, but when the rest of the entire pallet is empty the trip was unnecessary and it makes me wonder what they could have been doing instead of those(tending the flax?) and how many times that happened over the course of the game.
Awww, my charts idea got shot down. Oh wells, the new solution seems interesting, can’t wait to try it out.
I’m going to wait until I see how changes are implemented before I form an opinion on them, for better or for worse, but I do appreciate the sentiment behind them. It’s not easy, having identified a problem, to cut or change a thing that’s become an accepted way of life for reasons of sentimentality or some sort of sunken cost fallacy.
Another thing I’ll acknowledge is that superfans that read code and make charts (like me) are not a representative of the general public or prospective future customers. In some ways, we’re an edge case, and I understand that things sometimes have to be done for The Greater Good. I look forward to seeing what future changes bring.
Would it help if a worker could carry a stack of certain items, say 5 or so bushels of crop, when moving from field to stockpile? Moving stacks of raw food to cook will probably be harder since the game has to try to predict kitchen output if you have more than one cooking station in your kitchen without overcooking.
On a side note, short of building barricades to enclose stockpiles, will we ever get actual stockpile/storage buildings or warehouses? And then be able to lay them out so they’re part of the production buildings?
I have thought that for a long time the bottleneck is the kitchen and not the farm. In CE a cook takes one item and makes a meal. In reality a cook takes several items and makes many meals. A baker does not make individual loaves he makes a large lump of dough and makes 100 loaves. In CE a sack of flour makes nowhere near enough bread that a sack of flour should make.
The other bottleneck is the constant shuffling of items on stockpiles.
That’s some pretty neat thinking. I really like that you’re taking the ‘is this REALLY doing any good’ approach instead of the, sometimes game-breaking, ‘it is real and thus it must’ approach.
For example, Doom would be a much different game if reloading and clip-burning were part of the ammo logistics. Or is locational damage modifiers were in play. (omitting, of course, that it was 1993 and such things were wizardry at the time) Those things would ruin the raw action Doom strives for. While it might not ruin the game, it does ruin that intent of the game.
See Doom 3 and DNF.
Oh wow, this article certainly seems to have poked the hornets nest a bit. 🙂
Nice to see people have such strong feelings about agriculture.
Part of the problem too is with the placement of goods in the stockpile. I have my stockpile in front of the kitchen and farm land in front of the stockpile. Colonists will move food to the stockpile randomly, but then someone else has to come and move it so that everything is in the same stack. If we can change this so the colonists will only place items in the same stack for each continuous stockpile area, we can save a bunch of time.
Another potential solution is to build a grainery or pantry, so you don’t have to worry about which stack a particular good should go to.
Colonists are spending far too much time stacking things in a pile. I’ll have one colonist move raw food to the stockpile, then another one has to come move it so everything is in the same stack. It should just be in the same stack the first time around.
Another option is to add cylos, graineries and pantries so you don’t have to worry about stacks.
This really brings up the question of why in the name of hell were they only baking one or two loaves of bread at a time when they could do an industrial-sized oven to make a thousand (okay, not literally a thousand) loaves at once? Also there were free-standing (aka, not attached to the walls) types of ovens that existed back in the day and age Clockwork Empires, that could be really nice to introduce?
Also, I’m curious how come homes don’t have stoves, so overseers might cook their own food during their off hours?
Oh my god, thank you so much. The old agriculture system was infuriating and opaque, and as such impossible to make informed decisions about. This will be vastly superior.
From the way you described it, it sounds like the time a crop takes to harvest is now only dependent on the number of times it is tended? Does this mean you could rush a crop to harvest by simply assigning a whole bunch of people to work on it? Because that seems….odd.
Yeah, your standardized harvest will occur 5x faster with 5 people than with 1 person.
Not sure how I feel about that. It might be tenable in terms of mechanics, but it seems too counter to how things work in reality…
If logistics is the problem, then I have to ask: Will Logistics never get an upgrade beyond the personal hauling we have now? I remember that when this game was less concrete (i.e. before the first versions came out) the concept was to eventually have cities with an automated logistic system via pipes or conveyor belts. Is that now totally abandoned?
I don’t mind having preset field sizes for each of the crops, but I think there should still be an additional option for a custom field size. That was a super cool feature and I really don’t want to lose it. You could have the field sizes you’ve come up with be the maximum (ideal) field size, but using the custom field size option, allow smaller fields that produce at a rate in direct proportion to the non-custom field size.