This the third/last of three update posts about the new level generator. The introduction is at Post #1 and the second partis at Post #2.

At this point we have something resembling a map:



It's probably fair to say that the generation logic so far is already complex. But this is only perhaps third of the way to the final map implementation-wise. As more passes work with the data, they make smaller and more specialized changes. There aren't too many steps left, but they are generally an order of magnitude more complex in implementation than most preceding steps. This is also why I attempt to get as much top-level decision making done as soon as possible, so that the later passes work with smaller and more specific parts of the map without making any significant changes to the overall direction.


The next big transition between the two generation parts is to actually create a tile layout on top of the clusters. This is quite literally how it works:



The main change is that the tiles actually correspond to the in-game tile hex layout (and all the math from here is in hex grid). It's also important to note that they are much denser than the underlying clusters, so all operation are way more fine-grained:



In other words, a single cluster is represented by a collection of tiles. This is how the cell-like structure of the clusters gets preserved to the final version.

The tiles that get selected (at least, the initial version) pretty much just match the cluster they are on:



While it was not really productive to design the main shape of the island using tiles are the basic "unit", it's important to start seeing individual tiles once the main shapes are determined, so going forward all changes will be done to tiles (directly and indirectly):



The downside of using purely random points to determine the clusters is that sometimes they are just too small or too large when they get converted to tiles. And there's no good way to handle this generally. These are basically statistical outliers, so after "placing" regions into tiles, I also either trim or expand them to a maximum or minimum number of allowed tiles:



The perfectionist in me detests this kind of bodging. So this may be a good time to reflect on this.


Randomness is always battling with order. As a concrete example, to create interesting rocky patch shapes I have to allow the random values to be random enough that these shapes get generated. I cannot restrict it too much or I will end up generating the same blob over and over. The problem of course is that random generation has no concept of subjective values like "interesting" or "balanced" or "doesn't break pathfinding horribly". To put it another way, the more cool stuff I let in, the more bad stuff sneaks in. Consequently, the more freedom I allow, the more rules I have to write.

There are several ways to ensure that the generated result is compatible with my goals. Barring just hard-coding all the values, I broadly label these "threshold", "fix", "retry" and "accept". This might sound like nitpicking (and I certainly didn't foresee myself writing an essay on randomness philosophy). But given that I have to make dozens if not hundreds of decisions as to how I will handle each such value, there emerge several patterns.

"Threshold" means setting a strict limit to the possible output of random generation. It may be strong bias, it may be a preset range, it may be a hard limit that cannot statistically be outside the designed range. For example, the middle of the island is always solid land - the threshold for land simply exceeds the noise values that are clamped to the hex shape there. The downside is that such thresholds are often fairly restrictive and I may miss out on interesting outputs simply because I deny too many.

"Fix" is the consequence of letting a lot of randomness through. Subpar outputs and awesome outputs are different ends of the same spectrum. If I aim to preserve the good bits, I have to be prepared to handle the bad bits. Besides reading like a fortune cookie, this just means applying certain fixes to expected problems, like the above example of under/over-sized regions. There is a downside though - I have to actually implement it, test it and forever maintain and adjust it with the rest of the generator, which is all the more complex because of it. This is also an excellent reason to keep such fixes self-contained in separate passes and easily reviewable.

"Retry" means literally that - just run it again. There are two general cases when I would do this. Firstly, if something breaks or I cannot generate something. For example, I might want to place a sand patch 5 tiles away from all the clay patches, but I just happened to generate clay so uniformly that there's no place on the map to place sand now. Secondly, when I don't like the result. Like the earlier example with the island shape - I might hard-code some subjective rules, filters or conditions. As easy as this solution is, it's also dangerous to start rejecting too often rather than have better rules. It's also too easy to filter too much and not give randomness a chance to produce neat results. And with a complex generator like this, one must consider that it becomes computationally costly - I just cannot retry things hundreds of times, especially during later passes.

And finally "accept". Sometimes I just have to give up. The result will never be without fault. That's statistically impossible. The good news is that this is actually mitigated by the layered complexity of the generator as well as high error tolerance of the game itself. It's actually surprisingly difficult to generate a map that's unplayable. Even a tiny map that can barely fit anything and fails half the checks is perfectly playable (and I didn't even cherry-pick the example, I just ran the game once):




Similarly to clusters, tiles may end up with small ponds and islets because cluster connections do not always translate to tiles perfectly and it's occasionally possible to create "gaps" between clusters when represented as tiles:



These are really rare and they also don't really matter for other non-water clusters. For example, a gap between a forest in the final layout just makes it more varied, but doesn't cause any gameplay issues:



A bunch of logic depends on coast distance, so I calculate each tile's distance to water and land:



Previously, I often encountered islands with annoying unusable coastal extrusions (long peninsulas) that mostly ended up as sand anyway. Similarly, there often appeared long water "tunnels" into land. I still occasionally get these:



However, now I attempt to find "landmass" and "water mass" areas, which are basically tiles that are deep inland or far from coast. This identifies any regions that are only connected by narrow strips of land/water:



As these are undesirable, I reject these results and retry the whole generation. It's fine for there to be extrusions like this, but they have to be "reasonable" and ensuring "wide connectivity" is the approach I found best to preserve enough interesting but not broken shapes:



Another common issue is an undesirable proportion of land-to-water ratio. Some shapes end up being too large (basically a hex), others too small (boring blob in center). So I calculate how much water there is that's not close to the coast and reject shapes with bad proportions:



A similar common issue is the whole shape being "offset" from the center so that some coastlines are really far from the "world edge", making for huge undesirable water stretches. I reject these shapes as well:




The height map random noise does a decent job of creating shallow and deep water around the island, but it is also prone to creating excessive shallow water. Since I cannot "fix" it during the initial noise pass (I would also affect how much land generates), I manually trim away shallow water too far from land (convert to deep water):



This basically makes deep water transitions more "aggressive". This is also mostly a result of visually confirming what sort of shallow water amounts and variations look goods.

Similarly, sometime the noise transitions are so "steep" that deep water ends up touching the coast, so I offset any deep water too close to the coastline (although I fine with there being only a little gap):



Finally, all this fiddling with water level may end up shallow offshore patches. I did consider leaving them in as small cool variations in the ocean, but they almost never actually look good because they are just extreme outliers of the height map noise. So I basically remove them:



Previous height map also controlled the beach elevation. That is, I spawned beaches based on the height map, which was based on the map size. This created really huge sand areas around the coastline, especially where the coastline wasn't regular. So far, I have completely removed any sand at the coastline except the specially designated beach regions. But I do actually want some narrow beach tiles to randomly appear. So I'm using some noise values to randomly change coastal tiles to sand but only with specific thresholds to avoid any excess:




A common issue with the resulting tile layout is that they sometimes have "sharp" edges - tiles that are almost completely surrounded by another tile type. This just doesn't look good in the final version, so I added a pass to trim these to match their surroundings:



With several iterations, this cleans up any unnatural looking extrusions.

A special case of this are coasts that may end up with micro-extrusions of single-tile peninsulas. I really don't like these in the final resulting tile layout, so I trim these:



Technically, this trimming happens before all the water coastline logic because I cannot modify water/land tiles once I have established the distances. (It was a "fun" bug to chase that caused the generator to crash every 1000th run or so.)


At this point I assign tile variation to the map based on a noise map:



Currently, this only affects grassland tiles (and technically forest tiles that may revert back to grassland). Compared to previous generation, these patches and transitions are a less messy shape and don't overlap contrasting variants as much. Similar to other noise maps, climate affects these for some extra variation between "biomes":



Previously, I used the same height noise map for these as all the other features and while it looked fine, it was also very obvious purely random and not following any sort of natural "land" layout.

This might seem like a fairly trivial decorative feature to discuss in such detail, but the map looks really ugly with all the grass tiles being the same variant, especially after seeing the varied background for so long. Seeing such a huge difference made by such a small variation makes me consider all the other places I can vary in minor ways but to great effect.


Finally, I get to filling the contents of regions. This is also what I call the process and the objects - fillers. Specifically, I will spawn trees, shrubbery and deposits all with the same general methodology and much shared logic but different details. Similarly to region creation, this will involve fewer passes that instead process numerous entries but in different ways.

First of all, I need to determine the "depth" of the region tiles, i.e. how far from the region's edge they are:



This may sound like a small thing, but it's a very important step that has huge impact on the resulting visual layout. Without this information, I wouldn't be able to make any transitions between region sufficiently gradual (or sharp) to look decent. It's also important for spawning the right amount of fillers, like deposits. This is not something I could not have done previously, because the map had no concept of "region" - all locations where only as gradual as the noise map at that location.

Currently, I do 3 runs for the different groups. Starting with trees, which get spawned in the forests (regions):



The placement rules, which are basically "how many trees per tile in which tiles" comes from the ruleset I specify:



An earlier generated noise map for tree types (which was affected by the climate) is then used to decide what type of tree to place - spruce, maple to birch. This all ends up creating a nice mix of trees in semi-contained regions:



Very similarly to trees, I place minor vegetation - shrubs, grass and flowers. They also have their own ruleset and noise map, but things are just tweaked to accomplish what I want visually (which really is 90% of how I come up with the parameters):



And finally, I place deposits in the earlier established deposit/minable regions:



Most importantly, these are not just randomly spewed across the map with too many or too few tiles, but rather deliberately chosen to occupy certain areas and be of certain size (as per their region). This is one of the main problems I had with the old generator. Now, deposits follow specific rulesets, including actual deposit counts:



It is also important to note that deposits come with the "amount" value. While count means "how many per tiles" - 1 to 3, amount means how many "logical states" they get in gameplay, which translates to how many times they can be mined.





Even a simple algorithm for "filling" the deposits into a region to look nice and natural ends up being a fairly complex process. For example, I prefer to fill in the deeper region tiles before filling the outer tiles. I also want deeper tiles to have more minable amount than outer ones. But all of this is still randomized.


At this point, we reach the end of the generation. The way I have structured the generator, I technically started implementing it with an input and an output pass, so I have always had "the output". This really is an arbitrary point, which is decided by what the game needs and when I stop. As I mentioned at the start, the primary goal was to get it back to working to the same level as the old generator plus fix the primary problem. At this time, that is roughly where it's at. Of course, it's easily extendable in all sort of ways now, so when I'm adding new features, I can now also consider making changes to the map generator.

I skipped describing much of minor logic and a lot of details. I also skipped all the things that didn't work - a lot of the above is the result of experimenting and making multiple versions for passes. I might mention some if and when I add some feature that is tied specifically to some part of the generation.

Combining all the outputs and data from the passes, I get my final "image":



Importantly, this is all not presented in the actual game, but rather only in the separate generator "project" visualized with a quick debug texture creation. And this also contains all the important data from the preceding passes, that does not appear in the final game in any form. For example, none of the cluster and region information, none of the noise maps or stuff like climates is part of the gameplay. Probably 90% of the data gets discarded. In fact, the only new data that I store compared to the previous version is the spawn location. But this data can be fed into the game now, which really "only" has to spawn the things that the output asks for - tiles and props plus whatever hard-coded spawn features. Notably, the game doesn't have to "fix" anything that the generator messed up - it's basically expected to be correct.


I've been writing the main points to these posts along with implementing the generator. By the time I'm publishing the update, I do a full write-up from these key points. And, oh boy, were there a lot of those! By the end of it, I could hardly remember what I meant by half of the stuff I wrote down at the beginning. These posts also serve not just to discuss my progress publicly, but also to help me think through many design decisions by "talking them out". And there is still a lot to talk about, but I have to keep it relatively short (I say while having to split this up into 3 parts due to length).

The main conclusions and future plans can be found in the first part: Post #1.

This the second of three update posts about the new level generator. The introduction is at Post #1 and the third/last part is at Post #3.

I will now go into step-by-step process of the generation passes. For clarity, I will try to explain things in the way that makes most sense rather than sticking to exact technical pass layout. I'll try to group sections by generation "topic", although there is a lot of overlap.


Previously, the generated terrain was based purely on a noise map (Perlin noise). This created decent-looking gradual layouts, but this did not let me actually change anything in absolute values. That is, I could adjust things relatively - for example, have sand at 5% threshold, but then it would be random amount of sand up to 5% on any size map, which might be terrible on huge maps. There was no way for me to say - I want only 3 "patches" of sand, because there was no concept of a "patch" or "scale".

So the first and main terrain step is to produce discrete "clusters" (based on the map size). First, I generate a bunch of random (shapeless) points:



Then I tessellate these (basic Voronoi diagram) into individual (shaped) clusters:



Due to randomness, some of these often end up being too large or too small, so I run an extra smoothing/averaging pass (Lloyd's relaxation):



This produces a nicely distributed and organically-looking pattern (kind of like cells). Jumping way ahead, this is what will give the terrain the "clustered" look I'm going for (warning: now you will never unsee it):




The next big thing that I generate is the separation between water and not-water by heightmap, which is a convoluted way of saying that I'm building a coastline. This is where a noise map like Perlin noise works really well, so that's what I'm using:



Now, I cannot directly apply this to clusters, because the edges need to be water and the middle needs to be the island mass - by design. Previously, I was using a squashed circle on top of the height map to "cut out" the rough shape, but this created a lot of water in some directions and too much land in others. So now I implemented a much more accurate hex shape with proper "distance to edge" calculations:



I can then overlay this shape over the actual heightmap, reducing or increasing the random value to force it below or above certain thresholds:



This makes sure that anything outside the "big" hex becomes water and anything inside the "small" hex becomes land. The in-between area is then where the noise actually affects the shape. With some visual experimentation in later passes, I can tweak the noise parameters to produce satisfactory results.

I can then apply the "clamped" height map values to the clusters themselves and decide which clusters become coastal shallow water and deep water:



Of course, due to the very nature of applying thresholds to randomness over an area, I sometimes end up with little inland pond and offshore islets. For gameplay purposes (and all the issues these cause), I am removing these when I find them:




And this is just the start of the "battle" against randomness "ruining" my islands. I'll talk about this more a little later.


There is no perfect way to generate an island shape. Perhaps there are more suitable algorithms just for the island shape generation, but I also have all the other generator's parts to consider and they have to all be compatible. So instead of seeking some perfect algorithm, I'm just brute-forcing the generation a bunch of times until it doesn't get rejected. Some passes are there purely to reject the result and tell the generator to restart.

One such pass is for, broadly, "island shape". I generate a few "control points" in a rough approximate ellipse around the island and check if they are land or water:



If there's too much water, too much land or too much repetition, I reject the shape. Otherwise, it's probably interesting enough to keep. There is no science behind this - I was just looking at hundreds of islands until I came up with heuristics and parameters that struck a good balance between random and still somewhat hex-like shaped.

This is a good time to reflect on just how many maps I generate throughout the process:



I have set up my generator to support output export at every step, so that I can leave it running for many iterations and then check them for any systematic problems. This is not something I could do before, and this is an invaluable methodology for designing and implementing a system like this.


Among many experiments to make different regions of an island feel more varied, I settled on a "climate" concept, which flags clusters as belonging to a certain climate (to a certain amount) and other passes can use this data to alter their generation. So this doesn't do anything by itself, but it provides additional customization for later passes. It's kind of like biomes, but currently there isn't any biome-specific terrain, so I'm calling it "climate".

For start, I select a few "control points" in a circle around the map (I chose this shape for simplicity and because the maps aren't large enough to come up with complicated layouts). Each climate has a area it can influence:



Then several climates are assigned randomly, specifically 2 forest, 2 plains and 1 rocks (and the rest stay default):



These are just thematic names that describe my intentions. The climate regions then flag clusters within their influence with an appropriate climate value/weight for later use:



Again, jumping way ahead, slight variations is later passes would create noticeable differences:




Previously, I placed the starting area or spawn in the middle of the island and manually cleared it from obstructions and non-buildable tiles. And while this works, it's implemented backwards. Instead, what I really want is to decide on the spawn location and then make sure I don't obstruct it with anything and place the relevant things around it.

So now I pick a random location on the island within a spawn selection area torus:



From there, I pick a valid (for example, not too close to water) closest cluster and construct a spawn area (this uses the same logic as regions, which I will describe later):



This creates one "main" point for the spawn and "grabs" nearby clusters to expand the area to a specified desired size. In addition, I place several "meadow rocks" areas, so I can spawn starting stone deposits around but not on top of the spawn area.

Finally, I create a small spawn exclusion zone, where many things can generate normally, but it will mostly remain free of obstruction:



While this may sound simple, it's extremely easy to get wrong and took me enough experimentation to make a working version. There was a good reason why I previously kept the spawn centered and it was to avoid the many issues of random placement of potentially-overlapping terrain features.


Most of the map is generated in two big parts - discrete features like rocks and clay patches and continuously semi-random ones like forests or flowers. Regions are for preset discrete locations, so they have to be generated first before everything else is "filled in".

It is very difficult to break down region generation into multiple passes, because they are basically all identical except their rulesets. And separating these rulesets is only useful for visualization (which would take huge amounts of work, so I didn't really do it). So what I end up is producing the region map in a single pass:



Generally speaking, regions are groups of neighboring clusters that form an area for some purpose. For example, there could be a 4 cluster region for coal rocks. Each type of region has a long list of hand-crafted rules and requirements, mostly derived from experimenting. Plus, most of these have some sort of rules about distances in relation to each other. So it makes more sense to just see the results for all at once.

For example, here is a ruleset for placing sand regions:



What this says is that it will place 2-3 region with 2 clusters semi-randomly; it won't place two regions close to each other and will place regions close to but not next to the coastline.

There are many more rules and nuances I could add, but it's best to keep it simple - more parameters just means more work adjusting them and debugging issues. And there are already 12 different region groups just to match the basic level generation goals.

There are some notable rules though worth mentioning. For instance, some regions are much more likely to generate in certain climates. Notably, all rocks-based minable regions are more likely to appear in the rocks climate:



Jumping ahead to final generation, this would allow the terrain to shape village direction and create a part of the map that would naturally focus on mining and industry:



This is not something I could have influenced like this before and is only possible because I can "direct" such discretely-selected regions towards certain results I'm looking for.

Another example is a beach region (in addition to regular thin noise-based beaches discussed later), which randomly generates along the coast in a few locations:



This adds variety to the map without covering half the map in sand, like it used to do before.

I should note that while this is how I primarily use the regions for now, they do not specifically just control tiles (grass, sand, rocks, whatever), rather they flag the clusters as belonging to that region. In fact, the number of tiles that later get converted to their "region designation" is more strict than "cover the whole region". So regions in that sense more of an abstract layer informing later generation what to select but not necessarily exactly how. More like "this is a good place for X".


The second type of regions are the "filler" regions that, as the name implies, fill out the rest of the clusters that aren't already designated for something. Because this doesn't require any discrete counts, this can be done with a noise map. I'm using several slightly different noise maps for different purposes, specifically tree cover, tree types, plant type and tile variation. It's also fairly simple to add new variants and then use them in later passes.

For example, here is (part of) the tree cover noise:



This assigns a "tree cover value" to each cluster (point):



Then a bias to increase or decrease the noise value is applied based on the climate it's in:



These are small adjustments that each climate provides, but they can create a significant variation for each "filler":



Now with the noise values decided, empty clusters can decide what sort of content they want. For example, tree cover decides where the forests will be located:



These noise maps will be further used in later passes for relevant selections. The above selection was more or less binary, but there are many more things that can be decided based on the full range of the random value.


I'll continue describing the remaining steps in the next, but this seems like a good time to reflect upon all the things that I am not doing. As I mentioned, it's important to set myself some limits on what I'm implementing, otherwise I will never finish this. I am certainly thinking about a lot of cool things that I could do.

As an example, I used the cluster layout and the Voronoi diagram edge connectivity to build a cluster "height map", spawn a "lake" region and then build a river running from the lake to the nearest coast:



Of course, this is far from something that I can translate into tiles and gameplay, so it's more of a proof of concept. But I thought to mention this just to give an idea of the possibilities.

Next post: Post #3

This update replaces the game's island map generator with a new more robust and expandable version.



I had two primary goals for the new level generator. Firstly, to bring it up to at least the same level as the old generator - but do this with a modular, extendable and configurable approach. And secondly, to fix the biggest problems with the old one - excessive unusable land, poor scaling with world sizes, bad coastal shapes and many minor issues.

There is a lot to talk about designing a complex system like this. I won't go into a huge essay about my software architecture here. There are many reasons why I'm doing the things I'm doing even if they oftentimes feel like over-engineering convoluted solutions to simple problems. But I will go over the most important parts.

Due to Steam post limit, I had to split this up into three parts. This post will focus on the overview and general approach, and the goal of the generator. The other two parts will go through specific generation steps: Post #2 and Post #3.


The hardest part of making a complex parametrized system is testing and iterating its results. The faster I can preview my changes and the easier I can understand the impact of these changes, the faster I can work on it and by extension produce better results.

This is my best friend:



To accomplish fast iteration, the system has to be designed with this in mind from the start.

A map generator makes hundreds of decisions when building a map from high-level choices (for example, the number of biomes) to specific low-level choices (for example, number of trees per tile). Usually, these are encoded as direct and indirect parameters that I can quickly tweak to achieve the desired results.

The difficulty comes from having lots of parameters and wanting to understand their impact at the same time, which means previewing the difference they make to the map generation. And this is a difficult problem because any changes that happen after the relevant ones can obscure the results. Most parameters have a huge range of possible values and only a narrow band of value produce desirable (or even usable) results.

So I want to preview not just the final result, but every step of the way. To do that, I am splitting the generator's logic into discrete steps or "passes" so that I can look at the independent output(s) of any pass in the sequence.

It is also critically important that the result preview is visual. This may sound like an obvious criterion, but implementing clear and useful previews takes significant additional time and effort. It is thus a longterm strategy, which means it has all the pitfalls of additional code to implement and maintain.



Another important consideration is coding the generator, not just running it. The last thing I want is to break everything by making changes. Implementing separate passes will take more time but not nearly as much time as having to rewrite large parts of the code if I interconnect everything. If I mess up some pass, then I will likely only break its inputs and outputs to the previous and next passes. And realistically I am almost guaranteed to rewrite, remove, add or majorly change many of the passes because I simply don't know how exactly they will work.

And one final and often overlooked benefit is personal motivation. Actually seeing the system work after every change is a huge boost to my motivation. It's the difference between just making something work and investing that extra polishing time. In a large system like this, small details quickly compound.


I would like to describe every step the generator takes, because I personally find it all very interesting and I could talk about it for hours. Unfortunately, this will end up with a hundred pages long post (and about 20 times over the Steam post limit). So I will try to summarize the most important steps and parts. And even with me being "brief", it is still about 3 times over the post limit. So as I'm splitting the update into three posts - this one (broad overview) and two step-by-step overviews of the generation process: Post #2 and Post #3.


One thing I barely considered for the old generator is scaling parameters with the generated world size. This is where the huge sand areas of the old generator in the large maps come from. And this is actually a much more difficult problem than it seems, which needs to be "baked into" logic from the start. Every variable that controls something size-dependent for the generator must decide how it behaves with different map sizes and I need to be able to quickly control it. In fact, there must actually be all the variables to control size-dependent features (for example, I cannot scale parts of a noise map without scaling everything). For example, I would want to specify that a beach is 2 tiles wide or 5% of map size, or 3% of map area, etc. Choosing an incorrect value or approach might work fine for the reference size, but may produce terrible result for different sizes.

So when specifying parameters, I make sure to specify (and preview) how they scale:



Generally, the options are "static", "linear" and "exponential" (with inverse variants). Static mean the same value for all sizes - e.g. number of spawn locations. Linear means it scales with the map size (width) - e.g. allowed water edge distance. And exponential means it scales with the map area - e.g. number of stone deposits.

And when testing the generator, I can run any combination to verify that they all work correctly:




As mentioned, this update is not meant to majorly change the gameplay beyond (A) fixing and adjusting most problems with the old generator and (B) those changes that are best done now to avoid too much disruption later. So there are still a few bigger changes that do impact gameplay:

Rocks no longer spawn all over the place, but rather in discrete patches focused towards one area of the map (this preview is from the tiny map, because I cannot get a better screenshot from a large map to demonstrate the idea clearly):



Furthermore, rocks now come in 4 variants - Rocks, Coal Vein, Iron Ore Vein and Limestone Vein, with their respective deposits only spawning there:



Consequently, the Mines now need to be placed on the appropriate type of rock:



(That is one chonker of a tooltip... I haven't really come up with a way to shorten it either other than having 8 separate lines.)

Sand and Beach are now different tiles. Minable and usable Sand now spawn in discrete clumpy patches. Beaches spawn along the coast (sometimes in clumps) and they cannot be mined.



They look a bit empty (again, because I did not want to expand the scope of the update), but there is potential to add something here.

Overall, the island shape has somewhat changed. The generator attempts to "fit a hex shape" into the game area, with a roughly-expected distance to edges, but still some larger coastal variation (I explain the various constraints in the other posts). A more "extreme" example of an island that is basically a hex:



The coastline of the island is also much cleaner. There are no extended peninsulas or closed bays - the vast majority of the map should be accessible. But there can still be significant variation of the coastline. Again, a more "extreme" example with lots of "shapeness":



Most islands end up somewhere in between the two, leaning towards more varied coast.

I also added a new grass type for some visual variety and as a proof of concept that I can vary vegetation:



Which kind of lead to discussing the possibilities...


One of the main goals of the new level generator was to be able to extend it in linear time. In other words, add new stuff quickly. This means there are a lot of things I can now add to the map that I previously couldn't. Some are very easy, some are more difficult, some are impractical. For example, I won't be making multiple islands (impractical), but I can easily add more biomes (easy) or cool features like a river or two (difficult). The great thing is that I am not limited to any particular single algorithm that has to somehow produce all the results in bulk - the generator consists of many individual steps and I have a lot of freedom to add and modify those.

A particular direction I want is to specialize and utilize different parts of the map, so that the terrain shapes the village more than it currently does (i.e. not at all). For example, you might have a swamp in one end that is needed for medicinal plants or flood plains in another part, where crops grow best, and so on. Following this, I might be able to force some production chains to actually need transportation from their production location to their processing location rather than having everything clumped together.

Another big potential feature is allowing player customization for the generated map. For example, forest density, deposit amount, climate bias, etc. I haven't implemented any of this, but I have kept this in the back of my mind when designing systems. I basically comes down to having user values selecting or adjusting one or more generation parameters.

Finally, I could potentially add--if not full replayability with different climate zones and resources--then at least enough differences between maps and their layout to not all look the same.

So this is all something that I'm looking forward to (admittedly, I am also exhausted having spent so much time on the generator.) I won't even speculate on what I want to add next, because there are just so many possibilities. In fact, deciding what to add and--more importantly--what not to add is in itself a big design decision/direction.


I am currently using Unity engine for the game. You my have heard about the recent Unity trust debacle. I won't go into details here, but the main point is that I do not wish to continue using the engine. Unfortunately, MicroTown is many years into development and strongly tied with the engine's features. This makes porting to a different engine very difficult and time consuming. I don't know if I can realistically invest that much time into this. I spent a couple weeks investigating engines and experimenting to see what such a transition would require. For now, I am still undecided. But it's likely I'll have to stay with the current engine.


I had to really stop myself from starting to add more features to the level generator. It has already turned out to be the largest "feature" that I have ever worked on. And the final touches and fixes again took way longer than I anticipated.

I wish I could have split this update into multiple parts over past year or so. But unfortunately this is one of those "all or nothing" features. I cannot implement half the generator or even 90% of the generator - it has to be all of it. So updates have been, shall we say, a bit slow (in addition to some other real-life stuff). So I tried to work on it 50/50 mixed with other features/updates, but that hasn't really been a good approach. I will definitely avoid splitting major workloads like that in the future.

So, hopefully, I will be making several "terrain updates" adding something to the generator and either adding or modifying something in related gameplay.


Changes

• Implemented new level generator algorithm
• Overall terrain shape is now properly based on a hexagonal shape, but there is more coastal variation and most landmass is slightly further from the edge of the map, but with more variation
• Terrain is now constructed in a more cell-like pattern, where "cells" correspond to biomes/regions, such as meadows or forests. Trees and other props will have way fewer unnatural "stretches" and "clumps". These "regions" will tend to be more uniform and connect more naturally.
• Islands overall shape will avoid generating with no coastline variation or excessive water or land
• Island now has several larger "climate" or "biome" sections that somewhat alter its layout and features - a part of the island has more forests, a part has more plains and a part has more rocks along with other slight vegetation biases.
• Deep Water to Shallow Water transitions are now smoother
• Water will not have excessive "patches" anymore
• Coastline is less jagged now and fewer extended unusable peninsulas or bays will spawn
• Add Switchgrass, a type of grass that spawns in Grassland
• Rename "Flower" to Marigold
• Add generic Flower concept
• Vegetation (Tree layout, types, tile variation, and Shrubbery/Marigold) layout are all now based on a separate noise patterns to avoid unnatural patterning
• Add new tile Beach that replaces Sand along the coastline, not suitable for quarrying
• Coastal tiles have much less Sand (that is, fewer Beach tiles) now
• Sand, Clay and Rocks now spawn in dedicated patches and cover much less of the terrain
• Patches of Rocks, Clay and Sand won't spawn next to similar patches anymore
• Rocks patches will spawn more in "rocky biome" and will generally include all the ores in that region (although they will still spawn randomly elsewhere)
• Clay patches now only spawn further inland
• Sand patches only spawn closer to coastline
• Several larger Beach locations now spawn randomly along the coast
• Rocks now have resource vein variants - Coal Vein, Iron Ore Vein and Limestone Vein (and their excavated variants - Excavated Coal Vein, Excavated Iron Ore Vein and Excavated Limestone Vein)
• Coal Mine, Iron Ore Mine, Lime Mine can now only be built on their resource tile variant, while Stone Mine can be built on plain Rocks
• Spawn point is now randomly offset from the middle of the map
• Spawn region is now clear of obstructing terrain
• Spawn region will always have some free-standing rocks around it
• Spawn region will only be set in "regular" climate avoiding inconvenient terrain for starting
• Patches with resources will avoid spawning in poorly-accessible unbuildable locations, like surrounded by water or unbuildable terrain
• Animal Habitats now spawn based on distance to coast rather than distance to map edge/center making for more uniform spawning and avoiding unreachable locations
• Animal Habitats now pre-spawn properly instead of appearing one at a time after the world starts
• All the internal properties of level generation now scale with the world size appropriate to their purpose. For example, larger worlds do not get larger beaches or excessive rock patches while smaller worlds still contain sufficient rock patches. Terrain features, like biomes stay proportionally-sized.
• World generation will no longer stall UI (some other operations will also have fewer UI stalling portions)
• Older saves with Mines will have their tiles converted to respective resource tile
• Older saves will have empty stone patches randomly converted to resource patches
• Add worker self-delivery max distance indicator "circle" when building or selecting buildings
• Add the worker self-delivery max distance value to several relevant tooltips
• Item deliveries during carrier shortage will allow self-deliveries, ignoring regular priorities and proportions, but not not stalling/failing to deliver
• HUD delivery info tooltip will also show self-delivery count

Fixes

• Selecting Observer would not show the empty icons above observable building until they had done at least some work
• Fix worker self-deliveries not working above dedicated carrier max delivery distance
• Fix workers delivering 2 or 3 items of their building's output to storage removing/replacing them from the building as worker
• HUD delivery info tooltip showing the wrong number of available (idle) carriers and some other slight inconsistencies due to self-deliveries
• Fix props attempting to transform while a worker is using them, for example a sapling rotting while being harvested by an arborist (and this invalid combo causing games saved at this moment to fail to load)

Balancing

• New terrain generation alters various gameplay elements

Rudy
Snowy Ash Games

This follow-up update adds Technology Tiers to the game, requiring Tier-specific research point production. This is a smaller update content-wise, but it does drastically change the mid- to late-game gameplay by requiring all later technologies to produce second and later third tier research items, which have their extended production lines.


So some mid-game techs are now tier 2 and require T1 and T2 points:



And late-game techs are now tier 3 and need T1, T2 and T3 points:



The three separate knowledge items (from the Leather update) now produce their respective tier knowledge points -- notes - 1, scrolls - 2, codices - 3:



The top overview HUD now shows the knowledge amount broken into tiers:



I briefly considered making 4 technology tiers, the last being "inspiration" for the monument construction. And I still want to implement this in some form. But the game currently just doesn't have enough techs or more content to support such granularity and late-game. So for now it's 3 tiers.

I also wanted to balance the Observer (former Scholar) and reduce the "free" point gathering, but besides just making it slower, I would have to change some core mechanics for it and somehow separate buildings by industry or at least type. This all ends up being far beyond the scope of the update.


I keep promising smaller and more frequent updates, so finally I have a smaller update. *ahem*

My immediate goal is to integrate the new level generator system into the main game. I've been working on it as a separate project for multiple reasons. Integration is one of the most difficult parts, but it's the only remaining large task to get it into the main game. I am tempted to work more on it and add all sorts of new features, but I really do need to just get it into the game first and worry about additional content later. So that's my primary goal right now - switching to the new terrain generator.


Changes

• Technologies now come in three Knowledge Tiers: Tier 1, Tier 2 and Tier 3 - each is gathered as points independently
• Research Scroll now produces 1 point of Tier 2 Knowledge
• Research Codex now produces 1 point of Tier 3 Knowledge
• Tier 1 techs require only Tier 1 points
• Tier 2 techs require Tier 1 and Tier 2 points
• Tier 3 techs require Tier 1, Tier 2 and Tier 3 points
• Technology point cost increases in each tier individually
• Goals now also provide Tier 2 and Tier 3 points according to the tech they are based on
• Update various tooltips, descriptions and Micropedia entries for the tiered Knowledge points
• Add Leatherworking goal
• HUD top overview Knowledge amount now shows points for all Tiers
• Technology panel UI tech buttons now show the tiered costs for techs
• Micropedia now lists when a building can be observed
• Butcher can now toggle Meat and Hide production
• Butcher's Table's steps can now be discarded (like some other buildings with toggled production)
• Auxiliary step discarding can now also be triggered if there's no more space for the item (that is, full inventory will no longer stop items from producing, i.e. full Hide inventory won't prevent more Meat production)
• Discarding will no longer trigger if all item outputs are full (no point discarding when nothing can be filled)
• Discarding will no longer trigger if it's the only item the building is producing (everything else would be discarded too)
• Discarding as a task priority is now the same as the step it's discarding (so buildings where discarding is an expected operation don't leave them until last)
• Buildings with produced item/unit toggles will not show them if there is only one option
• Building produced item/unit toggle button tooltips will mention which item or unit they don't need

Fixes

• Fix inconsistencies in observable building list
• Micropedia will again list Butcher's inputs, but as animals now
• Papermaking goal using wrong base tech/award
• Fix incorrect tech unlock costs for later techs
• Fix Research Scrolls and Research Codices not increasing the correct (internal) Knowledge value
• Fix Research Notes providing wrong Knowledge point amount
• Library now showing operation progress bar for Research Notes use
• Fix Research Scrolls not being delivered
• Fix saves failing to load due to previous patch
• Fix discarding tasks taking almost no time instead of the expected short duration
• Workers working with several auxiliaries will now pick the auxiliary that is closest to finishing the product instead of (usually) picking an auxiliary with the most progress
• Building with togglable production will not continue working if production toggles are disabled
• Some tiles would convert to Sand after removing a building from them

Balancing

• Technology tier introduction drastically changes mid-game and later tech progression requirements

Rudy
Snowy Ash Games

This smaller update (but part or a larger direction) adds Leather item to the game and the production chains leading up to it; plus various changes.


I decided to make Leather production fairly involved with multiple production chains using all the different production mechanics - growing, harvesting, animals, crafting buildings, mining. Essentially, Leather is a high value item used for high value purposes and I wanted to represent that by having diverse and significant production requirements. (There aren't any final products yet except Codices (which are not balanced yet), but this should lay the foundation for the "next tier" items. Though I decided to publish the update before I get further carried away with changes.)

Quarries can now build a Lime Mine, which produces Lime:



Arborists can now grow Wattle tree saplings and Foresters will plant them. These don't spawn/grow naturally and need to be grown from saplings.



Wattle trees do not produce Logs, but instead Bark. These are also collected by Lumberjacks like other trees.



Bark is used in Bark Mill to produce Tannin:



The Butcher building now comes with an Abattoir and a Table required auxiliary buildings, where animals are... processed. In addition to Meat, Butcher will now also harvest Hides from Pigs once Leatherworking is unlocked.



Animals brought to the Butcher now actually hang around the building as "real" units instead of magically disappearing into it as virtual items. The worker will actually fetch the individual animal and lead it to the Abattoir. I felt it was an important part of my "every item is real" design principle that I neglected with animal transfers (mostly due to implementation complexity).



An optional Butcher's Pen can be constructed to keep the animals within certain tiles instead of wandering randomly:



This also means that animals can now die of old age if they aren't... processed fast enough by the Butcher.

In addition to Butcher, Hunter can now also skin and harvest Hides from Boars and Deer:



Similar to Butcher, Hunter now also produces Meat and Hides:



Animals will now be double-harvested - first for Meat and second their Carcasses for Hides. Before Leatherworking is unlocked, the Hunters will just leave the Carcass.



All (wild) animal (carcasses) now leave bones behind:



This adds a little bit of extra visual variety (instead of dead animals disappearing instantly):



Tannin, Lime and Hides are then taken to the Tannery building, which processes them through a Hide-preparation Bench, Liming Vat (using Lime) and Tanning Pit (using Tannin). This produces Leather.



Leather is currently used by Currier to produce Book Covers:



Bookbinder now requires Book Covers in addition to Paper to produce Empty Books:



For now, there aren't any major changes to knowledge gathering and technologies. Some techs have moved around and adjusted requirements. I have also adjusted the details and buildings in preparation of making separate technology tiers.

Notably, Scholars will now always produce Research Notes without requiring Paper and the Library is available from the start, where these Notes must be taken to get the Knowledge points.



The Scribe will continue using Paper, but will make Research Scrolls instead. These are also taken to the Library.



Finally, The Bookbinder works similarly to before, producing the Research Codices:



These changes serve to establish a common design language of a Library serving as the central location to "deposit knowledge" of different quality (tiers).



In the future, I will add additional tech tiers and unique knowledge type(s) that requires Scrolls/Codices for higher tiers. This would then make sense for Leather to be this expensive and involved to produce. Currently, Scholars are more than sufficient to produce all the knowledge you need to unlock all the techs. But I have to limit the scope of these updates or I'll never publish any at all! So for now Leather and Knowledge are not balanced. Notes and Codices will simply produce more knowledge - 2 and 3 respectively.


One thing (that I should have done from the start) is making sure all buttons have a visually-distinct and consistent appearance when pressed. And to account for color blindness, this cannot be simply a change in hue (in fact my beige + green UI choice is the worst possible one for most common color blindness types).

Here is the setup for a "normal" UI button:



Now, I don't use every possible combination of color and state and element, but there are a lot of them. I tried to keep everything modular and only use what I need. But this has nevertheless created a lot of individual pieces to maintain, which is one the reasons for taking a long time to adjust.



I should reflect that doing such a change after so much of UI is already implemented and wired is really tedious. I basically have to adjust every single button and interactable control in-game. Some never had a "pressed" version, others mixed them up, others have conflicting states, etc. This is the sort of thing I should have done from the beginning and really planned how all UI elements would have clear states, and then never deviate from that in any particular UI part.


I also finally added dragging to build multiple roads (in an earlier mini-update).



The most tricky part of this was choosing which way to angle the road. There are almost always 2 symmetric layouts that a road can be drawn between two tiles. For this I had to decide where the player most likely intended the road, based on the mouse movement up to that point:



In short, when dragging a road I keep track of every coordinate the player "visits". But I only keep one coordinate for every distance from the mouse. I then calculate how "far" the player's movement is from either of the two variants and pick the one that is "closer".

This is much easier said than done, especially if you consider that you could be moving the mouse around a lot in all directions, passing the same point repeatedly, "rewinding" back, extending, dragging so fast tiles are skipped, changing your mind, etc. It basically ended up with me just playtesting until I couldn't really make it any better. The real difficulty was testing it and fixing all the corner cases.

I suppose I could have done this ages ago. But, like I suspected, this one feature took me a full week to implement. If I had to do this feature by itself, it would probably take an afternoon. But within the game as it is, it has to be integrated with all the other systems - camera, input, controls, rendering, selection, construction, etc. And that's always very tricky and finicky, especially for something like this that breaks half the systems when they only expect one click and one action.

I realize that I still haven't added multiple building drag-building. But this is a slightly different problem because it is an area-based operation and the actual area you would want to fill is kind of context-based. In fact, I need two operations (with a modified key, probably) - "circle" and "rectangle". I'm sure there are other things I'm not even thinking of yet.


Houses now have random chimney smoke. But only if they have Firewood available.



I'm sure this ranks really high-up on the important feature list. :)

But, in seriousness, I made the Houses 7-tile buildings so that I can show visual feedback as the result of the player supplying them with all the items. This is important feedback that directly correlates to player's actions, in this case long-term supply. Furthermore, stuff like there being more chimney smoke during winter and less during summer is not something most people would immediately consciously notice, but I believe that it is an extremely positive overall experience when the player notices and experiences one of the rare moments like "wow, the game actually considers the current season for smoke amount".

Selected buildings (technically, only Butcher for now) will now also have marker sprites for animals (and their carriers):



I didn't manage to add this before, because internally animals are units, which are not items. I mean, it sounds obvious, but that means all the code I have for item delivery markers needs a similar copy for animals/units. I do want to add more production involving animals in the future, so leading animals as inputs/outputs would be the kind of feedback I need markers for to be consistent. (There are other places like this - Pigs don't appear in item report and there's no designated Animal report window. So, technically, you cannot currently track your Pig production/usage.)

You can now toggle newly-placed building worker slots between one and all filled - this menu shows up when placing a building with worker slots:




First of all, apologies for the slow updates. The real-life™ has gotten in the way and I had very little opportunity to work on the game.

My immediate next concrete feature is likely the technology tiers. I don't have an exact idea of how it will work, but I have some probable solutions. As always, I suspect it will turn out more complex than I am thinking. The main goal is to make knowledge gathering more involved and less "rushable". And I just generally like the idea of multiple "science items" all needed together for late-game techs. And everything needs to be balanced.

I have some ideas for Leather as well - namely, Work Clothes for residences (along with regular linen and warm wool clothes). There are a lot of things that logically follow leather availability. I might make a mini update for this and some other residence tweaks. And now that I have animal "harvesting", I also want to add Fur and Luxury Clothes of some sort, plus something to do with birds. Although this is getting dangerously close to needing residence levels and upgrades...

The level generator has really taken the backseat for a while now. I still really want and need to finish it, so I can add some unique biomes and locations to the map that I cannot do right now due the technical limitations of randomly generating the world in a certain way. But it also has the hardest part left - the step where level generator output is converted to gameplay tiles. There is no lack of annoying technicalities to solve for this.

As always, I have a long list of ideas and changes both my own and from the community. As usually happens, I'll try to pick some more requested and/or desired feature(s) to implement in parallel. Of course, I'm always happy to hear out ideas and requests.


Changes

• Add Leather item
• Add Leatherworking technology (requires Woolworking, Quarrying, Forestry and Hunting)
• Add Hide item
• Butcher now has Abattoir and Butcher's Table auxiliary buildings
• Animals delivered to Butcher now wait at the building instead of "disappearing" as inputs
• Butcher now produces Meat and Hide from Pigs
• Butcher will now properly list Pigs as "inputs" with tooltip info similar to items
• Butcher can build optional Butcher's Pen auxiliaries for animals to wait at
• Add Carcass props for hunted animals - Deer Carcass, Boar Carcass, Wolf Carcass and Wolf Carcass
• Hunter's Lodge will now leave behind animal Carcasses after skinning an animal
• Hunter's Lodge will now collect Deer Carcasses and Boar Carcasses for Hides once Leatherworking is unlocked
• When wild Animal corpses decay or Carcasses decay or are harvested, they will leave behind Bones (that will also decay eventually)
• Add Bark item
• Add new Tree species Wattle grown from Wattle Saplings and harvested for Bark (instead of Logs
• Lumberjack can now toggle Log and Bark production
• Add Tannin item
• Add Bark Mill building with Bark Roller that crafts Bark into Tannin
• Add Lime item
• Add Lime Mine to Quarry for Lime mining
• Add Tannery building with Tanner's Bench, Liming Vat and Tanning Pit that crafts Hide, Lime and Tannin into Leather
• Add Book Cover item
• Add Currier building with Leatherworking Table that can craft Leather into Book Cover
• Bookbinding now also requires Leatherworking
• Bookbinder now has a Bookbinding Table auxiliary building
• Bookbinder now requires Book Cover in addition to Paper to make a Blank Book
• Rename "Notes" to "Research Notes"
• Rename "Codex" to "Research Codex"
• Rename "Scholar" to "Observer" (and reuse the name "Scholar" for more advanced building)
• Observer building no longer requires Paper to produce Research Notes
• Observer building no longer directly produced Knowledge, but requires produced Research Notes to be taken to the Library
• Library is now unlocked by Research from the start
• Tutorial now includes Library construction
• Add Research Scrolls item
• Research Scroll is using visuals from former Notes, and Research Notes has new visual
• Add Research Scroll item
• Scribe building now takes Paper and crafts Research Scrolls (instead of Research Codices
• Add new building Scholar and Scholar's Desk that now uses Blank Books to make Research Codices
• Library building now accepts Research Notes, Research Scrolls, and Research Codices
• Reorganize the tech tree for the new technology dependencies
• Papermaking now requires Research (already unlocked at start)
• Bookbinding no longer requires Research (since the required Papermaking is based on it now)
• Add worker slot pre-fill toggle buttons for the construction tab/menu - a choice between default one slot or all slots filled when building
• Houses will now randomly have chimney smoke when they have Firewood (more in Winter, less in Summer)
• Make tech tree line intersections and splits clearer for certain ambiguous cases
• Add Markers for animals being led (currently Pigs to Butcher)
• Roads can now be placed by dragging (default right-click); dragging will show preview and construction availability for each tile; placing will succeed even with some tiles being blocked; dragging will also upgrade roads; dragging can be cancelled with opposite mouse button (default left-click)
• Add more frame cap limit options
• Diet need Sentiment tooltip for buildings will now show the underlying values
• Improve descriptions for Food Quality and Food Variety
• Import Stations and Export Stations tooltips will now mention that number of items types/stack and per-stack capacity

Fixes

• Smith being unlocked too early by Smelting when there are no items that can be crafted yet
• Rare tutorial processing exception when loading an older save that redeploys a building while tutorials are active
• Fix internal exception when zooming while drag-building roads
• Fix UI windows (notably, tech panel) not sizing correctly to fit on the screen
• Saves would not load if there were old Quarries/Mines with disabled production
• Multiple items from the same Food Category not contributing correct Food Variety values
• Pickles not being included in Residence total food reserve count and thus some calculated values
• Diet need requiring too much Food Variety (technically achievable, but unintentionally strict)
• Some infolines not showing correctly
• Minor infoline fixes
• Fix error when toggling sale or export items while the building is under construction causing material items to be "reset" and cause subsequent internal errors
• Fix Boardwalks not buildable on Excavated Rocks
• Smith unlocking before Forge, which has nothing to craft by default
• Pickling-related building not being observable by Scholar
• Loading older saves could result in broken Forges, because they now require production item selection
• In rare cases, changing production or selling items would break item internal state
• Deposits would rarely not generate the correct amount
• Fix rare bug with older saves failing if the tutorial is active and some relevant building needs to be reset
• Fix rare potential exception when leaving the game world with non-default input mode (e.g. constructing)
• Rare internal error when a building or road with active Markers is removed and markers potentially recreated for invalid entities
• Add missing UI step for Glass Kiln
• Fix internal corrupted state for a case where a building is finishing de/construction, but an item that needs relocation appears on it (such as being dropped or unit dying and leaving a corpse), thus triggering item relocation which fails as the building is completed or removed
• Fix a rare case of building Markers causing an internal error when a unit performing some delivery to/from it dies
• Fix a very rare case where just-selected Import Stations and Export Stations would cause a game save to fail
• Fix Export Station route tooltip showing incorrect (inverted) list of items selected for shipping

Balancing

• For now, Research Scrolls will provide 2 points of Knowledge and Research Codices will provide 3 points
• Adjust some tech costs
• Villagers will no longer die from consuming food items directly from storage without having a Residence early in the game
• Stone Deposit now provides twice the amount of harvests, i.e. 6 to 12
• Non-food Reserves will now last roughly 50% longer
• Change Cheese quality to 2 up from 1 to make it easier to get the bonus of 2 without Pickles

Optimizations

• Rendering updated sprites (especially when there are a lot) is slightly faster
• Reduce lagspike when updating changes to a large amount of sprites, such as when tile construction validation appears/disappears
• Reduce lagspike when showing a large number of similar sprites, such as toggling between tile construction validations
• Reduce sprite visibility change slowdown when scrolling and zooming when there are a lot of sprites

Rudy
Snowy Ash Games

This smaller update tweaks resource mining by adding early-game mineable deposits and adjusts late-game quarrying. The update also adds more depth to food items.


The major change in this update is the addition of free-standing deposits around (a newly-generated) map:



The start of the game now has a Stonecutter building instead of a Quarry:



These operate basically like Lumberjacks - the workers go out and harvest the nearby deposits:



Each full-size deposit can be mined 6 times, so these patches last for a while, but not indefinitely. This makes initial stone resources much less a "build-and-forget", but something you have to keep an eye on, mine from several sites (some possibly far), and eventually transition to quarrying.

Quarry is now unlocked by Quarrying tech and each resource type has its own mine type:



Sand and Clay quarry are now also separate buildings and Sand/Clay Pits are no longer part of the Quarry:



I haven't decided exactly what I'm going to do about clay and sand mines since they have similar issues to the quarry. But they are okay as is for now, so I'll leave this for later.

Quarries can now use Mining Tools (which is what I renamed Tools). Every Mining Tool delivery will last for 6 excavations at a mine:



Mining with tools is significantly faster, but not required. Mining in general is slower now, so having tools would likely be preferable to having lots of villagers.

Besides various opportunities for balance and progression, I mainly like deposits for the visual variety and the "verticality" they add to the map. Any feature that adds new props and interactions with the world is a big plus in my book. I love the idea of each deposit slowly depleting visually watching the villagers go hit the rocks. As for balance, this changes a fundamental part of the initial gameplay, so I'll have to see how it goes.

I originally wanted quarries to be way more involved instead of just mining deposits, but I never got around to it, so it all stayed very "flat". I feel like this being literally on of the first things the player learns about, it should be significantly cooler.

What I still haven't added are rock tiles that have specific underground resources, so that the player would have to build mines in certain locations. But this requires me to make substantial changes to the level generation, which I cannot easily do with the current/old generator. Even the deposit generation needed code that is more hacks than logic. (For example, I couldn't even add deposits outside stone areas.) So I'm holding off on that for now, but will probably revisit things later. I also haven't added any sort of ore processing, which would make long-term production a bit more involved.

And stone is still not use for anything late-game, so there's that to address at some point.


Food now has several new "properties" to make food production and use feel more meaningful.

For example, a simple food item:



Versus a complex item:



This makes me want to aim for the fancy foods instead of potato quality.

First of all, food now belongs one or more categories, like Produce or Meats:



Each food item has a set quality:



Quality is the average quality of the best 4 items. In other words, as long as there are enough high quality items, the overall score will be high.

Each food item provides variety (for each of its category):



Variety is the sum of all the varieties in each category with a limit of 3 per category (so you cannot "stack" the same category).

You'll note that Pickles are really the only item that stands out at the moment because I didn't have any such items before. In fact, it's the addition of Pickles that prompted such questions as - how is it any better than just stacking potatoes.

Villagers in Houses will now consider both food quality and variety for their Diet need (score):



To sum up, all of this mean that items like Pickles actually provide as much food variety as 3 individual vegetables and still boost "fancy" quality score. So you could start with basic food supply, but transition to better mixed foods (and stop selling "cheap" food). Now I "just" need to add a bunch of new food items to fully utilize this new stuff. (And somehow allow houses to cram all these items...)

This feature is one of those where it's not obvious just how much extra stuff needs to be added to make it work. But this does allow me to handle "better food" in a way that can be balanced and explained reasonably well. Admittedly, about 80% of this work is UI-related, but that's how some features are.


One feature I have wanted to add for a long time but never got around to are so-called "ant trails" - on-the-ground virtual paths between locations. Currently, I am using these for export/import station routes:



If you mouseover a route in the selection UI, it will also highlight the relevant trail.

These use the same logic as regular in-game path-finding, so they actually follow the paths that couriers would take along the routes (and I think that's really neat):



There is a lot of potential for these in various locations, although none are really a priority right now. It was the export routes that felt more like a bug or at least a glaringly-unfinished feature since it didn't indicate where routes go. (There are the building markers, but you have to actually scroll around to find them and they didn't specify which route it is.)

It doesn't sound like a complex feature, but as always with these, it's the little things that get you. For example, I discovered some non-aligning sprites:



I won't go through a lot of detail, but I talked about path-finding and where path "nodes" are in a previous update post: https://steamcommunity.com/games/931270/announcements/detail/4748472700555436873 In short, path-finding is not just between tiles, but also between every corner of the tile. And the exact pixel distances for hex tiles the way I have them aligned means that even seemingly-identical transitions are actually 1 pixel shorter or taller depending on the exact location. Which means I ended up with a silly amount of sprites for this:



All this took a few days to do, but I think it's a nice "nice-to-have" feature.


One requested feature is that export stations can now toggle items per route:



This allows some more complex exporting rules. Honestly, export/import stations are now way more complicated (and versatile) than I ever originally expected them to be.


Another update so soon? What is this, Christmas?

I think I will continue to do some smaller updates for now. I have no idea what I will work on short-term since I don't want to do anything huge or overly complicated over the holidays. There are some high impact features I am looking into, but I have no idea whether they are huge changes or something I can get partly done and playable until I try. So I don't want to commit to anything. But I would really like to add technology tiers and rework scholar and library knowledge gathering. If not that, then something to do with late game, objectives and/or more involved monument construction.

Long-term, I am still aiming at a better level generator and all the features that come with it. As I mentioned before, I will try to make some updates that are "part of" level generation, like this deposit update, but does not require it. Even so, I was limited in how I could place and distribute deposits, so that's the sort of difficulty of not having supporting features.


Changes

• Generic Quarry Mines have been replaced by Stone Mine, Coal Mine and Iron Ore Mine
• Sand Quarry and Clay Quarry are now separate buildings
• Add Stone Deposit, Coal Deposit and Iron Ore Deposit props
• Add Stonecutter building
• Add Deposit concept
• Deposits will generate in new worlds on Rocks areas - a guaranteed number around spawn, proportional further away, and then randomly
• Add Quarrying tech unlockable after Mining
• Quarry is now unlocked by Quarrying
• Sand and Clay are now mined at Sand Quarry and Clay Quarry instead of Quarry, which is now only for Stone, Coal and Iron Ore
• Quarry now toggles production by item instead of by auxiliary
• Quarry now has separate mine buildings for each resource - Stone Mine, Coal Mine and Iron Ore Mine, which cannot toggle their production
• Quarry Mines now have to prepare area from Rocks to Excavated Rocks
• "Tools" have been renamed to Mining Tools; change icon
• Quarry Mines now can use Mining Tools for 6 operations; they can still work without, but much slower
• Mine building inspection UI to show Mining Tools use
• Mining Tools now require Quarrying for unlocking
• Add goal for Quarrying
• Food items now have a Food Quality values - 1 to 3 "points" (for example, Carrot is 1 point and Pickles is 3 points)
• Food items now belong to one or more Food Categories - Produce (e.g. Carrot), Dairy (Cheese), Meats (e.g. Roast), Pastry (Bread) and Preserves (Pickles).
• Food items now have Food Variety values for each Food Categories.
• Villager Diet need now uses Food Variety instead of counting items, however each Food Categories is limited to max 3 variety "points"
• Villager Diet need now uses Food Quality as additional criteria, which is based on best available item average quality (currently, best 4 items)
• Export Station can now toggle items on a per-route basis
• Items now show a reserve infoline (in tooltips and Micropedia); Food items also show their food-related values - quality, categories, variety
• Shack (former House) building has been removed
• Building inspection HUD route removal button now requires confirmation - second click (unless Shift is held)
• Selecting Export Station and Import Station will now show a visual trail to the route-connected stations along the tile path; and mousing over a route in HUD inspection will highlight the respective trail
• Better infoline sorting rules (notably, production recipe is listed before usage recipes)
• Minor Micropedia and UI improvements
• Micropedia reserve entries to show item's recipe infoline

Fixes

• Fix empty tooltips in Micropedia when trying to display locked entities in current game
• Building inspection auxiliary construction button tooltips not showing construction costs
• Victory window social link icons misaligned
• Main menu background image to not unnecessarily upscale if UI is set to upscale
• Unlocking a tech would deselect an active construction tab button
• Some props having empty tooltips
• Pickles not being delivered
• Grocery Shop not being unlocked with (only) Pickling
• Micropedia Pickling entry failing to load due to exceeding entry limit
• Fix possible crash when trying to save/load the game

Balancing

• Initial easily-mineable stone supply will now run out, requiring expanding via Quarrying and using Mining Tools
• Food Variety now allows items like Pickles to provides greater variety
• Longer mining times at the Quarries
• Less Sand and fewer inland Sand/Clay areas will spawn
• Medicine and Furniture as Reserves will last longer

Rudy
Snowy Ash Games

In this small update, I'm adding a Pickles food item and a bunch of various small changes and fixes. Most of these are fixes and adjustments since the previous update post.


The main addition is the new Pickles food item:



First off, I've added a new produce food item - Cucumber:





These are basically identical to carrots and tomatoes, but introduce some more variety. Now, I didn't actually want Pickles to only require Cucumbers. In fact, I wanted Pickles to be made from more than 2 veggies, which just seemed a bit too simple. So they actually need all three veggies and the new Cucumber is the third.

I've also added a new farm building - Paddy Farm, which is for semi-aquatic crops. The new crop for now is Sugarcane:





Currently, paddies don't require any special tiles or preparation. This would have been one of the things included with the future level generation. For now, they act pretty much like regular Farms or Gardeners.

Sugarcane isn't used directly, but is used to produce Sugar at the new Sugar Mill:



Glassblower can now make Glass Jars ("Glass" in now called "Glass Pane"):



This means there is now a secondary use for the Glassblower, so they aren't totally useless after the monument.

From Sugar and Water, you can make Vinegar with a Glass Jar:



And finally, with Vinegar and all three veggies, you can make Pickles:



Pickles (and cucumbers) are residential food items. Pickles can be sold at the Grocery Shop. They also last significantly longer than "raw" veggies and longer than other prepared foods.

So, yes, this is a long and involved production chain, which I think is cool for endgame food items. Here are just the minimum required buildings for it:



In the future, I want this to serve as a trade item. It's difficult to produce, takes a lot of resources and is in some ways inefficient when you can just "feed" people raw vegetables. So its value would be in being able to trade it and acquire some resource you cannot otherwise. Pickles also theoretically won't spoil, although I haven't added any proper food spoiling mechanics (yet).


One big decision I made is to remove textual descriptions from all items, buildings, etc. where this description simply describes what the entity does as part of its "recipe line" or (internally-called) "infoline". For example, Plank describes how it's made at a Saw Horse at the Sawmill. And Sawmill describes how it makes Planks via Saw Horse. And Saw Horse describes how it makes Plank at Sawmill. This is a lot to write, maintain, and read. And it is also very much redundant to the infolines that can visually and consistently show this using the same design language. For example, Flour item would only show these infolines without any description:



It feels like something is missing, but there really is nothing else to say about Flour. I could add some flavor text about Medieval flour use or something. But there is nothing gameplay-related to write here - no information I actually need to convey.

So Instead of text, I make sure to show infolines wherever it is useful to know about the entity in question. This mostly means most of the selection/toggle/etc. buttons now have a tooltip with an infoline now:



It should also be noted that any potential translation work would be much easier when every single entity doesn't need to have 3 redundant sentences translated. I would generally want to rely as much as possible on non-textual ways to present information - icons, symbols, recognizable layouts, etc.

One non-obvious difficulty is to choose which infoline needs to be shown here. After all, I can show how Flour is used or how Flour is made. So infolines have some priorities - for example, how to produce something is almost always what they show. (I should note that this is all extremely finicky to implement - in order to make it look simple and clean, it requires an inversely complex and messy implementation.)

I made a lot of small changes to Micropedia, but among them is having lists use the infolines instead of text:



I also added a few more infoline types to show some important information and to have entities show something where they otherwise didn't: For example, resident capacity:



Or knowledge production:




Shops now can toggle their sold items:



There's a few scenarios when this could be useful. None were critical before, but now I'm considering when you wouldn't want to sell veggies that are used for pickling.


I am still working on the new level generator and related changes. That remains the main goal for now. Unfortunately, it's a huge task that integrates with every part of the game, which basically means I've not posted any updates for a while to the point where people are concerned.

So the plan is now to split the work between smaller updates and the future level generation update. I will try to make separate earlier updates for some changes I planned together with level generation. On one hand, this means I'll likely post more smaller updates instead of disappearing for half a year. Bu-u-ut on the other hand, this means level generation update will take longer as I package and expand updates that would otherwise be too small or too broken to publish on their own. In the end, it's roughly the same amount of content, just differently spaced-out.

I personally wanted to just get the big update out of the way. But I think I should just accept that it just never works out that way. I think I have a tendency to always want to add just a bit more stuff. And then it's suddenly 3 months later and I'm still adding "just one more thing". It's the developer's equivalent of "just one more turn". And it always feels like any updates are not large enough anyway, this one included.

I think for now I will just get a few small updates out. I'll try to mix some new content with some mechanics additions. But I'll also try to work in the direction of level generation. Which is very broad and very vague but basically means "anything related to tiles, terrain and layout". So I will probably do some mining rework features next. I've been forever meaning to change the "3 mines can support the whole village" into something more involved mid-to-late game.


Changes

• Add Cucumber item produced at Gardener
• Add Paddy Farm with Paddy Plot buildings
• Add Sugarcane item grown from Sugarcane at Paddy Farm
• Add Sugar Mill with Sugar Press, Syrup Mixer and Sugar Dryer buildings
• Add Sugar item produced at the Sugar Mill from Sugarcane
• Rename Glass to Glass Pane
• Add Glass Jar produced at Glassblower, which can now choose production for Glass Kiln
• Add Vinegar Brewer with Alcohol Vat and Fermentation Vat buildings
• Add Vinegar item production at the Vinegar Brewer from Sugar, Glass Jar (and Water)
• Add Pickler with Packing Table and Pickling Box
• Add Pickles item produced at Pickler with Carrot, Tomato, Cucumber and Vinegar
• Add a new construction menu tab "Food processing" and move various buildings there from the "Food" tab, add most new ones here
• Cucumbers and Pickles are now Reserve items. Cucumbers provide the same amount as other Produce, but Pickles last much longer
• Items can now have distribution values for Shop target deliveries, i.e. veggies shared between Pickler and Produce Shop
• Add Pickling tech that requires Brewing and Glassblowing
• Produce Shop now sells Cucumbers
• Grocery Shop now sells Pickles
• Add "Pickling" goal to make Pickles
• Shops can now toggle/disable the items that they sell
• Rearrange tech tree slightly to accommodate the new tech and dependency arrow layout
• Food tooltip now shows "processing" food counts for those as inputs, i.e. Pickler
• Starting Food Stockpiles will now randomly pick two of the three available from Carrot, Tomato and Cucumber
• Gardening goal now requires any Produce items instead of specific items
• Remove most description texts from items, buildings, props, etc. that repeat what the icon- and label-based lines explain, i.e. "recipe lines"
• Many tooltips will now show the primary/significant "recipe line" for related entity
• Micropedia will now show the primary/significant "recipe line" instead of a description when listing various entities
• Various Micropedia changes - layout, details, relations, etc.
• Achievement panel to fit more items to account for new food items
• Add Scholar and Library "recipe lines" for Knowledge production
• Add House resident amount "recipe line"
• Adjust names for grass tiles, i.e. Thick Grassland and others
• Change some tooltip labels for bonus-affected values to use clearer wording "faster"/"slower" rather than ambiguous "rate"
• Add various new concepts for Micropedia - Produce, Crop, Aquatic Crop, Felled Tree, Building Material, Produce, Storage
• Various sprite and UI layout fixes
• Some tutorial text improvements; make sprites more readable and pronounced, add some detail; adjust timing to switch steps faster
• Split first construction Lumberjack tutorial into step-by-step parts and allow returning to previous step
• Distribution panel to auto-size based on resolution to fit all the entries; otherwise show scrollable area
• Shops can now have up to 10 dedicated sellers (worker slots) that will serve houses in 24 tile "radius"
• Constructing Shops or Residences will show in-range or out-of-range basket icons and range indicator
• Constructing Taverns will show Residence influence icons (like already shown vice versa)
• Change Tavern's "work range" label to "service range" for clarity
• Change Residence "influence range" label to "neighbour range" for clarity
• Constructing Scholar will also show out-of-range knoweldge-observable icons
• Crop growth tooltips to show potential stage speed variation % (e.g. seasonal growth speed)
• Residence reserve item tooltips to show item/delivery demand/priority
• Instead of random villagers starving, homeless villagers will starve first followed by villagers with no food reserves in their residences
• Shops will warn when there are no Residences in range if worker slots are enabled
• Add operation and auxiliary building range indicator/label to building inspection HUD window
• Add timer to achievements in achievement progress window that need it (currently, Happy Place)

Fixes

• Fix building workers swapping tasks with other workers for auxiliary tasks (including when it may be more efficient, but not intuitive/logical)
• Reduce delay between a building worker finishing a task and the follow-up task being available
• Add missing tooltips for entities in lists in Micropedia
• Fix "recipe line" prop entity position and vertical offset
• "Recipe lines" would show locked props
• Outside delivery toggle button not being green when selected
• Possible error/crash in some pausing interactions
• Fix some very long tooltips going off-screen
• Fix some singular/plural spelling/grammar issues
• Remove some redundant font assets from build
• Fix Export Station error when choosing shipment items while it's being constructed
• Forester attempting to choose tiles with incompatible objects and then failing to plant at all
• Forester placing saplings without removing existing object(s) in tiles with incompatible objects
• Forester not attempting to preserve felled trees when considering what props to remove
• Selection HUD for Quarry overlapping self-delivery toggles with efficiency display
• Export Station over- or not delivering items in second and later "slots" based on the first slot
• Export Station reporting shipment items source issue incorrectly with several selected items
• Changing or removing Export Station's items in second and later "slots" would incorrectly record available space for items
• Fix issue where a tile would disappear due to construction work attempting to prepare a tile that then transitioned (e.g. dirt regrowing or moss decaying), subsequently causing any interaction with that tile (location) to fail, including saving the game
• Some tasks not counted for task counter totals
• Removing a shipment item "slot" from Export Station could lead to delivery of incorrect number of items and broken inspection display under certain circumstances
• UI elements reacting to default navigation events (arrows, enter, escape) and conflicting with custom actions; in particular, technology unlock screen would open repeat purchase confirmation dialogues, each able to spend knowledge
• Fix Export Station sometimes not delivering items on "full only" setting when there are multiple items and/on targets
• Fix exceptions on moving the mouse outside the playable area when constructing certain buildings
• Charcoal Burner not observable by Scholar
• Not showing meaningless residence empty reserve consumption info in tooltip
• Crop growth tooltips showing stage time and progress without accounting for possible variation (e.g. seasonal growth speed)
• Fix Mead brewing goal appearing before Beekeeping is unlocked
• Villager's carried item occasionally improperly offset
• Reword various incorrect and imprecise descriptions
• Delivery markers for Houses will appear nearer to actual delivery location to avoid overlapping sentiment info icon
• Fix periodically-updatable tooltips not updating upon moving between different elements
• Residences not deducting score from Housing need with no other nearby residences
• Planting Birch Sapling would not count towards "Trees Planted" goal
• Top overview food tooltip not showing the correct consumption number
• Villagers will resume starving and consuming Food when they have no immediate access to food (i.e. houses with no food reserves or homeless)
• Micropedia infoline elements (like building icon and label) to have proper interaction/mouseover area for clicks and tooltips
• Buildings with worker item delivery (Export, Large Storage) would not deliver items when the target building's capacity is close to full and would cancel pending incoming tasks at other times
• Fix Charcoal not being producable with only Fishing unlocked
• Herbalist would continue infinitely crafting Medicine even when the output is full
• Fix Monument construction achievement not triggering
• Fix achievement window not tracking achievements previously unlocked in Steam
• Balanced Diet achievement not working
• Balanced Diet achievement not including Cooked Fish
• Populous achievement not working
• Fix achievement individual sentiment checkmarks not lighting up
• Happy Place achievement not working because it requires unattainable Awesome Sentiment

Balancing

• Charcoal Burner now produces 3 Charcoal per Log
• Residence (House) reserves will last ~30% longer
• Increase Shop building space for each item from 24 to 48
• Change Tavern operation range from 8 to 12, which is the same as "amenity" range for Residences
• Farm Crops (Wheat, Barley, Hemp) now grow about 30% faster
• Crop growth is further normalized across Seasons (i.e. growth slows down or catches up to match the season), making crops ready roughly at the start of Autumn
• Crops decay 50% slower allowing them to survive into Winter
• Crops won't instantly decay in the first half of Winter allowing more time for harvest
• Potato now follows similar growth rules as crops
• Wasted Dirt tile repairing is about 50% faster in total and twice as fast late Winter
• Adjust Residence reserve demand to prioritize houses with fewer items
• Starving villagers will consume Food at a rate comparable to the rate of villagers in houses with food reserves
• Villagers will die quicker upon reaching the point of starvation
• Villagers have a small chance of dying (5%) when forced to consume a random item due to not having immediate access to food (i.e. houses with no food reserves or homeless)
• Residences require 2 neighbours (other residences) for +1 Housing need bonus down from 5

Rudy
Snowy Ash Games

In this smaller update, I'm adding a bunch of wood-related changes, additions and tweaks.


The major change is that I "split" Planks item into Timber and Planks items, both produced at the Sawmill:



Timbers are now exclusively a construction material:



While Planks are exclusively a production input (currently, only Carpenter):



The reason for this is basically design simplicity - I want to keep long-term construction and input processing separate. I don't want one input to mess with the other input in weird ways. It's just more straight-forward to have these as different items with different proportions. Over time, I observed a few issues that would take disproportionately longer to fix "properly" than to just eliminate the cause altogether.


I added a new tree type/species - Birch. Functionally, all trees are still the same. But a new type adds some nice visual variety:



Trees will now produce 2 logs per tree. Chopping a tree will leave behind a felled tree, which can be chopped for another log:



This makes tree areas last longer, which is most important early game, especially if you lose track of it.


Saplings are now tree species specific, that is, there are now Maple Saplings, Spruce Sapling and Birch Saplings:



Each can be grown at the Arborist's Tree Nurseries:





And the Forester will plant them independently by selection:



All three tree types can now be seen growing from sapling to full tree:




The other major change impacting production is that I "split" Coal into Coal and Charcoal. Charcoal is produced in a new Charcoal Burner building:



Coal is now used as industrial fuel:



While Charcoal (and not Firewood) is used for cooking and similar "light" production:



The main reason is that I did not want Firewood to be shared between residences and production buildings. Same as with planks - the issues I saw are easier to "dismiss" than fix. The other reason is that too many building are using (or should be using) coal, but I did not want the same item to be used everywhere. So now there's a hefty list for both. Adding fuel ingredient makes food production more involved, which is one of the goals. And it also requires more log production and thus bigger forestry areas.


I added a new tile type - Moss. Moss appears "under" forests and makes them look more distinct (here, cleared from trees to showcase):



Moss will decay into grass if nearby trees are cut down and no new trees are planted. Grass will also overgrow into moss after being surrounded by trees for a while.


Export station now supports up to 4 exportable items. This was one of the more requested features for logistics.



I probably should have made it this way to begin with, but there's a bunch of extra complexity I did not have time to add at the time. (I think I spent a third of the time on it for this update.) Notably, there was no way to control which items are fetched or exported internally. And random selection did not work well, so I had to consider all these things.

I also added a simple cleanup tool, which marks items in a tile for prioritized removal. So these will get chosen over other items next time an item is needed.



Building and selecting houses will now properly show the range at which things affect it:



I also (finally) added an automatic deadlock resolution if there aren't enough available building materials to (directly) construct the material production buildings (i.e. Lumberjack, Sawmill, Saw Horse, Quarry, Mine, Mason). I thought a lot about how to best fix this, but I think the most obvious solution is best right now - I just spawn the missing items for the building in question. There are other concerns and issues with starting materials, but at least this fixes the main problem of getting stuck.


My next large goal is to add a proper terrain generator to the game and I am slowly working on it in parallel. Depending on how it goes, I might make another smaller update or go straight for the generator. I still need to revamp and expand quarrying and mining logic and related production.


Changes

• Rename "Plank" to Timber, which is now used only for construction
• Add "new" Plank item, which is now used only in crafting/production
• Carpenter now uses "new" Planks
• Sawmill can now produce Planks
• Add Planer auxiliary building for Sawmill for Plank production
• Sawmill can now toggle produced item(s)
• Add Charcoal item
• Add Charcoal Burner and Charcoal Kiln buildings
• Bakery (and Oven) now also requires Charcoal
• Brewery (and Brewing Vat) now also requires Charcoal
• Smokehouse (and Drying Rack) now requires Charcoal instead of Coal
• Firewood is now only used for Residence supplies via Supplies Shop
• Add Birch tree variant
• Rename item "Sapling" to Birch Sapling
• Add Spruce Sapling and Maple Sapling items
• Rename planted "Sapling" to Maple Sapling
• Add planted Spruce Sapling and Birch Sapling objects
• Tree Nursery can now select whether to produce Birch Sapling, Spruce Sapling or Maple Sapling
• Forester now also accepts Spruce Sapling and Maple Sapling and can toggle used item(s)
• Planted Spruce Saplings become Spruce trees
• Planted Maple Saplings become Birch trees
• Add Sapling concept to refer to any kind of sapling
• Trees now produce 2 Logs each by leaving behind a Felled Maple, Felled Spruce or Felled Birch that can be harvested again for another Log
• Rename object "Stump" to Maple Stump
• Add Spruce Stump and Birch Stump objects
• Add Stump concept
• Chopped-down Trees now leave their species-specific stump behind
• Stumps now have a shadow
• Add Moss tile for forests
• Grasslands and its variants will turn to Moss if there are Trees and vegetation around it
• Moss will revert to Grasslands or its variants if there are few or no Trees or vegetation around it
• Export Station can now export up to 4 different items
• Export Station's HUD inspection shipment items can now be changed, added or removed individually
• Export Station will collect and ship items and Import Station will distribute items proportionally (using global item distribution weights)
• Add new "Cleanup" tool to construction tools menu that can be used to tag items lying on the ground for cleanup, which prioritizes them for deliveries
• Additional crafting recipe tooltip/Micropedia lines will now display as combined (like for Brewery)
• Selected building to not have blue tile overlay instead of green, which was intended for highlighting similar buildings
• Similar building highlight will have an "invalid" overlay texture for buildings that do not match production
• Adjust various sprites and descriptions to fit the new changes
• Houses needs with range (Socialization, Housing) with show the value in tooltips and Micropedia
• Houses will show need influence range tile "circle" and buildings that affect it will show an arrow icon (positive or negative, in range or out of range)
• Building issue indicators will hide if some other temporary/conditional icons need to be shown for the current interaction
• If there are no usable material production buildings (i.e. Lumberjack, Sawmill, Saw Horse, Quarry, Mine, Mason) and no usable material items (i.e. Timber or Stone Slab) that can be delivered to them, the game will gradually spawn in missing items at the construction site, thus preventing a "soft-lock" situation.

Fixes

• Buildings with multiple auxiliaries like Brickyard would always pick the first auxiliary from its internal list
• Rare case when an invalid entity would be selected when something would look for a closest entity matching specific criteria
• Some buildings and items were not listed in various tech unlock lists
• Selecting a building to construct would not switch UI to non-selection mode showing some incorrect UI/feedback elements
• Minor fixes to various descriptions
• Auxiliary building world sprites in various UI locations to have better vertical offset/centering
• Buildings listing missing auxiliaries before they are unlocked
• Tooltips with inner dynamic elements not correctly sizing
• Worker slot for not-yet-constructed building saying that no workers are available
• Change Smelting-based goal asking to deliver Tools (which cannot be delivered anymore) to Iron Ingots instead (for now)
• Fix a couple invalid labels
• Operation location selection not highlighting tiles out of range
• Tavern not consuming its stock (for new Houses)
• Adjust Tavern stock entry tooltip label

Balancing

• Brewery and Bakery now have 3 worker slots up from 1 and 2 slots respectively
• Charcoal extends processed food production chains
• Trees now grow twice as slow (but produce twice the Logs)
• Stumps remain for longer

Rudy
Snowy Ash Games

In this update villager needs and residence reserves have been fundamentally reworked. Although most of the changes are internal and organizational, this still results in a fundamental gameplay presentation change. I say "presentation" because the actual gameplay doesn't really change if you consider the main player actions - supply houses with goods. It is however presented (and hopefully perceived) differently, more in line with the way I originally intended.


I removed happiness from the game. The main reason is that it was a big simplification of how villagers "feel". It was the first version that worked decently and games have done a number-based happiness value before, but it's all very abstract and very simplistic, and I simply don't like it. A single total happiness number does not really represent villager happiness. For example, 20 happy villagers making +20 total happiness just doesn't make much sense when this number isn't capped to anything. And even if I average the happiness numbers, it still does not represent anything - 10 happy and 10 unhappy villagers does not really make 0 "neutral" village happiness in the same way as 20 content villagers would.

Then there's the question of what is "happiness" itself. Philosophy aside, what does a happiness "number" represent? Is a villager with a good diet but bad health really feeling "neutral"? In other words, how much information does representing villager's happiness only as a single number lose and is such simplification useful and fun to achieve? So, again, I just don't like doing it that way. I am simulating so many things for each house and villager, but then I just sum it up to a single number. This just feels like too many "lost" details.


So the big change is that I added several discrete "needs" - Diet, Housing, Health, Comfort and Socialization. This lets me separate villager "feelings" into independent categories. Each need is based on different factors that only apply to that need, so it's intuitively clearer what cause and effect each would have. For example, when a player is providing medicine, they know this will affect health. I will discuss these factors a little bit later; for now I want to focus on the big picture first.


Each need is separately assigned a "sentiment" value. I settled for 4 values as for now: Awesome, Good, Neutral and Bad. They get appropriate icons, colors and labels. And I only added just enough values to establish a sort of scale of opinions. I think keeping it simple is preferable to having a lot of values.


So now I can think about expressing the total sentiment, for example, how do all villagers feel about their health? Of course, this leads back to the same problem as happiness - what is an average anyway, when opinions can vary so much? So I have to be careful trying to naively conclude the mathematical "average". Instead I need to consider sentiment level percentages of the population and how common each value is while also keeping it understandable for the player. Let's just say, this is a difficult design problem.

The system I came up with tries its best to determine the dominant sentiment, but falls back to various descriptive alternatives. These variants are:

• One sentiment is totally dominant, e.g. Good
• One sentiment is mostly dominant, but there is a significant portion of "neighbouring" sentiment, e.g. Good, leaning Awesome
• One sentiment is prominent, and there are significant portions of "neighbouring" sentiments, e.g. Good, but disparate (i.e. "Good, but spread towards both Awesome and Neutral")
• No sentiment can be said to be dominant, i.e. Mixed

This lets me fairly accurately describe the majority's opinion. And while there are a lot of ways that sentiments can arrange, in practice the whole village usually runs a certain way. For example, if there is food shortage, then it's unlikely that there are many villagers thinking Diet is "Awesome" and it is much more likely everyone shares a similar sentiment.

In fact, the above summary was my requirement for the feature. The player must be able to read the description in a sentence or less. A lot of details could or couldn't be implemented to support this result. From there, I can add all the UIs and explanations and breakdowns, but there must be this one high-level at-a-glance summary.

(A question you might ask: couldn't I summarize my sentiment totals into a single happiness value for the whole village the same way? The answer is: yes, I could. But this would actually be summarizing the wrong values in a subtle way. What I would want to first determine is the happiness for each villager and then summarize those happiness values for a total. But this creates another "meta-need" that runs parallel to the existing needs. In other words, I now have Diet, Housing, etc., and Happiness. And this just doesn't feel right to me. If happiness is the summary of needs, then why do I even need to list the other needs anymore? And this just returns back to the very start of having just one total value.)


Each sentiment is based on the fulfillment of its need. What this means in practice is that each need has a list of factors that increase or decrease the "score" of that need resulting in a higher or lower sentiment. For example, not having a house would decrease the Housing sentiment while having Medicine reserves would increase the Health sentiment.

Now, I admit that this gets complicated fast when I start explaining the details, even though it's relatively easy to summarize. For example, it's simple to state what a need is for:



But the actual logic to determine the score needs a very rigorous and methodical explanation:



And only then the "real" sentiment value can be concluded:



This is complicated, for sure. But I technically was doing very similar logic before with happiness, I just never really explained it. Thinking about how to explain this to the player forces me to both simplify things and also keep them well-defined.


The major challenge is to actually show all the needs and sentiment in-game. For presentation and gameplay purposes, I am still keeping needs and their sentiments primarily as part of houses:



This does mean that all residents in the same house have the same sentiment.

Meanwhile the top HUD overview icons now show all the summary sentiments:



A tooltip breaks them down and explains them in more detail:



In addition, a new window is available that expand a little bit more about the sentiments.



So if I need to add additional UI explanation to needs and their factors, this will likely be the place.

Overall, I think the UI is doing a decent job of summarizing and explaining things. It's definitely much more intuitive than I could ever explain in text.


Happiness was previously based on house reserves. In short, more reserves = better happiness. I had a lot more hidden rules here, but that's the essence of it. As I mentioned at the start, these changes don't really affect the core gameplay - houses still want all the reserves from shops. Except now each reserve contributes to different sentiments in different ways that I can define and control precisely.

So the big change is that now I can add more items as house reserves easily, i.e. without disrupting anything. At its simplest, adding a new reserve simply won't change anything. But I can then integrate it in one of several ways. As an example, I added Cooked Fish as a new item and reserve for houses. It now functions like other (prepared) foods.



I definitely want to add more reserves and more items and production chains. Half the reason for reworking the reserve system was to allow more and varied items.


I previously had something like 30 parameters used for happiness calculations. In-game, I explained may be 5 of those. Let me just say that this is definitely not how I personally would want to play any game. Hidden numbers suck. The more you play, the more they suck. So my design philosophy is to avoid hidden numbers. Of course, I cannot explain everything, so there will always be endless hidden numbers and values. But I will try to explain anything that significantly impacts gameplay and could also vary significantly.

There are two locations where most explanation would take place. Any current values would appear in tooltips. And any potential rules would be in Micropedia. Now, this isn't exactly revolutionary - I have already been doing this since the start.

(Going on a slight tangent, I know this sounds a bit silly, but this is technically gameplay. Reading tooltips and reading Micropedia is technically playing the game even though you wouldn't immediately describe it that way. In fact, most players would say that they prefer to "play the game" and not "read the wiki". But, as a player reading a tooltip, you are acquiring information and making decisions based on it. And that's the same thing as looking at the map and placing a building. This is a matter of presentation. When you think about it this way, it's easier to see why some games may feel bad when they have a bad UI, poor explanations or hidden numbers. Even though it's not actually "real" gameplay, it makes "real" gameplay worse.)


There are two big feature sets I removed: tools and happiness productivity bonus.

I removed both for the same primary reason: hidden numbers that modify values too much and are hard to explain in UI. I just don't like the direction these are taking.

Happiness productivity also has the problem of cascading into failure. In short, losing happiness reduces productivity, which lowers produced item amounts, which lowers house reserve supply, which in turn reduces happiness again. So it turns into a viscious circle. This is exacerbated by seasonal changes and harvest timing.

Tools suffer from delivery and logistics issues. It's not too bad, but there isn't any nice way to distribute tools with export/import stations. So anyone trying to maximize tool bonus will inevitably be at the mercy of logistics and item delivery priorities. Internally, tool delivery is another "layer" of deliveries that causes additional issues. I thought the feature is cool and I still do, but I don't think my current implementation is good enough without a large rework (such as, dedicated tool stations or repair workshops).

I am also removing the difficulty option for now, which was basically whether not having items in houses results in negative happiness. This was always a temporary solution to the game being too hard when happiness goes negative and efficiency drops a lot, causing everything to spiral out of control. There are no longer any efficiency penalties, so the "difficulty" like I had it doesn't affect anything. I will revisit "difficulty" options later in some form.


MicroTown at its core currently is mostly about production chains and supplying the houses, which are--simply put--just a place to dump the final goods. And that's the core problem here. Houses don't really feel like a residential area. They are fine from a pure gameplay loop perspective, but not in their presentation.

So, as part of house redesign, I converted houses into 7-tile buildings so I have a lot more "space" to work with:



Houses now intentionally take up a lot more space. I have always wanted the residential sector to feel larger and more prominent. Logically, villagers should want a living space that isn't the size of a workshop. In this sense, having to settle the villagers is an "obstacle" for the player to overcome. So a larger house size is one of the steps in the direction of a more involved residential area.

Secondly, I added a bunch of visual variation to houses:



As much as I primarily focus on the functional aspects of features, there are certain features that benefit greatly from visuals. And I think houses are one of those. Visual variation makes them feel more organic as opposed to strictly functional work buildings.

Now, I only wanted to expand houses as far as villager housing needs are concerned, mostly to do with nearby infrastructure. Notably, I needed them to be the "final design size" of 7 tiles so that I can adjust and balance all the related distances. But once I started changing things, a lot more problems cropped up. For one, they looked all the same and so extremely boring. So I had to add visuals at the minimum. And so on. There are a lot of ideas I still have for houses, but they are all so interconnected that it would require a whole lot more changes, which this update wasn't really about. I will work on stuff like civic amenities at some point.

The one significant factor is that this drastically reduces how many "villager per tile" can be "produced" by houses. So I increased the house resident total number from 8 to 16 and also doubled the storable reserve amount:



Previously-constructed houses will remain as 1-tile shacks with the same number of residents, but with only 2 reserve items and no new reserve items (currently, cooked fish). They will also never fulfill the housing need. These will likely get removed at some point.


As always, there are a lot of tiny miscellaneous changes I won't cover in detail.

Although one new UI window worth a mention is the achievement progress panel:



Since I intend some of the achievements to be more like challenges and goals, then this will track the current progress. Everything is very simple here for now, but it does let you see the progress even if Steam has already unlocked these.


The good part is that I can extend the need logic. I can add more needs, more factors, more evaluations, even more sentiment values. I do have to be careful though. For example, I could break down needs even further, but then I would reach the other end of the complexity spectrum - too many values that become just noise, impossible to follow and generally unfun to care about. At the end of the day, as a player, I just want to know if I'm doing good and is the number is green. So I am breaking this up into something that could generally be seen as a "single high-level need".)

I apologize for this update taking so long. Long story short, I had to take care of some real-life things. Not to say I didn't make this update way too big again by mixing a lot of different features.

I think I will focus on some smaller updates for now. I have to rework plank production and use, especially for the start of the game balance. I also want to look into mining resource changes and long-term endgame production. I can now add new house resource items, so I will think about various options there. I also have a long list of bugs and tweaks to do and I will probably look into some of the more needed ones.


Changes

• Replaced Happiness with Sentiment
• Market squares and Stalls are now fully removed
• Houses are now 7-tile buildings
• Removed Happiness efficiency bonus
• Removed Tools use in production buildings
• Carpenter now requires Nails
• Old "House" is now Shack and can only be deconstructed
• Add House as a 7-tile residential building
• Residential buildings are now all part of Residences logic
• Reserves in Residences are now "real" items and are kept track of and shown in the inspection UI similar to other building items
• Residences reserve item usage is now a timer before the next item is consumed, also shown in the inspection UI
• Shack accepts up to 2 reserve items as before, but does not accept any new or future items
• House accepts 4 reserve items
• Firewood now lasts longer in Summer and less time in Winter
• Medicine now lasts less time in Autumn
• Wool Clothing now lasts less time in Winter
• Add villager needs - Diet, Housing, Health, Comfort and Socialization
• Remove Happiness and replace with Sentiment separate for each Need
• Each villager's Sentiment is now based on the fulfillment of their Needs (rather than directly from reserves in Residences)
• Villager Needs are now evaluated based on various factors specific to each need
• Add information about Need and its Sentiment-affecting factors in the tooltip for building inspection
• Food in Residences forms a "Food" reserve group and consumption is reduced for multiple food items
• Linen Clothing and Wool Clothing form an "Apparel" reserve group and consumption is reduced when both are available
• Residences total Sentiment is now an approximation of all the individual Sentiments in that Residence
• Village total Sentiment is now an approximation of all the individual Sentiments of all the villagers
• Total Sentiment represents the dominant Sentiment (e.g. "Good"), can shift towards a different sentiment (e.g. "Good, leaning Awesome"), can vary either way (e.g. "Good, but disparate"), or can remain "Mixed" if the opinions vary greatly and no single sentiment applies
• Add Needs list to Micropedia where each is explained, including the factors that change the Sentiment
• Add Reserves list to Micropedia where their use, duration and bonuses are explained
• Additional information in Reserves tooltip for building inspection
• Homeless villagers to only have Sentiment about Diet and Housing needs
• Villagers to not have any Sentiment at the very start of the game until Residences are built and first population increase
• HUD top overview now shows the summary of the 5 Sentiments instead of a single happiness value and the tooltip explains the breakdown
• Add Sentiment report window with a full breakdown of Sentiments for each Need
• Remove global productivity bonus (since there is no longer a single global happiness value)
• Monument no longer provides happiness
• Tools are no longer used as "Supplies" by work buildings and do not provide productivity bonuses to buildings
• Remove villager needs difficulty option
• Remove difficulty setting UI for now since the only option it had is no longer applicable
• Add achievement progress panel that shows all the per-village achievements and a simple checklist of the necessary steps to complete them
• Add Nails item made at the Smith from Iron Ingot
• Forge now has to select if it is crafting Tools or Nails
• Furniture now also requires Nails
• Carpentry now requires Smelting (and Logging instead of Forestry)
• Add Cooked Fish item smoked from Raw Fish at the Smokehouse (instead of Roast)
• Meat Shop now sells Cooked Fish
• Houses now accepts Cooked Fish as a Reserve of Food
• Add various concepts like Need and Sentiment
• Add many new icons, like Needs and their Sentiments
• Micropedia now shows what Technology unlocks each entity, as well as what entities are unlocked by each Technology; also add to some tooltips
• Add "back" and "forward" buttons to Micropedia for quick navigation between visited entries
• A lot of description and label changes to reflect the new and changed features
• Adjust tutorial explanation text and steps slightly to reflect the new changes
• Unpausing returns the game to previous speed
• Ranch auxiliary building order to match related item order
• Buildings with adjustable operation location will now draw a max range tile border
• Selected buildings and potential construction buildings will highlight in- and out- of range tile overlays for their compatible auxiliaries and parents as well as other buildings of the same type
• Constructing Scholar will show production building knowledge icons

Fixes

• Fix some building spawn/delivery positions
• Adjust construction sprites for some buildings
• Adjust item pickup/drop-off location for shops
• Fix Monument construction Glass delivery location
• Clicking fast speed UI button when paused would return the game to regular speed instead of fast
• Fix tile validation overlay not changing when switching between construction of entities that have different placement rules (e.g. Stone road vs Boardwalk)
• Fix tile validation overlay not updating when constructing multiple buildings/roads
• Fix incorrect farm animal harvest duration and subsequent item pickup duration
• Stop workers from most self-deliveries when there is work available
• Fix various descriptions/tooltips with outdated or incorrect information

Optimizations

• Various formatted text rendering is slightly faster

Rudy
Snowy Ash Games

In this update, I am adding weather to the game, specifically weather effects for rain and snow. This isn't something that affects gameplay (yet), so it's purely a visual update to make the game look nicer and have some visual variety. And weather is great for this type of goal.


I'll start with the end result of the two effects I implemented, because it's simpler to discuss the steps that way. The two effects are rain:



and snow:



This looks relatively simple, but actually has a lot of internal considerations both from technical and design perspective. I am usually prepared that features end up more complex than they seem to be, but this one really surprised me.


Keeping with pixel art aesthetic, I would want to draw rain droplets and snowflakes. But for performance reason, I cannot draw separate sprites for every particle (this would be many thousands of particles). So I use bigger sprites with multiple droplets that look more or less random:



I call these "slides". The trick is to spawn and overlap, and quickly move many of these slides, so the viewer cannot easily track individual slides and they look like individual droplets.

This seems simple enough... until you try it out and it looks bad. The reason is that the sprite size and the spacing between the particles on the slide is very important. It has to fulfill 2 opposing criteria - it has to be both regular and random. If I make it too big and regular, it will look like a grid moving across the screen. But if I make it too small and random, it will have many unnatural distracting "gaps" and "clumps" of particles. In short, this required a lot of trial and error and even then the result is a compromise.


Individual slides animate by moving downwards and a little to the side:



From there I add a little bit of speed variation to each slide and a corresponding color variation (slower - dimmer, darker). This way, it instantly looks like there are depth layers of particles:



This is probably the biggest visual impact of the whole feature. This variation is fairly subtle in the actual game, otherwise it again becomes too obvious that particles are part of bigger slides.

The depth illusion also really comes together with parallax, which I discuss later.


New slides are spawned above the top of the screen. Then they gradually fall down though their trajectory. Finally, they despawn below the bottom of the screen. Since slides have width and height, then there is an additional margin around the viewport to fit them:



I cannot spawn or despawn slides if they are partially visible; they must have completely left their "visibility area". This means the slides "exist" (simulate, render, animate, etc.) in an area larger than what the camera actually sees. This certainly adds extra complexity and calculations.


Camera zooming changes the number of visible slides:



At first, I began implementing this as simply spawning extra or despawning excess slides at the edges. But I quickly ran into 2 problems.

Firstly, I don't know exactly where to spawn new slides. If I do this randomly, it looks wrong. Weather slides normally gradually fall down though their trajectory. This is theoretically a deterministic process, but practically it just isn't worth the time to re-simulate and predict sprites like that. Plus, I have to (de)spawn them at the "edges" only, which is a lot of additional math to determine the area that does or doesn't need slides.

And secondly, if you zoom in and out quickly, it is very obvious that the weather is not in the same location as before. It might not seem like a big deal, but in practice it's annoyingly way too noticeable.

So what I do instead is I always have a fixed number of slides for the entire most zoomed out view and I simulate them all as if the camera could see them. Of course, I don't render them visually. This might seem like a waste of performance to simulate them, but counter-intuitively at medium zoom, the camera can actually see about 2 out of 3 of the total number of total slides:



So this isn't at all that wasteful and the simple simulation math is fast anyway. Plus, my new rendering logic lets me process this very quickly anyway.


It's a little bit difficult to think about how slides move when the camera is moved/panned. Intuitively, it seems like moving the camera would "move" everything. It's a bit easier to visualize if one thinks about the visible portion of the world changing instead:



From this perspective, the slides form a "box" around the visible world area and this box moves together with the camera viewport. In fact, without animation or parallax it becomes obvious that slides don't actually move at all in respect to the camera:



So there isn't actually anything special that needs to be done for this by itself. Of course, without animation or some movement, it looks completely flat.


Since camera panning is a constant player interaction, then it is very important that this preserves the weather effect depth illusion. I do this with a subtle parallax:



All slides are moved proportionally to the camera pan. Further (dimmer, slower) particles are panned a little bit less than closer (brighter, faster) particles. Thus variable speed, color and movement together form a rather convincing illusion of depth and volume.


So there are 2 ways in which slides can "escape" their box around the world - animation and parallax. Animating slides fall down and right, thus going off the screen. Parallax while panning moves the slides in any of the four directions, also moving them off the screen. Both cases are essentially identical in that theoretically I need to either add or remove slides.

And the solution is actually super simple - I just teleport the slide to the other edge of the camera viewport. For example, if a slide moves too far right, then I teleport it to the left side of the screen across the width of the viewport. Thus, the number of slides remains constant and they preserve the "density" on the screen.



In practice this works like an infinite repeating plane -- no matter how far and fast the slides move, they just wrap around the screen. And this works great.


There is one corner case to this and that's changing resolution (resizing window). This completely messes up all calculations. But I decided to not even bother with this. The visual glitch is not overly horrible and the slides fix themselves eventually. And how often does one change resolutions while playing?


The final feature is to set the mood of the whole scene, which I do by applying a subtle tint to the game world and modifying shadow intensity. It's easiest to visualize by comparing them one after the other in an animation:



Because of color constancy of human vision (and the method I use to blend the colors) it's counterintuitively hard to perceive the change unless you focus on a specific point or the whole image at once. It's more obvious when the game is full screen and the player happens to "unfocus" and notice the difference.

It's more obvious with individual pixels (the eye can pick out warmer and cooler):



What I use for tinting are two "temperature" colors with orange for warm and light blue for cool:



I deliberately only define "cool" and "warm" colors so I can tint the whole scene either one way or the other. While technically I could tint the scene in any mix of colors, multiple colors would end up "fighting" each other and it would be a mess.

Seasons and weather presets define how they affect the world tint and shadows:



Individually, it's basically: summer is warm and winter is cool; sunny sky is warm and rain is cool.

Combining, I get combinations like: sunny summer is hot and snowy winter is cold while cloudy spring is neutral. Moreover, rainy summer or sunny winter is also close to neutral as they "cancel each other out".

Mathematically, this gives me a single "temperature" value between cool and warm, which corresponds to some color between blue and orange. Technically, it's between blue and "nothing" and orange - as the colors reach the neutral midpoint, they "fade" to nothing and there is no tint:



And then I blend this color with everything in the scene. For this, I transform the colors using the soft light overlay blend mode. The exact effect is harder to explain than it is to just show it, but it is basically like shining a weak colored light onto everything, which is essentially what I am going for.

If I were to crank up the tinting to 100% of the tint color, it would look like this:



In contrast to simply multiplying colors, overlay blending methods do not "erase" the underlying color. Meanwhile, color constancy allows the eye to perceive the original colors even when the whole scene is overwhelmed by another color. But even these extreme examples still look relatively reasonable. Which just means that the actual subtle tinting looks very convincing (at least, in my opinion).

A "proper" blending method also keeps color values largely unchanged, which is important in distinguishing elements (for example, tinting doesn't negatively affect people with color blindness):




At first I was going to do more effects like thunder or blizzard. But the problem is that they just become so prominent as to be annoying. So I settled with fewer "gentler" effects for now.

I want to remark that a feature like this is very easy to do badly. And what is "bad" is also highly subjective. It would be much easier to make an easy (fast and dirty) version of effects and shading. But like many video game elements (such as screen shake or full-screen damage effects), it would be very obvious when done badly, with glitches and/or obtrusively. This can make the whole feature very distracting and eventually annoying.

These effects of course have a performance impact. I am drawing large overlapping sprites all over the screen. In fact, before the last rendering revamp update, I couldn't implement these effects without slowing everything down too much.

Both weather effects and tinting can be disabled in the options as well if this is not your thing.


As before, I'm working on housing and civilian needs. I have been working on weather effects in parallel for a while. So I released this update in the meantime just to have an update while I continue with the bulk of the work.


Changes

• Add Weather to the game, which includes Cloudy, Sunny, Rain and Snow
• Weather gradually transitions between clear, cloudy and precipitating (either rain or snow, depending on the Season)
• Rain does not occur at the very start of the world (and older loaded saves)
• Add full-screen particle overlay effects during Rain and Snow weather with varied falling animation, parallax and "depth"-based coloring
• Weather particles shift and scale based on camera movement and zoom
• Add ambient sound during Rain weather
• Add HUD current weather icon and tooltip, add weather icons and descriptions
• Add world tint "temperature" color based on current weather and season, ranging from cool (blueish tint) to warm (orangish tint), as well as shadow intensity multiplier based on the same criteria
• Add audio options toggle for ambient sound (currently, only weather) and volume slider
• Add graphics options toggles for weather and world tinting
• Add "no habitats in range" issue for Game Warden's Lodges
• Custom icons for the Monument techs
• Add internal world weather stat tracking
• Shift-selecting a building or road to build will also "copy" its construction priority
• Animal Habitat selection panel tending label to also show time since last tended

Fixes

• Town Hall no longer requires Bricks for construction
• Bricklaying tech is no longer required for Town Hall tech
• When construction Beehive as auxiliary building, the work range is now shown (with the appropriate label)
• Animals (specifically, Fish) spawning on land
• Occasional internal error due to lag when playing visual effects
• Housing and Firewood goals requiring Market Square and Supply Stall instead of Produce Shop and Supplies Shop respectively
• "Wildlife Conservationist" achievement triggering incorrectly
• "Balanced Diet" achievement triggering incorrectly due to "Cooked Fish" being required for it, but unobtainable
• Deprecated or unimplemented items like "Cooked Fish" appearing in storage selection popup

Optimizations

• Full-screen weather effects can affect performance somewhat

Rudy
Snowy Ash Games