The Guild 3
DevDiary #18 - “About the next game update” - May 2021
With this developer diary we want to start to give you more information about the current development and to answer more of your questions. Please be aware that we sometimes still have to give development priority over a DevDiary and that the latter then appears either belatedly or on a smaller scale.
We have been working flat out on patch EA 0.9.14 since March. The patch is very important to us and is expected to be finished and ready for you at the end of May/beginning of June! But what will be in there? Quite a lot, we can assure you!
Balancing: We continued our efforts to further balance the game. Since every screw that you turn in one direction or the other can have an effect on completely different areas in the game, we will of course continue this after the patch. At this point, we would like to thank everyone who helped us a lot with their bug reports, their suggestions and their constructive criticism. You are great!
Difficulty level: Many of you criticize that the game is too easy. Yes, unfortunately this is still the case in EA 0.9.13.5. The level of difficulty actually has little effect on the game and we had to a) first make the AI “smarter” and b) among other things, enable our designers to use advanced formulas to calculate costs and reputation. Additionally, with patch EA 0.9.14, the handsel and salaries of employees will scale with the level of difficulty, as well as the chances of success with performing especially social actions.
AI: While we're at it, AI will see the vast majority of improvements, and AI dynasties will now become serious entities and adversaries. And if you play hard or impossible, then you will really have to nibble. Of course, there is still room for improvement here and we will continue to turn one or two screws in the future to make AI even smarter. But we look forward to your feedback as soon as you've played the patch.
Sound: In March we already presented you with the first iteration of our SFX revision. In patch EA 0.9.14, we not only continued where we left off, but we also added a lot of new sounds. For example the noises that handcarts and horse carts emit and the sounds in the village and in the city :-)
This is only a small glimpse into patch EA 0.9.14. We would like to address one more thing that has nothing to do with the patch at the end of May/beginning of June and is only relevant for those of you who do not want to play in English or German: We are planning to translate all so far untranslated texts and to include them in a patch in July or August - depending on how long the translation into French, Italian, Spanish, Polish, Russian, Korean, Chinese and Japanese takes. We have waited until now to take this step, as a lot of new texts on the basic functionalities of the game have been added up to this point in time. The new texts that come into play from then on will be translated at a later date.
In the next DevDiary in June we will talk about our further plans. Stay tuned :-)
H. Meyer
Producer, THQ Nordic
G. Holzer
Project Manager, Purple Lamp Studios
DevDiary #17 - "Location, Location, Location" - April 2021
This time around, our DevDiary #17 will concern itself with a small piece of a very large and complex system of The Guild 3 - the AI. The Guild 3 is a very complicated game, offering a vast amount of actions to take and choices to make at any point in time. In order to present a challenge to the player, the AI has to be able to pick a reasonable course of action, and follow it.
We’ve previously presented some areas of the AI, so this time we will concentrate on one system we recently improved upon for the coming patch: Where the AI places its buildings!
This might initially sound like a trivial task: “Just pick a good spot and build there!”. For a human it’s easy to pick a free spot for a new building, but for an AI, unless completely random placement is acceptable, several considerations have to be taken into account. We recently looked at where our AIs put their businesses and residences and determined that we needed something better. To understand what we arrived at, we must first see where we started:
The old building placement was very simplistic. It basically followed three separate rules, based on what type of building needed to be built:
- Residential buildings are simply built close to existing residential buildings. The average position of all owned residences is taken as a starting point, and nearby streets are searched for a free spot. This will cause families to build clusters of homes. The only time a family will “break out” of their starting area is when they upgrade to a house that can only be built in a city - they will then simply search for a buildable spot until they reach a city, and build there.
- Warehouses are built in the middle of all owned businesses. This follows the same logic as above: Take the average position of all businesses, and start looking for a free spot on the closest street.
- Businesses are built close to existing warehouses. If the family doesn’t own any warehouses, they will try to build close to a market instead. Similar to warehouses and residences, all businesses are close together, with the only outliers happening once city exclusive businesses are getting built.
It is pretty obvious that this will always manage to find some valid spot for placing a building, the construction sites will likely be far from optimal. A fishing hut, for example, should try to build close to a fishing spot, and a herb hut should be placed close to a source of herbs, while a barber or preacher should try to find a spot that is in the middle of a highly populated area.
Therefore, we set out to improve on the old building placement logic, and came up with a few key aspects that should be supported:
- It should be possible to specify individual rules per building type.
- It has to be possible to specify buildings you want to build close to (e.g. resource providers, markets, etc…).
- It has to be possible to specify buildings that you want to avoid (e.g. the competition, arsenals, robbers, etc…).
- There should be no limit on the number of rules you can specify per building type.
- The process of finding a spot that satisfies all those rules should be fairly quick (so that the game doesn’t hitch whenever an AI tries to place a building).
- The process of finding a spot should be fault tolerant (so that if you specify e.g. rules only for buildings that don’t exist on the map yet, we still find a valid spot).
Those are a lot of constraints! After we gave it a lot of thought, we decided to implement this via a building placement heatmap.
Essentially, we are now filling the entire street network with values that represent how ‘good’ the street is. Are buildings on the street that you want to build close to? Increase the value of the street! Are there buildings that you should avoid? Lower the value of the street!
After assigning these values to the entire map, we order the streets by their accumulated value, and then try placing the building on them one after another.
So how does this measure up against the criteria we established above?
To adjust the placement of a building type, the designers can specify a list of rules, which looks like this:
PlacementRules = array
{
("Grove", false, 2.0),
("Market", false, 2.0),
("*", true, 1.0),
("Warehouse*", true, 2.0)
};Each line specifies one building type that is of interest to the placement. Wildcards are supported, so while “Grove” will really only match buildings of the type “Grove”, “Warehouse*” will match buildings of any type that begin with “Warehouse”- like the “Warehouse”, and the “WarehouseCountry”. A simple “*” will match ANY building.
The next parameter, true or false, specifies if we are only interested in our own buildings of that type, or in all buildings of that type. So while the rules above are interested in all groves and markets on the map, the last two lines specify that they only apply to all of our own buildings, and all of our own warehouses.
The final parameter determines how important it is for us to be close to that building type. Higher values make the buildings more “attractive”, while lower values mean that they are less important to us. Negative values can even make buildings repulsive, pushing building placement away!
Entering numbers and hoping that everything will work out can only get you so far, so we also added a development switch that allows us to see the importance heatmap while placing buildings. So what does it look like, for example for the rules above?
This shows the heatmap for placing a herb hut, which uses the example rules.There is a grove at the end of the bright red street, which causes this location to be especially attractive for placement. There is no free spot immediately next to the grove, so the AI would likely place a herb hut at one of the free spots along the orange colored streets.
To demonstrate how e.g. warehouses affect building placements, we added two warehouses in the lower right corner of the depicted area. This moves the “attractiveness” to somewhere in the middle between the grove and the warehouses:
Finally, here’s what the same area looks like when finding a good spot for a fishing hut:
There is a fishing spot located at the end of the dark red road in the upper right corner, so the AI would try to find a spot very close to it.
We hope that DevDiary #17 gave you a bit of insight into a tiny part of the AI code in The Guild 3! As mentioned above, this will be part of the coming patch end of May / beginning of June. The patch will include a lot of other AI improvements, but that is another story.
Purple Lamp Studio
DevDiary #16 Part 2 - "Squeezing the world through a pipe" - March 2021
If you haven't read part 1 yet you can find it here.
Today, we want to continue with another issue that is difficult to solve: the raw amount of data that needs to be sent over the network to keep all players up to date about what is happening in the game world. Whenever a character executes an action, the Host needs to broadcast the changes that occurred to all Clients. The more characters there are actively running around in the world and executing actions, the more network traffic will be generated. When too much traffic is being generated, the Clients will start to lag behind which means that there is an increasing delay between requesting an action to be executed and seeing the character actually doing so.
To diagnose this type of problem, we have a tool that records and visualizes all the traffic that is sent. As you can see in the image, the tool visualizes in a graph how much data was sent over time. The height of a bar indicates the total amount of data. The colored sections in the bar show which type of objects (characters, buildings, items, etc.) are associated with the data. The numbers next to the labels indicate how many of these objects were updated.
In the graph above the buildings stand out for producing too much traffic. Buildings are in second place regarding the total amount of traffic generated with only 29 updated instances. In the same timeframe it took 315 updated characters to produce a similar amount of traffic. This means that buildings produce much more traffic per update than characters. After digging deeper, we were able to find out that buildings are sending needlessly data about locally stored paths to other nearby buildings along with each update. We were able to fix this issue in patch EA 0.9.13 and significantly reduce the amount of network traffic that is generated by buildings.
Additionally we noticed that on large maps, the number of supply caravans could become very high. The large number of characters moving around was also generating a problematic amount of network traffic. Because of that, we reduced the number of supply caravans that restock markets in regular intervals. Each supply caravan carries more goods, so fewer caravans are required to keep the markets stocked.
With these improvements the Multiplayer mode should run much more smoothly on larger maps. Nevertheless, the total amount of network traffic is still the biggest technical issue for the Multiplayer mode. We will do our best to further improve it in the future.
Character Movement
We also want to shine a spotlight on how character movement works in Multiplayer. It is a good example to demonstrate how certain features that are straight forward in a Singleplayer mode can be hard in a Multiplayer mode. In part 1 of this DevDiary, we have described the usual approach for executing an action in Multiplayer. It is to have the Host perform the action and broadcast the resulting changes to the Clients. When applied naively to character movement, the Host would calculate the path for the character and, over time, update the position as the character walks along the path. In this scenario, each change in the character’s position needs to be broadcasted to each Client. This approach has two problems. For one, it requires a very large number of position updates that need to be sent over the network. And secondly the character’s movement would appear to stutter on the Client because all data that is sent over the internet is always subject to an inconsistent delay.
There are different ways to solve this problem. The Guild 3 approaches it by transmitting primarily the movement destination. The Host will send a message that says “Alice is now running towards position X” or “Alice is now running towards Bob”. Each Client will then independently perform all the steps necessary to move Alice to her destination. That includes calculating a path and moving Alice along that path while trying to avoid collisions with other characters on the street. Once Alice has reached her destination, the Host will send a final message: “Alice is done moving. Her final position is X”. When this message is received on the Client, they will accordingly finish the movement process and place Alice on that position. With that approach, the characters will move smoothly on the Client with only a minor correction at the very end that ensures that the positions of standing characters remain accurate.
Recent Problems aka “Where did my friends go?”
Many of you have noticed and reported connection issues when trying to join multiplayer games in the past couple of weeks. In order to properly explain those problems and how we tackled them, we have to take a little detour into how our matchmaking system works.
The first important part of this system is the matchmaking backend, which enables us to connect between Steam players with players from GOG. The backend is developed, hosted and maintained by another team at THQ Nordic. Secondly, The Guild 3 uses a software library, which communicates with this backend to create, maintain and make your games visible and joinable from all around the world. When you host a game, we send a command to create a so-called lobby for you in the backend, which in turn takes care of making it visible (or invisible) to other players and also enforces player limits. Other players can then see your game in our game listing window, which retrieves this information from the backend. When you decide to join a session, we send a command to the backend that you intend to join this specific lobby. Once this is successful, the backend then notifies the hosting player’s game that someone wants to join and their game instance will then initiate direct communication between your game and the hosting player to make your session possible.
Now let’s have a look at the recent connectivity issues many of you have experienced. We received reports from you and our internal testers, that joining of multiplayer games would sometimes not work or behave in a weird way. With the help of your feedback, the work of our testers and our own experiments we could analyse the issue and see that the underlying problem was in the backend and was most likely introduced with a recent update. As with every piece of software, bugs often surface when implementing new features and this was exactly the case here. We then provided the backend team with all the information we could gather about the problem and they then worked tirelessly to resolve it. In the meantime we also did some small improvements to make the connection process smoother. Patch EA 0.9.13.5 then included an increased connection timeout and a little fix for disconnecting from lobbies. The increased timeout was necessary, because the backend is also used by other games from THQ Nordic and may experience heavy load from time to time.
For the upcoming version of the The Guild 3 we are currently working on some more improvements, which should make the multiplayer experience a bit smoother. E.g. we are upgrading the library we use to interact with the backend (the new version contains a couple of bug fixes and improvements) and we are also remodeling the multiplayer connection process a bit to provide for a nicer experience.
We hope that this DevDiary was able to give you another interesting insight into the multiplayer mode of The Guild 3 and why it is so difficult to solve all problems quickly. We will do our best to continuously improve it.
Patch notes for EA 0.9.13.5 "Spring in the Duchy of Burgundy!" – March 24th, 21
Hello everyone!
Originally planned as an Easter surprise for you, we decided to launch the brand new scenario map of "Dijon" together with the bugfixes for the multiplayer lobby and the reconnection to existing multiplayer games.
Please inform us if you still have trouble with the lobby and the initialization of your mp games. We will continue to work on the multiplayer and bring out more optimizations in the coming patches.
Patch EA 0.9.13.5 includes the following content and following bug fixes:
- the brand new scenario map of "Dijon", capital of the Duchy of Burgundy!
- fixed a bug in the multiplayer lobby, that gave false reports about the fill-state of mp games - players tried to join a game but the response of those lobbies was sometimes: "maximum number of participants already reached"
- the log-in and log-out process of clients has been optimized - before that the process sometimes time out and the client received the notification that the connection has been lost
- the reconnection process to existing mp games has been optimized - like with the log-in and log-out process, the reconnection to existing games was sometimes not possible due to false responses (“unable to connect”) or timeouts
We hope you enjoy the spring in the Duchy of Burgundy, in singleplayer or in multiplayer with your friends!
Patch notes for EA 0.9.13.1 – March 11th, 2021
Hello everyone!
Thanks a lot for your immense help with locating and hunting down the crash bugs in EA 0.9.13. Your save games and dumps steered us to the sources of the issues!
Save games from EA 0.9.13 should be loadable with this version. All save games you have provided us for this bug hunt are working fine again.
Regarding the annoying bug in the multiplayer lobby: we are on it! Please be a bit more patient. We will deliver a separate patch once the bug has been nailed down.
This hotfix however includes the following bug fixes:
- Fixed a crash in the tutorial when producing offspring
- Fixed several crashes when loading a save game
- Fixed a crash when setting up transport routes
- Fixed a bug in the storage rules where the procure settings did not respect the max storage settings and the transporter procured endlessly intermediate products
Known Issues
- The game might still crash in rare instances when going back to the main menu. We need more time to fix this bug. It will be rolled out with the next version.
- Although we fixed a few instances of items duplication for this patch, items can still be duplicated when dragging them from one employee/family member to another employee/family member inside the building windows (business, market, residence). We are on it.
Thank you all for your patience!
Patch notes for EA 0.9.13 “I am the master!” – March 4th, 2021
Hello everyone!
With patch EA 0.9.13 we are going to give you the reins for your businesses into your hand: you can now manage each single worker manually - if you’d like to do so! And you can allow/forbid the auto-equip routine for the master AI of your businesses, which has equipped your transporters with backpacks and carts even when you haven't seen the benefit in that.
A main focus has been set on improving usability, stability and performance of the game in single- and multiplayer to make the overall playing experience better. To achieve this, we invested a lot of time in fixing bugs and we made bigger reworks of existing features like the production, the budget book and the supply transporters.
A lot of effort has been put into balancing as well - most noticeable in the changes regarding influence gain and costs, and in the prices for titles, buildings and their addons. We will continue to balance the game until you and we are happy with the results.
The complete soundscape of the game has been reworked. A lot of sounds had to be changed or replaced completely, and all maps had to be reworked as well. Like with the balancing of the game, this is just an intermediate step until we reach a state with which we and you are satisfied. We value your opinion a lot so please give us your feedback to the recent changes in the survey (see below) or in the forums.
New features
- Individual Production:
-- Manual assignment: With the individual production, every single worker can work on a manually assigned product or action. By dragging the desired product or action directly on the worker, the workers start producing only this product or performing only this action no matter in which production mode the whole building is. Note: The workers who have such an individual task don’t produce any intermediate products, thus you must make sure that the rest of the employees support this individual worker.
-- Productivity bonus: In case you don't rely on the automated production and use the manual production, manual looped production or individual production, a small productivity bonus is given to the respective workers as they are more motivated by these personal instructions. This small bonus is applied to workers who perform business actions, too!
-- Residence: Children and adults can now perform their tasks in parallel in the residence, no matter how many orders have been placed.
- Guards of the Sovereign: The sovereign has two bodyguards and two guards for their main residence.
- Political Offices:
-- As an office holder in the chamber of the "town henchmen", you are now able to send away a city guard. The city guard will then head for the marketplace to see what is going on there, while you can do whatever you please without the watchful eyes of the city's constables.
-- You can now withdraw from office-applications in case you don’t want to go that political career path anymore.
- Prison and trials:
-- Accused workers who are imprisoned or waiting for a trial can not be fired anymore. From now on, your business will be affected if one of your employees gets caught...
- Options:
-- Auto-equip of transporters: In the options menu, you can now find a setting to enable/disable the functionality that auto-equips your transporters with a backpack or cart. This way, you can have full manual control about the equipment of your transporters if you wish. By default, the auto-equip is deactivated in the options.
-- Edge scrolling: The camera panning when the mouse is near the window border has become optional. This should help those of you who are playing the game in windowed mode or on systems with more than one screen. By default, the edge scrolling is turned off.
- Character and building focus: In case you’ve lost the selected character or building out of sight, you can focus the camera on them again by double clicking on the portrait icon in the lower left corner (the currently selected character or building).
Content & Balancing
- Production:
-- Several smaller optimizations and bug fixes have been done in the production to give you better feedback.
-- Storage rules: In manual looped production, transporters do not automatically sell intermediate goods above the minimum storage limit. You have to manually set the max storage limit to make them sell the goods. This new behavior leads to a more optimized production flow as intermediates are now more frequently on stock than in previous versions.
-- Gathering: Characters who are manually sent to gather resources can do this now without the need of unpausing them.
-- Warehouses: Transporters of warehouses don't immediately sell the intermediate items anymore and instead consider the needs of your businesses first.
- Supply caravans:
-- Improved the handling of the distance between supply transporters and their guards.
-- The frequency of supply transporters has been reduced to avoid maps crowded with horse carts.
- Budget book:
-- The budget book received a complete overhaul. You should now have a more detailed list of all your expenses for your businesses, rented resource providers and your family.
-- Also the score section (former winning points) has been completely reworked.
-- Several bugs in the budget book were fixed during that rework.
- Balancing:
-- Buildings and building addons are more expensive now. The building conditions (health) have been balanced and the building conditions can now be upgraded through new building addons. The bonuses of building addons have been reworked, as well as the numbers of available building addons per building.
-- The influence gain of several actions has been reduced, while the influence costs for titles and for some skills have been reduced. The influence gain for office holders has been reworked as well.
-- Some of the more powerful actions, especially the actions to gain influence, now have a family wide cooldown. So if one family member performs the action, the cooldown counts for all members of the family.
-- The costs for the actions "Church donation", "Oil the wheels of bureaucracy", "Bribe an official" and "Send to the court of the monarch" now increase with your title. While in the beginning you pay just a few coins, those actions will become a lot more expensive when you reach a higher rank.
-- The privilege to lease mines, quarries and/or lumberyards is now granted with the citizen title. And you find a new icon in the action bar of those resource providers which gives you access to the map-wide lease menu.
- Soundscape:
-- The sounds of birds, crickets, wolves and so on are now played with a frequency set for each sound sphere separately.
-- The sound spheres for villages, towns and marketplaces now have several variations which are randomly played. The transition from no-sound to sound is obvious at some marketplaces when you move the camera towards a marketplace. We are working on that and hope to have a much smoother transition in one of the coming patches.
-- Footstep sounds and sounds of horse carts should be less penetrant and annoying now.
-- The sound volume for incoming notifications has been reduced.
- AI families and NPCs now have a different logic for using the horse carts. This leads to a smaller amount of horse carts on the map.
- Characters who are buying or selling at the marketplace are now occupying defined positions in front of the markets and are thus crowding the area in front of the markets a bit less.
- Ships now create effects on the water when they are sailing.
- The display of name plaques of buildings and characters has been improved. They are now only shown until a certain distance to avoid maps crowded with text.
- Achievements have been reworked and adapted to the latest changes in the game. This task is still in progress and minor changes still need to be done. Some maps are not released and thus the respective achievement can’t be unlocked for the time being.
Bug fixes
- Performance: several improvements to the performance in single- and multiplayer were made
- Stability: Fixed several crashes in single- and multiplayer - they are becoming less and less :-)
- Multiplayer: Fixed several bugs with synchronization in multiplayer
- fixed two bugs that made transporters or their horse carts turn invisible
- fixed a bug where unconscious characters could not be selected (correction of the hitbox)
- Chat:
-- a small exclamation mark icon notifies you now about new chat messages
-- the chat now “jumps” to the most recent message to make it easier to follow the conversation
- fixed a bug where the order list in the production did not update after unlocking a new skill or upgrading a building
- fixed a bug where characters held items while they were using a hand cart, a riding horse or a horse cart
- fixed a bug where characters held items while they were visiting the tavern or the barber.
- fixed a bug where the user needed to have the double amount of money to unlock a building add-on
- fixed a wrong message when the player tried to equip items that were not suitable for the character
- fixed a bug where high level businesses made too little money
- fixed a bug where the spouse and the heir did not have all icons correctly displayed in the family tree
- fixed a bug where the market window did not open when a henchman entered the market
- fixed a bug where characters did interact with dead characters - this is a game about the late middle ages and not a fantasy game :-)
- fixed a bug where several actions failed when the worker was too far away from the home business
- removed the needless add-on tab from rented resource providers
- fixed a bug where the items you had selected (in the upper left part of the production menu) to be part of your automated production were not saved
- fixed a bug where the summoning action lead to wrong numbers of received items
- fixed several bugs where characters could get stuck (paths, bridges)
- fixed several bugs with the display of ships
- fixed the broken conquer building action
- fixed a bug where people were sleeping outside of the market
- fixed a bug where the bomb was thrown into the wrong direction on the client in multiplayer
- fixed a bug in the tutorial where already read texts were not displayed anymore
- fixed a bug in the tutorial where the scroll position did not get reset
- fixed a bug where several notifications did not get triggered (e.g. an employee has died)
- fixed a bug where adopting children in the church failed
- fixed a bug with toddlers being stuck in the church after losing the residence
- fixed the missing intro on the Augsburg map
- fixed a bug where certain skills were missing on the Augsburg map
- fixed a bug with a too high bonus for the skull lamp and the rose water
- fixed a bug where dead family members were still displayed in the residence
- fixed a bug where items in production could already be equipped
- fixed a bug where characters paid for services although the waiting time timed out
- fixed a bug where the change place of residence could be performed for free although it should have cost 200 coins
- fixed a bug where a building window didn’t open under special circumstances
- fixed a bug where the portrait colors of the spouse did not get updated after the wedding
- fixed a bug with the character list filters in the business window not getting updated correctly
- an exclamation mark appeared without content in several places of the game - that has been fixed
- several building models have been reworked to fix bugs in the structure, in the texture, with the shadows or the LODs
- a lot of character models were reworked to fix bugs with the skinning or with animations
- a number of sounds were missing on several maps, like the cuckoo or the magpie
- several misplaced props have been fixed on all maps
- port and school on the Prague map had no name
- fixed several instances of missing texts and made many text fixes for English and German loca
- fixed some dozen more small bugs not mentioned in this list
Known issues
- Score: the calculations of the points for offices and for the main residence are not yet finalized
- Achievements: the three score points achievements are not yet finalized
Important information
The game does not display/load save games from outdated patch versions as they have become incompatible due to the rework of core systems.
If you are experiencing difficulties with loading and saving the game, you may attempt to delete all files from the folder “%userprofile%\Saved Games\Guild3” (C:\Users\[USERNAME]\Saved Games\Guild3).
Multiplayer: If you have a restrictive firewall then you may have to manually open the following outgoing ports to be able to play in multiplayer: 61111 TCP & UDP, 36895 TCP & UDP, 36975 TCP & UDP. You can find this information in the FAQs Multiplayer on our webpage as well!
It is quite possible that some problems that you have in your game are caused by missing or corrupted files. In this case, the following might help: right-click on "The Guild 3" in your Steam library, then Properties - LOCAL FILES - VERIFY INTEGRITY OF GAME FILES...
If you still have issues afterwards, then we recommend uninstalling the game and then manually delete the folder “%localappdata%\Guild3” (C:\Users\[USERNAME]\AppData\Local\Guild3). Then re-install the game.
Crash dumps for bug reports can be found in “%localappdata%\Guild3\sentry\reports” (C:\Users\[USERNAME]\AppData\Local\Guild3\sentry\reports) per default.
Join our official Discord server (link) where you can meet us (that is, when we take a break from developing games) and other players to chat about the game.
What we are planning for the next patch
Bug fixes, bug fixes, bug fixes, plus balancing and SFX. And maybe a brand new scenario map :-)
A short outlook...
We will further work on balancing and the soundscape of the game and we will focus on improvements for the AI. Fixing bugs will stay our highest priority at the moment, but we are also starting to make plans for a brand new rogue profession...
**********
We value your feedback!
If you have the time, we would appreciate it if you could fill out a short survey regarding the changes we made in patch EA 0.9.13: Google Form
Please note: we do not collect any personal information other than your feedback - you will remain completely anonymous. This survey will end the day we release the next patch.
The next patch is close!
We just wanted to give you a short update about the long awaited patch EA 0.9.13, which should have been released already.
As we are writing these lines, the version EA 0.9.13 is just a few hours away from being moved into our internal stabilizing environment. There, it will be undergoing extensive testing and if our QA does not find any major issues, it will go live in the first week of March.
Patch EA 0.9.13 has grown to one of our larger patches so far. While mainly focussing on fixing bugs and on balancing, we have reworked some features as well.
Thank you all for your support and patience!
DevDiary #16 Part 1 - "Of Hosts and Clients" - February 2021
Before we dig deeper into the multiplayer mode, we want to briefly shift to another topic: we are aware that a lot of questions about the editor have come up recently. We would like to tell you that, while the editor is still something we are planning to release, it will not happen before the game is finished. The editor is still undergoing changes as we progress with the production of the game.
Now, let's head back to the topic of this DevDiary. First, we want to give you a short overview of the general architecture. The Guild 3 uses the very common Client-Server architecture. One player (the one who starts the game) gets a special Host (also known as Server) role assigned which means their instance of the game gets to decide what is happening in the game world. The other players are Clients who need to send requests to the Host to influence the game.
For example, if a Client wants to send one of their characters to attack someone else, they will send a request to the Host that basically says “Please, execute action Attack with Alice on target Bob”. The Host will then verify the request and check if Alice is able to start this action (e.g. Alice is not sitting in jail currently and Bob can be attacked). If the request is valid, the Host will start the process of executing the attack. The first step in the process is to send Alice to run towards Bob. The Host will then broadcast to all Clients what has changed. The changes will list for example: “Alice now has an action Attack with target Bob. Alice is now running towards Bob.” As the action gets executed over time, the host will broadcast additional updates such as “Alice has reached her destination and is now standing at position X. Alice is now playing the animation punch. The hitpoints of Bob are now 20.”
So to sum it up, a Client sends requests to the Host that describe the actions that they wish to perform. The Host will validate the requests and inform all clients via broadcast messages which changes have occurred in the world.
Ongoing challenges
There are two primary challenges for making the Multiplayer mode run stable and reliably. In the past, we have had many problems related to these two topics. And even now we are still struggling with them from time to time, since they are related to how the underlying networking system works in The Guild 3 and are very hard to solve completely.
In today’s DevDiary, we want to focus on the first issue, which is a very technical one. For Host and Client to be able to communicate effectively, they need to have a shared knowledge about which characters exist in the world. In the example above, they were sending messages about the characters Alice and Bob. For this to work, both have to have a list of all the characters that exist in the world. Both have to know that in the current world there exists Alice, Bob, Charly, Dave, etc. And this list can change because characters can die and new ones can be born. So at some point in time, the Host will need to send a message to all Clients that says: “There is a new character Eve. She stands at position X, has brown hair and is wearing a commoner’s garb (as well as all the other things there are to know about Eve).” Everyone needs to remember about Eve so that when a later message arrives that says “Eve has changed her clothes and is now wearing plate mail”, all the Clients know what to do and display Eve in the new piece of armor.
When things go wrong, it can happen that a Client has forgotten about Eve and does not know what needs to happen when a message mentions Eve. Depending on the case it can go unnoticed for a while, but in the worst case these situations can crash the game. Of course, this issue exists not only for characters, but also for buildings, trees, items and all the cog wheels that make The Guild 3 work.
This type of problem is notoriously hard to diagnose and fix. Usually, when we encounter a crash related to this, it is already too late to understand what went wrong. For example, imagine a crash that happens because a Client received a message that says “Alice is now running towards Eve” and the Client does not know who Eve is. To fix the issue we need to find out why the Client does not remember Eve and when they forgot about her. At the point in time when the game crashed, this can be hard to find out.
The most reliable tool we have to solve such issues are log files. In a log file, we can record a history of changes that happened in the game. Whenever a character dies or a new character is born, an entry is added to the log file. If we have a log file for such a game session that crashed, then we can look into the history and find out at what time Eve was forgotten. Based on that it is usually possible to find out where things went wrong and fix the bug. We have made good progress at finding and solving many of these issues, but from time to time we still find some, so our work is not fully done yet.
We hope this DevDiary gives you a rough idea how the Multiplayers mode works. In the next DevDiary we will continue with the Multiplayer topic and explain another issue that is difficult to solve. Stay tuned for part 2 in March!
DevDiary #15 - "The wheels behind the veil" - January 2021
It has been a while since we posted our last developer diary. Sorry for that, we were really busy. This time we want to talk a bit about the topic ‘AI’, a topic we only briefly mentioned in our previous diaries. We want to elaborate on what we have done with the AI so far and what we are still planning to do in the upcoming months.
When hearing or talking about AI most people will probably think about our AI dynasties first. And while that is correct, it should be noted that we actually have several AI-controlled systems in the game. NPCs are AI units, but also the entire market restocking system as well as the transporter route calculation and order task generation are done by an AI that we are continuously working on.
But let us focus on our AI dynasties. They have seen a lot of changes in the past months. Most notably we changed the objective system that is controlling their actions and we added some additional systems to take care of all the other things that they should be doing.
One of the biggest and most visible issues is that AI dynasties die. They simply fail to marry or, if they marry, they do not produce offspring. For this we actually found several reasons, all contributing to this, some old and some newly introduced, and some of them very entertaining if you were watching closely.
For example, some characters would go out and romance… everyone. Those little Don Juans and Juanitas would just do romantic interactions with a partner, until they failed. With this their objective failed and they would move on to another objective, like “beg for money”, until they got the objective to find a partner again. Only, instead of resuming their existing romance, they would start a new one. Resulting in them having multiple romantic partners, but none on a level where they could successfully propose marriage.
To fix this, we had to tackle multiple issues. We had to fix the quest structure that handles giving tasks to AI characters, in itself. Now objectives are checked for basic requirements first, so if a character already has a partner, they will not seek a new romance, but resume the existing romance.
Additionally there is a check if a partner is still available for marriage. Romantic partners who are already married, are too old or have a very low score, will be removed as a possible partner, if a character is looking for marriage. This way it is ensured that no fruitless romance is pursued. At least not for too long.
We also added separate quests for pursuing romance/marriage and affairs and make sure that single characters prioritize looking for marriage, rather than pursuing an affair. While this sounds very obvious, it is less obvious on the technical side, as romantic actions are shared between romance and affair.
We also changed the quest structure for our AI to group actions that need to be followed in a certain order. For a human player it might be obvious that a romance needs to be started, then grown through compliments, kisses and sweet talk, until a marriage proposal is likely to be accepted. But our AI needed to learn that not all actions have to be executed in such a manner.
We also allow our AI to turn to other actions, if an action within such a group fails. Prior, our AI would follow all the steps until the very end, even if none of the follow-up steps had a chance of success. So if they failed to start a romance, they had no choice, but to try compliments, sweet talk, even marriage proposals, though they had no partner for it. This is just time and data that is wasted, so it was stopped.
Another issue that we changed is the skills and business buildings that an AI chooses. Originally, the AI chose their skills based on what they could afford and chance. And if a skill or new building was unlocked, again it was mostly chance for it to actually be built.
AI dynasties are now assigned an “Unlock Build” that makes sure skills and professions are unlocked in a way that allows an AI to build businesses that support each other based on their products and unlocked skills. Not one of each because they are the cheapest or the only they can afford.
In addition to that, but still in development, the AI has now a way of managing their budget. So they can save money for unlocks and businesses, equipment, normal expenses etc. This way, they will not spend all their money on the cheapest thing they can afford, but the next thing that makes sense.
What priorities are given and which Unlock Builds are selected depends partially on the Archetype that an AI has. Archetypes refer to a basic attitude (honest/shady, generous/egoistic, diplomatic/aggressive) and they can not be changed. Which means that an aggressive family will always try to choose an action that matches this and is more likely to be assigned an Unlock Build that supports this. They also have access to objectives, particularly created for these types.
As said, the AI is still undergoing a lot of changes and enhancements, so that in the end the AI is both challenging for you and supports the illusion of a living world.
All the best,
Purple Lamp Studios
Patch notes for hotfix EA 0.9.12.6 – December 18th, 2020
Hello everybody!
Unfortunately, with patch EA 0.9.12.5, a problem with the transporters of thief and robber crept in that could spoil your play fun over the Christmas days. As a "drive-by" fix we were able to fix another bug with transporters.
Saved games from version ES 0.9.12.5 should still be loadable and playable with this hotfix.
See you in 2021 :-)
Bug fixes
- Fixed a problem with the transporters of thieves and robbers - they should sell stolen goods on the market again
- Fixed a bug where all the supply caravans were waiting in front of the markets during nighttime