New Knights Province server

As shown in a previous blog post, KP development suite has a great automation tool – Runner / Stadium which can crunch simulations of hundreds of games with AI players in a matter of hours. Such automation is good not only for AI tweaks, but also for tracking down bugs and improving overall game performance and balance. These things go hand in hand – better AI can use more of game mechanics and features, which lead to more bugs being discovered and more sub-systems being used that affect the game’s performance, making it more representative of what actual players will experience. Larger target being – let the machine do the dirty work of discovering bugs instead of players.

My current PC is an i7 870 Lynnfield, with 4 cores dating back to 2010 or so. It is old, but still quite capable of running the game in Stadium in 8 threads and producing meaningful results in a sane amount of time (see previous blog post). To make a reference point, let’s take a 4p Crossing map – a 2 hour game takes 175 seconds to complete in one thread. Given that KP is a single-threaded application, it multithreads very well and it also takes full advantage of Hyper-Threading – we can have a total of 8 threads, it gives us 16 hours simulated in 175 seconds. In other words, my current PC working at full load is capable of simulating ~5.5 minutes per second.

Being able to simulate whole minutes in a mere second is an amazing result, but it means that I can barely use the PC during that as CPU load is 100% and there’s little to no processing power left for other things. For practical purposes, no more than 7 threads could be used, which is still some impressive 4.8 game minutes per 1 real second.

I need more though. Tweaking AI parameters means that I need to make informed decisions about preferring one setup over the other, where due to the random nature of the game, results are very “noisy” and meaningful statistical difference starts to show up only after hundreds of games results are averaged out. So I started to look into servers in April 2020 (right when the prices went up). Since KP can be simulated in headless mode, it needs just a lot of threads and a handful of RAM and no GPU. Perfect job for a server-like PC.

Since I needed a lot of cores and pretty much nothing else, the choice initially was between AMD Threadrippers and 5900X. Both were very pricey though (especially with reliable motherboards factored in) and they would have only 2 RAM channels. Having dozens of games being simulated at once surely means a lot of memory access. New 4-channel motherboards are very expensive. Another option was to go for refurbished Intels and 2-CPU motherboards. Among these choices there was another option – new Chinese motherboards. AliExpress offers both second-hand CPUs and new motherboards. For a fraction of the price, one can get an older server CPU and a new 2-CPU motherboard (based on the older X99 chipset though). 2 CPUs have another advantage that each one can access its own RAM via 2 channels.

Target configuration (met 100%) – Huananzhi X99 F8D motherboard ver 2.2, two Intel E5 2680V4, 4x4gb Samsung PC2400 DDR4, two Snowman 6-heatpipe 2 fans coolers, Chieftec 850W PSU, my old Nvidia N250GTS, Netac SSD.

While the order was en route, I started searching for a case and minor supplies. The case needed to be a big one, to accommodate the EATX motherboard and allow for good air circulation. New ones were quite pricey and I didn’t fancy the fact that they all look ugly with those perforated black fronts and tops. On the other hand, I could buy a second-hand case for 1/10th of the price and custom mod it to my needs.

The case I found was Thermaltake Armor VA8000 – tall and wide ATX tower with vertically placed PSU mount, lots of fans, whole front full of 5” slots, thick metal, broken covers and full of dust and gibberish from previous owners.

Cleaning up and throwing junk out took some time. In the process I threw out the whole front panel, because it was so clunky and cumbersome – servers don’t need fancy fronts! The PSU that went with the case had capacitors blown, so I decided to throw it away too, salvaging just a couple of parts, including the fan (you will see it later). All case’s fan cages and HDD rack also went into the dump – unnecessary dust-accumulators.

Motherboard arrived first in late December. Since it was from quite a new and untested brand, a thorough inspection was required. To my relief, everything looked fine except a stray uncut pin on the back and some minor corrosion on some of the copper pads all around (I hope it won’t compromise the soldering..). Following fellow reports I also have checked VRM radiators and discovered that one’s thermal pad was offset by as much as 1/4 leaving half of the VRMs uncovered. This was an easy fix to carefully re-align and re-adhere the pad. A couple of days later these pads were replaced altogether (more on that later).

Despite the computer case having a whole assortment of motherboard mount locations from various standards, I still had to map and add 4 missing ones for the motherboard I have.

Case front was covered with a plain piece of thin MDF – nothing to see there (will add power buttons and LEDs later on, and an intake fan if needed).

RAM and coolers came in early January – no surprises here. Had to swap one cooler’s fans around, so that they could all fit and form a straight air flow when placed on the motherboard. Unfortunately, due to large holding brackets and nearby RAM slots, they could not be set in parallel (facing up). 2 RAM slots were also blocked by the bracket levers. This is fixable (levers would need to be trimmed by just a few mm), but since I had only 4 RAM planks – that was okay. CPUs came a week later and finally I was able to begin the full assembly.

Hardware assembly went fine. According to the instructions, a couple more steps were required – putting in a CR2032 battery, resetting CMOS and toggling 8 dip switches to configure SATA usage (from what I read, motherboard revisions of 2.3 and up don’t need this last step – it is done programmatically there). Figuring out SATA setup was not easy though, I spent a good portion of the day on that due to faulty SATA cable (had to test it on my main PC to verify that). After replacing the cable everything went well.

OS installation went straightforward, Win7 is enough for such a server. Huananzhi LAN drivers refused to install with “FindFile failed” error, finding and manually choosing replacement Realtek drivers (from Lenovo?) worked well. Boot time, albeit said to be long, was not a big issue – I can wait 30 sec. Other than that, everything else went surprisingly well – all the cores were present, CPU frequency was good, RAM recognized, SSD working fast.

Seeing 56 threads fully loaded with crunching the game simulations is a satisfying sight:

Next immediate concern was temperatures. After all, these are two very hot square tiles under those heatsinks, each converting up to 120 watts of electrical energy into heat continuously under load. Providing those CPUs with the right voltage at such loads, VRMs are also big heat generators. Measuring CPU temperatures under load in the open case showed up to +55C and +61C respectively (the second CPU in the cooling line is a bit hotter). Closing the case caused the temperatures to quickly rise by ~7C before I decided not to continue the test and started to look into airflow optimizations. First and most obvious flaw was at the back – CPU air flow hit the backplate.

Straight air exit was needed. Since the case was a wide one, it easily accommodated a 12cm fan (taken from the old PSU mentioned above), I only had to cut out the metal and fasten the fan with the wire grill. Powering the fan directly from the PSU at 7 volts was a good compromise between airflow and noise. This had a great effect – CPUs temperatures went down -10C. Even in the closed case they don’t go higher than +55C and +60C now.

Second worrying issue was VRM radiator temperature, which climbed up to +63C on the radiator top in an open case. VRM chips’ temperature must have been at least 15C higher. Temperature reading in an idle state was not very much lower – +54C.

Looking for a replacement for the existing not-so-good aluminum radiators was not easy. I could not find a copper radiator with specified size (100 x 20 x 35 mm). Best I found was 100 x 75 x 24 mm. That radiator needed to be cut to size and mounting holes were to be added. Even with a good hacksaw and drills, this is a chore. Hence I decided to give it a go with the stock radiators, better and thinner thermal pads and add cooling tunnels around them (huge thanks to Dah for helping me with this idea and overall troubleshooting and good advice on other hardware issues). Thin plastic sheets were bent into U like shapes with 38mm sides and 110mm length. One small 4cm fan was securely attached on the intake end with small screws of each tunnel. Tunnels are firmly held in place with springback from CPU fans pushing on them from top. Fans are powered from the motherboard. Unfortunately, they don’t seem to be regulated in any way, but since they are so small and relatively slow-paced, they don’t add much to the noise.

This drastically improved the VRMs temperature under load. It went down from +63C to +42C.This is largely attributed to the poor radiators shape choice, which coped badly with convection cooling and worked well with throughout air flow.

With all this work – what’s the final result? As noted above, my old PC was capable of ~5min of game simulation per second. New server is capable of running 56 threads, each crunching a 2 hour game in ~100sec. That is 112 hours every 100sec ~67min of game simulation per second. Solid x13 improvement! Now that I write it, I’m shocked and amazed myself – how much more processing power I have at my command xD

Posted in Hardware, Tools | 1 Comment

How does one fix AI starvation?

Knights Province AI opponents in Skirmish have a known occasional issue of not producing enough food for their servants, resulting in citizen starvation and early collapse of their town economy due to that. Let’s look into what it takes to fix that issue!

What is it so bad about unit starvation in the game anyway? Well, a number of things:

  • First and foremost (all others stem from it) is that units dying of hunger is a planned penalty from the game for poor town management. Hence all the points below are more or less intended to be working together to implement that penalty.
  • Units die of starvation and need to be replaced by hiring new ones, which is free for serf/builders, but costs gold for skilled professions. In both cases, re-hiring takes additional time.
  • Units waste time by going to Tavern frequently and back instead of working
  • Hungry serfs may die while carrying wares, which not only wastes the ware, but also means that a new delivery will need to start from scratch.
  • Hungry builders may die while performing roadworks, effectively canceling them. New roadworks will need to be issued.
  • Hungry units create traffic jams on their way to and around the Taverns, further taxing the economy
  • This just looks bad

The first thing to do before we dive into tweaking and refactoring, is to define in simple and measurable terms “What is starvation and collapse of the economy? How can it be quantified?”. So that we could run a game for some period of time and conclude if the AI player starved or not and possibly measure to what extent. Not all measurements could be reliable though – for example, having little food in stock does not necessarily mean that it’s in shortage, since we can easily rationalize that in an efficient economy there are no ware surpluses – everything gets made to be used. More reliable metric might be counting unit deaths from starvation. This is not as straightforward too, since e.g. Builders can die of hunger while waiting for stone when building roads, no matter how much food there is – meaning that some number of deaths may occur due to other reasons (e.g. stone shortages). This also requires the game to run for at least an hour (so that at least half of the newly trained units get enough time to get hungry). Another metric – total Gross Domestic Product (GDP) (how many wares were made in the town during the game). When the town economy is down, GDP should be down as well. And finally (at least for now) is Army Power – how many warriors were trained. This is an indicator of a well-running economy too – since lacking in food production could seriously handicap military power as a result.

In the end, I chose to look at all of these metrics – (town GDP, ArmyPower, food reserve and starved units).

Next thing – we need to measure and display the metrics in a digestible form. For that there’s the good old Runner/Stadium tool – it runs batches of games in headless mode in many threads and collects and displays resulting data from them. Due to the nature of the game, resulting values have a large degree of random jitter in them. However, with large data sets, those irregularities get averaged out and we end up with more or less normally distributed sets of values. Box plot chart is a good starting point for representation of such measurement. It shows 5 percentile values, which I chose to be: 5, 25, 50, 75, 95. So that we can ignore the few random outliers and look at the bulk.

Unfortunately Delphi has no modern and easily-available charting library, so I had to either resort to a limiting text display or to process the data and export it into an external viewer. Highcharts.js is one of such external “viewers”, it looks nice, works “out-of-the-box” and I have successfully used it in the past. The main problem with it is that Highcharts is a JavaScript library. In prior uses I was creating JSFiddle templates and copy-pasted data into it by hand. Now I wanted to optimize that out. Since the stock Delphi WebBrowser component didn’t want to display Highcharts, and I had a prejudice towards Chrome, I decided to jump at the possibility and went ahead to embed the Chromium frame inside the Stadium. Now it was a matter of getting a boxplot template and stuffing it with data – a trivial task. The template gets filled and displayed in the Stadium’s UI automatically. This also allows for easy template swapping (to e.g. another kind of chart or other JS modules).

With the display sorted out – let’s get back to saving AI players from occasional starvation!

One more thing – you may ask, why don’t we just cheat it away? Like giving AI tons of food or disabling hunger for it altogether. Well, Knights Province is a kind of game with attention to detail already. It would not look good to have AI towns be “all smoke and mirrors”. Another concern is that cheating robs us of the chance to learn and to understand and fix the core issue. Layers of cheats also make the development problematic in the future, where they might become so entangled that we can not simply do anything else but try to blindly cheat more and more.

Our first stab will be at AI foreplanning. Perhaps AI starts to build the food economy too late? Let’s try increasing the value of grain production lag – a parameter that says how long it takes between building a farm and getting first grain from it. After all, grain is the main basis of the reliable food production in the game. The value was set suspiciously low (5min), whereas empirical measurements showed it to be closer to 15min. So let’s try running simulations with increased value and see if they show any meaningful difference.

(open image in new tab for 100% zoom)

This and following charts are screenshots from the Stadium (mentioned above) whose main focus was on measuring the effects of tweaks in batch runs. Due to that, they are more technical than art and aren’t very readable unless viewed at 100%. Simulations were run between 4 skirmish AIs on a skirmish map for 120min (albeit not as many times as in runs below, hence taller boxes). Displayed groups are – Houses built by AI, Total produced wares value (GDP), Army size in units, Enemy kills, Number of units starved to death. Sections are for grain lag values (AB_GrainLag).

We can see that mean values (averages) and boxes are more or less similar. They don’t show a trend we would expect (higher lag => less starvation) and the means are well within their own and neighbour boxes (25th-75th percentiles) – meaning that the values are quite varied and means themselves are not very reliable – hence we can conclude that the effect of the change is likely quite insignificant.

The second attempt was increasing the AI’s food demand calculation’s results. If citizens die because of too little food being available, certainly there’s a possibility of a flawed estimation of the amount of the food needed, resulting in too few food-production houses being planned and built and food being made. Running new tests with increased coefficients showed very good correlation and effect between increasing food demand and reduction in starvation to death. 

(open image in new tab for 100% zoom)

Simulations were run between 4 skirmish AIs on a skirmish map for 120 minutes. Displayed groups are – Houses built by AI, Total produced wares value (GDP), Army size in units, Registered enemy kills, Food reserve at the end of run, Number of units starved to death. Sections are for food demand multipliers (AB_FoodMul).

We can see that with additional food demand multiplication (by 1.3, 1.6, 1.9, 2.2) starvation goes down (food balance increases, starved count goes down). But going past 1.3 starts to affect the army count by a lot, while not giving much of a positive effect in starvation numbers.

It would be easy now to slap a 1.3 multiplier as a patch, but out of search for knowledge and experience, we might want to go deeper and figure out why the calculation was flawed in the first place.

Old calculation took units full condition (2400 seconds of life) and divided it by empirically measured units overeat (115%) with added 30% as a safety bonus on top of that. This formula was written a long time ago when everything was just simpler. It worked good enough for some time – the AI still built a town and trained an army.

In the code the calculation was “1 / (2400 / (1.15 + 0.3)) / 60” food per minute per citizen.

Now let’s rethink the rationale behind these food demand estimates and add some important details:

  1. A typical citizen has full condition at 2400 and goes to eat when he’s at 300
  2. Let’s say by the time he arrives at the Tavern he’s at 240
  3. This means, typical eating cycle is 2160 seconds
  4. According to the Tavern algorithm, a citizen will eat till he’s at least 90% full and at most – 89% + 60% – 150% (60% being the most nutritious food – sausage)
  5. That said, now we can assume that typically a unit can eat 120% food servings each 2160 ticks (36min)
  6. This is not all, however. All units start with 60% condition and this means, they will want to eat earlier the first time.
  7. Throwing the above numbers into a table allows us to see that, for example, at the end of the first hour (24min+36min) a unit will need 2 full servings (240% food) instead of 1.66 servings (200% food). This is 20% higher (0,04 food per minute) than expected if we compare to e.g. the 10th hour (0.033 food per minute,  when the effect wears out).
  8. This effect wears out over time, but since a typical mission is just 1-2 hours, we do need to account for that initial food demand too.

And here’s a comparison between old and new food demand calculations and results:

  • resulting old value was 1 / (2400 / (1.15 + 0.3)) / 60 = 1 / 1655 / 60 = 0.036 (servings of food per minute per citizen)
  • resulting new value is 1 / (2160 / (1.2 * 1.25)) / 60 = 1 / 1440 / 60 = 0.042 (servings of food per minute per citizen)

This result goes in line with our tests above – new food demand should be at least 17% higher.

Now we can run simulations to see how this works and check if it needs any additional safety bonuses.

(open image in new tab for 100% zoom)

Simulations were run between 4 skirmish AIs on a skirmish map for 120 minutes. Displayed groups are – Houses built by AI, Total produced wares value (GDP), Army size in units, Registered enemy kills, Food reserve at the end of run, Number of units starved to death. Sections are for food demand multipliers (AB_FoodMul).

As we can see, starvation went down by a lot with new food demand calculation. For comparison we also have something close to our old value (0,036 / 0,042 ~= 0.8) – it reliably brings the starvation up again. We can also see how adding additional bonuses past 0.2 will not improve anything, but quite the opposite – reduce the army output and just boost already slightly excessive food reserves. With that result it looks like we can add a small 0.1 bonus for good measure and call it a day.

This was just one of the many small and big AI issues. With improved tools and discipline, now it is more clear on how to approach and solve them.

Bonus, while writing the article I have sped up the simulation by about 40% and have changed the display to error bars that show 95% confidence intervals (since results are quite normally-distributed).

(open image in new tab for 100% zoom)
(open image in new tab for 100% zoom)

These charts show the result of 1400 and 470 runs between 4 skirmish AIs on a couple of skirmish maps for 120 minutes. Displayed groups are – Houses built by AI, Total produced wares value (GDP), produced warfare value, Army size in units, Enemy kills, Stone reserve, Food reserve, Number of units starved to death and Run times. Sections are for serfs per 10 houses (5 – 11). I’ll let you draw conclusions from that chart yourself 🙂

Posted in How things work, Live progress, Tools | 3 Comments

Serf army gets more equipment

Had an inspiration for 3D modelling. Only a few ware models are missing now

Posted in Artwork, Screenshots, Sidenotes, Tools | 1 Comment

Starting Alpha 12 wip cycle

It’s been a long time since Alpha 11, but at last, Alpha 12 is entering its public Wip cycle! Starting from today, you can find a link to fresh Alpha 12 wip build on Discord.

Long story short – lots of coding, game design, artists interactions and debugging went into Alpha 12 over the past year. There are several new big changes and improvements in the game:

  • Sheep farms, Sheep, Pastures, Wool, Gambesons!
  • Reworking object picking (aka hitboxes) UI/UX
  • Reworking HUD UI/UX
  • Waterfalls and multiple water levels
  • New text localizations – French, German, Spanish, Polish and Turkish
  • And as always – a lot of smaller features and improvements

Here’s a video highlighting main features by Wychor on the official Knights Province channel – make sure to subscribe!

Now let’s look into these features more closely.

As always, a word of caution – anything described below is not final and can change during or after Alpha 12 release.

Sheep, sheep farms, pastures, wool and gambesons

One of the things that bugged me from the early days of this project, was that Leather Armor, albeit looking cool in all those modern movies and TV series, was not actually period correct. It is Gambesons that were mainly used. Now with Fences that were added as a prototype in Alpha 11 we can finally do that – add Sheep, Wool and Gambesons. Each piece deserves a separate paragraph to introduce and to explain:

  • New kind house is added – a Sheep farm (this is one funny name that may stay or go). There works a Breeder who tends to the Sheep. Sheep farm has a new unique thing about it – it has a backdoor, through which a Breeder can access the pasture.
  • A Sheep farm needs to have a pasture next to it. Pasture is an area on terrain next to the Sheep farm, enclosed by natural obstacles or other buildings and fences. Pastures can be shared between several Sheep farms, but as playtesting showed, they work out best when they have size restrictions of 4 – 80 tiles.
  • When the Sheep farm is complete and has a breeder inside and enclosed pasture next to it – then Breeder can bring out baby sheep! They will graze in the pasture slowly growing up and growing wool on them. The rate depends on the pasture terrain – unfieldable terrain tiles provide 0 nutrition, fieldable tiles are x0.5 nutrition and grassy terrain tiles are x1. However, the main source of sheep nutrition is grain that Breeder gives them.
  • Once sheep are mature and wooly enough, a Breeder will come inside the pasture to trim them for Wool. Raw wool gets processed right in the Sheep farm by the Breeder and gets turned into hanks of wool (called Wool in the game, for short). It’s a new ware in the game. Wool is produced two at a time.
  • Now serfs can take Wool from Sheep farms and bring it to a new house – Clothmakers, where a Tailor (new profession) will take the Wool and turn it into Gambesons.
  • Gambesons are now used instead of leather armor to equip tier 2 warriors in the Fort.

With that in mind, the old leather production chain (CowFarm -> Cowhides -> Tannery -> ArmoryWorkshop -> LeatherArmor) is no longer in use. Cowhides, Leather and Leather Armor and Tannery become obsolete and are removed from the game. The sheep concept is a testbed for all other animal breeding concepts. So changes to the meat production line and stables are also on the roadmap.

Better object picking

With fences having a bigger role now, it was time to rework object picking – a way game detects what object should get selected when a mouse click occurs. Now you will be able to select more of in-game objects – fences, trees, ore decals. Selection precision was also improved – now the objects are being selected by their shape, not by the footprint on the terrain. Here’s a developers view on the object shapes:

Updated objects HUD

There is also a new HUD for selected objects. It has more focus on the object’s avatar and is intended to be closer to the final looks it will get in the future. It is still in the prototype stage.

Sidenote: Apparently, finding a good UX/UI artist is really hard. I have been searching for several months now with mixed success.

Waterfalls and support for multiple water levels were added

Now there can be up to 4 different water levels (each with its own waterbody setup). Water shader was also slightly improved. Setting up waterfalls is a chore, but I’m hoping to improve and streamline that process based on your feedback.

This change also caused the rework of the way waterbeds and shorelines are set up – now it’s dynamic and depends on the actual tiles that are covered with the water. So there’s no more “underwater” surfaces. Any surface can be a waterbed now – even hot lava xD.

Among other noticeable improvements

In-game changelog – now you can see what is new and what has changed since previous builds.

Improvements in AI city planning – e.g. now AI will try to restore road/building plans if the worker building them dies

New music track (Bells) by Juan I. Goncebat

New maps by Wychor (Lake Plateau, Erlond, Nile)

New animals for new waterbodies

New terrain surfaces, including cave floor with 3 different stone densities (had to revive my Substance Designer skills)

Grain fields render performance improvements (from 9 fps to 46 fps!)

Further Alpha 12 plans

  • Playtesting and tweaking sheep/pastures/fences/AI interactions
  • Upgrading all the missions to the new non-leather/gambesons flow and non-singular waterbodies setup
  • Creating a sheep-oriented mission for the Introduction campaign
  • Fixing Alpha 12 bugs (https://github.com/Kromster80/knights_province/milestone/9)
  • Getting HUD wrapped up (continuing the redesign and/or adding missing bits)
  • Lots and lots of smaller fixes and improvements

Download links to new Alpha 12 wip builds will start to appear in the Discord #new_versions channel (along with changelogs). Give them a try! I’m looking forward to your feedback on Discord

There’s also a new channel for Knights Province videos – The videos on the channel will be about announcements, development updates, map highlights, and more. Right now the channel already has some playlists with mapmaking, development and gameplay videos made by other KP community members. Let us know if YOU are someone who makes KP videos and would like them featured in the official playlists.

Posted in News | 17 Comments

HUD redesign – work in progress

So I’ve been working on the Knights Province HUD redesign lately. It is a two-fold endeavor – design and programming. Here’s how it goes:

Some terminology first – typically, HUD is a short for the Heads-Up Display – GUI elements that pop up over the “world” view, showing some general information and/or the selected objects info. Here and below I will be specifically referring to the in-game object’s HUD that appears when an object gets selected (a house, a unit, a tree, etc).

So basically I’m quite content with the current blocky HUD. It was always planned to be a temp solution. Something that can be slapped together and work. Grey at first, recently it got nicer with colored background textures and subtle shadows, but still – it is a temporary solution. It serves its purpose of being a “sketch/prototype” very well. I’m glad to have it functional and would like to keep it that way. However changes are due.

What was the push for the change? Fences and sheep!

Looking at other games (specifically Age of Empires) I always liked the idea of being able to select every major object and trees to see its info. Now with fences it is doubly important to be able to select them and view their details (e.g. player ownership).

HUD design and coding is one part of the endeavor. Object picking in-game is another one. Suffice to say – it took some noticeable amount of time and effort, but now it seems object picking is working rather well and is future-proof (with improvements already queued).

Back to the HUD topic though. Being able to select more kinds of objects meant that the HUD needed to be updated to show the new objects in a pleasant way, or, even better – redesigned! Being so used to the existing design I would not be able to radically change it without taking a long break from the game development and coding, so I have had to hire a freelance artist to help. Just_bu stepped in. Below are just some of the sketches (ideas) she has made:

You may notice they have an odd style and gamma – this is intentional. On this stage we were generating UX/UI layout sketches. Seeing what needs to go together and what can be moved. Checking out the balance between form and size.

Unfortunately, Just_bu had to move on to a higher priority project some days ago. Now I’m posting the vacancy description once again, hoping to get a new pair of hands on the case. Important to say – Patreon donations helped to cover the costs. Big thank you, patrons!

After running some research and seeing different UI ideas, I saw that Knights Province UI tended to gravitate towards certain structural layouts. Being reasonably sure about that, now I’m starting to update the game engine too. Refactoring old “rigid” forms into more flexible “modular” design. Here are some modules I have isolated as example in the old UI:

And after some extensive research I was able to create the following table, that covers most of the in-game entities and the HUDs they need (a fragment):

It contains the entities (rows) and modules they need (columns). Pretty straight-forward. With just minor complications arising from allied/enemy states and cross-module dependencies. No road-blocks though – just a lot to code and refactor! xD

One of the bigger and nicer HUD elements I wanted to cover in more detail is an object’s avatar. It is going to be a central piece of the new HUD. I’ve chosen to reuse the in-game 3D model for it (instead of hand-drawn graphics), to speed up and ease up the development. The model gets rendered into its own texture and post-processed with a nice glow effect.

Avatar being rendered into its own texture with glow and antialiasing is somewhat performance costly, but I’m hoping to optimize that later on, when it becomes accepted (cos who knows, maybe new UX artists will bring in superior HUD ideas that do not involve avatars).

Here’s another wip example – Store HUD getting “modular” overhaul – wares module is now common between it and the Camp, Fort and Barracks (all houses with “a lot of wares” stored inside):

Objects HUD redesign is a “soft-ball” of sorts. If it goes well I plan to redesign other in-game GUI elements (minimap, build menu, etc.) later on (maybe in Alpha 13). Main menu redesign is lower priority (think Alpha 14 or later).

Once the big HUD overhaul/refactoring is stabilized I will be able to release new Alpha 12 wip build (with beta sheep and better fences and waterfalls and other nice features). So, armed with that, work goes on!

P.S. And as always, I’m happy to read your comments and discuss on Discord 🙂

Posted in Live progress | 15 Comments

Short 2020 overview

2020 is nearing its end. Thank you everyone for following the project!

What about code?

2020 in commits

What about gameplay?

2020 in highscores

Happy New 2021 Year! Let’s hope it will be a much better one! 🙂

Posted in News | 3 Comments

Alpha 11.3 update

Here’s a third minor update with a bunch of bugfixes and small improvements:

  • Fixed a crash when ordering to attack an already demolished house under FOW
  • Minor naming changes (lance > pike, pike > halberd, house > building)
  • Smooth scrolling for lists
  • Fixed a bug when a keypress would leak from reassignment of a hotkey into a players name editbox in Options menu
  • Fixed crash on loading a savegame with fences being built or attacked
  • Fixed small memory leak on hotkeys resave
  • Fixed harmless junk text getting written into settings on hotkeys resave
  • Fixed crash on reopening Highscores after GFX reinit

Knights Province Alpha 11.3 (installer)

Knights Province Alpha 11.3 (7z package)
Posted in Downloads | 16 Comments

Alpha 11.2 update

Here’s a second minor update with lots of bugfixes and small improvements:

  • Fixed stone stockpile placement after house get demolished
  • Fixed error on loading a savegame with a dead group assigned onto a quickselect (Ctrl+0..9)
  • Fixed a couple of minor memory leaks
  • Changed “erase” to “remove” in various MapEd menus
  • Don’t list the horses in the map maker when selecting the resource for wagons #283
  • Messages with buttons should allow for no glyphs #282
  • Fixed mines placement locations visible behind the FOW #270
  • Fixed a bug when Save/Load of the mission unlocks every profession in the school #267
  • Added script action UnitUnlock, like the HouseUnlock #279
  • Fixed a bug when Stonecutter was unable to mine the stone from map corners #281
  • Possibly fixed error on game start when GetDocumentsPath was returning extra slash on the end
  • Calls to Action.(House/Group/Unit)OwnerChange if the new owner is the same as old one will be logged and ignored
  • Fixed stockpiles “auto (collect)” behavior (it was reversed) #266
  • Fixed error in saving a mission from MapEd with default human hand preceded by empty hands
  • Lasso selection should expand a bit when made close to map edge #278
  • MapEd places units under rotated camp wrongly (when applying skirmish) #272
  • Fixed ability to queue the last (5th) unit in the School #280
  • Updated list of patrons in Credits
  • Allowed for grain on snowground25% terrain [#284]
  • Added some snowground25% terrain to Winter Stand to equal out the starting locations
  • Improved KT panel layout a bit
  • Fixed dust puffs locations offset after canceling a house plan (also responsible for crash if they were to be spawned outside of the map bounds)
  • Fixed crash on unchecking Skirmish setup options in MapEd
  • Adding faulty savegame into the crashreport in case a crash occurs
  • Fixed crash on scanning or loading a map with empty script file
  • Fixed CRC calculation being 1-off
  • Implemented undo history depth in MapEd (default 512) [#286]
  • Slightly improved GUI of Records\Global layout
  • Added points assigned for each place into highscores (will be filled once KT is updated)
  • Renamed “Rank” into “Place” in highscores
Knights Province Alpha 11.2 (installer)

Knights Province Alpha 11.2 (7z package)
Posted in Downloads, News | 6 Comments

New maps

Alpha 11.1 was released just recently, yet it already has 4 new maps for download (https://discord.gg/3fsaFAj) and a mapmaking tutorial by Wychor:

Posted in News, Video | 7 Comments

Alpha 11.1 update

Following initial release, here’s a minor update with several fixes and improvements:

  • Fixed bug with hotkeys assignment when Ctrl key was pressed and released before assigning a key with another Ctrl key
  • Ported the rest of FXAA 3.11 implementation (better AA)
  • Reordered render init and error messages
  • Wrapped log creation error into a human-readable message
  • Removed unnecessary settings resave on game init
  • Made hotkey UI buttons wider to fit Russian captions
  • Improved pathfinding efficiency by ~35%
  • Changed unit-house damage formula from “AverageDamage/2” to “AverageDamage/1.5*Morale” (Militia will hit weaker, Knights will hit stronger)
  • Reduced time it takes to make a savegame by ~30%
  • Fixed black shadows in Store house construction site
  • Tweaked and minorily improved some house models
Knights Province Alpha 11.1 (installer)

Knights Province Alpha 11.1 (7z package)
Posted in Downloads, News, Uncategorized | 4 Comments