The Autumn Sale Is Here, Lords and Villeins is at a Whopping 50% OFF!
Hello everyone,
Autumn is here, but if you're tired of the gloom, wind and rain and dropping temperatures, why not spend your evenings in Lords and Villeins, planning and ruling over a simulated feudal settlement? You won't be able to avoid the autumn season completely, but it's on for only a quarter of the time in the game!
And to further brighten this generally bleak time of year, we bring good news - one of the most anticipated sales in the whole year – The Autumn Sale is here! Not only is Lords and Villeins at an awesome 50% off for those of you who haven't tried it yet, the game's Soundtrack is at a 50% off as well, and to save even more, you can purchase both at the same time in the Lords and Bards bundle!
If you have any feedback, suggestion or question about the game, don't be shy and join the official Lords and Villeins Discord server, we will be happy to chat with you there!
And Fulqrum Publishing is discounting every game in their arsenal as well!
In the early days of Lords and Villeins pre-production, I observed that most city-builders tend to simplify their economy into a few abstract numbers. The settlement just has 100 piles of wood "somewhere" and people can spend them instantly at an infinite distance. Only games like Banished, Dwarf Fortress, or Rimworld would dare to put them in a physical world, but even then all resources were universally shared and not really owned by anyone.
In this, I saw a potential for a different kind of city-building game. One where resources are not only physically present in the world but also privately owned. One where people can not simply take what is not theirs without consequences - including the player. And so the defining direction of Lords and Villeins was set and our team embarked on a journey of solving what turned out to be an incredibly difficult problem.
Before we start designing any kind of simulation, it is very useful to define, what kind of behavior we are looking for. Is the goal to be realistic to draw upon observations of macro and microeconomics? If not, in what ways does it differ from reality? We had to ask ourselves this question nearly every day of development so I am not going to be able to uncover everything here, but a few things stood out above all.
The goal of our economy is maximizing the profit of every entity. This is similar to what AI simulations sometimes call the utility function, but it is important to realize that making more money in this game is not guaranteed to maximize "happiness" (which is what utility functions are typically aiming for). In fact, in many cases, it goes against the survivalist intuition to prioritize immediate profits. While there is no right or wrong approach, this was a direction we chose to go for since survival can be rectified by players more easily than profits.
Our economy is fully logical. This is a key distinction from real-life economies that often display phenomenons stemming from shortcomings of human psychology. Supply and demand are calculated exactly and precisely, with perfect information and without personal bias - something that is impossible in the real world. This should be seen as a feature, rather than a bug.
Logical does not mean perfect. Players rightfully point out many scenarios when villagers are "dumb" and engage in actions that seemingly cause them to lose money or even die. Achieving a perfect simulation would require an incredible level of intelligence that is reaching the scope of highly advanced AI research centers, let alone for a team with one and a half of programmers. At the end of the day, we are making a game and we would like to reach a point where we can consider it "finished". In some places, we rather try to give players tools to manage the behavior of villagers so they can try to minimize the negative impacts of the imperfect AI.
Now that we have the goals more clearly defined, let's unpack what our simulation is doing. We can distinguish between three main elements of the economy: the villager, their family, and the market. On each level, we have a number of systems that together simulate the economy as a whole.
A villager is the source of labor and thus their most direct impact on the economy comes from two places - their needs and productivity/efficiency. Concerning their needs is rather simple. They need some food, clothing, and tools, they need to get paid if they are employed in the demesne and occasionally they spend money at the inn or in the theater. All we have to do is aggregate those values for every individual and take them into account on a higher level (family economics).
On the other hand, their productivity is a different beast. The AI that runs their brain must be able to recognize a variety of contexts and make minute-to-minute decisions that lead to the most optimal outcome of their day. For this, we have developed a three-fold system: the priority solver, the goal planner, and the execution routine.
The priority solver evaluates the priority value for every possible goal that a given villager could possibly try to achieve. From simple goals like reducing hunger or gaining energy to complex goals like producing a material, shopping on the market, managing storage, or cleaning the house. Most goals can be quickly discarded as impossible (i.e. there is no need to plan for visiting a graveyard when none of the family members are buried there). The rest gets assigned a priority number. This number is typically fixed to reflect its importance relative to other goals but can be dynamically changed in certain contexts (i.e. producing resources becomes all the less important the more people are already producing it. Or cleaning the house becomes far more important if the villager is assigned the role of a household cleaner by a different layer of the AI).
The goal planner takes the latest snapshot of the priority queue and attempts to solve plans - a series of steps to achieve the goal in the game world - for each goal from the highest priority to the lowest. The planning process can test for specific conditions of each step and it is also responsible for solving what we call the resource flow - a mathematical set of transactions that validate if the villager has access to enough resources to execute the whole plan, and where would they come from. Once a planner finds a viable plan for any goal, it gives the plan to the execution routine. From there on, it only evaluates plans for goals, that have a higher priority than the one currently executed, and if it manages to find a plan for any of those, it may force the villager to interrupt their current plan and change their focus. To make sure that this happens only in very necessary scenarios, we are greatly increasing the priority of goals that are currently executed so that only the highly reactive or immediately serious goals have the capability to override them.
The execution routine deals with the specifics of the real world. It calls the pathfinder to calculate a path to all targets that need to be reached (see our previous pathfinding article about that here). It handles the reservation of resources and locations so they are not blocked or taken by other villagers before they can reach them (in essence secretly communicating with others over an infinite distance) and it handles the execution of specific tasks along the way.
In terms of the economy simulation, a family is equivalent to a business. For every villager in it, we aggregate their consumption and production for each day. From there, we add some abstract information and predictions - given the history of their production, the size of the family, and current priorities, we try to predict how much of each resource they can produce the next day and generate additional demand for an appropriate amount of material that they will need to produce them. Here we also evaluate the availability of construction materials and generate orders for construction services by carpenters and architects.
So a family unit is largely just an aggregate for demand of material and consumer goods. More importantly, though, it is on this level where we determine, how much of the current stock of each family will be offered on sale. This is done by fitting a statistical model with a history of produce and sales for the most recent 60 days. The outcome is a predictor that dictates, how much of a current stock, after accounting for their taxes and other existing needs, should be offered on sale. This way, the AI has the ability to anticipate lows and highs across the varying seasons and maintain higher stocks in preparation for seasons with lower produce without oversupplying the market and plummeting resource prices.
This model starts with a generalized dataset. Over time as the game collects real data, it adapts and optimizes its decision to the existing situation. A similar approach is also used for generating demand for material. We start with a base assumption and adjust it based on a monitored history of the past few days.
The AI always plays a game of catch-up. Tuning the parameters too much can make it overreact to small fluctuations. Making it less sensitive can make it stubborn and ignore significant outliers. This relationship is a large source of its inefficiencies and no matter how well we tune it, they will always be present. But assuming a stable environment, it should lead to optimal behavior.
All families also aim to slightly oversupply the market to create some reserves for a so-called ad-hoc demand - that is a demand generated dynamically by villagers during the day, which was not accounted for in the morning. The ideal outcome is to offer a certain amount of resources so that on average, they are only left with a small percentage at the end of the day remaining unsold.
The family level is also where the player has the biggest impact, as their warehouse can be a significant source of supply thus creating an indirect market force. The taxation policies can also limit the supply provided by others and since the addition of automated trading policies, the player can also generate their own demand on the local market.
The level of the market is concerned with two main things - market prices and the import and export economy.
Pricing is a very simplified simulation of supply and demand with no inflation. For every resource, we are setting a so-called standard price. This is the price the game always starts with. Then for every day, we aggregate the supply of all families for a given resource, and we monitor the percentage that was sold.
Remember that the ideal outcome here is that every resource is slightly oversupplied. We look at the real percentage and depending on how close we are to the ideal scenario, we conclude that the resource is either balanced, oversupplied (large % of offered resources remains unsold), or under-supplied (when all or nearly all offered resources were sold).
If it is oversupplied, we will slightly reduce its price up to a certain minimum. If it is under-supplied, we will increase its price. And if it is balanced, we will move the price closer back to its standard price (so increase or decrease depending on where it currently sits). This means there is never inflation, and the dynamic prices only act so far as market stagnation and disproportions in supply are forcing them to. As long as this is maintained and the prices remain close to their standard values, all families should (in theory) be able to produce all resources and generate profit on every produced item.
The reason why that only works in theory is because there is one major problem - it is practically impossible to achieve perfect balance on the hundreds of resources that the game generates, in a population of hundreds of people.
Even more so, if a family is too overwhelmed with labor and is unable to reach storefronts on time, the price can go down even if the demand practically exists. However, since an overwhelmed family that is unable to spend their money is a demand without a meaningful impact, reducing their price to attract caravans that can spend their money is a correct behavior.
Caravans give us the ability to buy nearly infinite amounts of resources and provide (far more limited amounts of) supplies that the settlement can not reliably generate. In some cases, the reliance on caravans can be quite high and the amount of supplies they would bring to keep the economy balanced would cross far beyond a comfortable level of immersion, so we keep their impact somewhat limited. To a large extent, players can adapt to this situation and find ways to grow their economies in more stable ways, especially with the addition of favor that alleviates the randomness of generated professions. However, it still leaves us with a problem of cash flow.
What happens, if caravans consistently supply far more, than they buy from the market? Eventually, all gold disappears from the economy and villagers will lose the ability to trade. In fact, we do not even need the caravans for this to happen. Certain professions are naturally far more universal than others. Farmers, hunters, foragers, innkeepers, and builders tend to be largely profitable because their services are so fundamental. And over time, their pockets grow rich, and the wealth gap in our little society is slowly but surely increasing.
We could keep increasing the complexity of the simulation and introduce inflation to alleviate this problem further, but this is the point where we decided to opt out and leave the problem to balancing and player input. On the balancing side, we try to improve the bottlenecks of the production chain and the pricing gaps between higher-level resources to make it easier for other professions to generate disproportionate profits with lower volumes of sales.
On the side of the player input, we give options to utilize high rents on households, the embargo on caravan trade, and find ways to circulate the money back into the economy. This is arguably where we still have some work to do and we are currently testing a new balancing patch, which went through significant efforts to improve these values, but even after years of trying, we are inevitably facing the conclusion that this is always going to happen, and we have to embrace it.
I tried to keep it simple and abstract enough so that you can get a general understanding of the systems that drive the economy of Lords and Villeins. Even though it ends up still being quite a long article, I hope you found it insightful and enjoyable to read.
As a small side note, this simulation also made Lords and Villeins highly historically inaccurate. Feudal economies were far more close knit, intertwined with exchange trades, publicly rented utilities and so on. Trying to keep it accurate would explode the scope of our game beyond anything we could do, so the decision was made to also abandon the historical accuracy in those aspects and simply deliver an interesting game while still keeping its medieval theme and inspiration in the production processes of goods.
I would love to hear your thoughts! What parts of the economy simulation do you find most enjoyable? Which parts tend to be frustrating or repetitive? There is always room to grow, but as you can see, with so many moving parts, our work would never be done.
I truly believe that this approach to a city-builder is very unique, but perhaps also quite niche. Over the years, I have learned that certain problems will never go away and while I do my best to please as many of our players as possible, this is the game we set out to do and I remain committed to its vision, despite its shortcomings. I simply hope that after years of improvements, what we arrived at can satisfy your cravings for a decent economy simulation and get you excited to discover the endless fun in the city-building sandbox of Lords and Villeins.
Truth be told, I was not fully aware, that its weaknesses are also its biggest strengths, and in the past, we were a little bit shy in marketing Lords and Villeins as such. Rather than highlighting its economy, we focused on the society and medieval aspect of the game and maybe we created the wrong expectation. You might have noticed that our store description is now quite different, as we learned from this mistake and tried to change our approach. I hope this article serves to celebrate the long journey we have had.
Thank you for staying with us and supporting us along the way. And stick around, because more exciting news is coming!
Michal Honestly Games
1.3.27 Hotfix Is Out Now
Greetings Lords and Ladies,
We'll keep it short this time, we just wanted to inform you that the 1.3.27 hotfix has just been uploaded to the main build. Check out the Change Log below to see what exactly has been fixed.
Are there any more bugs that we missed and that need to be fixed? Report them here on Steam or join our Discord server!
Change Log:
Fixed possible error with campaign mission not getting marked as completed if a user completed the second-to-last task ahead of time
Fixed missing demand for paper from the clergy
Fixed a game breaking bug when a family requests to split while some of its original members are in clergy or serving as servants
Updated the in-game changelog
Patch 1.3.26. Has Just Arrived!
Behold Lords and Ladies,
The Campaign update is now live! We have concluded the public beta and all of you can now enjoy a new campaign mode - 15 distinct missions that cover the game mechanics and teach you about the game in a more detailed and comprehensive way.
With this campaign, we primarily aimed to improve the experience for new players as it is replacing the old tutorial mode. Returning or experienced players might find the campaign less engaging, so please keep it in mind if you decide to jump into it. Who knows, maybe you will also discover something new about the game!
This update brings amazing things also for those who fell in love with Lords and Villeins a long time ago! We have completely reworked pathfinding, which dramatically improves late-game performance, added a number of quality of life features and introduced a new game module, that allows you to limit the maximum attendance on Sunday Mass.
If you have not been following the beta and would like to see a detailed changelog of things, that were since released there, please read the announcements for the initial 1.3.17 and the following update for 1.3.20. Since then, we have added a few more fixes, which are listed below, and with those changes, we are releasing the updated v1.3.26 live!
As always, we will keep monitoring the state of the game and issue hotfixes on the live version if anything critical comes up. We are now shifting our focus on a balancing patch, so stay tuned for more information about that!
If there's anything update related or game related in general, feel free to ask us, we'll be happy to help! The best place to do that is our Discord server or the Steam forum.
Also if you like Lords and Villeins and have not reviewed it yet, we would be incredibly grateful if you did it now! Just follow the link and share your opinion with other players.
1.3.26 Change Log:
Reduced the threshold for harvesting crops to 20. Crops can also be harvested if there was a fully grown crop for at least two days.
Slightly reduced penalty to royal reputation from noble influence
Fixed bug where a toggle for special settlement debuffs get reset when players switch tabs in the new game menu
Fixed bugs related to wrong "Target Can't Be Reached" notifications
Added hierarchical pathfinding and a new option in settings to toggle path smoothing
Fixed issue with shoe equipment not being generated for villagers (nobody started with boots or shoes)
Fixed issue with tutorial tips not showing up during campaign
Added new notification when the final chapter of each mission is reached. At this moment, player can also exit to main menu and continue on the next map
Imported localization for all languages
Complete tutorial achievement changes its wording to be tied to completing the campaign
Builder desk no longer requires carpenters
Sanctuary mission adds 150 extra favor when the recruit monks quest begins (raised from 100)
Profession buttons in request family tab are now refreshed properly when game modules are changed
Fixed game crash when user rejects loading an outdated file
Fixed game crash when game attempts to load an outdated file
Added 1.3.25 to compatibilty version brake list (save files created in older version will throw error)
The Path To Pathfinding In Lords and Villeins
The public beta for the campaign update is soon coming to an end. In fact, we expect it to go live as early as next week! Besides re-designing the tutorial experience into fifteen distinct missions, each focusing on a unique game mechanic, we are adding one more major improvement to the game - overhauled pathfinding system.
It is improving performance dramatically and because we went through quite the journey of solving it over the years, maybe it would be a fun read to share it with you. So let's get into it!
What is Pathfinding?
If you are not sure what pathfinding is, let me first introduce it a little bit. In the world of AI, we typically refer to NPCs or other intelligent creatures - in our case the villagers - as agents. Agents can do a lot of things, but almost all of them involve getting from one place to another in the game world. So pathfinding is just that - mathematically solving the problem of finding a viable path between two points on the map.
In most cases, this is about as complicated as solving a maze with a pen. You start at a starting point and gradually explore all directions until you reach your goal. If you are smart, you prioritize your choices when to take turns by taking guesses. For example, if the goal is on the right end of the maze, it does not make so much sense to explore paths on the left before you explore the path to the right. It could be wrong, but on average, making these kinds of smart guesses will make you faster. So the art of making the right kind of guess is also a big part of pathfinding.
Common Approach
At first, I utilized a very common algorithm known as A*. It is quite simple and sufficient for most games. The main premise is to make a good guess about the next direction, while exploring multiple paths at the same time. As it alternates between each direction, it keeps track of how long the path is so far and a guess about how many steps are left before it can reach the goal from where it currently is. Then in every step, it simply explores the direction that is most likely to be the shortest until either all options are exhausted, or the goal has been reached.
This algorithm is often quite fast, but when paired up against hundreds of villagers each searching multiple paths every frame, sometimes across the whole map (which is not small, especially the experimental ones), it was soon obvious this would not hold on its own.
Memory To The Rescue
The first thing I considered was to have villagers remember things more, so they do not have to calculate the paths over and over again. After all, if the maze did not change, why not just store already calculated paths in the memory and simply ask for it again later? Furthermore, each discovered path works in both directions, so if they are stored, only half of the maze needs to be solved.
This was a nice idea in theory, but the reality was quite different. On larger maps, memory was bloating really fast, reaching several gigabytes of extra storage. And unfortunately, it was not even making anything faster for two main reasons.
First is that our villagers recognize differences in where they are allowed to go. Not every villager sees the same "maze". Some can pass through some doors, some can lockpick them, while others must avoid them completely. So they are relatively unlikely to ever share already calculated paths with another villager. Most paths were never reused, until nearly all path-finding maps were fully solved and already taking gigabytes of data.
The second problem was the fact that our world is very dynamic and constantly changes. Whenever someone builds a wall, any paths that are going through this location must be thrown away. If we destroy a wall, there could be an already stored path that could now reach its goal faster. We can keep it anyway and sacrifice the accuracy for performance, but this can get quite extreme and it is not very practical. And since there is no good way to tell which paths would be affected, in the end, all of them had to be discarded with a single change on the world map.
The third and small issue was that all of the memory would be lost whenever you would reload a save file, so attempts were made to also serialize this data. This however led to extreme loading times and very large save files, so I abandoned it quickly as well.
Multicore Approach
Most CPUs nowadays have multiple cores that can be leveraged to improve performance, but this does not happen automatically so as my next attempt to make things better I went in to write an architecture that can leverage them.
Every agent now registers the paths they need and puts them in a queue. Then every frame, the pathfinding service would create a batch of multiple requests and schedule them for completion. This allowed me to compute multiple paths at the same time each on a different core during a single frame. The downside was that there was now a guaranteed one-frame delay for each request, but it was a small price for the gains in performance.
Having a queue of requests also allowed me to prevent spikes by limiting how many paths get computed every frame. This eliminated nearly all performance spikes unless a rare very long path would have to be calculated. On the other hand, if a lot of agents requested paths at the same time, they would now have to wait several frames before their request was completed and it introduced a new problem - villagers periodically stopping and standing while waiting for the pathfinders' response.
This was especially apparent every time a wall was built or destroyed. All villagers had to stop their movement, request a new path, and then wait for several frames to get them. This made any large maps with hundreds of villagers frustrating to play (though they were not exactly playable before either).
Despite this, performance gains were still very significant. I also converted the code to use native data structures in order to utilize Burst compiler. To cover how it works would be rather complex so let's just say it made each iteration of the pathfinding run a lot faster on the CPU. And this is where we were until now.
Hierarchical Pathfinding
Pathfinding is now becoming pretty fast but it still has two major downsides - very long paths still take forever to compute, and any time something changes anywhere on the map, all agents must request a new path. It was clear that hierarchical pathfinding would be necessary to solve this.
This one is more difficult to explain, but in essence, it works by separating the map into individual clusters - rectangles of a uniform size. What we want is that any change inside of this rectangle will only affect the rectangle they are part of, and its direct neighbors. If we can somehow do that, not only we can now store some paths in the memory without having to constantly throw them away, but perhaps we can also leverage this to make very long paths to be calculated much faster.
To do this, we will search on the border of each cluster, and create a connection with its neighbor when we can see that an agent could cross the border there. We can also merge some of them to reduce their amount (with some limitations that I will omit here for the sake of simplicity). Then we will calculate a path between all connections inside of the cluster to get something like this:
Now each time a world changes, we only need to repeat this process for the cluster that contains this change. It also turns out that solving just the connections between these entrance points and connecting them in a chain will be very close to the most optimal path for any combination of points on the map. So our pathfinding almost magically becomes a lot more simple.
Because we know which points can reach other points and how long is the path that connects them, we just need to connect the dots on the way to our destination and search for some final bits around the starting point and the destination. If this is too complex to understand, think of it as an abstract orientation map. Instead of having to look directly under your feet with every step, there are direction signs all around you and you just need to blindly follow them.
On a large map of 192x192, traditional A* had to solve sometimes up to 40 000 nodes to conclude its search. On a map of this size, we would create on average between 1000 to 1500 crossings. This makes the maze that we need to solve about 5-10% of its original size. So this abstract map pre-computes about 90% of the complexity of the pathfinding that is shared between all possible paths, leaving the final 10% to figure out some details specific to each combination of the starting and destination points.
This makes even very long paths solved blazingly fast for only a small amount of added memory and a tiny loss in accuracy. And because searching individual paths is so much faster, it does not really make sense to store any of them anymore, since the cost of managing this storage would likely outweigh the benefits of it. What makes sense to do here, is for each agent that follows a path, to also remember which clusters it will go through, and have them request a new path only if these clusters get modified before they reach the final destination. Occasionally they might take a longer path when a shorter path just opened up for them, but these scenarios should be very rare and we can avoid the awkward occasional village-wide halting of movement.
Every path can also be re-traced and smoothed out for only a small extra performance cost to make the final path nearly exactly the same as any high-cost low-level A* algorithm would find. In the end, I decided to make this step optional so players can toggle this in settings if their CPU can handle the workload.
What is the Catch?
Of course, all optimization has its tradeoffs. In this case, building a wall needs to rebuild the cluster immediately, which in rare cases can lead to a performance spike, if the cluster is particularly complex. We are also taking up a bit more memory than before to do this. Searching the path in this abstract map is also very difficult to do natively so the benefits of Burst have been somewhat reduced. Loading times were also extended by up to 10 seconds on very large maps as this abstract map needs to be solved before the game begins. Multiple cores are still leveraged and they make updating a cluster a lot faster, but they do not have a lot of impact on individual searches.
I hope you enjoyed this rather technical read! I would like to open up about the complexity of our game, to shed more light about the challenges we face when optimizing it. What we do is not typical for indie games and it is not always easy to see as much of that work happens under the hood.
If you did enjoy this article, let me know in the comments and tell me if you would like to see more of them! There is a lot of interesting stuff to cover, so I would be happy to share them with you. In the meantime, come hang out with the community on our Discord, and celebrate the Strategy Fest with us!
Michal Honestly Games
Update 1.3.20 Has Found Its Way To The Public Beta
We greet you, Lords and Ladies,
The time has come to update Lords and Villeins once again! This time, we focused on fixing as many annoying bugs as possible, along with improving some QoL features and balancing the game in general. For now, this update can be found in the Public Beta version where you can test it and if there are no issues, we will push it to the main build soon. You can find the whole change log below the article.
If you're still not a part of the Public Beta and you wish to be, entering it is incredibly easy! All you have to do is right click on the game in your Steam library, select Properties, Betas and find the "artisanbeta" branch. If you encounter any bugs or have any feedback to share, we would love to hear from you! Share them here on Steam forums, or come join our dedicated Discord server.
It's also worth mentioning that Lords and Villeins is a part of the currently running Strategy Fest, meaning it's discounted by 50% - that's a hell of a bargain, isn't it? And to spice things up even more, if you get the game along with the whole bundle that includes the official Lords and Villeins Soundtrack, the discount will apply there as well, that means you will save even more money!
Fixed storage capacity not being displayed on all storages in the hover menu
Fixed villagers taking and dropping money to purchase meal at the inn when it is not allowed to serve locals
Fixed Tutorial Tips toggle in the settings always getting set to true after restart
QOL and Balancing:
Families in the population book are now grouped by profession
Daily deterioration of noble relationship reduced by 50%
Removed sand from produced resources of the Furnace zone
Increased inventory capacity of Chest to 200Kg (increased from 50kg)
Increased inventory capacity of Bar to 50Kg (increased from 15 Kg)
Hunters now hunt for up to 6 corpses in the knackery (increased from 3)
Visiting nobles arrive with only 2 excellent meals
Gem Ore has now 15% probability to be mined (increased from 5%)
Rabbits now yield 1 hide and 10 meat (increased from 0 hide and 5 meat)
Sheep now generate 6 wool each harvest (increased from 2)
Swapped priorities of producing paper and leather on individual steps to maximize producing the resource (paper, leather) instead of the consumption of material (rag, hide)
"Anyone can build" category in the construction queue is now disabled if a higher construction tier is selected (it would never display any blueprints).
When clicking on a button to display full production queue on a blueprint it now correctly initializes the accounting report to display the queue that contains the blueprint (select correct family, category and tier)
The sex need is no longer displayed in intelligence reports if deprived and it no longer impacts happinness or mood. This is because in many cases villagers struggle with this need simply because they do not yet found a partner and the player has no control over them doing so, which only leads to confusion.
Farmers will now only start harvesting if a certain amount of crops are fully grown. This is evaluated once a day per zone, and the limit is reduced if the amount of planted crops in the zone is lower than the limit. This further optimizes farmers to harvest and plant crops more efficiently.
New game module added that allows you to limit the amount of people attending the Sunday Mass without penalty.
Update 1.3.17 Has Just Arrived To The Public Beta!
Greetings, Lords and Ladies,
We have some really good news for you! The previously announced free Campaign update is now ready to enter Public Beta! We will keep it there for a few days just to make sure everything is how it should be and later release it on the main "branch".
This patch focuses on redesigning the tutorial experience into a more in-depth and approachable campaign. We have prepared fifteen distinct scenarios, each focused on one major game mechanic of Lords and Villeins which can now be introduced in bigger detail, with video tutorials, tips and challenges along the way. As you progress through the campaign, you will unlock more features until finally reaching the full complexity of the sandbox mode.
While new players are the focus of this patch, we also wanted to bring something for our existing players to play through the campaign. So for each campaign map we are adding a unique scenario with special permanent buffs that alter the gameplay in a thematic way. As you progress through the campaign, you unlock these buffs into the sandbox mode, where you can play with any combination of them as you like!
As of now, we are releasing the update with only the English localization, but we will be adding other languages before the patch goes live on the main branch, which is when we will also update the wording of any tutorial-related achievements.
HOW TO JOIN THE PUBLIC BETA:
If you're still not a part of the Public Beta and you wish to be, entering it is incredibly easy! All you have to do is right click on the game in your Steam library, select Properties, Betas and find the "artisanbeta" branch. If you encounter any bugs or have any feedback to share, we would love to hear from you! Share them here on Steam forums, or come join our dedicated Discord server.
What Is Next?
While this marks the end of the previously announced three major post-release patches, that we have announced at the end of last year, this is not the end! We continue working on the balancing and performance and we have more amazing things to announce soon, but right now, we are still not ready to bring you more details. So, we will just leave you with a mysterious teaser that we have recently published on our social media and let you speculate!
Change Log:
Brand new campaign mode!
Play through 15 new maps, each themed around a core game mechanic of Lords and Villeins
Experience a narrative element of a noble house growing their reputation with the royals
The campaign is aimed to introduce new players to the game in a more detailed and approachable way
Each map introduces a buff that modifies the game behavior. Unlock these buffs for your sandbox games as you complete the campaign.
Other:
Added a new Settlement tab in the accounting tab that displays the wealth information
When placing trees or soil you can now use the scroll wheel to change the grid pattern
Family creation is now a separate step so you do not have to confirm it every time you create a new map
Expanded campaign with video tutorials
Default socage tax is now 25%
Brewing station, Filtering tub and Windmill no longer require a carpenter to be built
Added the ability to caravans to pick up trashpiles and keep them in their pocket in the unlikely event of dropping a trashpile
Restricted collecting resources the caravans own to only one person per family to reduce the likelihood of dropping a trashpile due to single-frame reservation concurrency issues
Added a note to caravan storage and storefront showing which family is assigned to them
Added a randomized maximum amount per item limit in the quest deliveries to prevent impossible scenarios (i.e. 600+ bottles requested since value of each bottle is low)
Variety of bug fixes
Also, please, note that the new content is currently localized to English only. The full localization process will start after we make sure that the build is in a good to go condition.
Summer Sale Is Here, The Prices Have Never Been Lower!
Hello everyone!
That time of the year is finally here, Summer Sale has arrived on Steam, and with it comes tons of discounts - so don't hesitate and get all the cool games to play when you wish to get cozy at home and hide from the hot weather outside.
Lords and Villeins is a part of the sale too! This time for a 50% lower price. It is a great opportunity to bring over your friends and enjoy this game together. Don't hesitate though - the sale ends on July 13!
To see the whole list of discounted games by Fulqrum Publishing, follow this link and head to "Discounts".
Care to get something extra? Lords and Villeins is also offering the Lords and Bards bundle which comes with the game and its iconic medieval Soundtrack. A perfect opportunity to complete your collection!
The development team is fully focused on finalizing a brand new campaign mode, and we have other exciting things to announce later so stick around! The journey with Lords and Villeins is far from complete.
Patch 1.2.20 Has Just Arrived!
Greetings, Lords and Ladies,
We have a small, but important patch for you! We have fixed the critical issue related to family member duplication, changed some achievement requirements and adjusted a few more things to make the game as pleasant as possible!
Feel free to check the whole Change Log below!
NOTE: Save files from previous version (1.2.18) should remain compatible. However, there was an issue which duplicated nobles that were married during their visit and in case you have encountered this issue, we are unfortunately unable to recover your save file. We apologize for this issue.
Fixed critical issue of a noble family member being duplicated when married
Removed the "Everyone Is Here!" achievement (have all artisan professions on the map)
Changed the condition for "Settle them All" achievement. It now requires accepting a visiting family for each profession once across all games (peasant and artisan included)
Reduced requirement for the "There is Nowei" achievement to reach 250 population.
Homegrowing pot is no longer affected by underlying soil quality and always maintains 100% growth speed
Recruits and servants that were accepted through the council request will no longer trigger council request that asks to relieve them from service
Guards will no longer wear jewelry unless it is in their equipment preference set by the player
Vandalism will no longer target structures that do not deteriorate (and thus can not be repaired)
Hotfix v1.2.18 released!
Greetings, Lords and Ladies, Even though the latest update has been thoroughly tested during an open beta phase, some pesky bugs managed to sneak through to your settlements. We have managed to squish them and just published a small hotfix to improve your governing experience! If you encounter any other critical issues, please do not hesitate to report them and we will fix them as soon as we can.
Full changelog:
Fixed crash when attempting to switch to German localization
Fixed issue with regular families damaging royal reputation when relationship is bad (intended behavior is that only noble families have this ability)
Fixed possible crash that occurred when a family was being removed
Added warning when loading save files created in version 1.2.15 or older that they are not supported
