While I've have been working on the next update, a lot of additional delivery-related stuff crept in. So this patch is to summarize more of the bigger delivery-related changes.
Key changes
Villagers can now deliver up to 3 items at a time. Originally, I didn't want villagers to carry more than one item, because I wanted the screen to be filled with the peeps running around. This is a subjective reason, but then again, so are many of the decisions I make anyway. But in the end I convinced myself that having multiple deliveries per villager is actually perfectly fine.
If there are enough carriers, then most deliveries are currently still for just one item, because carriers run to deliver as soon as possible and don't know how to "trade tasks" or "add items" to their current delivery. In fact, the only reason they would need to carry more is when there's not enough carriers.
The item stack size is now 12 (up from 4). This means way more items can be brought and stored at buildings. The actual difference is mainly noticeable for larger maps and farther deliveries when carrier numbers and distances become the bottleneck.
These two changes shouldn't really affect small villages much, but should have a more major impact on larger villages and more spread-out villages.
Technicalities
So here's my "fun" design problem: pretty much all delivery issues I have or had can be solved by having more carriers. In fact, all my fixes and extra features are 85% mitigation of low carrier numbers with more elaborate ways to balance deliveries. And I am now mitigating the mitigation of these features...
Take this chain of delivery logic as an example:
• Only carriers used to carry items to a building (but this meant workers idled while a compatible item sat nearby)
• Then I made the workers themselves carry a nearby item (but this meant they spent half their time carrying instead of working)
• Then I added weights to prioritize carriers (but this meant single workers would still carry items over a far carrier bottlenecking their own production)
• Then I made worker wait a bit before deciding to carry (but this meant extra-far carrier was chosen even if the worker had nothing to do in multi-worker buildings)
• And then I made worker not prioritize work if they had none or there are others already working
This isn't too bad, but there's the rest of the game to consider. The biggest difficulty is adding all the tasks and commands that a villager could potentially do and then making sure everything is linked up correctly. I have an upwards of 200 commands right now. And more than half deal with deliveries.
Every item in the game is "real" -- it exists from the moment it is crafted until it is consumed. When a villager picks up an item or puts it in storage, it doesn't become a "number in a spreadsheet", it is still the same actual item with an in-world state, location and any history or properties it may have. The UI might not show it:
But all of them are separate internally:
Of course, all of that and other similar decisions were deliberate choices on my part. I knew I was adding complexity and difficulty for myself. But I really want the game to remain true to its simulation nature as much as possible.
Future plans
My future plans are pretty much as they were before. I'm working on the next update and it's most of the way done. It will add some high-level progression milestones and steps to the city as a whole. It will not hugely affect gameplay (yet), but I want to see how it feels and works before committing to further changes. There's also many other small changes that I can publish.
There are still various major and minor changes and improvements I want to make to the deliveries. But I will work on these at a later date, because they aren't critical and I really want to get the next update out soon.
Full changelog
Changes
• Change item stack size (i.e. building inputs and outputs) from 4 to 12
• Villagers (both carriers and workers) can now carry 3 items simultaneously for deliveries to building inputs and storage as well as building and road construction sites (it has to be the same source and target)
• Villagers carrying 2 or 3 items of the same kind will show a 2/3 stack sprite of these items (instead of a Basket)
• Villagers run slower when carrying multiple items
• Workers at buildings will prefer to continue their trade work rather than delivering items (e.g. Well worker will keep pumping Water instead of immediately delivering it)
• Rename "Book" to Blank Book to mitigate usage confusion with Codex
Fixes
• Pottery Wheel getting stuck in last production step thus providing infinite Unfired Pottery
• Fleece Tub potentially being able to skip needed Water for repeat operations
• House sentiment box tooltips not working
• High construction delivery priorities being ignored when there are many construction sites
• Clay Pit and Sand Pit not resetting the digging step, thus allowing quick item gathering
• Sound not playing on game launch if audio options background toggle is disabled
• Error when changing something in UI for inspected entity right as its state changes invalidating that change (e.g. switching construction priority of a building right as it is completed)
• Leaving a world to main menu with a window open and starting a world again would get the button responsible for that window stuck
• Top HUD tasks overview icons and numbers will now report based on tasks/deliveries/items that have been queued/waiting for a little while, thus preventing them from fluctuating wildly (e.g. on larger worlds they could be permanently in the red, while in reality all were being assigned, but with a short delay)
• Carriers would also wait a short while before accepting item deliveries like building workers (mostly just having a small pointless delay, but rarely also making an inefficient delivery choice)
• Building workers will not always prioritize their own task over delivering items if there are already other workers working (thus avoiding a case where a really faraway carrier would be called for something a worker can deliver nearby)
• Farther distances over which an item will be chosen for a delivery grows gradually over time (thus having a short grace period where a closer/nearby delivery could be chosen even if it becomes available after the item)
• Rare error when a supply task with multiple items was aborted
• Selecting a building would become increasingly laggier each time a save was loaded
• Items being dropped or consumed in some cases would momentarily be available and passed to threaded delivery processing causing them to be occasionally pointlessly picked for delivery only to be discarded
• Items would not get delivered when their internal delivery proportion demand values reached extreme thresholds
Optimizations
• Only several alike items from a larger stack (previously storage, but now also inputs/outputs) will report for delivery processing, thus reducing number of entities to check