Howdy again! Feel free to Join the Discord![discord.gg] to follow the dev more closely. If you know anyone who likes to read technical game dev blog posts like these, feel free to shoot them a link, I'd appreciate it.

I just wanted to take a moment to celebrate the 138th Steam Upload to the game since its inception.
It's really surreal to see this number slowly tick up day by day. It will still take thousands of updates yet, but the game is slowly taking shape.

Over the last two weeks or so, I've done a mountain of work to move my logic out of Unreals standard framework, and into a "ECS" centric framework, with FLECS.[www.flecs.dev]

One of the primary goals of Peasant Simulator is to let players live out their medieval lives in a world full of "things". A "Thing" can be really anything interactable. A tree, a bush, an apple that you eat, a bloomery currently smelting iron, a corpse decaying in a forest, an item inside an inventory, etc. The technical term for a "thing" is an Entity.

The Systems (the S part of ECS) that govern how these Entities interact with each other, I'm loosely calling "The Background Simulation". This background simulation will determine how fast food rots, where wolves go to hunt, how flammable things are and how fire progresses through them, how fast crops grow, etc.

Everything with a Blue Box around it, exists inside of the background Sim.

Everything in the game world is comprised of Components (Entity+ Component + System) which store their data, and are manipulated inside of this Background Sim, then exposed to the larger gameplay framework of Unreal for rendering and networking.

With FLECS handling it, I can fully utilize most of the CPU's horsepower.

Without getting too technical, an ECS framework is perfect for laying out your game worlds worth of data in a way that is easily digestible for a modern CPU to absolutely crunch through, utilizing all of its cores, and all of its speed.

This is a bit of digression, but 4.5 Ghz on 12+ cores with 32 gig of main memory is an *astronomic* amount of speed and resources that modern machines have access to - and its an absolute crime that we're still yet to standardize dev practises that fully utilize these resources.

ECS is one way to unlock this horse power, BUT ...

Its a very "different" way of making a game compared to the status quo. In exchange for this differentness, you gain SPEED.

By breaking the things in the game world apart into their constituent pieces, the CPU is able to process each piece with greater efficiency, for example:

A Fish isnt a fish - its an Npc{} with Age{Value}, WaterNavigating{} and DropsOnDeath{FishMeat}.
A Crop isn't a crop, its a WorldStatic{} with Age{Value}, CurrentWetness{Value} and Harvestable{RequiredAge}

Crops growing, and drying out.

The Background Sim then looks for all things with Age, and increases that value. All things with Wetness, and decreases that value. Very simple operations applied to many thousands of things, very efficiently. Once a Harvestable{} whose Age{} is greater than their RequiredAge is damaged, it drops fully grown food into the game world, and removes itself from the sim.

With this framework I can now setup the game world so that every fish in every river is slowly maturing, every item left about can slowly decay, trees and crops can grow by the thousands, and each building you place can maintain health, repairs, etc.

Usually you need to fake this sort of stuff, and use smoke and mirrors to hide the exchange while the players not looking - with ECS you get your cake and can eat it too.

Right now, there are a few simulated attributes, and there will be more to come.

1. Crops progress their growth, up to a maximum value.
   
2. Things that are "wet" (crops) dry out slowly, and in the case of crops, will actually die if their "wetness value" ever becomes zero.
   
3. Buildings maintain an internal health value, and can receive damage. When this value hits zero they drop building materials into the world which can be gathered.
   
4. WorldItems ALSO maintain this same internal internal health, but use it to "change" into other items when destroyed. Trees Change into a log + some sticks, rocks change into chipped rock, etc.

This is a relatively small list at the moment, but the framework is there. I'm still tweaking it and testing weird edge cases, playing devils advocate to myself, and looking for flaws. But it's looking pretty good so far.

Here is what some example code looks like, for handling "death" of things in the Simulation.
Firstly, we apply damage to the Entity:

Then, for anyone that died as a result of that operation, who also drops items on death, drop the items (Add Static Item To World):

Players need to know where stuff is. Wolves need to know where the closest deer is. NPCs need to know where the nearest Log is, so they can chop it to wood, etc. To do this efficiently, I've implemented an R-Tree acceleration structure to make this quick and efficient. I didn't write it myself, that's quite above my skill level, but thankfully there are some good R-Trees available for use online, which I've repurposed.

A player querying the game world for the closest three "Things" - you can see the green lines connecting their "face" to the "things" in the game world.

Knowing what's "close" to a location is a difficult problem, but thankfully that is now solved for Peasant Simulator. Now things like campfires will be able to set things on fire that sit too close to them, animals will be able to hunt, and perhaps even players will be able to "track" entities around the game world if their tracking skill is high enough. I'm yet to write these features, but it's looking good.

R-Tree's also have an interesting property in that they can be streamed on and off the disk, so there are potentially streaming related optimizations to be had there, but I'm not looking into that just yet.

This is the next technical roadblock I need to solve. It's a multiplayer game! Which means that the connected clients need to be able to look at food on the floor, and see that it is 20% cooked, or 80% rotten. This is my next feature I will be working on.

That's all for now, thanks for reading if you got this far! Again feel free to Join the Discord![discord.gg] and say hi, pitch ideas and features, or just lurk and follow along. And again,if you know anyone who likes to read this sort of technical content, feel free to forward it their way. See you in the next one!

Join the Discord![discord.gg] to follow updates as they happen and be part of the community.
Fishing is now making its way into the game as a fully interactive system.

1. Bodies of water now support fish populations, with fish visibly swimming across the surface. Additionally these surfaces will LOD down to no fish when the player leaves the area, when the player re-enters the area. Eventually the same fish will respawn, but for now its random.
   
2. Players can cast a lure into the game world with a simple click.
   
3. When the lure lands, it generates a noise visualized by a white sphere.
   
4. Fish within range of the noise will be startled and quickly swim away. Retrieving the lure also creates noise, making careful timing important.
   
5. Once in the water, the lure drifts along its cast trajectory and is gradually influenced by wind direction.
   
6. The lure periodically checks for nearby fish — the eventual goal is for the lure to actively attract them.
   
7. When a fish is nearby, players can release the mouse button to attempt a catch.
   
8. If the lure is close enough, the fish will be hooked and caught.
   
9. If you're just outside the catch range, you'll miss — and the retrieval noise will scare the fish away.
   

The system still needs work, but the aim is to create a fishing experience that is manual, rewards patience, prediction, and observation, with the ability for players to tactically coordinate by shepherding fish.

• Spear fishing — Equip a sharp weapon, wait, and strike for a dead fish.
  
• Hand fishing — Crouch in shadows, wait, and grab to catch live fish.
  
• Physically hauling caught fish, requiring players to carry them by hand.
  
• Ecosystem balance — Overfishing could deplete lakes entirely.
  
• Introducing fish stocking — Add certain species to lakes to control populations.
  
• Fish responding to player shadows and movement.
  
• Better fishing rods and lures improving catch rates.

Thank you for reading, as always the link to the discord is here:
Join the Discord![discord.gg].

Join the Discord![discord.gg] to follow updates as they happen and be part of the community.

Over 50 000 networked, placeable, lootable, destroyable items spread out throughout the game world.

In Peasant simulator, the world will be filled with interactive items. Not only that, but players will be able to place and customize their spaces, potentially creating thousands of props in their villages. This is a technical post that is going to explain how I pulled this off.

These changes will underpin all of the gathering, building, and networking systems throughout Peasant Simulator.

This post is going to have a lot of jargon in it, so I apologize in advance.

How hard can cutting a down a tree or picking up an item be, really? You just look at the thing, left click, and either you loot the apple or the tree falls down ... Can't be that hard right? Wrong. Follow along if you wanna find out why.

You will often hear people comment that making a multiplayer game is hard, and they arn't wrong.

In Peasant simulator, the game world will be littered with interactable items. Players will be able to level forests, pick wild foliage, and place items all throughout their environment in a myriad of ways.

This means a lot of information needs to be sent (replicated) over the network to and from varying computers.

But if you try and replicate a lot of information at once, you hit a hard limit brick wall, and Unreal will crash the program. It does this for the sake of the rest of the gameplay not falling apart, so its a good thing, but if want to replicate a LOT of things to a player, it represents a problem.

If you and a friend host a new game and make a bunch of changes to the world, via editing, building, looting, etc, everything is fine. Even for many hours.

But eventually a new player will connect (referred to as a Late Join), and the server will try and tell them about the game world. It is at this point that this bit of assembly code will say hi:
And if you're in the editor, you'll be greeted by this red text:
Congratulations. You just crashed the server.

We can't send it all at once - we have a hard limit of 65536 bytes per packet. If we cant send it all at once, we send it in chunks - Chunked Replication, and it looks something like this:

1. The player attempts to place an item into the world
   
2. The game asks the ItemEdits system if any player has ever edited this area before.
   
3. If no, the system creates an "Edit Chunk", and remembers it
   
4. The system then stores the edit inside of the this "Edit Chunk", but only if the Edit Chunk doesn't already have too many edits inside of it (otherwise we would defeat the purpose of this whole approach). So, only store an edit if there are <512 existing edits in the chunk, and if not? We create a new chunk and insert them there.
   
5. Later, the system determines which chunks a connected player needs to know about (whichever ones are close to the edit in the game world.)
   
   Problem B - What does it mean to be "close"?
   Determining which chunk is closest to a location, in a sea of chunks, is potentially very costly. We cant just check each one, so we need a way of cutting the data set down to a smaller subset of ones more relevant to the problem ... oh would you look at that its our old friend Divide and Conquer again.
   
   1. Whenever a chunk is created, we snap (quantize) its location to a grid. Like a big checkerboard across the game world.
      
   2. We then insert the chunk AND this location into a "Spatial Acceleration Structure", known as a "Spatial Hashmap" (other structures exist and they all have their pros and cons, but Spatial Hashmaps are fast enough, and very easy to write.)
      
   3. Whenever we wish to determine if a chunk is close to a given location (like where you wish to drop an item for example), we take that location, Quantize it to the grid, and ask the Spatial Hashmap if there are any associated with that location. There may be many.
      
   4. We now iterate over these chunks, and check their changes, finding the one that matches the location we're trying to edit.
6. Once we know which chunks that player needs, we serialize the chunks into binary, ensuring that we always stay below a total serialized amount of 65535 bytes. If we get close to going over 65535, we halt. We will handle the rest later.
   
7. At this point, the system has correctly determined, in this frame, the maximum amount of edits it can hand to a client, for this specific location, without crashing the server! Yay!

Whoever invented geometry sucks.

When dealing with potentially thousands of interactive items in the world, rendering becomes a significant bottleneck on both CPU and GPU resources.

Luckily in Unreal 5, we have access to Nanite which will significantly mitigate a lot of the costs associated with drawing the triangles of the items to the screen. So I leverage that, which mitigates most of the problems (while creating some other problems of its own). But Nanite doesn't magically solve everything.

The naive approach of creating an individual actor for every tree, rock, or placed item would be catastrophically expensive, even with Nanite, and this mistake gets made a lot. Unreal has many "Per Object costs" (non technical term I just made up) associated with rendering things actor by actor. It could probably do it at or slightly below 60 frames per second, but ideally I would like more.

I approach the problem the same way I do with Chunked Replication - but with Chunked Rendering.

1. When Item Edit Chunks replicate down to our machine, we send a "Root Position" for the chunk also.
   
2. If no "Item Edit Renderer" is near that location, we create one. This will be a new actor, and we pay some costs here.
   
3. We then iterate all of the individual Edits stored within the Item Edit Chunk, and create a new "Render Instance" for that edit, and begin drawing them to the screen using Unreals Instanced Static Mesh components. In the standard rendering path Instanced Static Meshes can be slower then Unreals specialized Hierarchically Instanced Static Mesh components, but because we're using Nanite it can shortcut the need for the HISM component, and render its specific ISM component which is much faster then both.
   
4. Tadaa! We just received an "Item Edit" from the server

If you do this right, you can have A LOT of "things" in your multiplayer world:

Over 50 000 networked items spread out throughout the game world.

These things, in the final game, will be things like mushrooms, sticks, piles of hay, firewood, animal droppings, corpses, flesh, dropped equipment, etc. I will generalize this too to include things like building elements, furniture, etc.

You may have noticed that we solved all three problems in basically the exact same way. Divide the problem into some smaller set of problems, and see if solutions can attack these smaller portions directly.

Pretty much every video game ever made hinges on this concept. Rendering, Physics, Networking, everything. Its a rather elegant way that almost always tends to effectively break larger problems down into more manageable problems that the computer can crunch. Not always, but most of the time.

There are many different ways that many games will attack this problem. This solution works for mine , but who knows, one day it might change again. Whatever code the game needs is what it will get.

A few people with access to the game were instrumental in helping me test and find the varying crashes and bugs associated with building this system. Thank you for your time. As always the link to the discord is here:
Join the Discord![discord.gg].

f8d7c0 - Making a big start on world replicated items scaling system
362d64 - Added module to spawn high performance items into the game world
a9f3bc - Refactoring item changes
a5afb6 - Tidying up some code around the item edits
41f3b8 - Fixing bugs
c7ce21 - Bunch of checks because items are null at the moment
17593b - Adding an item edits subsystem actor to handle map-wide item edits
9a674d - Added helper function to get terrain height at point
4c2b58 - Modified engine modules to access terrain heightfield content
163bb3 - Changes to item replication code
a74509 - Major breakthrough with item rendering code
8dd9d1 - Game world spawns with 50,000 meat
958458 - Pushing changes because items now actually compile
4005b7 - ITS ALIVE!
89d9cd - Currently have a bug involving item deletion while a new client is connecting, trying to resolve
625bba - Using spatial hash maps now instead of distance checking everything
9b665a - Adding fixes to quantization problem

Join the Discord![discord.gg] to see updates as they happen.

So since restarting the games development, I've actually managed to put a good chunk of work into it, and I've gotten a lot done, and I want to write some dev blogs about it, so over the coming weeks I'm going to be retroactively talking about the content I've added in periodic dev updates.

So in this post we're going to talk about farming and items.

Items are interesting in games because pretty much every game has them but no two implementations are the same. In Peasant Simulator, I've implemented what I'm calling "partial items" - meaning that instead of 1x Raw Meat, you have 1.25lb's of Raw Meat. If a recipe calls for 0.2lbs of Raw Meat to create some Jerky for instance, you would be able to create many bits of jerky from a single item of 1.25lbs of Raw Meat.

Farming items are treated the exact same way. When you fill your bucket up with water, the bucket contains an Item called "Brackish Water", and has a capacity to hold say 2lbs of water.

Your seed bag can hold up to 10lbs of any ONE type of seed. So you can't fill it with all sorts, you need to be specific.

I think this could be a neat idea to handle the games many item needs, so I'm going to roll with it for a while and see if it is fun, boring and tedious.

I've written a lot of the backend features to support farming in the game, and the steps to engage in the mechanic at the moment roughly are as follows:

1. Equip your Hoe - Right now all players start with all tools, and cannot remove them, so for now all players will have access to a hoe.
   
2. Find a patch of farmable soil - The map has varying splotches of different color, and they represent either farmable area, or non farmable area.
   
3. 2. Till it with your hoe - This spawns a "plot" actor into the world, that can be interacted with to conduct farming. You can remove them by striking them with your hoe.
   
4. Equip your speedbag, and fill it with seeds found in the wild. - The idea here is that you will need to fill a "bag" item with seeds, and then empty that bag into your field. So you might fill it with 20 pounds of barley seed, then plant that seed into say 50 plots.
   
5. Pour the seeds onto the tilled soil - This embeds the seed type into the tilled soil, and it begins to grow, if watered.
   
6. Find a source of water - The map has many sources of water. They have a natural capacity, and a natural replenishment rate. If you drain them fully, it will take some time for the water to return to that water source.
   
7. 6. Use your bucket to draw water from the source.
   
8. 7. Haul this bucket of water to the soil to water it. - The idea here being that players will need to make risk reward decisions based upon how close they can find tillable soil patches to water sources, as they wish to mitigate the travel time hauling water. Eventually they will be able to irrigate and build wells, etc.
   
9. Wait for the crops to crow - A crop will receive growth progress provided its watered. Currently there are no seasonal factors, crops simply grow. Its very basic
   
10. When fully grown, cut them down with a scythe - Equip your scythe, and attack the crops! They will destroy themselves and their seed plot, and dump their fully grown crop onto the floor. I haven't thought about how to interact with tubers etc yet.
    
11. Haul the crops into storage bins either by hand or pitchfork. - By default you can pick some wheat up with your hands, but you cant haul much of it, its sort of like water in a bucket.
    But with a pitch fork, you can carry up to 20 lbs of wheat. In future players will receive movement and exhaustion penalties based on what they are carrying in their hands etc, and there will be a hygeine and filth consideration there, but its early days atm.
    That's the roughly farming as it currently stands.

Crops only gain growth progress provided they are watered. They cannot die to not being watered yet. Something that I will be experimenting with later is the progression of blight and disease, and how it can propagate through crop fields.

Handling anything that needs to propagate at scale will need a lot of investigation into on the CPU, GPU, and networking sides because its very prone to rapidly scaling out of control performance wise. The same goes for fire, and disease spread between animals.

The goal with this farming method is for it to actually be quite laborious. That way, each "break point" will feel fulfilling. The idea is that the player will progress like so:

1. Hand farming
2. Better tools
3. NPC assistance
4. Animal / beast of burden assistance (ploughs etc)
5. Full farming automation.

And hopefully at each break through the player will feel as if they have really taken a load off their back.

I also haven't performed any major optimizations on these yet, and the systems are very heavy in performance. I have several ideas for major optimizations, both in the GPU, CPU, and network side.

Something I want to experiment with is streaming "big data" down Unreals networking stack in a way that doesn't choke out the connections, and allows for late joiners. It's a tall order - but Unreal can do it.

Thank you for reading.
Join the Discord![discord.gg].

Going forward I want to include the change list with each dev update post. These changes are old, but I'm including them here for the especially curious.

e95c68 Added palisade walls - Sepha
0f447f Added a rough starting player area - Sepha
bd7a8a Adding things which can be grabbed with player hands - Sepha
1233fd added apple mesh and apple world items - Sepha
89a301 World items now spawn QTY 1.0 by default - Sepha
4c049e starting to hook up multi teired interaction system - Sepha
17eb91 expanding item code to be trait based - Sepha
e5df52 adding in item traits from lyra - Sepha
23ec57 Consumables can now apply gameplay effects when they are consumed - Sepha
bf9b00 Fixing trait type querying - Sepha
ee7348 Added thirst trait to the game, but its not in the UI yet - Sepha
03c49a Fixing up death code - Sepha
ac07f8 Drinking brackish water now kills you - Sepha
c8d2e8 wolves now spawn at night and annihlate the player - Sepha
01a9a0 Sleep deprivation will now kill you - Sepha
a2e65d Fixed bug where sleep deprivation stacked Fixed bug where sleep deprivation cleared after 5 seconds - Sepha
26f81b Added "Satiety" stat - Sepha
8107bd about to do a massive inventory rework - Sepha
da93b1 Significant refactor to item instances - Sepha
74c4d2 Fixed old item redirection bug on nodes but some are still bugged - Sepha
b3324e Removed null interaction message - Sepha
46a1c6 Adding interaction target names to interact popup - Sepha
1c5dfe Interactables now return their name - Sepha
5e2c73 Food is now no longer wood - Sepha
74a784 Fixing up interactions but about to move them to GAS - Sepha
129cea adding gameplay abilities to food that is eaten - Sepha
6d1880 Seeds are now more capable of determining what they grow - Sepha
1bec5f FIXED THE [quack]UCKING STATS FINALLY - Sepha
b8a57a stats bars are now more generalized - Sepha
7bbf4b can now press T to break own ankles - Sepha
648ac5 Added encumbered gameplay effect for when hauling heavy items - Sepha
ad1ba0 can now take specific water items from watersources - Sepha
2ff08d Added bed mesh - Sepha
3090ba categorized blueprint interfaces for easier navigation - Sepha
a8a9c3 beds are now interactable - Sepha
ed99f4 Added sleep interaction tags to game and bed - Sepha
ea0798 big refactor of interactable display names - Sepha
5d4b11 Fixed bug where lakes wern't drinkable - Sepha
c0e3fa Corpse nodes wern't correctly spawning flesh - Sepha
ad3454 Doubled length of time between wolf spawns - Sepha
7dd938 Increased TOD duration - Sepha
bc9c50 refactoring how items can water crops - Sepha
4adc1b Fixed bug where crops were unwaterable - Sepha
9fc5b6 Fixing seed plots to be able to accept water AND seed - Sepha
6e23ed Fixed half of tilled soil wateirng - Sepha
1934cd Farming is fixed! - Sepha

It's been a few years, but work has resumed on the game.

The current state of the game prototype!

I'm currently changing the name and branding of the game to "Peasant Simulator". Don't be concerned though, the essence of the game hasn't changed, I just prefer the name and imagery.

If you want to follow along with the games progress and/or gain access the CICD branch, feel free to Join the Discord![discord.gg].

Chickens!

Going forward, I'm going to change how the development on this game is structured, and how updates are delivered to the player. I don't want this game to sit in the dark forever. I want players to gain access to the game as it's being created. This is Early Access after all!

Going forward, players will be able to immediately access all updates to the game as they happen. Want to know more? Read on.

For anyone not in the know, CICD means "Continuous Integration, Continuous Deployment". What does that mean? It means that going forward, builds will regularly, and automatically, uploaded to steam showcasing the games progress, and will be made immediately playable to anyone that has access to the game and has opted into the branch.

The process looks like this:

• 1. I modify the game, and upload those changes to source control.
  
• 2. Periodically, a build computer checks if the game has changed.
  
• 3. If it has, it rebuilds, and repackages the game
  
• 4. If this succeeds, the game is uploaded to Steam.
  
• 5. Discord is notified, showing the community a description of the changes.

This means that as the game is being created, you can play it - if you opt in. Every change made to the game is uploaded to this special CICD branch. Meaning every bug, every glitch, and every exploit. If you simply cannot wait for updates, the CICD branch is the place for you.

The original mission statement of this game project was to iterate rapidly, and deliver features to players, experiment with gameplay, and make changes as needed - to find the games fun. In this original goal, I completely failed. This is being changed going forward. Game prototyping will be a central tenant of the game, with the CICD above being utilized to get these tweaks and changes into the hands of fans immediately.

This shot of fishing for example:
This is example of the kind of content that will be prototyped and available onto the CICD branch. It isn't pretty by any means, but it is playable. Iterating quickly like this and keeping features low in scope allows me to make tweaks and changes, responding to player feedback.

Thank you for reading. It's good to be back to the project, and I'm looking forward to seeing how it develops. There have been a LOT of changes going on in the background and I'll be talking about some of them in the coming weeks.

If you want to follow along with the games progress and/or gain access the CICD branch, feel free to Join the Discord![discord.gg].

Howdy everyone!

For the last few days I've been working on setting up our games biomes and some basic biome interaction, check out the following WIP images of our biomes so far!

To spawn the biomes into the game world, I've taken a "temperature" + "wetness" approach so far, and its giving quite decent results. Basically, the further from the equator of the map you are, the colder the temperature gets, and the further inland you are, the dryer the map gets - multiplying these two together allows us to determine which biome you're in.

The biome layout, their flora, and fauna all spawn procedurally, and so will be totally different based on your map seed. Right now this map seed isn't exposed to the player - but we see no reason why not to expose that in the future :)

My goal is to hopefully ensure that pretty much every map seed has a good variation and scattering of biomes, as well as their sizes. Right now the generator needs a little more work - because a lot of seeds end up simply generating heaps of open and empty ocean :(.

A continental shelf, approx 4+km wide ingame.

You can clearly see the biome separations here, between the central hot climates, and then the more temperate climates as you head north or south - ending with boreal and tundra biomes at the edges of the map.

World overview.

Grass is incredibly thick and tall in the forest biome. The sun is blocked by the above tree canopy, and the density of lumber and smaller forgeable bushes is crazy high.

The forest is a bountiful place - plenty of forgeable food can be found there in the form of berries, mushrooms etc - but it is also the home to most of the games animals, so by virtue will be quite dangerous.

Wolves, bears, boar, and deer, can all be found in the forest biome. Every so often, the game world checks to see if the player is in a particular biome, and attempts to spawn an animal around them.

The animal needs enough free space from other animals and humans in order to succeed in spawning - and different animals have different chances to spawn. For example, chickens are far more common then wolves are, and bears are exceptionally rare.

The grasslands are a deceptively simple biome. It doesn't really provide many naturally found resources in the way of forgeable or harvestable plants, there are however some flowers that can be plucked for use in late game dyes.

However, it makes up for that in its geography - providing excellent places to build, and fertile lands to farm. It mostly shines as a fauna based biome.

The grasslands are home to the grazing animals. Bison, horses, rabbits, chickens, etc. I've set up the grass biomes to be not particularly rewarding, but not particularly threatening either.

In fair weather, you should be able to survive in a grass biome just fine, but without lumber to build a shelter, and without a long term food option, its going to be hard to survive without leaving the grasslands biome.

Eventually, you will be able to return to the grasslands in order to tame a worthwhile horse, or to domesticate sheep, goats, and other grazers.

---
Currently, the below biomes haven't much/any content developed for them, but I'll follow this dev blog up in the near future with what content we're going to be putting into these other biomes - and what makes them unique from the other more temperate biomes:

Currently, the plains only spawn the odd tree, as well as some grass for animals to graze. So I'm going to be updating this biome pretty substantially in the near future as I figure out exactly what belongs to this biome in terms of gameplay.

Our initial thoughts for the desert were to make it an abundant source of natural minerals, like iron, and copper - etc, along with salt, and potentially some other naturally occurring spices used in late game recipes and foods.


A southern ice shelf continent. White = Tundra, Dark green = Boreal forest

Probably the most 'extreme' environment that a player will actually manage to survive in long term. Exactly what the boreal forests offer players when compared to more temperate areas is yet to be determined.

The goal with tundra is mainly to ensure players aren't able to venture outside of the world. The idea being that "survival" in the tundra is basically impossible.

We haven't thought too much about the tundra biome, but as we work on it, we will update you all in a future post.

Lastly, the map doesn't spawn proper "rivers" or "lakes" yet - but that's something I'm going to be exploring in the near future. I want to create a specific biome that exists around bodies of water, flowing rivers, etc, that provides an abundance of fishing opportunities as well as some bears opportunistically hunting in the rivers.

Hopefully, if we do our job right, our players will find ample areas that provide either strong tactical position, challenging gameplay, or fun roleplay opportunities throughout our biomes for founding towns and cities.

---

Alright well that's everything for the biome update so far! We still have lots of other extra content to show off, but we're going to detail that in dedicated posts rather then lumping them all in together. Also - I'll make sure to follow up with a biomes pt2 post when the other areas are more fleshed out, so stay tuned!

Remember as always, if you want to influence the direction of the game, then please either jump in the discord and come say hi, or feel free to post in the steam community!

Discord: Join Discord![discord.gg]