This update replaces Markets with Shops and adds significant rendering optimizations. And I might as well call this "Rendering Update", because I spent most of the time working on optimizing sprite drawing.


Shops are new buildings that are set to replace Markets and Market Stalls.



They essentially do the same thing that Stalls do, except each shop can store and distribute several item types. For example, a Produce shop would sell Tomatoes, Carrots and Potatoes at the same time:



Shops allow me to add more items without adding a lot of micromanagement to Markets and Stalls. I can instead focus on logical item "groups", such as foods, supplies, clothing, well-being, luxuries, etc. The gameplay would then not be so much about having exact items, but a decent variety of items and an overall satisfaction for that item group. It's also much easier for me to design for and players to work with fewer categories.

For now, Markets and Stalls will still work, but they are tagged as obsolete and will be removed (probably) in the next update. Basically, I'm leaving them working so anyone who wants to update their world can do so. Unfortunately, I cannot maintain two versions of item distribution, so I will have to completely remove Stalls later. I also cannot automatically replace them in-game with shops, because shops are 7-tile buildings.


There are now 2 more larger world size options. Thanks to the optimizations, I am finally able to create bigger islands without lagging everything. These won't have better terrain generation yet and the camp still spawns in the middle, but at least they are an option now.

Animal habitats now have to be selected to see their information:



This is mostly because I could not easily re-implement in-world tooltips following the rendering changes. But I also had this planned regardless, so I just went with it. There isn't any new information yet (notably, about quality factors).


So the problem is: MicroTown's rendering is fairly slow because there are a lot of things to draw. I should note that MicroTown being "just" pixel art is rather deceptive. The game needs to render more geometry than many 3D games and, for various reasons related to how GPUs work, it's not much cheaper to send "just" sprites to render than it is to send 3D models.


Optimization should generally be done based on profiling, i.e. evidence. So, most importantly, I need to count the number of sprites that are required to draw everything in the game world. For my test case, I am "looking" at a 1440p resolution zoomed-out 160-size world with 2000 villagers. These are the numbers of in-world entities that exist in the world:



This is a rough indicator of how much "stuff" needs to be drawn, but it's inaccurate because each entity does not correspond to a single sprite. There could be zero to a dozen of sprites needed for an entity, depending on many factors. This also does not account for many extra things, like effects, tile overlays and outlines, markers, building icons, etc.

So here are the numbers of individual sprites:



These can be further broken down into broader categories:



The numbers I am most interested in are the 25k/54k renderers. This is how many sprites need to actually be drawn out of the total sprites that exist. Importantly, there are 5k updates per frame, which means that that many sprites were changed, added or removed.

Which means there are two main focuses for entity processing optimization - knowing what to render and processing changes quickly. Subsequently, the main rendering optimization focus is to render the visible sprites as fast as possible. And these two sentences are so much easier said than done.


The main bottleneck is the CPU time it takes to render the game world. Unity works with "game objects" to do things, broadly speaking. For the game world, I only use game objects exclusively for sprite rendering (no data or logic there). Each sprite renderer requires a separate game object. So every sprite I mentioned above requires a game object, which is easily 50k objects. Meanwhile, for Unity, general consensus is that 10k objects is too many.

I basically have these long long lists of objects:



Unfortunately, there is only so much I can do before Unity itself bottlenecks like this. I've squeezed out as much performance as I could with this setup. Without going into too much detail, there are too many engine-dependent things happening that I cannot change in any way like sorting, culling and communication with the GPU. Unity simply isn't built to support so many objects via its "conventional" game object means. It doesn't matter that the GPU renders everything in 0.5 ms when it takes 25 ms for Unity to prepare and send the data. It still has the overhead of all those universal game objects regardless how many are visible and how cleverly they are optimized for rendering.

So here comes the technical and difficult part...


After lots of research and experiments, I decided that I would need to bypass almost all of Unity's "standard" rendering overhead and send sprites to the GPU more-or-less directly. This is essentially how most GPU-based 2D games have always done this. Simply put, "draw sprite S at X, Y" for every sprite. Unfortunately, this is much easier said than done nor does it capture the many complexities. Unity isn't a 2D game engine and all its features have many layers of expensive abstraction. But thankfully Unity does provide rough access to lowish-level graphics logic.

In short, I can send a mesh to render directly to the GPU. A mesh is just a bunch of triangles connected at their vertices. In my case, to show a sprite, I only need a quad -- a rectangular mesh that is 4 vertices and 2 triangles.(This is also what Unity uses by default for sprite renderers, except with a lot more stuff.)



I can not only send a mesh once, but "send" the same mesh again and again, which is called GPU instancing and which saves the day. Technically, I am not even sending multiple meshes - just the one quad, but I am telling the GPU where to draw copies of it. So each quad mesh would correspond to one sprite and I would send a batch of such sprite data to the GPU to get them all rendered at once really, really fast. This lets me render any arbitrary layout:



Fortunately, I have built the game in a way that allows me to fairly easily "collect" all the sprites I need to render (which still massively downplays the difficulty of this conversion). As I described, I have game objects that correspond somewhat to game world entities. I know where they are located and roughly in what order. So I "just" need to pass these to the GPU myself. It would look something like this (with a colorful test texture):



Except, there are no "sprites" on a GPU, there are definitely no sprite atlases. All the "sprites" here look the same. Because a "sprite" is a high-level engine abstraction done through custom assets, custom shaders and lots of engine code. All I get at low-level is a texture and raw vertices and pixels. What I really need to do it specify locations on the final atlas texture, so I can draw specific sprites that would be arranged there (these are 16x16 "squares" from the same 2048x2048 test texture):



The next step is to somehow combine individual meshes and send things to the GPU in batches. The problem is communicating what data I need to send per mesh, that is, per sprite. Naively, I can only set one property per communication, which basically results in every sprite in a batch being the same:



The solution is that modernish GPU shaders can be compute shaders, which can receive and process large chunks of arbitrary data and run (parallel) processing on the GPU. This means I can actually pass all the sprite information to the shader in one big batch very efficiently. This data can then be sampled to select the correct region from the atlas texture from the sprite's location data for each mesh/quad.

And this provides the starting basic functionality of rendering sprites directly to the GPU almost the same as game object sprite renderers, but for a tiny fraction of the cost. Here is the pipeline itself working correctly if not the logic of drawing everything:



This does unfortunately come with a bunch of significant drawbacks that can be summarized as "additional complexity" and whatever is the opposite of "ease of use". But I can live with these considering the speed benefits.

The new problem is that now everything that Unity did -- sort, cull, toggle, offset, scale, etc. -- is gone. I now need to make it all myself.


Most importantly, I can't just "render all sprites" in whatever order they are (unintentionally) stored. I can technically do that for tiles, roads, and tile overlays, because they never overlap and are exactly spaced. But every other entity must obey visual depth sorting. Simply put, a unit can walk in front and behind a building while still being in the same tile. But sending sprites to the GPU is fast precisely because it ignores such pre-processing details and just draws things sequentially. Just rendering naively would result in this:



Thankfully, my job is simpler than it could have been trying to sort 50k entities -- I already have a game tile hex grid. Every entity has a whole tile coordinate and I can hugely optimize sorting by looping through the tile coordinates in "visual order".

Entities also have in-tile fractional coordinates. So I have to loop through the entities in a tile back to front. For optimization purposes, I have to keep the entity list pre-sorted and add and update entities as their coordinates change. And this basically correctly sorts 90% of sprites.

The final consideration is that for entities at the same coordinate (like parts of the same building), I need an extra hard-coded depth-sorting value so they appear in the right order even though they are technically at the same location.

Sorting is probably the most time-consuming part to implement because I have to change and adjust so much code. Every one of these "considerations" is another layer of complexity and difficulty. And with all that, I am only now approaching the same visual results as I had at the beginning:




Another important consideration is to cull anything that is not visible, that is, literally not render sprites that are not on screen. It's a simple problem to explain, but deceptively difficult to implement efficiently. I cannot just check 50k items every frame. So I keep a list of entities per-coordinate, update the lists when entity coordinates change, and loop only through visible coordinates when rendering:



The biggest consideration is that whatever code logic I do, I will be CPU bottle-necked and I cannot offload this work to GPU in any reasonable way.


All the small effects in the game were provided by Unity's particle system -- smoke, dirt, chips, sawdust, etc. It was all relatively easy to set up. And none of this works anymore with the custom rendering pipeline. Unity's particle system wasn't compatible with how I rendered regular sprites. So I had to recreate the effects myself -- all the logic, animation, sprites, visuals, previews, etc.

There are now some new optimization considerations. For example, various effects like digging dirt used the same basic logic where a 1-pixel particle would fly out. There would be some 12 particles, which equates to 12 sprites. This is actually quite a lot when you consider they have to follow all the new rendering/sorting logic I implemented. I now have to design effects paying attention to the number of sprites they produce and optimize when I can. For example, I can use only 4 sprites if I make an "animation" of the particles splitting up as they spread over time:



My favorite effect -- smoke, which I painstakingly recreated -- takes up 8 sprites:



Here, there's nothing I can do to reduce the number of sprites, and it will be slower than Unity's particles were originally. Of course, I am considering the big picture performance and presentation, and nice effects are definitely a worthy "expense".


There is so much to talk about, because I am now revisiting 3 years worth of various visual features. But one of the cool easy-to-add changes was adding shadows for units:



These are very subtle and usually get lost in the "noise". But they subconsciously feel good. I couldn't add these before because they would get incorrectly rendered on top of other things - buildings, other units, etc. - because units would run all over the place and cause depth-sorting issues. However, now that I am "sending" sprites into layers for rendering, I converted all shadows into a "shadow layer", so they get drawn on the ground before any sortable objects, thus they are always on the bottom. This fixes a lot of shadow glitches I had, as well as lets me add shadows without worrying about problems like this.

In fact, I have a lot of new debug tools I had to make to visualize and find all the different parts. For example, a shadows-only preview:




All this fancy shader stuff is great and all... except many older systems don't actually support it. The whole GPU-based compute shader processing is a relatively new concept. In fact, systems older than 3 years are increasingly unlikely to support it. Whereas even 15-year old machines could run the game before. Virtual machines also don't support advanced 3D accelerated graphics, which means I cannot test the game on macOS and Linux with the new rendering logic. This is also not something I can afford.

I did not enable analytics in the game, so I have no idea what systems MicroTown's players have. But the game has a strong retro vibe and I would not be surprised nor could I fault any players for trying it on an older system. So I have to support them. Which means implementing a fallback method for rendering everything.

(Un)fortunately, I cannot just fall back to my original Unity-based rendering, as I have essentially changed and rewritten everything. Thankfully, I have about 90% of actual logic reusable, because it's only the communication with the GPU that cannot utilize fancy data transfer logic. I have my list of sprites, their location, atlas information, etc. So "all" I need to do is replace the fancy shader stuff with a dumber, slower version.

Naively, I would basically have to send a mesh per sprite to the GPU one at a time. This is too slow (even with native batching), but I can also combine these meshes together. Which is also too slow with Unity's tools (but comparable to how fast the game ran before). So in the end, I am manually re-constructing meshes vertex-by-vertex to match the expected "sprite layout". It still makes things very CPU-bound, but it's still better than before. The biggest problem is just the human time it takes to get everything implemented and running smoothly.


Most of the time I was looking either at a complete mess like this:



or this:



Or trying to fix one of the 100 different things that were glitchy:



I even discovered 2D MicroTown:



As a final thought, I only summarized the "correct" path to implement this. I spent a lot of time experimenting, agonizing why something doesn't work and getting exhausted by debugging. And this is besides Unity crashing every time it doesn't like something. The power of working directly with shaders is great and the results below speak for themselves, but it's also equally mind-numbingly tedious and disproportionately time-consuming. As a one-man team, I can't detour through such rabbit holes unless it's absolutely necessary.

So I'll end this with some benchmark comparisons. (I am not comparing FPS, because this isn't an accurate measure for games like MicroTown. The game doesn't have a fixed time step and fewer updates just means it has to process more changes.) These benchmarks are done on a 1440p resolution zoomed-out 160-size world with 2000 villagers drawing 25k entities (same as in the section on entities above) on 4-year old high-end hardware:


A full frame now takes 34 ms instead of 63 ms, which is almost twice as fast. Notably, specifically rendering now takes 6 ms instead of 35 ms before, which is more than 5x times faster! Even the fallback method takes "only" 25 ms. It's still only 30 FPS, but this is also an extreme case. I think I have squeezed out as much performance as I will be able to from rendering. But I could also easily add more entities and sprites without a significant performance hit. (In fact, I imagine most of the future optimization will be to the world update logic. In these examples, world update takes around 20 ms.) Of course, this will vary system by system, but there should be a significant improvement for all systems because the game is CPU-bound.


I originally planned for "Shops and Houses" to be the next update (i.e. this update). This would have allowed Houses to use more items so that Shops can sell more items and then I could add more production chains and variety. But I only managed to get the Shops working, so the next main goal is getting Houses working. This will likely be a smaller update, but with bigger breaking changes. The Houses will likely also become 7-tile buildings.


Changes

• Market Square, Food Stall and Supply Stall are scheduled to be deprecated; they will remain functional for the current version, but will need to be replaced by Shops
• Optimized rendering requires compute shader support: at least DirectX 11, OpenGL 4.3, OpenGL ES 3.1, Vulkan or Metal
• Older system will fall back to a slower rendering method
• Add shop buildings: Grocery Shop, Produce Shop, Meat Shop, Clothes Shop, Supplies Shop, Medicine Shop with corresponding sold items
• Shop building HUD inspection to show full item "progress" (unlike market stalls)
• Add Shop concept
• Tooltips to show sold items at shops (similar to storage building tooltip)
• Export Station and large storage buildings will distribute items directly to nearby shops
• Market Square, Food Stall and Supply Stall are no longer constructible but will remain functioning as before in the world
• Rename "Fish Steaks" to Raw Fish
• Rename new game world size options from "small", "medium" and "large" to "tiny", "small" and "medium"
• Add "large" and "huge" new game world size options
• Fish Animal Habitats will no longer spawn far away from coast
• Remove tutorial steps for Market Square and Food Stall construction and replace with Produce Shop construction
• Adjust tooltips and explanations mentioning Market Square logic to instead describe Shops
• Animal Habitats no longer show tooltips on mouseover; instead Habitats can be selected in-world and show an inspection panel with the same information and changed display
• Add in-world markers for Animal Habitats animals
• Shadows now appear on the "tile layer" and don't overlap other objects
• Tile outlines, selection indicators and other tile overlays appear above roads
• Markers and various indicators now appear above in-world objects
• Mine, Sand Pit and Clay Pit prepared ground sprite now appears on the tile "layer"; adjust worker position and mining effect offset
• Villagers and animals now have shadows
• Add water splash effect to fisher casting and reeling animation
• Micropedia now has "Tutorials" section/list
• Item tooltips and Micropedia descriptions now combine storage entries to multiple buildings
• Add tooltip and description for Beer and Mead usage at Brewery
• Add amount label to (de)construction item progress for building and road inspection
• Add warning in main menu if compute shaders are not supported and the game will run a slower fallback rendering method
• Path-finding will discourage walking between buildings as much
• Units will no longer stick to exact hex tile centers when path-finding and choose straighter paths
• Workers with carts entering and exiting Export Station and Import Station will now move at a non-slowed down speed
• Hunting goal now counts skinned (but not shot/hunted) animals as part of the completion number
• Add internal "animals skinned" stat
• Roads to have separate sprites for vertically-mirrored bits and new dedicated sprites for the straight segments
• Add a more-expensive Boardwalk type of Roads that can built on otherwise unbuildable land tiles (Sand, Rocks, Clay)
• Add Boardwalks tech
• Add Boardwalk construction Goal
• Roads to have a new dedicated sprites for the three-way segments
• Animals now walk instead of running (internally, since visually these are the same speed and animation currently)
• Fish move faster to bait/hook
• Idle villagers will walk more instead of running, especially for short distance
• Adjust Import Stations item positioning so all stacks fit on the same tile
• Import Stations will also distribute their items to Food Stalls and Supply Stalls
• Large Warehouses and Large Granaries will also distribute their items to Food Stalls and Supply Stalls
• Add issue warning for large storage buildings that have dedicated workers but no compatible item sources or targets
• Large storage buildings to mention how workers operate in the description and change range explanation label for construction

Fixes

• Micropedia search bar results would disappear when clicked before the click is processed and would not navigate to the clicked entry
• Raw Fish item distribution proportion unintentionally defaulting to weight of 1 instead of 3
• Oven operation progress not showing correctly when the worker is activating the cooking process
• Export Station and Import Station not showing all item delivery marker icons
• Florist missing tooltip/Micropedia information line about Flower "production" from Seedlings
• Brewing Vat not showing cooking sprite and smoke
• Building workers still accepting tasks from far away blocking other workers from and choosing them until they arrive
• Building worker with no task going to the building from far away even when the slot is disabled
• Building construction and deconstruction markers now appear on the tile "layer" and don't overlap other objects
• Mouseover tile would occasionally be momentarily incorrectly calculated
• Various sprite fixes
• Path-finding will avoid leading units through single-tile buildings
• Fix path-finding not considering "exiting" a building tile in a proper direction
• Path-finding will prioritize "front" tiles for multi-tile buildings and avoid going through "occupied" building tiles
• Path-finding will again avoid leading units through fields/plots/pens, but take corners instead
• Animals will properly ignore pathing restrictions and walk in pens as desired
• Fix path-finding choosing sub-optimal shortcuts
• Fix villager slowdowns when running between certain road tiles, most noticeable with carts
• Animal Habitats not spawning
• Graph window not working when loading previous version saves
• Acquiring items not present in loaded saves causing an exception in internal graph logic
• Export Stations sometimes not delivering items when one of its target Import Stations has a full stack of that item
• Technology panel buttons having mouseover detection region larger than the button itself
• Skinned animal stat not being recorded in saves
• Animal Habitats not despawning when reaching a low score
• Fix large storage building worker incorrect waiting locations
• Import Stations and large storage buildings would not fill up compatible building items fully
• Fix exception when loaded saves would fail to assign unit idle locations
• Remaining items not appearing in the world when extracted from stacks
• Internal ID conflicts between units (namely Pigs that are led to Butcher) and items would cause one or the other to be excluded from future deliveries for the ongoing session
• Import Station issue verification causing internal exceptions while it's constructing
• Large storage building issue verification incorrectly triggering when there are compatible item source buildings in range
• Building issue verification for required auxiliaries would incorrectly show double-issue for buildings with multiple auxiliaries
• Building issue verification for issues that have a building of item list to report would not update the tooltip if these lists changed

Balancing

• Garden Plots, Crop Fields, Tree Nurseries and Animal Pens now cost 2 Planks instead of 3 (and 1 Stone Slab)
• Import Stations can now distribute up to 6 items to nearby targets
• Large storage buildings can now distribute up to 6 items to nearby targets
• Double Large Barn and Large Granary capacity
• Increase Forester operation range from 3 to 4 to match Lumberjack operation range

Optimizations

• Redo rendering pipeline and significantly reduce CPU usage and overhead
• Most visual-related logic has different performance cost, usually reduced
• Small, emptier worlds run slightly slower, but large worlds run significantly faster
• Increased memory usage
• All particle effects are redone and slightly different due to using a new system
• World entering is slightly faster
• Reduce redundant unit internal animation processing
• Speed up villager idling location lookup
• Entering (generating, loading) and exiting a world is slightly slower due to the pooled objects now having inefficient hierarchy for mass changes
• Processing (pathfinding and delivery processing) threads sleep longer and more frequently when idle freeing CPU usage
• Internal game logic is now capped at 90 FPS, so faster machines do not do needless processing
• Slightly fewer HUD rendering batches
• Building issue periodic checking is faster
• Many minor optimizations

Rudy
Snowy Ash Games

This smaller update adds fish animals and fishing to the game.


Firstly, fish will now spawn in their own water-based habitats:



These work very similarly to land-based habitats, except for the requirement to be in shallow water. There are three types of fish/habitats: Striper, Salmon and Marlin.

After unlocking the Fishing technology, a Fisherman's Hut can be built. The workers will go to the nearest coast with fish and cast a rod and wait for a fish to hook:



This catches the fish corresponding to the animal's species:



(I considered whether a "caught fish" should be the same item or if each species should have its own. There is no functional difference and I doubt there ever will be. But the extra items do take up the extra space in UIs. I don't really mind this too much and I find it cool to have variety. Although I might need to eventually figure out some sort of grouping of similar items, like in the Item Report window.)

The raw fish then has to be taken to the Fishmonger building, where it's prepared into a Fish Steak at a Gutting Table:



From there, Fish Steaks are taken to the Smokehouse, exactly the same as raw Meat:



In fact, this is so exactly like Meat, that the item produced is also a Roast. I guess no one can tell the difference. But, on a serious note, I do not want to add more food or supply items at this time. There are already 12 of them and the way Markets and Houses handle them is rather subpar. Taking each individual item to houses and having houses track each of the 12 items is simply too cumbersome. So this is a compromise until I rework the villager "shopping experience".


No day goes by when I don't discover there is some complex backend code that I need to work on to enable a feature. Of all the things to break, I didn't imagine imagine fishing would break path-finding so badly.

First of all, fish "walk" in water, so I had to create rules and separate tile "swimmability" flags that path-finding can use depending on how a unit moves (i.e. on land or on water). But that's relatively easy.

Instead, I discovered a bug where workers could not find a path to some buildings that were built on the coast (i.e. if grass would touch the water). To explain the problem, I need to quickly explain how path-finding coordinates work in the game.

The game uses hex tiles, and so the coordinate system is not a straight-forward X-Y horizontal-vertical axis. But for that the path-finding is still not too difficult to "solve", I just have to be careful how coordinates are assigned and what directions are allowed for movement:



(If you want to know more technical details on the basics of hex grids, then look no further than the excellent https://www.redblobgames.com/grids/hexagons/ guide.)

The tricky part is that I don't actually want movement just between tile centers. You likely have noticed that workers run between buildings, although it would not be obvious how path-finding does this when you consider the coordinate system it works with. For MicroTown, I only allow movement between the adjacent centers and corners:



In fact, internally, I have 3 times as many path-finding "nodes" as tiles in each axis direction. Here are the node relative "distances" and "missing" nodes from the full path-finding data:



So in fact units cover many more "locations" and "routes" to reach them that just moving between tiles when looking for paths:



Besides walking between structures, another important reason why I am doing this is because units need to access certain buildings from a certain direction. For example, the fisherman has the door pointing South-West, so workers need to use the South-West tile or corner:



And this was where the bug happened. The design-to-implementation question here is: which tile does a corner belong to? And in what directions does each corner enable access to buildings? Because each corner is part of 3 tiles:



This does not matter on land. But I had not carefully debugged what happens near the coast (in fact, I had to implement the above visual debugging to see what was going on). Depending on direction, corners would use the water tile to decide if they can be traversed, thus making buildings inaccessible.

So to do this properly, when I update path-finding data for a tile, I am also updating corner path-finding data. I need to check all the adjacent tiles, because every corner has a combination of 3 different tiles. For land-based path-finding, this means allowing corner movement if any "connected" tile is a land tile. So, in essence, every coastal tile is fully walkable:



Of course, this is just one aspect of what is needed and there is much more happening, like road priorities, multi-tile building avoidance, full-tile movement preference, direction-dependent movement validation, preferred route distance estimation, etc. Much of the difficulty of changing such a fundamental system is all these additional factors that have to keep working.


One of bigger UI changed is that all technologies are now in the same window and tab:



I basically removed technology branches, because they served no real purpose other than to have empty unfinished-looking tabs in the tech window. It also seems like most technologies are some sort of production ones anyway.


In the future, for the fishing specifically, I can imagine adding something like fish oil item for... some purpose. I can also imagine more fancy foods, like crabs, or specific items, like pearls that could be acquired. I originally thought that fishing would be done in boats, but decided not to over-complicate the matters at this point.

I also think Hunters would eventually have a dedicated skinning/preparation building where additional items are produced, such as furs. Then I would have individually-itemed animal carcasses similar to fish species.

However, the big plan is to improve the Market logic. I am more than happy that many long production chains culminate in arrival at the market. But I am rather unhappy with how individual per-item market stalls have to then distribute the items to individual House slots. I think this is boring linear micro-management. Basically, the market may as well have come with the stalls "pre-installed" for all the use their exact layout does.

So I will likely "convert" stalls into shops of sorts, like a Meat shop or a Produce shop or a Clothes shop. That way, I can have a similar number of shops as stalls, but they can "sell" several items and thus overall, it would be a much larger variety of items. This would gradually enable me to add currency as well. Then the central Market "authority" would be responsible for taxing the shops or some such. This is very likely what I will work on next.


Changes

• Add Fisherman's Hut building
• Add Striper, Salmon and Marlin as "wild Animals"
• Add Striper, Salmon and Marlin items fished from respective fish animals
• Add Fishmonger building with Gutting Table
• Add Fish Steak item produced from fish
• Add water-based Animal Habitats for the new fish species placed along the shore
• Land and water Animal Habitats have separate spawn rules, locations, habitat score calculation rules, visuals and various other properties
• Game Warden's Lodge is now specifically for land-based Animal Habitats only (and mentions this in description)
• Add Fishing tech, unlockable from start
• Add fishing Goal to catch fish
• Add "Animals hunted" and "Fish caught" (internal) statistics
• Smokehouse and Drying Rack can now also cook Fish Steaks into Roast (for now)
• Adjust building worker idling locations
• Idle building workers will now occasionally rotate
• Add concepts: Livestock, Game, Fish
• Not showing icons anymore for in-text concepts
• Canceling building deconstruction before it begins will "suck back up" building's compatible items
• Import Station to show item stacks separated
• Remove technology branches -- all technologies are now on the same page
• Technology window entries no longer show their name labels
• Technology window will resize to fit more of the screen vertically and can now scroll its content vertically
• Mr. Piggles' portrait is now the game's icon
• Newly-available building output and stored items now have a short delay during which they won't get assigned to regular deliveries, but can still be picked up by large storage building and Export Stations workers thus prioritizing them over carriers
• Building workers can now discard the resulting item of an operation if this item is no longer compatible, this applies to Brewing Vat and Loom
• Import Station can now accept and store up to 6 types of items independently; it will no longer get "clogged" by one type of item when receiving multiple types of items
• Up to 3 types of incoming items to Import Station are now shown in building inspection HUD with "progress" bars
• Loading saves where Export Station or Import Station has to be reset will preserve previous shipping routes (although active deliveries will be cancelled)
• Shipping routes can now only be set to Import Stations that are complete or under construction (but not deconstructing)
• Export Station inspection shipping routes selection will only show if it is complete or under construction (but not deconstructing)

Fixes

• Add missing Hunting Goal to hunt animals
• Some valid coordinates were not considered for Animal Habitat placement
• Fix some minor animal animation issues
• Pathfinding would not check coastal corners of tiles and workers could not go to buildings placed adjacent to coasts
• Fix profession distribution panel builder increase button decreasing the value instead; fix tooltips on all buttons being on the wrong buttons
• MacOS builds are now Intel only until Steam-injected libraries support Universal (i.e. ARM) builds and work on M1 chip systems
• Tooltips getting stuck when showing entries that check game progression while not in a game (i.e. main menu)
• Internal exception when removing a shipping route at a Export Station and cancelling tasks involved with the route due to not accounting for certain tasks failing to cancel remaining tasks and corrupting the internal route state
• Import Station clearing its incoming routes after construction
• Export Station not clearing its outgoing routes when deconstructing
• Some rare issues adding/removing shipping routes during building construction
• Import Station workers would only distribute the (internally) first stack of items

Balancing

• Smokehouse can now hire 3 instead of just 1 workers
• Drying Rack takes longer to "cook" meat

Optimizations

• Pathfinding internal checks are significantly faster

Rudy
Snowy Ash Games

This update improves item logistics and long-range deliveries.

My goal is to give the players much more control over item deliveries. Instead of relying on the game to successfully figure out what needs to be taken where and making assumptions that may not be correct, this would allow the players to direct items with more precision and have a consistent way of having long-distance deliveries.


The biggest addition are the courier stations – export station (left) and import station (right):



To summarize: An export station delivers specified items to one or more import stations. Export station has dedicated workers for collecting items from nearby processing and storage buildings, as well as dedicated couriers to handle the deliveries. Import stations have dedicated workers to distribute the delivered items to nearby processing and storage buildings.

You can think of these as active item "hubs" in an area (a "passive" hub would be storage buildings). They will promptly collect nearby items and efficiently send them away to a different hub, where they can be distributed again.

Just to be clear, all the existing delivery logic still exists. The game can be played without building any courier stations. Free carriers will still grab whatever items they can deliver (although they won't
"interfere" with courier stations themselves). In contrast, courier stations is a way for the player to "force" consistent deliveries, especially across longer distances.

Most of the setup happens at the export station:



Here, you can specify the item to deliver, the number of workers for collecting, the number of workers for deliveries, and the destination import stations (and their priorities).

The items will be delivered by a worker pulling a cart with up to 12 items. These carts are efficient compared to regular carriers, however will slow down immensely outside roads. This makes planning and building roads increasingly useful if you use couriers.



The items will end up at the import station:



From here, workers can distribute them to relevant storage.

With this, I also removed storage-to-storage delivery logic, so storage building can now only collect and distribute items to and from processing buildings. Courier stations will be needed to take items "directly" to a different storage location.




The storage buildings can now store almost every item in the game. There are still separate warehouse/barn/granary variants and the buildings and items will show in the tooltip where they get to be stored.

The HUD has changed a little for these:



They also do not list all the items you can select, because since every item in the game can now be stored and there would be too many to show. Instead, upon clicking the selection button, an item selection menu will pop up:



This selection is now used everywhere where an item needs to be specified, including the export station.


The other big change are the large storage buildings:



Besides larger item capacity, the big advantage and important feature of these are the dedicated workers that will collect and distribute items from nearby processing buildings:



These workers will only ever collect and deliver items for their storage building, making these essentially dedicated couriers.

All the existing and new storage and logistics buildings are now in the logistics construction tab:




There is now the option to limit the regular carrier item delivery distance:



This works best when the village has courier stations set up for far deliveries. This way, couriers can be "told" to not bother with long-range deliveries and focus on short-range.

Builders will now also follow a proportional value rather than an absolute:



This means the players don't have to constantly change (or even be aware of) the maximum builder value.

I also added a few achievements and tweaked some of the existing ones.


This update is not perfect by any means. Item logistics is a massive feature set and for every feature that works, there are ten things that could go wrong. It's a relatively simple concept to explain, but a notoriously difficult one to implement. I am writing this and it feels like I just started adding the long-distance routes, but somehow it's been over three months already.

I built the game around the concept "carriers deliver everything". I eventually added worker self-deliveries, and this already complicated matters a lot (in fact, I only now fixed some long-standing bugs relating to that). But now I am adding logic where items that were previously exclusively delivered by carriers can also be freely delivered by building workers – collected from outputs and storage and distributed to inputs and storage. Suddenly, internal logic has become much more complex and difficult to follow.

And this also means that I could not split the update into multiple smaller ones (i.e. Storage update & Hauling update like I originally planned). The underlying delivery logic is just too "spread out" through everything. I also don't have a stable build at any point due to the number of changes. Nor do some of these additions make a notable difference without the whole package, like large storage without dedicated workers.

I also spent a very long time hunting and fixing some of the rare bugs. These were ranging from self-fixing and annoying to actually crashing the game. Despite their rarity and inconsistency, they eventually happen if one plays long enough. Unfortunately, this also means that tracing and debugging them is very time-consuming.


Foremost, I want to add more content. By which I mean "immediate" features like production chains and such. I have not really decided on exactly what is most impactful or interesting at the moment. I know I want to make larger maps and more diverse resources and I will probably begin implementing some of that. Namely, long-range deliveries would allow me to spread out the resources more and larger maps won't have as many logistics issues.

On the backend side of things, I need to rework how markets work. Houses currently need 12 items and that's 12 different market stalls, each needing collection and distribution. I can't realistically keep adding more items that I want without making this whole gameplay part overly tedious. This also isn't really how I envisioned markets.

I will of course be on the lookout for how well these new changes work and will adjust things based on feedback.


Changes

• Add Export Station and Import Station buildings for bulk item delivery Routes
• Add item selection popup window for selecting among many items, use for shipment item selection for Export Station and storage buildings
• Implement Export Station item retrieval from nearby processing and storage buildings
• Implement Export Station item delivery via "couriers" following specified Routes, add route priority adjuster
• Add Routes creation/selection HUD for Export Station
• Implement Import Station item distribution to nearby processing and storage buildings
• Add markers for shipment target and destination (and active transfers)
• Couriers don't carry items, but load them into a cart and pull it instead
• Couriers with a cart don't experience slower base movement speed regardless of the number of items in the cart
• Couriers pulling carts outside Roads move much slower
• Add several issue checks for the new buildings (shipment item not set, no source or target in range, no shipment routes set)
• Add Hauling technology that unlocks the courier buildings with Roads and Storage being prerequisites
• Add max delivery range for carriers that can limit how far items are delivered by regular carriers (excluding couriers and self-deliveries); add UI slider next to carrier slider at the profession distribution window
• Max builder value is now a proportion of total worker population (like carriers); adjust UI and controls to match
• Rename "Roads" construction tab to "Logistics" and place Export Station and Import Station there
• Storage buildings (Warehouse, Granary and Barn) no longer transfer goods between other storage buildings (they can still toggle regular input/output deliveries)
• All items can now be stored (except Corpses) in storage; set up lists of items for each storage building "type"
• Storage building stored item selection now uses a popup to show all items and a separate section to show stored quantity
• Change storage building description to describe what they store better and remove explicit mentions of storage from individual items
• Changing storage building's stored item now "drops" all items and "collects" any compatible items already on location
• Move storage building construction entries to the (new) "Logistics" tab
• Add large Large Warehouse, Large Granary and Large Barn with increased capacity
• Large storage can employ dedicated workers that retrieve/collect outputs and distribute inputs to nearby processing buildings
• Storage workers will also obey storage item transit input/output toggles
• Add Large Storage technology to unlock large storage buildings with "regular" Storage tech as prerequisite
• Add Goals for Hauling and Large Storage, adjust requirements for Storage
• Shift+copying buildings also copies Export Station shipment item selection
• Building workers will run to the building instead of walking if they are far away
• Buildings can have 2 worker "rows" with different tasks, namely Export Station's collectors vs. couriers
• Buildings can have different worker "names" for building inspection, such as "Collectors" and "Couriers" and optional description tooltips for their labels and buttons
• Shift-clicking worker slot buttons in building inspection toggles multiple slots - clicking an enabled slot disables it and all slots to the right while clicking a disabled slot enables it and all slots to the left
• Add icons for Animals and display them in all HUD locations - inspection, buttons, tooltips, etc.
• Add Animal conservation (by Game Warden's Lodge) tooltip information entries
• Builders will remain at their construction site if there are tasks pending or incoming items rather than walking off early
• Building and road construction sites to show a marker for their builders
• Technology window now uses large icons (that match items)
• Add additional vertical space to the Technology window to fit the new technologies
• Add "Monumental" achievement to construct the Monument
• Add "Wildlife Conservationist" achievement to establish a Game Warden's Lodge for every species of wild Animal while not hunting at these Animal Habitats
• Add "Populous" achievement to reach 2000 Population
• Add "Rocky Road" achievement to have 1000 tiles with stone or better Roads
• Construction menu will highlight newly-unlocked buildings
• Make invalid tile overlay indicator more obvious
• When placing multi-tile buildings, only invalid tiles will turn red instead of also valid tiles where the building wouldn't fit due to being multi-tile
• Roads and techs to show icons in Micropedia along other icon fixes
• Remove item delivery distance grace period during which newly-available items would be prioritized to closer destinations
• Add building marker/indicator for non-idle workers
• Add building marker/indicator for outgoing item delivery target buildings
• Building marker incoming icons are now more cyan than blue
• Add Marker concept and Micropedia entry explaining the individual icons
• Building efficiency value now counts missing workers as being inefficient
• Clicking construction tabs will not cancel the current selection
• Building's selection HUD will not hide when building auxiliaries or selecting its operating location
• Add next happiness level note to the top HUD happiness segment tooltip
• Building sites do not affect Animal Habitats score until construction starts
• Cut-down Trees during construction will leave a Log item behind
• Shift-selecting an auxiliary building while a compatible parent is selected will leave the parent's selection HUD active

Fixes

• Fix workers delivering items to other buildings sometimes incorrectly counting/reserving the items potentially either over-delivering items or getting stuck never receiving more deliveries
• Fix rare bug where cancelling deconstruction of a partly constructed building or road would result in it never being completed due to incorrect pending material counter
• Fix rare bug where delivering multiple materials to a road would not count the items correctly and would either complete the road with "incorrect" materials or get stuck with missing material(s)
• Fix rare bug where saving would fail due to an unfinished road construction when multiple material delivery task incorrectly decreased the pending material counter
• Fix rare bug where assigning conflicting tasks would sometimes cause another task to "disappear" and at worst cause a crash
• Fix rare occurrence of food items being used up due to global hunger not properly cancelling tasks involving them potentially causing a crash and "broken" items
• Livestock Animals not wandering in their pens
• Minor discrepancies in counting idle villagers
• Items occasionally incorrectly visually offset in Stockpile when multiple are delivered
• Minor item delivery discrepancies due to using item-to-villager distance rather than item-to-destination
• Minor item distribution discrepancies when reaching internal overdelivery limits
• Add missing button click sound effects for distribution panel
• Redeploy Sewing Desks due to incorrect internal version (that didn't cause issue before, but would cause them now)
• Builders will leave their construction site if there is nothing to do rather than stay idle permanently when there are other construction sites waiting for work
• Builders will actually stay at the construction site (like the tooltip says) if it is set to highest priority (even when builder proportion is exceeded)
• Building workers won't accept and "lock in" tasks before they have actually arrived at their building (potentially delaying processing or item usage by other workers while they are running)
• Fix Hemp description wrongly listing it as deprecated
• Barn being unlocked without Storage tech
• Minor marker display issues, such as with worker self-deliveries
• Fix incorrect (visually missing) Town Hall shadow
• Fix multiple tasks involving same multiple items not verifying that all items do not conflict and potentially causing a crash and "broken" items
• Worker marker constantly removing and readding itself
• Some rare marker glitches
• Fix crash when a villager dies while constructing a building and leaving behind an "invalid" item
• Have higher priority construction sites receive items by not having a delivery distance grace period
• Fix macOS start-up crash
• Cancelling building construction with an active item use by builder leaves it in an invalid state that causes saving to crash
• Clearing selection with Esc not clearing internal selection and markers
• Fix buildings having invalid internal item state upon loading/upgrading from an older save and crashing the game when interacted with
• Fix Mason and Windmill continuing to work and failing to produce items when the output is full
• Fix building efficiency value resetting after loading a game
• Esc occasionally causing an internal exception when building an auxiliary building or selecting building operation location
• Internal exception during selection-based input mode while the selected entity changed state (such as building deconstructing while selecting its operating location)
• Internal exception redrawing tile borders when selected entity's state changes
• Erratic carrier hiring and firing when at 5/6 carriers or occasionally at the exact minimum proportion value
• Profession distribution carrier slider current value indicator not matching up with the slider's handle
• Global self-delivery toggle value not being saved
• Productivity and other "bonuses" not applied to certain auxiliary building operations
• Completing certain auxiliary tasks would not update parent building's task (e.g. Farm not planting produce before continuing to repair Wasted Dirt)
• Rare internal exception drawing tile borders when multiple changes affecting them happen on the same frame
• Shift-selecting a building and then canceling construction would leave last selected entities selection HUD, but it would not update
• Potentially fix cases of "black screen" on launch on macOS
• Fix crash during saving while a worker is trying to plant something in a Dirt tile that has decayed into Wasted Dirt
• Fix crash during saving when a villager dies while having an active pathfinding request queued or being processed
• Fix a rare case of a carrier choosing an incompatible item for multiple item bundling/delivery
• Fix a very rare crash when saving the game exactly when the path-finding process returns a result
• Update game engine to (potentially) fix compatibility with latest macOS versions

Balancing

• Arborist work range is now 4 tiles (from 3)
• Reduce Warehouse and Barn capacity from 64 to 32
• Replace "Utopia" achievement with "Happy Place" which in addition to 3 minutes of Happiness, also requires 500 Population
• Wasted Dirt repair is slightly faster
• Wasted Dirt repair is much faster outside Winter

Rudy
Snowy Ash Games

This update focuses on the backend features for building construction, broadly speaking. My main eventual design goal is to make construction feel like a larger part of village development. This means things like longer build times, additional construction steps, more required materials, more builders, larger buildings, more builder animations and actions, more visuals, more feedback, etc. As part of it, I also added a lot of smaller features that I wanted to add but couldn't before.


The biggest change (at least, internally) is the support for multi-tile buildings. Here is the "new" town hall on a 2x2 footprint (or 7 tiles):



I have not yet "converted" any other production buildings, because this would basically remove them without replacing and break any games. Besides, I need new art for them all and this is a out of scope for this update (see also future plans).

And here is the new (unfinished) monument on a 3x3 footprint (or 19 tiles):



With this, I also added support for multiple builders at the same construction site. Larger (future) buildings will require more time to complete, but this will also be offset by more builders working on them. This is probably the primary way in which I can visually "explain" that constructing buildings is a significant endeavor.

Notably on visual side, I added the graphics for construction progress for buildings:



This was one of the visual things that has been bugging me forever, but I was not able to add it due to how the construction and deconstruction progress was stored. It is now self-consistent (and you can no longer cheese the materials by toggling between de/construction).

Buildings can now also support more than 3 materials for construction, notably the monument will now also require planks and iron ingots.


I added a new tile type "dirt", which is basically dug-up grass. This will be the "default" tile under all buildings:



Builders will dig up the tile at the start of construction and will now actually convert it to dirt (if it's not already dirt). Previously, only workers at places like farms and ranches would dig up the working tiles, but these were just a variant of grass. They will still do it, but now they will work directly from dirt and further prepare them for use.

This makes the village look more lived in and creates a starker visual contrast between the village and the surrounding nature.

The dirt will also slowly regrow back into grass if there's no building on it:



With dirt tiles being their own "type", I can also add transitions between different tile types. (Before, "fake dirt" was only at the borders of crop fields, animal pens, etc., so it didn't really matter if it had a "sharp edge" with the grass outside the area.)



I numbered the different transitions above and you can see how just such a small location can have transitioning surfaces from everywhich side.

I even had to work on improving my pipeline for transition creation, such as a quick preview so I can tweak any issues:



This change is similarly mostly about the backend. Previously, I would never change the tile after creating it (dirt was just a variant of grass). But this also meant that everything assumed that it can "connect" to tiles safely and the tile would never disappear or change its type. So now I have the ability to transform the tiles as desired, which paves the road for various tile-related features.


Buildings can now "decide" if the workers will self-deliver items, that is, bring nearby input items and deliver nearby output items to other buildings or storage instead of waiting for a carrier. This behaviour is both a positive and a negative feature and the line is very blurry and based on so many factors. When it works, it's great. When it doesn't, it can ruin production. I thought about this a lot and in the end I decided to allow the players to enable and disable it. This would still be important even after upcoming updates and changes to logistics, so I might as well do it right.

Firstly, each building with workers now has a toggle to either allow or disallow self-deliveries or keep it at the default setting:



Secondly, the item distribution window now offers a building self-delivery toggle tab that lists all the building types and each has its own toggle for all buildings of that type:



There is also a global toggle to simply disallow all self-deliveries by default. This can result in very different layout and carrier requirements. With a small village, it almost always works better with self-deliveries, and this is the default option and this is also part of my "just works" design goal. In the end, I am allowing the players to choose how their workers spend their time and if they want to optimize long-term or react short-term, I'm happy either way.


Selecting a building, will now show the a small in-world marker above the items that are being delivered/imported to (blue, arrow in) or taken away/exported (orange, arrow out) from the building:



This will also show the villagers performing the delivery before the items is yet picked up:



This should make it much easier to see what items are being delivered without needing to check the tooltip that can only show a list of items and their approximate distances.

I will likely expand this to "mark" other related things as well, like workers themselves. However, this is a finicky feature that takes a lot of time, so I will work on this at a later date. My primary goal was to show the items and carriers since these cause the most confusion, especially for construction. This will also be particularly helpful for the future logistics updates.


Most of the work was in the backend, but here as some notable changes.

All buildings with workers now track their efficiency and show it in the HUD:



This is simply the percentage of time that the workers spent working. In addition, I also show the time spent self-delivering items so it's clear when workers are spending time hauling items versus doing the building's designated tasks, which is not necessarily bad but also not necessarily good. In any case, the player can decide what they want to do with this information and possibly use the self-delivery toggles.

I (finally) changed the minimum carrier value from an absolute number to a proportion and changed the UI to be a percentage slider:



Importantly, I made it so that going under this limit will start dismissing workers from the buildings. For this, I use the most occupied and then least efficient workers.

This now functions more intuitively like "I want X% of villagers to be carriers" rather than the more convoluted "minimum".

I also changed how the UI shows the de/construction material items:



This is an extreme case for the monument, so there a lots of items. But for regular buildings, this should work up nicely. The old "button" was just too unclear and cramped.

I split the top HUD overview and their tooltips into the tradesmen/carrier/builder sections:



I removed trying to show green/red status icons for these, since they are almost always just a little wrong. The end result is that a village working 98% of the time has red icons while a village not doing anything can have green icons (since technically all tasks are fulfilled). I think I was trying to be too smart trying to "tell the player" what the goal should be when it's not actually a goal at all.


This update took way longer than anticipated because of a fundamental backend assumption that tiles map 1:1 to buildings and that tiles remain "fixed" throughout. Adding such fundamental features retroactively is never fun. For example, path-finding had no idea how to handle not being able to walk between multi-tile buildings. I think it was worth it just to allow the larger monument. But, of course, there are tons of buildings that could be multi-tile.

The next thing I am working on before anything else is a delivery "caravan" system. There is a lot to discuss about it and I will probably leave it for the next update notes. I didn't do many logistics changes in this update mostly to not delay it any longer. For example, there are still various issues with construction, particularly with priorities and deliveries. But much of it needs logistics "fixed" first.

For the more distant future, the next part of building changes would be making all primary buildings be 3x3 tiles. That is, for example, a farm would be 3x3 while the fields would remain 1x1. However, I will not do this change right now as there's a specific problem I want to focus on.

Of course, there are all the other things I have mentioned here and there before - markets, better civilian needs, happiness overhaul, more production chains, trading, etc. etc.


Changes

• Monument is now 3x3 (19 tiles)
• Town Hall is now 2x2 (7 tiles)
• Multi-tile buildings are now supported by the backend: currently used footprints are 2x2 or 7 tile "circle" and 3x3 or 19 tile "circle"
• Add multi-tile outlines for building selection and construction
• Selecting any tile of a multi-tile building selects both the exact tile and the building itself and with separate outlines
• Add (de)construction markers for multi-tile buildings
• Buildings are now (de)constructed through several visual construction steps; add in-progress sprites for primary and auxiliary buildings
• Update (de)construction item progress UI to be shown as a progress bar with sections for used/delivered/pending/needed items with appropriate icons
• Make (de)construction progress bar advance smoothly and more accurately than before
• Town Hall's footprint is now 2x2 or 7 tiles
• New larger Town Hall sprite
• Monument's footprint is now 3x3 or 19 tiles
• Monument now also requires Iron Ingots and Planks for construction
• Add Iron Ingot to building proportion item distribution window
• New large Monument sprite and its construction steps
• Make Dirt tile a separate tile for "used" tiles, including its previous "variants": Tilled Dirt for farming and Stomped Dirt for animal husbandry
• Builders clearing a tile for construction will now convert it to Dirt
• Dirt tiles will slowly revert back to grass as Regrowing Dirt and Regrowing Dirt if there is no building on top; other dirt types will first turn into "regular" dirt
• Tilled Dirt under Crop Fields and Garden Plots will turn into Wasted Dirt at the arrival of Winter and workers will need to retill it
• Tree Nurseries don't need the tile tilled anymore
• Buildings with workers will show their work efficiency percentage in inspection HUD based on their time spent working
• Building workers will now follow a self-delivery setting and not bring or deliver items to and from their building if self-delivery is disabled
• Add self-delivery toggle (enabled, default, disabled) to building inspection HUD
• Add a "Self-deliveries" tab to item distribution window with a global self-delivery toggle (enabled/disabled) and per-building type (enabled, default, disabled) delivery toggles
• Change profession distribution carrier minimum value from an absolute value to a percentage value
• Workers will now leave their buildings to become carriers to reach the global carrier threshold
• Split top overview work section into individual "Tradework", "Deliveries" and "Construction" sections and simplify the tooltips
• Remove unclear and often incorrect green/red-colored status colors from top overview worker numbers/labels
• When a building is selected, items being delivered as inputs or carried away from outputs and carriers coming to take the items are indicated with in-world markers with appropriate icons (blue - incoming, orange - outgoing)
• Add UI/HUD button pressed variant and change various buttons that are "toggled" to have the pressed version (instead of just color change)
• Add water tile animation
• Update and improve various tile transition sprites
• Remove old save potential upgrade notice from save/load menu

Fixes

• Toggling between construction and deconstruction no longer returns material items randomly, but proportional to what was actually used
• Item distribution UI stuck with previous world's values after load or new game
• Rare exception when moving obstructing items from a construction site when the items are chosen for delivery
• Incorrect partial tile border outline for selected buildings with no auxiliaries
• Rare exception when selecting between buildings that have differing border logic
• Switching between different building construction would not update the invalid tile outlines in some cases
• Butcher producing Meat without Pigs
• Young Deer walking sprite animation mismatch
• Wrong tooltip info for Codex production "recipe"
• Wool Fabric production chain missing from Carding Machine tooltip
• Shift-selecting unbuildable building would change selection but not visuals
• Certain world changes would not be reflected as current selection changes
• Wrong Sapling removal animation
• Worker digging animation not showing particle effects in many cases
• Minor selection change trigger issues
• Occasional tile transition sprite overlap flicker
• Minor tile transition sprite issues
• Brewing Vat to not individually select production, rather parent Brewery to decide what to brew
• Confirmation window to use the Enter/Submit input instead of passing it to window under it
• Saplings to not grow in Winter

Balancing

• Increase various construction costs
• Increase various construction action durations
• Saplings grow faster
• Trees grow slower
• Tree Nursery workers plant and dig up Saplings faster

Optimizations

• Optimize tile updating speed (however, all water tiles need constant updates, so overall the game is slower)
• Improve certain redundant frequent update calls

Rudy
Snowy Ash Games

This UI-focused update adds Micropedia, a browseable in-game information "encyclopedia". Together with improvements to tooltips and presentation as well as nicer-looking icons for all the important buildings and items.


Over time, I have been drawing icons for buildings in the main construction menu. I wanted to replace them because of how unrecognizable they are. It's one of the first things a player sees in the game and it remains the primary mechanic, and all new building unlocks appear here. So it sucks when the sprites are so interchangeable and it takes clicking and reading tooltips to find what one is looking for. (And it is unlikely that the in-world sprites could ever not only be distinct enough but also fit in the small buttons.)

Long story short, here's a comparison between an old and new construction menu page:



Even if not immediately obvious, these should be infinitely more memorable and recognizable. You don't even have to play the game to guess most of these. There are still tons of auxiliaries, but these mainly appear under their own parent buildings, so it's not such a big problem.

Originally, I was trying to come up with unique icons only for buildings in the construction menu. I was mostly using their tools (pickaxe for quarry, saw for sawmill, etc.) as icons:



But I very soon ran out of tools, so to speak. Some buildings I could still represent with unique objects (like an anvil for smith), but others I had no idea how to represent (e.g. an icon for paper mill that isn't paper). So I ended up just drawing the primary items produced. And this actually worked out better than tools, so I drew items for most buildings instead.

Before long, I had about 70% of in-game items drawn, so at that point I might as well draw the rest. So now I had icons that I can use in all the HUD/UI elements with items, "automatically" improving these:




The majority of the work was actually for the tooltips. Micropedia is just a consequence of creating a structured easily-browseable repository for "all the tooltips". It has a bunch of extra information, but the data backend is the same.

Now, old tooltips did and still do their job:



Not great, not terrible.

However, my primary goal was to create extremely simple tooltip presentation that is also visually appealing. Like construction menu, this is the first place where a player looks to understand a building or item or anything. For example, the first thing a new player might learn is these:



Lumberjack and sawmill aren't exactly complicated, but a player who has learned this "language" can look at a more complex tooltip and understand what is required:



Then, from there I can use the same formula and expand until I have, for example, cheese inspection:



There's a whole lot of different things I can show. My main design problem was actually limiting which info I show. For example, tooltips are limited to the most important stuff.


And so the Micropedia is a separate in-game window that has an organized list of every entity and concept in the game. (Well, not every every one, but all the main ones anyway and then some.)



I expect that Micropedia would serve two primary use cases - (1) looking up something specific and (2) just browsing.

For the (1) case -- the player likely has a question about something, probably what some entity is or does or needs. If Micropedia can actually answer such question, then the quickest way to the answer is most likely through a search:



Opening Micropedia instantly focuses on the search bar and you can start typing. Hit Enter and it will go to the best result.

Or alternatively for (2) browsing, everything in Micropedia is broken down by categories (items, buildings, animals, techs, etc.) and then each item is listed (mostly, alphabetically). So you can see and browse all entries.

Currently, Micropedia is rather technical and doesn't list many specific values or go into explainations. I will be adding more of these in the future.


I combined several buildings, and removed all intermediary items (see the full notes for the list). This may or may not break some games, depending on how those building were arranged. The merged building are Brickyard, Paper Mill and Textile Mill:



There are a few items in the game that are "intermediate". For example, Cheesemonger first brews Milk into Curd and then pressed Curd into Cheese. This Curd item is a real in-game item with all the related features. Then there's buildings like Brickworks and Brickyard which not only have intermediate Grout, but also Unfired Bricks delivered between them.

I think it was a cool idea to show these items and to see them carried around. The problem is that these clutter up the UI -- every place that lists items, like item report, also lists these items. (And if I were to just hide them, then what's the point of having them?)

I also adjusted the inspection HUD to better show to the player that there's a "virtual" item that gets transferred between auxiliaries. For example, Brick Moulder:




This update was a little more chill in terms of workload. It still took twice as long than I had planned. And the UI work is always tricky. But it was still "holiday reduced workload update". However, I do need to get back to some of the tough changes.

I want to get back to expanding the end goal and making the monument a larger objective. And there are numerous steps along the way. I'm not even sure how large and complex each step would be. For example, I have to make multi-tile buildings. I need to change how construction tasks work and allow multiple builders. Builders need to be able to carry items. I need to rework how construction input items are stored and used/reclaimed/counted. I want to add multi-step construction for the monument. This probably means building upgrading. Likely I need foundation/platform construction. I need to add more and new materials for all of it. Etc. In short, my main goal for "endgame" has a lot of mini-goals that I will likely add one at a time.


Changes

• Remove Brickworks, Grout and Unfired Bricks
• Grout Mixer and Brick Moulder are now part of Brickyard
• Brickyard now directly receives Sand and Clay instead
• Remove Pulp Mill and Paper Pulp
• Pulp Vat is now part of Paper Mill
• Paper Mill now directly receives Hemp and Water instead
• Remove Carding Mill
• Carding Machine and Spinning Mule are now part of Textile Mill
• Textile Mill now directly receives Hemp and Wool instead
• Remove Linen Sliver, Linen Yarn, Wool Sliver and Wool Yarn
• Remove Unfired Pottery
• Remove Clean Fleece
• Remove Curd
• Remove Honeycomb
• Add Micropedia window - an organized information repository - split into categories and their entries
• Add categories for Micropedia - concepts, items, buildings, roads, villagers, animals, props, tiles, technologies and seasons
• Each entry in Micropedia shows its information - description, sprite(s), usage and some hard-wired related info
• Entities and links are clickable in Micropedia, switching to the corresponding entry
• Add unique recognizable icons for all items, roads and most buildings
• Most places in UI/HUD use the new icons for entities
• Expand entity tooltips to include usage/production information and other most-relevant information
• Add various new concepts
• Add and tweak various icons
• Add and tweak various sprites
• Change descriptions for all the changed buildings, items and others
• Remove Water Tower
• Add "Hide UI" button to pause menu that hides UI/HUD in-game (and prevents input for the duration of it)
• Building workers are now more reluctant to carry their own items
• Beehive now shows a warning when no Flowers are in the operating range
• Add a privacy notice and some extra info to save upload window; make toggle for optional Steam ID submission
• Remove the Population count requirement to unlock the Technology Branches
• Add a goal for building Town Hall
• Add wild Animals - Deer, Boars, Foxes, and Wolves
• Wild animals will spawn in Animal Habitats up to a limit
• Animal Habitats spawn and despawn in the world based on surrounding forest "score"
• New worlds and worlds loaded from older saver will have up to the default number of Animal Habitats spawned
• Animal Habitats show an in-world indicator and the mouseover tooltip provides additional information
• Rename Pork to Meat and Ham to Roast
• Add Hunting technology available for research from the start
• Add Hunter's Lodge building unlocked with Hunting
• Wild animals can be hunted - the worker will approach, shoot and harvest the animal for Meat
• Recently deceased wild animals can be skinned - the worker will harvest the animal for Meat
• Hunter's Lodge can individually toggle which animals are hunted
• Wild animals that die leave corpses instead of despawning immediately; the corpses eventually decay
• Add Game Warden's Lodge who will tend nearby habitats
• Herding now requires Hunting instead of Farming
• Smokehouse and Drying Rack now unlock with Hunting instead of Herding
• Add more particle effects to Drying Rack
• Add Animal and Animal Habitat concepts
• Trees no longer grow during Winter
• Forester and Florist no longer plant during Winter
• Various text and sprite adjustments
• Add wild Animal "baby" versions
• Only grown Animals can be hunted or skinned by the Hunter's Lodge
• Animal Habitats in new worlds generate with the appropriate number of Animals

Fixes

• Animal Habitat improved quality score from Game Warden's Lodge not being deducted after the improvement time runs out
• Workers at some buildings with multiple auxiliaries would not complete work at auxiliary but run off to another auxiliary
• Tooltips showing "through" opaque/blocking UI elements
• Mouse scroll wheel no longer zooms in/out when over HUD/UI
• Keyboard numpad +/- zoom keys now have a reasonable delay to zoom in/out one "step" at a time
• Water not being "unlocked" from the start and inspection HUD not showing Well items
• Barn is no longer unlocked if none of the items it stores are unlocked yet
• HUD pause menu button not playing a "click" sound
• Incorrect distance calculation for pending deliveries
• Farm, Gardener and Arborist planting and collecting their production entities on unfinished auxiliary buildings and on untilled tiles
• Transit toggle buttons blocking storage selection in storage building inspection HUD panel
• Fix Water Tower being treated like a Tavern and fulfilling Houses tavern resident sentiment
• Fix rare exception/stall bug when a worker switches a harvest task at the same as the target plant decays
• Fix rare exception bug when an animal regains its product at the same time as dying
• Fix Gardener and Arborist occasionally not tilling a tile just after planting in all other tiles
• Fix wrong Drying Rack meat sprite layer
• Correct Unfired Pottery plural name typo
• Play the correct UI sound for road upgrading via the U shortcut
• Fix a very rare error where a task for livestock animal is assigned right as it is dying
• Fix animal inspection HUD box lingering after animal leaves the selected tile
• Fix Windmill starting milling and creating Flour without any Wheat
• Fix Hunter's Lodge workers sometimes running on the spot when approaching animals
• Fix Farms, Gardeners, Arborists planting things in the wrong Seasons
• Fix building workers occasionally not doing anything (because they had another task planned, which is no longer valid), for example Farm workers not tilling a field
• Animals in new Habitats start aged proportionally (instead all dying at the same time)
• Closing early access intro window with Esc doesn't open patch note or link window with main menu

Balancing

• Wild Animals spawn a bit slower in Animal Habitats

Optimizations

• Faster tile border and indicator re-drawing and minimize the lagspike on swapping/relocating them
• Buildings to not look for tasks for disabled worker slots
• Remove redundant task condition checks when first deciding on a task
• Add delay between buildings failing to assign potential tasks
• Remove expensive periodic task checks that can instead be aborted later
• Check building tasks according to priority to avoid unnecessary checks

Rudy
Snowy Ash Games

This smaller update adds hunting and wild animals that can be hunted for meat.


I added several wild animals -- foxes, boars, wolves and deer.



These wander around, graze and generally hang out in the forests. I think they add some nice livelihood to otherwise extremely static forests.


I added a Hunting technology unlocked before the Herding technology. The Smokehouse will now also unlock with the Hunting tech.



I added a new building - Hunter's Lodge. You can adjust its operating range to cover the nearby animal location. You can also toggle which animals get hunted:



The workers will then run out to any wild animals, shoot them and then harvest them for meat. Meat can be taken to smokehouses same as from the butcher.

Smokehouses will now require Firewood:



This makes early high-quality meat food production more balanced.

I also renamed Pork to Meat and Ham to Roast since multiple animals now "drop" meat and it would be slightly confusing. I might eventually differentiate between the different types of meat, but I don't want to add more items to the market and houses at this time. This is also the reason why animals only drop meat for now and not other stuff like leather or pelts or something.


Something to consider is where I would spawn the wild animals. As simple as that sounds, it quickly becomes a rabbit hole (har har) of design questions and decisions.

A naive approach would be to just spawn animals randomly in the forests. I would add some rules to not spawn too many or to not spawn "incompatible" animals together or to choose "nicer" less-populated locations to spawn. I can even simulate some rudimentary population growth. The player would just place hunters randomly around forests.

But there is a major usability problem with all of this. How do I explain to the player how many animals there are in any particular place? And whether they are breeding or spawning or anything else? You can may be individually track them, but this is rather silly:



And secondly, if the player was to hunt out all animals, then there is no guarantee that more will ever spawn right there and the production rate would be inconsistent at best. As a player, I can see how I might completely avoid hunting, especially if I didn't know the rules of animal spawning.

I can add further rules that prevent animals from disappearing and spawn animals for hunters. But now I'm 3 layers deep into spawning rules and this just doesn't feel right. It doesn't fit the sort of structured approach to resource management that I want to have.

So I decided that animals will instead spawn in species-specific habitats, which will have an in-world indicator:



You can mouseover the indicator for all the info in the tooltip:



I think this makes it instantly clear that animals are a "resource" in this location and that it can be "harvested". This becomes a clear source of a renewable resource chain. This is something you can plan for from the start of a new game.

There are some rules to the habitats (which are similar to what individual animals would have had without habitats). They will only spawn in forested areas on around grassy tiles. They won't spawn near buildings or roads. They will decay if the forest is cut down or things are built nearby. Animals will only spawn in habitats. These factor contribute to the habitat's "quality score".

The tooltip also explains when things aren't "working", mainly when new animals won't spawn:




Going with habitat quality concept further, I also added Conservation tech and a Game Warden's Lodge building. The warden will tend a nearby animal habitat, improve its quality (and thus spawn rate) and prevent it from decaying even under poor conditions. This is reflected in the habitat's tooltip:



This isn't a big or important feature; I just think it's kind of cool and I haven't really seen it done in other games. It's relatively easy for me to add, yet provides an extra level of depth.


The habitat feature happens to need a lot of parameters and I think it's a good opportunity to provide some technical insight into these:



Since I am dealing with randomness and procedural generation, everything that can go wrong will go wrong. Every time I add a parameter, I am essentially trying to extract order from randomness and prevent things going wrong. (For example, I would not want to spawn a habitat right next to another one. But this is a perfectly valid random result unless I stop it. Hence, I need a parameter that says how many tiles must be between habitats. In other words, I reduce the number of garbage results from randomness.)



I can change these values on the fly as the game runs. I can also restart/regenerate the world quickly while running to preview changes. Most of the time I start with a few parameters that I expect I would need and gradually add more as I find various edge cases and "problems".

For example, here's me debugging the validity of spawning a new habitat in different locations:



Some of these never get modified unless I make drastic changes. These values may as well have been written directly in code, but having them external makes initial testing much faster. Others I would tweak continuously and those parameters determine balance and gameplay. Of those, some are "public" and these are values you see in the game, in tooltips and such.

Of course, it's not like every parameter belongs to an exact "group". It's more like a way of converting design into implementation. I know I want to show some values to the player. I know I will need other constants to determine high-level decision. I know I will need to cover edge cases. Etc.

A final note is that every parameter adds maintenance. To be accurate, each parameter represents underlying code, which adds maintenance. Having parameters displayed like this together gives me a good estimate of complexity. When I see the parameter list growing, I know that I am increasing the feature's complexity and may be that's not always a good thing.


As before, I intend to be making smaller more frequent updates. I don't want to do heavy programming or involved design during the Holidays (especially after last patch's backend work), so I will probably work on some graphics and informational stuff. I think the in-game info codex is a likely addition.


Changes

• Add wild Animals - Deer, Boars, Foxes, and Wolves
• Wild animals will spawn in Animal Habitats up to a limit
• Animal Habitats spawn and despawn in the world based on surrounding forest "score"
• New worlds and worlds loaded from older saver will have up to the default number of Animal Habitats spawned
• Animal Habitats show an in-world indicator and the mouseover tooltip provides additional information
• Rename Pork to Meat and Ham to Roast
• Add Hunting technology available for research from the start
• Add Hunter's Lodge building unlocked with Hunting
• Wild animals can be hunted - the worker will approach, shoot and harvest the animal for Meat
• Recently deceased wild animals can be skinned - the worker will harvest the animal for Meat
• Hunter's Lodge can individually toggle which animals are hunted
• Wild animals that die leave corpses instead of despawning immediately; the corpses eventually decay
• Add Game Warden's Lodge who will tend nearby habitats
• Herding now requires Hunting instead of Farming
• Smokehouse and Drying Rack now unlock with Hunting instead of Herding
• Add more particle effects to Drying Rack
• Add Animal and Animal Habitat concepts
• Trees no longer grow during Winter
• Forester and Florist no longer plant during Winter
• Various text and sprite adjustments
• Add a privacy notice and some extra info to save upload window; make toggle for optional Steam ID submission
• Remove the Population count requirement to unlock the Technology Branches
• Add a goal for building Town Hall

Fixes

• Fix wrong Drying Rack meat sprite layer
• Correct Unfired Pottery plural name typo
• Play the correct UI sound for road upgrading via the U shortcut
• Fix a very rare error where a task for livestock animal is assigned right as it is dying
• Fix animal inspection HUD box lingering after animal leaves the selected tile
• Farm, Gardener and Arborist planting and collecting their production entities on unfinished auxiliary buildings and on untilled tiles
• Transit toggle buttons blocking storage selection in storage building inspection HUD panel
• Fix Water Tower being treated like a Tavern and fulfilling Houses tavern resident sentiment
• Fix rare exception/stall bug when a worker switches a harvest task at the same as the target plant decays
• Fix rare exception bug when an animal regains its product at the same time as dying
• Fix Gardener and Arborist occasionally not tilling a tile just after planting in all other tiles

Optimizations

• Buildings to not look for tasks for disabled worker slots
• Remove redundant task condition checks when first deciding on a task
• Add delay between buildings failing to assign potential tasks
• Remove expensive periodic task checks that can instead be aborted later
• Check building tasks according to priority to avoid unnecessary checks
• Faster tile border and indicator re-drawing and minimize the lagspike on swapping/relocating them

Rudy
Snowy Ash Games

This update adds seasons and seasonal crops to the game.

The game's save format has changed, see the "Save Upgrade" section below. To preserve old saves, you will have to upgrade them.

I thought about titling this update "Winter is coming", but that just describes my update schedule.


The game now has seasons. I went with the "standard" temperate ones: spring, summer, autumn and winter.



You can now see the season progression in the HUD and more info in the tooltip:



For plants, seasonality means that crops and produce will now quickly decay in winter:



In fact, all farm crops (wheat, barely, hemp, herbs) have to be planted in spring or they won't have enough time to fully grow and be harvested. Gardens will be able to (re)grow produce some 2-3 times a year.

Crops will also decay naturally over a period of time if not harvested:



This also means that gardeners and farms will not remain permanently idle and just stockpile ready-to-harvest fields. (You can still endlessly sow and not harvest anything, but you will need the workforce to maintain this cycle. And perishable/food items do not yet decay.)

As a consequence of seasonal harvests, the village will see a brief, large influx of harvested items. To support this, I added barns that are specifically for storing such crops:



I also adjusted how much food houses need. Simple foods (carrots, tomatoes, potatoes) will now run out quicker, while complex foods (bread, ham, cheese) will last longer. The values aren't perfectly balanced by any means, but this does move the game in the direction of complex food production chains being useful.

All crops (technically, all farm crops, gardener produce and arborist saplings) will now be planted and grown as three entities per tile (similar to trees):



Gameplay-wise, this means the space can be used more efficiently. Conversely, this means I can increase the plant growth time without sacrificing a lot of area, which I did.

Visually, having 3 crops per tile instead of just 1 means more animations and activity as they are sowed, grow and get harvested individually. The crop sprites are also simpler, more readable and easier to adjust as needed. And this also means I can add more growth stages, thus further increasing the amount of animation per crop.

Since crops are now individual entities, they are shown individually in the building inspection as well:



Crop fields and garden plots are one of my favourite features visually. I updated all the sprites, for example tomatoes and carrots:



For seasons, other plants will also change in various ways. For example, deciduous trees will yellow in autumn and shed leaves in winter:



Seasons do make balancing more difficult both for me and for the players. Basically, anything that fluctuates like seasonal crop yields is hard to balance. Previously, I could safely solve it with "whatever number feels cool", because the game just auto-balanced itself. If you lack something, you just build more production for it. It's still mostly true, but fitting things to seasons where crops actually die in winter means that I have to consider some timing values carefully.

I ended up coming up with and analyzing duration proportions in-depth and coming up with a theoretical model:



There is an interesting gameplay consequence to trying to fit production results into a specific time frame. Normally, the first crops you plant will be ready before the last ones planted even begin to ripen. This ends up with very unequal field growth and just doesn't feel right in-game. To counter this, crops will grow slightly slower or faster based on their stage and the current season (red and green cells in the above image).

In short, I have to tie all the duration values together from crop stages to year length.

This update is not too large content-wise given how long it's been since the last update. And because some of the changes I decided to make are disproportionately tricky to how much they actually add to gameplay. There are still more things I want to add related to seasons, but I decided to publish the update.

I also decided against adding more crops and grown food items, because this would bring the number of foods really high and micro-managing markets and houses demanding each type is too much of a mess. I will come up with a solution to this before I add extra foods (and supplies).


I rewrote the save system and changed the save format.

There is a lot I can discuss about the save system. This would get very technical very quickly because it's basically 95% about code specifics and how I handle each case. (In short, it's a fancy serializer. I tag my classes and variables with saving attributes and the system automatically saves the entire structure and then recreates it later. For the new system, I changed reflection-based value reading/writing to using automatically pre-generated code. The tricky part why I cannot use a ready-made serialization solution is that my code changes frequently and I need to be able to easily upgrade things through consecutive versions. With hundreds of classes and thousands of variables, the system need to be specialized to my needs.)

Here are the primary benefits:
* Saving and loading is much faster (with a caveat below), which was my primary reason to do this
* Saves can support many small entities better, which means I can have bigger maps with more stuff without exponentially increasing save processing times
* I can store metadata within the save files themselves, not limiting save info to slots and profile data
* I can potentially have an unlimited number of save files with unrestricted file names
* It's very easy to use, has minimal restrictions and barely distracts me from the actual programming, thus speeding up development
* The system is more robust and hopefully won't have to suffer breaking changes any time soon
* Saves have better data markers and extra data that allow me to debug code compatibility much easier
* Faster saving/loading means I can test old save loading/upgrading much faster and thus more often

Basically, there are no real downsides except the initial time required to implement it.

My save loading bottleneck is now the Unity engine itself and having to create/move/toggle all the objects in the scene. There is not much I can do about it and I am already employing all the immediate tricks I know of.

Here's a preview of the new save format:



Okay well, *I* think it was funny.


If you want to convert/update/upgrade your old saves (up to 0.5.x) to the new format (starting 0.6.x), you will have to follow these steps:

Open Steam client; right click MicroTown in the Library; Properties...; Select BETAS tab; switch the "select the beta [..]" dropdown to "saveupgrade" branch. Wait for the update and run the game. It will open the UI to convert your saves to the new format. Once that is done, follow the above steps again but switch back to the default "NONE" branch.



I apologize for the convoluted way of doing this. Unfortunately, I am not able to implement this conversion within the game itself, nor can I easily include a second executable in the build (especially for non-Windows). But I still wanted to preserve the save compatibility, (even though the game is in early access and "things may break" is partly expected). I also wanted to personally preserve all the older saves the players have sent in (even if the original issues wouldn't be present after the conversion).

(Note that the last 0.5.x version is also available here as "lastversion" branch and will remain there for the duration of 0.6.x release cycle.)


I've said before that I want more frequent updates, but this time I spent literal months on the next one. The main reason is that I'm working on both internal backend development and gameplay content additions in parallel. It's not too difficult to estimate the time needed for content updates (and I can always adjust on the fly). However, backend work is a complete lottery whether it will take a day or a month.

My backend is way more complex than a game of this scope would suggest. Often, the internal complexity gets in the way of content creation. But this means less bugs, more stability, better optimization, more consistent long-term changes, etc. I think it's a compromise I would like to see in the games that I play.

The reason for complicating things is that I have always loved games with attention to detail. This is also the design philosophy I am taking. For example, items stocked at buildings or placed in granaries or sold at markets aren't just "combined" into an internal counter. They all still exist as independent entities with all their attached data. For example, I could "poison" a tile next to a smeltery and then track it all the way from growing a crop there to being harvested to being stored and then brought to the market and sold and taken to the house to the villagers who eat it and get sick.


I have worked on quite a lot of features, just haven't completed any fully. I am fairly confident that I can release next several updates much quicker. In the nearest future, you can expect more season stuff, weather effects, wildlife and hunting and an in-game information codex. These are most complete features that I can finish before I approach some of the larger planned changes.


Changes

• New save format; old saves (<=0.5.x) are no longer compatible, but can be converted via the separate build on Steam's "saveupgrade" branch
• Crop Fields, Garden Plots and Tree Nurseries and their fields are reset
• All props (like trees and such) are reset
• Added Seasons - Summer, Autumn, Winter, and Spring
• Added Season HUD showing the current season
• Farm, Gardener and Arborist now grow their production as individual plants and not "as a building"
• New world prop objects for all the plants: Carrot, Tomato, Herb, Seedling, Wheat, Barley, Hemp, Potato
• Cultivated plants (crops, vegetables, saplings) are now grown 3 per tile and are planted and harvested individually
• Cultivated plants have more growth stages
• Cultivated plants now decay after some time of not being harvested; they will stay around in their decayed variant for a while
• Farm crops will slow or increase growth based on Season tending to be harvestable in early Autumn
• Farms won't plants crops in Autumn (since there isn't enough time for them to grow)
• Farms and Gardeners won't plant crops in Winter
• Crops and most plants will now quickly decay/rot when Winter arrives
• Garden Plots, Crop Fields and Tree Nurseries now show in HUD what crops are growing there and their growth progress (similar stages are grouped)
• Add Barn building to store intermediate harvested items: Wheat, Barley, Hemp and Herbs
• Trees (i.e. Maple and Spruce) will change leaves/needles as Seasons rotate
• Most plant sprites are adjusted or expanded, some shadows added
• Simple foods ( Carrot, Tomato, Potato) are consumed at a faster rate than complex foods ( Bread, Ham, Cheese)
• Flowers can be harvested by Bees more times
• Shift-picking building for copy building also copies the worker slot status (i.e. the number of workers)
• New less harsh pickaxe, axe and shovel sound effects

Fixes

• Cheese food amount missing from some formulas
• Tavern now serves a random item instead of prioritizing Beer over Mead
• Various particle/effect issues
• Some missing and incorrect task/command description labels
• Building workers will now work at the closest auxiliary as was intended (instead of randomly most of the time)
• "Replant tree" goal to show counter for Trees and not only Maples
• UI/HUD changes would not invalidate a tooltip properly and cause it to "stick"
• Fix road construction button tooltip bad syntax

Optimizations

• Eliminate lagspike when changes occur to tile borders, overlays and/or ghosts due to having to modify all tile game objects
• Much less overhead (such as when creating a world or loading a save) from having dedicated border, overlay and ghost sprite renderers on every tile game object
• Much less overhead from having multiple hex tile-shaping colliders on every tile game object
• Very slightly faster lookup for the current object under mouse, including much faster tile lookup
• Start preloading internal world objects while in main menu to reduce world entry times
• Reduce the number of redundant rendering
• Slightly faster animation processing

Rudy
Snowy Ash Games

This small update adds a soundtrack to the game.


The game now has a proper custom soundtrack made by composer José Ramón "Bibiki" García. There is the main theme and 8 gameplay tracks. This is obviously not a large update, but I'm super-excited about the new music and wanted to add it to the game as soon as possible. Previously, there was a single gameplay track running on a loop. It was a lovely track, but it got old really, really fast. And it was a stock track, so not original work.

I also needed a proper music system to support multiple tracks and proper transition between them. It's mostly just picking a random track with a bunch of rules about not repeating things. There is one interesting consideration though. If you've ever listened to a soundtrack/album on repeat, you know that your brain learns which tracks follow which. Even years later, you can instantly tell which song will follow next. This is something I wanted to avoid, so the music system stores the history of recently played tracks and avoids repeating the same consequitive tracks.

Here's an example of a random track order:



You can see that all tracks appear roughly equally, but the order is different and there is always "spacing" between the same track.

Here's an example of the sort of debugging I may have to create to support a new system, like the music system in this case:


You can see a bunch of things that hint at the internal logic. I could probably make a full write-up about all the decisions and details of the music system, but now I'm just padding this update post :)


I am currently working on the season update and this is my planned next update in the near future. It's about 85% complete for the immediate milestones.

The main reason for the update delay is that I had to work on a new save system. I will talk about this properly in the next update post. Unfortunately, new saves won't be compatible with the old save format. However, I intend to release a separate save upgrade release of the game that can perform a one-time conversion of the saves should you wish to do so.


Changes

• Added new game soundtrack (menu track and 8 gameplay tracks)
• Gameplay tracks will play randomly, but avoid recent repeats or following the same order
• Music tracks swap with an interval in-between (instead of cross-fading)
• Music toggling now quickly fades out/in the track (instead of instant switch)

Fixes

• Selecting between buildings with different item transit setups would not update the HUD transit selection buttons properly

Rudy
Snowy Ash Games

This update brings changes and an expanded framework for technologies that will drive the future expansion of progression features. (I know this sounds a bit abstract and wishy-washy and this update is a little bit all over the place.) In short, I added a bunch of technology-related stuff.


The big change is the way the knowledge is gained. A new Scholar building will generate research points. However, it won't just "magically" produce points. The worker will have to visit nearby production buildings, observe their operation and return with their findings. This will earn them a knowledge point.



So the player will have to actively "produce" knowledge. And the bigger the settlement, the more the opportunity for knowledge (as it realistically should be) and thus quicker expansion. So while it's perfectly possible to have a village with a minimal number of buildings (and I'm sure I'll add an achievement later), it's not as fast.

To that end, there's an obvious restriction to production buildings that can be observed -- they must have generated enough "observable knowledge" by being actively worked. In other words, you cannot learn from idle buildings. To help visualize this, I added appropriate icons to observable production buildings when selecting a scholar:



Once papermaking is unlocked, the Scholar can use Paper to record Notes about their observations:



These notes are now required by the Scribe to make the Codex books for knowledge:



Previously, these got "magically" written up with knowledge. So if Scholar learns from practice, then Scribe works out the theory, so to speak. The goals will still provide small knowledge boosts, but much less for later techs than before. So the player needs to build Scholars. I feel it's an opportunity to add more depth to technology/discovery mechanics in a way that actually explains where the knowledge comes from. I'll see how it goes and may be add more flavour to these interactions later.

Another big change is that there are now several (future) technology trees:



These are production, civics, economy, and culture. The current techs are all in the production branch for now. I might still rename or change the new ones, depending on what future features make most sense. The new trees are basically empty, but I will be adding and adjusting techs as I add the relevant features.

The tech trees unlock automatically based on the population:



This is primarily so that I don't overwhelm the player with a hundred techs at the start. But this works intuitively too -- the community has to advance far enough to worry about more than just survival. First, civics or population needs; then trading and economic growth; and finally culture and entertainment and such. Kind of like that needs pyramid. At least that's the rough idea, we'll see how it goes.

I also made a dynamic arrow system that can connect everything neatly:



Except, hold up... does Cheesemaking require Linen? 🤔 I didn't realize I would have this problem, so I needed some special cases and tons of extra sprites:



Such a small change making all the difference. In fact, the number of sprites I ended up making is rather ridiculous (and I didn't even make "exotic" combos for things I don't expect):



All in all, I'm pretty happy with how it turned out:



This also made me appreciate the work that must go into making tech trees and such in other games.

The Monument now requires a few more techs, one from each branch:



This will be the direction I will be heading and expanding until it's a sufficiently epic project to become a "world wonder" objective. I am avoiding just adding tons of techs for now, because I want them to feel sufficiently diverse.

I've also been working on various delivery-related backend improvements. One notable addition is that buildings now have "demand" for deliveries. This demand can be thought as priority for buildings that have less items than others. However, distance is still a considerable factor. Previously and when there aren't many items available, only the closest building will get items:



However, once there are more items, the further buildings will also start getting items:



This isn't efficient for immediate processing, but I think it feels more natural and intuitive. So I'm happy to sacrifice some marginal efficiency for more spread-out deliveries.

The settlement's starting layout has changed as well to a more ragtag arrangement (town hall and warehouses are now unlockable):



I did a whole lot of additional UI work, including standardizing many UI elements, adding icons, and various QoL improvements. Here's an icon creation example:



I have also added automated tests for various simple gameplay scenarios. This adds a bit of time to development, but it also saves me a lot of time should I accidentally break something (this has happened quite a few times already):



And of course, the most important update, a cobweb:



As always, I did a good chunk of work on the backend as to not accumulate technical debt and to keep updating on a steady (if not as frequent as I would want) schedule.


I don't usually go into detail about iteration and features that don't make it in. But I think it's important to mention the direction I considered but decided against, because it sort of explains what kind of game this is. (And because this update is twice as late due to redoing a bunch of things.)

Firstly, I was going to split techs into tiers/levels:



And these tiers would have to be unlocked. And for that I added a bunch of town milestones or "town stages":



Gameplay-wise, this would stop oneself from rushing technologies before having established a stable settlement, including an adequately-satisfied population. It also would stop the village from advancing with just a tiny population or only satisfying basic hunger needs.

This felt too artificial and not really the sort of "milestones" that a real settlement organically goes through. Or rather, such stage labels normally come as a consequence of organic development and not because the population decided to "advance to the next stage".

So I added "civic branches" that would drive the direction of development that closer represents the sort of governing decisions and planning that might be done:



One would have to choose what direction to take once all requirements are satisfied.



This meant the town stages would gradually "unlock" when enough civic development has taken place:



At this point, I was unhappy with the whole premise. These are features that artificially limit progression. It's a blurry line of what is "artificial", but a menu window telling you to "get X things" for undisclosed reasons likely fits. I think a game can easily become unfun if such restrictions are overdone. At the same time, they can serve as concrete goals. So I wasn't sure what to do at this point.

So I decided to get rid of town stages and just leave the unlocks:



But after playing around with it, it still just didn't feel right. I am having trouble just explaining it succinctly. In fact, none of this felt right and was just taking steps away from in-world gameplay and into menus. Now, I don't consider heavily UI- and menu-based games to be bad design or anything. I am sure this could work in a different game. But I don't think such direction fits MicroTown.

So, in the end, I made the call to scrap most of this and go back to focusing on in-world features and fewer separate menus. At least, nothing that feels too artificial. At this point, I had also planned and designed a whole load of future civic branch features and I am going to implement them as part of technology unlocks instead.


I am not completely over some sort of civic development direction. One such path is adding "policies", which would allow the player to shape the high-level development of settlement in different directions (as opposed to tech tree(s), which are basically linear). However, with hindsight of the iterations above, this will not limit the progression, but rather enhance or change it. This would be a pretty large feature (and it will likely not be in the next few updates).

I also want to work on a bigger objective building than the current monument. But this requires me to rewrite the building and construction logic to allow larger building footprints, construction stages/upgrading and multiple builders. This would be a whole update by itself in terms of work. But I feel it is necessary to make buildings feel grander.

Some of the new buildings, like bursar or hospice, hint at the sort of "city service" management direction I plan to work on. This involves a lot of individual moving parts, so I will be adding them gradually one at a time. I have mentioned before that I dislike the current "happiness" system, because it is too broad and too vague. So I will be replacing and expanding it into more logical "sections", like health, education, entertainment, etc. — the sort of stuff you would expect a population to need and care about. This way the player has clear targets, such as "raise health", and ways to accomplish this that vary from specialty features to mixing together with all the other needs and production chains.

I also need to make a "bonus system", broadly speaking. If policies or special buildings add or deduct some sort of bonuses (like work efficiency from happiness at the moment), then I need to show this in a consistent manner and this means having a solid system to begin with.

I will also likely do a couple minor updates with smaller feature sets, because I've been working on random stuff in parallel. For example, I've made some cool weather effects ages ago, but still have not added them. There is no "weather" or "climate" or "seasons" in-game (yet) and having it rain or snow wouldn't change anything practically. So on one hand, making such additions is only for some visual variety and I could add them sooner than later. But on the other hand, I really want there to be gameplay difference (like crop growth or something), so I've been postponing finishing it.

In short, there are a lot of plans and much work to be done. But I do have concrete goals and designs for the steps to reach them.


I will raise the price of the game from 8$/6.6€ to 10$/8.2€ at some point. I believe the game is in a solid state and offers enough content to warrant a higher price point.


Changes

• Scribes now require Scribe's Desks and Research Notes from Scholars
• Technologies now come in 4 branches - Production Technologies (where most of current techs are), Civics Technologies, Economics Technologies, and Culture Technologies
• Tech branches require a Population threshold to unlock
• Tech costs increase as more techs are unlocked (there are still several cost "tiers")
• Rename "knowledge" when referring to unlocking techs to Technology; keep the term Knowledge as the "currency" for unlocking; adjust tutorial and other texts
• Add additional UI for technology panel, such as branch tabs and tech connection/progression arrows
• Goals still award some Knowledge, but not enough after first few techs
• Add Scholar building that continuously gathers Knowledge from nearby active production buildings
• Separate Papermaking tech (i.e. Paper) from Bookbinding (i.e. Blank Book)
• Add Research Notes production from Paper at Scholars once Papermaking is unlocked (without Paper, they will still gather knowledge, but not produce notes; this can be disabled on a per-building basis)
• Scribes now have auxiliary Scribe's Desks required for operation
• Scribes now require Research Notes in addition to Blank Books to produce Codices
• Scribe's operation now takes significantly more time, but 3 workers can work from the same building
• Library now produces 2 Knowledge per Codex
• Town Hall is now (de)constructible and unlocked by Town Hall. however only one can be built
• A new settlement starts with a Tent (instead of Town Hall) and Stockpiles (instead of Warehouses and Granaries)
• Add a Camp Site starting/default tech to "standardize" what technologies lead to what; Dirt roads now require this tech
• Roads now require Stoneworking and Camp Site technologies (practically, this doesn't change anything, because those are unlocked from start)
• Add Storage tech that Warehouses and Granaries now require; add corresponding goal
• Monument now requires Monuments technology (instead of just Monument Schematics, previously "Monument Construction"), which itself requires Monument Schematics, Monument Design, and Monument Financing from all the tech branches
• Add Architecture tech unlocked by Papermaking and required by Monument Schematics
• Various minor technology changes
• Update tutorial to include building a Scholar
• Deliveries are now prioritized to buildings that have none to fewer items and deprioritized if they have a lot, effectively leading to a wider item distribution rather than nearest/most effective
• Certain buildings, like Scholar and Market Square can now receive items even at long distances
• Add separate sprite for when Crop Field, Garden Plot and Tree Nursery are harvested but not yet collected
• Indirect outputs (currently, Pigs from Ranches) are shown with other "real" output items in building inspection HUD
• Add U shortcut key to upgrade the selected entity (currently, Roads)
• All buildings now require holding Shift to continue building multiple; explain in tutorial
• Add gameplay option to always build multiple by default
• Add various additional concepts with tooltip explanations
• Change various UI sprites and icons; adjust many tooltips, texts and UI elements
• Construction HUD button column now always shows all buttons (practically, village/town building button is now always shown)
• Item report window selected item overview label with the total amount and storage amount versus capacity

Fixes

• Buildings that have auxiliaries producing items as input not working (Potter, Beekeeper, Brickyard, Wool Scourer, Carding Mill, Cheesemonger)
• Villagers not delivering multiple items to Market Square stalls.
• After loading a save, villagers being reported as ready for tasks when they are not yet, then sometimes failing delivery assignments
• Villagers bundling Market Square distribution deliveries that are too far away from each other (practically, different market)
• Villagers bundling deliveries of items on the ground that are too far away
• Construction occasionally halting when both stone road and building sites are pending and a bundled material delivery is scheduled
• Deliveries not being assigned with items remaining waiting and carriers remaining idle potentially forever on busier worlds where generated delivery count exceeded the update capacity
• Fix flag wave animation "direction"
• Fix mistakes in various texts and tooltips
• Construction HUD window becoming laggier after repeated world entering
• Fix tooltip panel text alignment issues
• Fix item report button clickable area overlapping nearby buttons
• Fix villager not holding carried item properly after picking it up for certain actions

Optimizations

• Deliveries are assigned faster on busier worlds
• Displaying texts that contain formatting/links/icons is now much faster and allocates comparatively very little memory

Rudy
Snowy Ash Games

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.


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.


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
[/olist]

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.


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.


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