2018 Christmas/NewYear mini-competition results

Mini-competition is over and I’m happy to announce the results!

We have 5 maps in the competition:

  • “Hodor” by Thibmo
  • “Longfingers Legacy” by Klassix
  • “Winter Stand” by Krom
  • “Xmas Tree Combat” by DarkianMaker
  • “Man Versus Man Versus Beast” by Eduardo Beltrame


Score 22.

Comments from judges:

  • Nice skirmish map
  • Nice map but approaches to camps are very wide for the size of the map

Longfingers Legacy

Score 22.5.

Comments from judges:

  • Very much like the details and usage of game assets
  • The maps looks OK, but please, less copy-pasta!
  • Would work well for a competitive map but could do with some more asymmetry. Could also do with a natural expansion of sorts for players to compete for

Winter Stand

Score 24.

Comments from judges:

  • The map looks great, nice addition for sure. Personally I would enjoy iron being available, though not all maps should have iron.
  • A lovely asynchronous map, but the river choke point is really too narrow for a proper fight against a defender

Xmas Tree Combat

Score 21.

Comments from judges:

  • Minimap and the whole idea look very nice to me. Simple and fun )
  • Very obvious X-mas reference. Haven’t seen a pure battle map yet, brings back KaM memories, bonus points for that. :smiley:

Man Versus Man Versus Beast

Score 21,67.

Comments from judges:

  • Unusual experimental map!
  • A very chaotic but interesting map, think it could’ve done with some more playtesting though
  • The amount of wolf dens…. wow. Interesting concept, too. But does need polishing.

Winners and prizes are:

  • 1st place with score 24  – Winter Stand by Krom
  • 2nd place with score 22,5 – Longfingers Legacy by Klassix (awarded Steam game of his choice (up to 15$ or equivalent))
  • 3rd place with score 22 – Hodor by Thibmo
  • All participants with maps scoring 20 or more – awarded with a small Steam game by Dah, called “You Can(Not) Survive”:


Posted in Events, News | Leave a comment

2018 Christmas/NewYear mapmakers mini-competition

Due to lack of time and small number of maps sent in, competition is prolonged till next week – 30 Dec!

Winter is coming along with Alpha 10 of the Knights Province! Let’s celebrate this with a competition! Task is simple – create an addon map for the game using built-in map editor (and optionally, dynamic scripts). Submit the map until December 23rd 30th. Await for results and get your prize soon after.

Participation rules:

  • New single-player map (can have support for upcoming skirmish/coop play)
  • Created in Alpha 10 wip (latest version available on Discord #new_versions)
  • Meet basic quality standards and be playable
  • Size M+ and any player count
  • Can be several maps per participant, but only one best one is competing for the prize
  • Jury members can participate, but are not eligible for 1st and 2nd place prizes
  • Best maps will be included into the game (for that you will need to write explicit permission, giving map away under CC BY SA)
  • Any map can be disqualified for undisclosed reasons by anonymous jury’s decision
  • Submit to kromster80@gmail.com or Discord #general_eng until midnight December 22nd 29th CET
  • Judging will be starting on December 23rd

Each map will be judged by the jury (DarkianMaker, Krom, Lewin, Maps, Thibmo). Map with the most points – wins. Points will be awarded in the following categories:

  • Visually pleasing design (up to 10 points)
  • Gameplay (up to 5 points)
  • Detalization (map objects, emitters, etc.) (up to 5 points)
  • Quest elements (dynamic script) (up to 5 points)
  • NewYear/Christmas references (up to 3 points)
  • Support for skirmish/coop play (up to 5 points)

Prizes are:

  • Scores 20 and above – small Steam game from community member Dah. Mention on the games website
  • 3rd place, small Steam game, mapmakers role on Discord channel
  • 2nd place, small Steam game, mapmakers role, Steam game of your choice (up to 15$ or equivalent)
  • 1st place, small Steam game, mapmakers role, Steam game of your choice (up to 25$ or equivalent), attribution in map description as mini-contest winner


Feel free to ask for clarifications, they will be answered here.

Posted in Events, News | 3 Comments

Food values

All Knights Province units need food to eat (well, except machines and animals). Otherwise they die of hunger. So dedicating a large portion of town to a food production is a good thing. But how much food is needed anyway? Let’s look into how much units eat:

Warriors can not leave their duty, so they get their food delivered by serf, which gets picked randomly in Camp/Store and tops warrior’s condition to 100%.

When citizen get hungry, they come to nearest Tavern that has free places inside (each Tavern can fit only 6 units at once). Typically when unit comes to Tavern he is at 13% full. When inside, unit will eat food in order it is listed in the Tavern until being 90% full.

I’ve been asked several times about food values for citizen, so here’s a small chart:

  • Fish – 0.5
  • Cider – 0.3
  • Bread – 0.4
  • Sausages – 0.6
  • Ale – 0.3

Please note, that above values are subject to change and should be considered correct only for current Alpha 9.1. In upcoming Alpha 10 values will be tweaked to:

  • Fish – 0.4
  • Cider – 0.2
  • Bread – 0.4
  • Sausages – 0.6
  • Ale – 0.3

So for example, in well stocked Tavern, unit will eat Fish+Cider+Bread and walk out, keeping Sausages and Ale intact.

Posted in How things work | 8 Comments

Alpha 10 nearing its release

Alpha 10 is going out of “work in progress” stage. Now its features are mostly done and last bugs are being ironed out.

Come by and take a stab at it in “Knights Province” Discord channel. Feedback is welcome!

Posted in News | Leave a comment

Site updates

Links page:
Updated Polish site forum link, as it moved to new hosting. Reorganized links order a bit, to bring more active hubs to the top.

Contributing page:
Added Patreon link to the top. Ungreyed some contributing activities.

Posted in Site | 5 Comments

Misty Mountains

There’s a new map being made for Alpha 10 of Knights Province. Called Misty Mountains. Giving word to map’s author Klassix:

“Mainly this map is for the future multiplayer, but of course AI handles it too, but surely it won’t use the flanking mechanics I tried to apply in the corners . You can be attacked in early game by 2 sides. Wolfs and Bruno the brown bear will take care of any fool trying to fast push you with 3 militia through the middle.

If we will be able one day to slow down unit movement with a special snow texture (or option) I will apply this on the middle to slow things down a bit. I did my best to balance things for all 3 players and suggestions are as always welcome.


You can check out the map in Alpha 10 wip available on Discord channel.

Posted in Live progress | 2 Comments

Copying animations between units

Last week started with a thought – “Copying skinning and animations from unit to unit should be trivial, right?”

Let’s see, but first – some intro:


All games need to store their assets (models, textures, sfx, etc.). For most games assets are prepared and stored in a way that their engine requires. With a custom engine, this goes a bit other way round – engine is created around common formats of asset formats that engine’s creators chose. Of course each game (and Knights Province is not an exception) might eventually distill required pieces and rearrange them in a way to speed up data loading and enrich with engine-specific features (i.e. KP has add-on info for house building steps or vertex weights for terrain tiles).

I’m mostly using Lightwave 3D format (LWO) for in-game models. I’m fairly experienced with it and when I need to create or tweak a model – Lightwave 3D is my tool of choice. Currently ~90% of models in the game are in LWO format (to be distilled later on, to improve loadig times and save space). Since all models were mostly static in early games life and I knew how to model staticobjects, I used LW to model placeholder houses and units.

However, game also needs animations, and that’s something I’m not really experienced nor skilled at. So after creating sample unit animation I went to hire freelancers to do better models and animations. Now I had to deal with their preferences, since asking someone to create both good models AND requiring them to convert it to format unknown to them is a tough/expensive thing. Fortunately, there’s a common ground – FBX is kind of a standard file format when it comes to models and animations for games. Most freelancers use it (also OBJ, but it’s less common).

So I was tasked with extracting models and animations from FBX. Since LW can open FBX files, I decided simply to use LW to convert FBX and call it a day. LW animation format is quite complex (and complicated). To extract animation data needed for the game, I wrote a special Python plugin to export animation frames into a text file in compact and straightforward form. Because of all that, existing process of animation import is rather lengthy:

  1. Obtain FBX animation from freelancer
  2. Convert FBX to LWO
  3. Tweak skeleton setup in LW
  4. Export static skeleton from LW to game format with a Python plugin
  5. Export animation same way

In actuality that’s a tedious 19-step process prone to mistakes. It works okay for 2-3 models, but it’s unbearable for anything larger.

So far game has just a bunch of animations. It would be nice to reuse some, e.g. walking unit animation is the same for all citizen (for warriors it’s a bit different, since they walk with regard to carried weapon).


It would be great to copy common animations from models who have them to the rest (e.g. idle and walk animations).

To make things right, I decided to write FBX animation importer. It’s not strictly necessary for the task, but once I’m at animations, it’s better to fix several adjoined areas. I already had code to read and parse FBX file format (few in-game houses are actually FBX, not LWO models). Expanding the code with reading of skeletal and animation info should not be that hard .. so I thought.

Last week was dedicated to that task. Things learned and reinforced:

  1. Anything that seems trivial could easily take 20 hours because of unforeseen details, auxiliary things and need to wrap it all into a neat “API”.
  2. Even with unforeseen details, if something seems doable (i.e. without involving words “automatically” or “somehow” in its description), it’s really doable, just needs more time.
  3. The way FBX and LWO stack transformation operations is different (and learning that alone cost me a day).
  4. Automation is great. Writing a small dedicated tool to convert, copy and launch preview instead of manually doing the same – saved my sanity.
  5. When something seems about right, but not quite – it’s almost as good as wrong.
  6. Animation bugs are fun:


Now with swordsman animations working, I intend to:

  1. Re-import  existing unit animations (and throw out LWO animation code)
  2. Write methods for copying skinning between models
  3. Tweak couple stray errors in skinning
  4. Have all units have common walk/idle animation in Alpha 10
Posted in Uncategorized | 2 Comments

Alpha 10 enters wip stage

Alpha 10 is entering “work in progress” stage, where it has its features mostly done. This stage usually runs for several months while I’m polishing features (and adding smaller new ones). Come by and take a stab at it in “Knights Province” Discord channel

Posted in Downloads, News | 8 Comments

Alpha 10 features

New features development on Alpha 10 is nearing its completion (more on that in articles end). Here I would like to list and explain features that went into it:

Particle effects
Smoke, dust, fire and mist effects were added to the game. That involved creation of new rendering engine section. Some details could be found in previous article. This includes:

  • Allowed and placed smoke for house work
  • Allowed and placed smoke for damaged houses (6 of 30)
  • Allowed and placed dust effects for plans placement
  • Allowed and placed dust effect for house destruction
  • Allowed emitters that could be placed on terrain in MapEd (e.g. mist and fog)

Covered in detail in previous article. This is a big rendering change and it includes:

  • New deferred rendering pipeline
  • SSAO itself
  • New custom antialiasing (FXAA2 and partially FXAA3)

Revised house-placement
Houses can not be placed around trees from all 4 sides now. This makes much more sense than before, where only lower-right tile below the tree was blocking house-placement. On the same topic, there are two ways of placing houses now, from game, where trees are blocking, and from script (static and dynamic) where trees get auto-magically removed (to keep scripting simpler). To keep town-building manageable, see the next change below

Allowed builders to uproot trees and small stones
Long awaited feature. There’s a new “Uproot” command in build menu. Now you can markup trees and small objects to be removed by builders.

Revised fishcatching
This is first iteration on improving fishcatching. Now every shore tile has certain fish count associated with it, that fisherman can catch (since it’s a shore property, it can not be cheated by building many Fishermans houses, although that would increase initial rate of catch). Fish will replenish slowly over time. Intention is to keep fish a good starting food source, but keep it limited, so you will have to invest into other food types when it’s ran out, but to keep Fishermans useful and whole process realistic – now they will keep catching small amounts of fish forever after.

Revised wind effects to act uniformly on flags, particles and map objects
This is purely visual feature. However it’s nice to have

Expanded undo/redo in MapEd (units, houses, etc.)
Better undo/redo is always a good thing! I’ve restructured undo/redo to handle various MapEd changes and will be able to include yet untrackable things more easily later on.

Unified main menu and gameplay options pages
Now you can change most of the same game setting during gameplay and MapEd as well. Except those, that require render reinit – resolution setting and localization (once it’s enabled)

Separate volume controls for sounds (alerts, effects, menu)
Separation and categories are not final yet, but the idea is there.

Sound for messages opened and closed
Found free sound and added it

Changed campaign UIDs to GUIDs (generated automatically)
This should simplify campaign creation a bit. You might need to update old campaigns if you want to see them in Alpha 10. Stock campaigns are updated by me.

Rigged coalmakers house to place/collect smoking heaps
This is half-baked feature until Coalmakers house model is made. For now – just a groundwork for upcoming feature.

A lot of other smaller features and bugfixes, among which:

  • “Replay has ended” should happen on mission end, not on last command given
  • House plan outline disappears when builder pick up tablet until he starts digging
  • Don’t let AI connect new houses to Towers/Campfires
  • MapEd showing error when trying to save SP map as campaign map (or vice versa) due to “slash” in path
  • Replay info would get lost on loading a savegame
  • Occasional “Integer overflow” error caused by (TKMMain.RequestRender > TKMFPSCounter.FrameEnd > TimeGetUsecSince > TimeGetUsec)
  • Game would rarely crash on trying to assign Train task to Blank who is walking out of a house

Non-game changes include:

Setting up Patreon
Finally set up a way of collecting donations for Knights Province development. More details on Patreon page and in one of previous articles.

Setting up itch.io page
One more place for Knights Province presence.

So .. Alpha 10 is mostly feature-complete. It still needs a lot of content placed (e.g. placing fire-damage smoke emitters for 2 dozen houses). Now it will undergo some weeks of Wip builds (uploaded on Discord channel) and then, with good luck, will roll out officially.

Posted in Live progress, News | 7 Comments

Working on render quality – Part 1 (SSAO)


Ever since the beginning of Knights Province project I wanted it to be visually pleasing. Slightly cartoonish style with bright colors, semi-realistic soft lighting and shading. Ambient Occlusion (AO) is one of those shading effects that add depth and sense of scale to whole scene, tying objects together and highlighting details.

SSAO composition

What is AO

So what is AO exactly and how does it relate to real world? AO is an effect of ambient light spreading between objects (hence the effects name) and also of some dirt accumulation naturally occuring in crevices. Counter to popular belief, AO is not 100% real-world based. Take a look at walls-ceiling corner – it has no dark gradient on it (even worse, some corners seem to gain brightness near the edge due to light reflecting from other side). Still, AO is a nice artistic effect that adds depth to the picture and gives objects more “weight”, making details to stand out more.

How AO is done

AO can be done in several different ways depending on the use-case. It could be raytraced and recalculated every frame (typical for offline rendering, what 3DSMax and Blender and other rendering apps usually do) when quality is the king. It offers superior quality at a cost of speed (typical scene can take 30+ seconds or minutes to calculate). Games can not afford this. For games, AO could be raytraced once and baked into lighting textures (so-called lightmaps). This offers greater speed. Downsides are – only static objects could be baked. Dynamic objects won’t have proper AO on them and on objects they interact with. Oftentimes older games combined lightmaps with fake shadow patches below actors feet/wheels/etc. That looked okay in 2000’s when computational resources were limited. Now, as the computational powers of GPUs have sufficiently increased, dynamic solutions for games could be made – SSAO, HBAO, HBAO+ and other variants. They don’t come that close to offline rendering solutions, but still offer good enough compromise between performance and looks, with some shortcuts taken.


Here’s a short list of options I’ve considered viable for the Knights Province:

  • Pre-baked lightmaps – look best on static objects, but don’t cope well with dynamic ones, needing lots of special-case “hacks” convoluting the render pipeline. They also require either separate UV map or unique UV mapping (which does not mix well with houses reusing textures and materials, cloned trees and terrain)
  • Dynamically baked lightmaps or vector maps – offer more general approach to the problem, but still require a lot of hassle and have noticeable flaws.
  • SSAO and its variants – is even more general solution. It works on top of any geometry and does not care about how it was combined. What you see is what gets AOed – It’s that simple.

Why did I pick SSAO

I’ve picked SSAO for its generality and simple SSAO implementation specifically for its widespread popularity, which must mean that it’s a good enough compromise between ease of implementation, performance and picture quality. There are many tutorials, common problems and solutions to them are well known too. Optimization techniques are plentiful as well.

How SSAO works in general

SSAO works by basically checking each pixels surroundings within a small sphere, to see if they block ambient light from reaching the surface. The more of those surrounding are covered by other objects, the more occluded the pixel is and the darker it will be. Ideally, each surfaces pixel checks whole multitude of directions and ranges to see how occluded it is from ambient space. In practice, this is very costly operation, so only handful of tests are made and their coarse results get averaged out.


Illustration below shows 2D version of SSAO where 3 surface points are checked with hemispheres oriented towards surface normal (reasonable optimization):

SSAO needs DR

In older times, when render was simpler, GPUs were rendering frames in one go and would calculate each pixels color by factoring everything at once. Now SSAO samples a lot of pixels over and over (even for coarse results, every pixel needs to test 16+ surrounding pixels to figure out its shading). Because of that, it makes sense to prerender required information and access it from some buffer. Providing for that is a complex rework of the rendering pipeline. Approach with rendering intermediate buffers is called Deferred Render (DR). Where’s before the game drew objects one by one in one go, now all objects need to be drawn into temporary buffers (typically that’s position, normal to surface, color) to later combine them into final picture. DR is already sort of in the game – shadowmaps, water reflections and fog of war are prepared in separate buffers and combined into final rendering.

DR plan

Render pipeline needed some planning in order to find correct place and sequence for each operation. Here’s how render pipeline is planned to be with DR and SSAO:

Current render structure of the game

SSAO optimizations

SSAO is very resource hungry algorithm – it needs to test dozens of pixels for every drawn pixel. Optimizations are vital. Most straightforward ones are – sampling only those points that are above tested surfaces (testing within hemi-sphere instead of whole sphere of directions). Then comes in randomizing of samples – it is done by rotating sampling hemisphere for each next pixel – thus output is more evenly distributed, but noisy. Blurring helps with reducing noise. SSAO has a number of controls, allowing to trade-off quality vs. performance – e.g. reducing number of test-samples used, reducing blur radius. At the moment I plan to add 3 SSAO setting – off, low and high quality.

DR and AA

Unfortunately DR does not mix well with traditional AA techniques, since DR relies on pixel perfect information in buffers, only straightforward AA could work (that is rendering frame X times larger and downscaling it), which is unfortunate for SSAO where each new pixel needs whole lot of sampling from neighbour area. Luckily there are known AA algorithms well suited for DR. FXAA is quite popular and easy to implement.

DR and transparency

DR has certain difficulty coping with semi-transparent surfaces (STS), since depth buffer can only contain a single value per pixel, it is either of surface behind the STS or the STS. Which means that either the surface behind or the STS one gets shaded wrongly. There are smart techniques to deal with that (e.g. using a checkerboard pattern and storing every 2nd pixel from other surface), but for the RTS that has quite few STSs (namely smoke particles and water surface) it is easier to deal with the issue by simply rendering STS on top of DR/AO geometry. STS generally don’t need AA too, since their transparency means they don’t create a lot of sharp pixels in the first place. Even better – STSs rendered on top of normal geometry cover some of it, thus reducing amount of sharp edges that AA will need to smooth out.

Recombining the render

Once AO is computed and applied, the render needs to return back to “normal” functioning to render STSs. This is done by writing RGB and depth values back into a buffer and rendering STSs using default depth test.

(Particle textures are replaced with checkerboards for debug)

In the following articles (which are already in works) I’ll cover FXAA and general render perspectives.

P.S. Thanks to Thimo for reviewing this article 🙂

Posted in How things work, Live progress | 7 Comments