Cộng đồng Steam :: Peasant Simulator

Peasant Simulator

Tất cả Thảo luận Ảnh chụp Tranh ảnh Phát sóng Video Tin tức Hướng dẫn Đánh giá

0 đang trò chuyện nhóm

Peasant Simulator is an open-world medieval sandbox. As serf or liege, smith, trade, farm, build, or conquer your way to fortune, glory, and a thriving medieval kingdom. Use your skills in construction, warfare, and crafting to build great towns and castles, then defend them from your enemies.

Ghé trang cửa hàng

Trò chơi truy cập sớm

Truy cập ngay lập tức và bắt đầu chơi; tham gia vào trò chơi khi nó đang phát triển. Tìm hiểu thêm.

Xem nội dung chính thức và phổ biến nhất trong cộng đồng trong tuần qua. (?)

DevUpdate #5: The Background Simulation.

23 Thg03

Background Simulation Devlog

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.

Patch #138!

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.

"The Background Sim"

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.

A modern CPU is fast. Like, really fast.

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.

Current Simulated attributes.

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

Crops progress their growth, up to a maximum value.
Things that are "wet" (crops) dry out slowly, and in the case of crops, will actually die if their "wetness value" ever becomes zero.
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.
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):

Querying the Background sim

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.

Communicating all this to the player.

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.

Thanks for Reading!

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!

Peasant Simulator

Does the game have a single player part?

灭资兴无

24 Thg12, 2021 @ 1:36am

Thảo luận chung

DevUpdate #4: Fishing

10 Thg03

Hello again!

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

Fishing

Fishing is now making its way into the game as a fully interactive system.

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.
Players can cast a lure into the game world with a simple click.
When the lure lands, it generates a noise visualized by a white sphere.
Fish within range of the noise will be startled and quickly swim away. Retrieving the lure also creates noise, making careful timing important.
Once in the water, the lure drifts along its cast trajectory and is gradually influenced by wind direction.
The lure periodically checks for nearby fish — the eventual goal is for the lure to actively attract them.
When a fish is nearby, players can release the mouse button to attempt a catch.
If the lure is close enough, the fish will be hooked and caught.
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.

Future Fishing Features

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.

Community!

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

Peasant Simulator

DevUpdate #3: A world of lootable items.

5 Thg03

Hello again!

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

Technical Update!

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.

Gathering from the world

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.

Problem A - The Internet

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.

Divide and conquer

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:

The Algorithm

The player attempts to place an item into the world
The game asks the ItemEdits system if any player has ever edited this area before.
If no, the system creates an "Edit Chunk", and remembers it
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.
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.
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.
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!

Problem C - Rendering

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.

The other Algorithm

When Item Edit Chunks replicate down to our machine, we send a "Root Position" for the chunk also.
If no "Item Edit Renderer" is near that location, we create one. This will be a new actor, and we pay some costs here.
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.
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.

Divide and conquer continued

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.

Final thoughts

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.

Community!

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].

Changelist

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

Peasant Simulator

Abandoned?

Is this still being worked on or has it been abandoned?

Biggy

10 Thg03 @ 3:08pm

Thảo luận chung

All the screen shots with people hiding their faces by looking away causes me to fear the use of crappy models

Speaking of models, will there be tasteful nudity in the game (i.e. female breasts) and dating simulation of some kind or do we just auto-procreate? The game seems similar to several other medieval games but there's always room for more games when that NEW game OFFERS more rather than just copying existing ideas. I am following this and hoping for the best.

...