Knights Tavern news

Knights Province Alpha 11 is going to be ready soon and it’s time to talk about one more unique feature that it is going to have: Knights Tavern!

[Tavern Scene, 1658, by David Teniers II]

Knights Tavern (KT for short) is a codename for the accounts server we have been developing since 2019. Accounts were one of the more often requested features in KaM Remake, but we never had expertise or bravery to actually implement it (well, for numerous reasons). Attempts were made for the KP, but they did not succeed until recently, when a lucky chance has arrived (in form of an article (https://habr.com/ru/post/491272/) and a code repository (https://github.com/Cooler2/ApusEngineExamples)). Now, knowing that the backend server can be developed in the same language as the game, KT is finally taking its chance to come true.

Neat thing about KT, is that it can be used for both KaM Remake and Knights Province. Both games are very much alike in terms of accounts info they provide and can benefit from. So we can safely build KT in such a way that it allows for a single account for both Knights Province and KaM Remake. Register once and play twice. KP is our testground for the KT. Once it is sufficiently tested, KaM Remake can be upgraded and start using it too.

You can help with KT playtesting right now, but more on that later.

Basic auth functionality is mostly covered: KT has player accounts that can be registered, activated, logged in to and logged out of, forgotten passwords can be reset.

For a proof of concept, KT can report how many player accounts it has and how many players were active within the last hour.

The first useful feature in KT are mission highscores. If a single-player mission was prepared by the mapmaker in a specific way (2 lines of script, one dynamic and one static), the game can submit the mission’s winning score to KT and later on show the player his ranking in that mission.

Highscores for the mission

Word of caution, KT is still in beta and might have bugs in all different areas. We hope to iron them out over time. That’s why we start testing with simple functionality, so flaws in the authentication (which there must be) can be fixed. So, since there might be bugs and weak spots, do not use your everyday life passwords for KT.

KT future allows for many interesting things:

  • Friends, instant messaging, lobby invites, clans, etc
  • Player ratings and reputation, ELO scoring, etc.

KT poses new challenges to us:

  • It needs to be coded in an asynchronous way, so that data requests do not slow down or freeze the game.
  • Player data needs to be passed and stored securely (we already use salts and hashes)
  • We will need to preserve the players data on upgrades and between game versions

Best of all – you can already try out KT and help us improve it! See the latest KP wip builds (available on Discord https://discord.gg/cEwJFSY). Please report any bugs or flaws. We are also open for suggestions on KT functionality. It can steer it into many directions and it would be best to pick ones that are more wanted.

Posted in News | Leave a comment

Knights Province has got an updated logo

Preparing to Alpha 11 release, the game has got an updated logo

Posted in Artwork, News | 1 Comment

How to access developers menu in the game

Pressing F11 once will show the menu on top and the status bar below.

Pressing F11 second time will open a right-side panel with more developers controls.

Pressing F11 again will hide the menus.

For gameplay convenience cheatcodes work only with the F11 menus visible.

Posted in Sidenotes | 1 Comment

Let’s have some fences!

Fences have been long on the game’s todo list. Being a really neat feature described by a single word, it comes with a lot of problems to solve. How does one approaches a feature like that?

First the “wants” had to be outlined. Fences might have a number of variants and uses in the game:

  • Short crossable fences can be used to designate grain fields and orchards. Purely aesthetic
  • Medium breakable fences. Can be a weak fortification, slowing down enemy advance. Maybe they can also be used to keep the cattle
  • Tall tough fences can be a better fortification. More expensive and harder to break
  • If we think about it, fences around house building sites are somewhat related too

Next comes the problems and features exploration phase. Here’s a short FAQ I did on fences before starting the work. Each line poses a problem and has a solution below. The FAQ is not final and solutions can be changed to accomodate for unforeseen problems, but for now I’m quite happy to have most of the questions answered:

  • How are fence plans placed
    • New plan type. Placed between tiles. One side must be walkable/reachable. Cursor magnets to nearest edge and outlines it.
  • How fences get built
    • By builder. He arrives on adjacent tile, digs for a while, waits for timber and hammers the fence in place
  • What do fences cost 
    • At least one wood or stone
  • On which side of the fence should the builder remain?
    • Let the fence plan direct from which side it gets built
  • Do builders walk through fences?
    • Maybe they don’t. Let the player manage the sides from which to build.
    • We could allow Builders to walk through fences. But this would break all the immersion and logic. Unless we show Builder hits a fence several times to remove it, walks though and then builds it back again? Builders do walk through small house plan fences though..
  • How fences get demolished?
    • Instantly in a puff of dust
  • How fences get destroyed?
    • Adding hp would be complicated. Let it be just a chance-based instant destruction. 
    • Maybe we can have a breaking animation and fence remainders on the ground?
  • How tough are the fences?
    • We can “roll dice” each hit. Chance of destruction can be linked with warriors attack.
  • How do we discourage extensive fortifications, are they a problem?
    • Likely not. The cost is quite high after all.
  • Whose property fences are?
    • Fences belong to a player (so warriors know whose fences to break and whose to walk around)
  • How do fences interact with houses?
    • Fences should be allowed to make perpendicular contact with houses
    • Fences could be allowed to go alongside house border later on, but likely it ’s not needed
  • How to build fenced area for cattle?
    • To become cattle yard it needs to be enclosed
    • Area can be built by builders
  • What is a yard?
    • Any enclosed area of size 4+ touching the house (e.g. side). Max size is .. ?
  • How do animals appear inside the yard
    • Breeder can bring them from the house
  • How do animals disappear from the yard
    • Breeder takes them out
  • How does Breeder carry the animal?
    • Animal goes by itself on a whistle?
    • Animal gets “follow” order?
    • Animal is taken into hands? (as in KaM) 
  • What if fence gets broken?
    • Yard becomes ordinary terrain
    • Animals can walk away
  • What if fence gets restored (or is built around existing animals)
    • Area becomes yard again
    • Breeder can access animals in the yard
  • What if player builds several yards
    • If they are accessible by Breeder – he can use them
  • What if there are odd units/animals in the yard
    • They remain there, if they can not escape
  • How do animals breed?
    • Breeder brings them in
  • What do animals eat
    • Grass and grain brought by Breeder
  • How do animals grow?
    • Cows/Horses grow +1 for each grain eaten
    • Sheep remain at the same size and just grow more wool
  • Do we always need fences 
    • No, if the area is naturally enclosed it should be fine too

This FAQ covered the player-side of things. Having that done the coding could begin. The code was written in a separate SVN branch to allow for easier comparison of before/after and overall changes made.

There was a number of cross-dependent problems in implementing of the fences. Here are some of the solved ones:

  • Fence edges block diagonal unit passability across a vertice between tiles (just like trees and such). However a fence has 2 endpoints, so code had to be updated to let 1 object block 2 vertices.
  • Fences go along tile edges and thus block unit passability. All the passability/pathfinding methods had to be updated to check the edges between tiles for passability
  • Unlike roads and fields, fences need to be built from specified side. Fence plan list had to account for that.
  • Enemy fences should be breakable, so the passability for warriors had to “ignore” the fences and still plan paths through them, knowing that warrior will break the fence on approach.
  • Breaking enemy fences should not interrupt current warriors order
  • Warriors should not break allied fences. Which means the terrain traversability now had to account for player alliances.
  • Breaking a fence should take some time (1-3 hits depending on warriors strength). Had to come up with a simpler formula for that
  • There needs to be support for different fences (visually and mechanically) at least for mapmakers. Thus the fences are planned to have properties and types.
  • Had added dynamic script commands to add or remove a fence.
  • Fences had to have player color markings on them. Since terrain render is already overly complex and overlay render caused some Z-fighting bugs, fences had to be made to render via a different approach that allowed for colors.
  • Refactorings had to be made along the way to adjoin similar methods encountered throughout the code.

Remaining problems and features:

  • Own fences need to be demolishable. There’s still no support for that yet. Not sure if this should be done with a confirmation or not.
  • It would be nice to have own and allied fence lines to be permeable without destruction. Should the gates be added, and if yes – that’s another bunch of problems to solve
  • It would be nice to have fence breaking animation
  • Cattle yards are a whole new can of worms. They will likely be implemented as a separate feature after the fences development is complete.

Fences are available since Alpha r8455. There’s already been some testing going on and a small bunch of bugs fixed.

Posted in Live progress | 7 Comments

Campaign improvements

Campaign menu is one of the menus that received the least attention during Alpha development so far. Why is that? Well, it’s not as important as the main game or map editor – it’s rarely used and serves a small role of allowing to click “Start mission” or choose to replay the previously beaten mission. It lagged so much behind now that it’s subpar even by Alpha standards. By requests from mapmakers it’s finally getting some dev time. Along with that campaigns are also getting some new features (campaign scripting, yay!)

What campaign menu should look like? The big idea is to have it in 3D as a sort of map laid on the table, with heights and 3D banners.

However this is far from priority, since it’s better to have a more developed game, rather than campaign menu, right? So for now, campaigns are getting most of their planned mechanics, but still retain its simpler (and easier to develop) menu.

Following features and customization abilities have been added already:

  • Chapters. Each chapter has its own background graphic and subset of missions.
  • Customizable mission flags. Each flag has 3 states that can have custom graphics – locked/normal/won. For example now you can denote fighting only missions with crossed swords and normal missions with city icon.
  • Nodes between flags

All these custom graphics can be png files in the campaign folder. If not supplied – the game will use default stand-in images.

New campaign format is mostly self-explanatory (just open the info.xml in a text editor). Images and texts are now referenced from within the campaign spec (info.xml) – less hardcode rules, more customization.

For the technical side – campaigns got scripting support! It’s made of two parts:

  • Persistent data storage between missions. Now mapmakers can record data from one mission and use it in the other. Did you help that rebels town in mission 2 – now rebels can send reinforcements in mission 4!
  • Campaign scripting. Mapmakers get control over which missions get unlocked and when. Did you choose to side-track to the mountains to help the miners or to chase the bandits and let the miners take the usurpers side?

There’s also another neat addition – Campaign Builder – a tool to create and edit campaigns for the game. From now on it will be included in the pack. The tool is rather basic in its look and function, as it’s not the main dev focus. Still it’s handy to set up the template for the campaign and especially the flags/nodes placement.

Give it a try!

  • If you are a player – check it out and report bugs/feature requests
  • If you are a mapmaker – start creating your campaign! (and report bugs/feature requests too)
Posted in News | 2 Comments

Cinematic controls at play

Playthrough of a Town Tutorial mission with new cinematics effects:

Video and Tutorial mission are both made by Thimo – thanks to him!

Posted in Video | 4 Comments

Cinematic controls

Cinematic controls are being added to the Knights Province.

These are commands that allow to block the player input, do the fade out to black, move the camera and change its setup, fade in from black at new location and pan/zoom around, while showing text and subtitles. They will become accessible from dynamic script. Of course this is all mixable with existing dynamic script for playing WAVs and spawning units. This will allow for more atmospheric mission intros and story/campaign elements.

List of commands is as follows since r8155:

  • CinematicBegin
  • CinematicEnd
  • CinematicViewStore
  • CinematicViewRevert
  • CinematicBarsShow
  • CinematicBarsHide
  • CinematicFadeIn(aDurationSec: Single)
  • CinematicFadeOut(aDurationSec: Single)
  • CinematicViewReset
  • CinematicViewSetTo(aX, aY, aHeading, aZoom: Single)
  • CinematicViewMoveTo(aX, aY, aHeading, aZoom: Single; aDurationSec: Single)
  • CinematicViewSetToEx(aX, aY, aHeading, aPitch, aDist, aFOV: Single)
  • CinematicViewMoveToEx(aX, aY, aHeading, aPitch, aDist, aFOV: Single; aDurationSec: Single)
  • CinematicText(aText: string; aScale: Byte)
  • CinematicSubtitle(aText: string)

All the names are pretty self-explanatory.

Firstly you need to enable the Cinematic mode with CinematicBegin, then it will be a good idea to store the current players view with CinematicViewStore and show the movie bars with CinematicBarsShow. Then the cinematic can play out, finally being ended with CinematicEnd.

Example script for the mission intro cinematic will look much alike:

So far cinematics are enabled only for Single-Player.

Feedback and suggestions for new commands are welcome!


Posted in Live progress, News | 2 Comments

New things in recent Alpha 11 wip builds

Alpha 11 is still in works, but I wanted to share a couple of new interesting things about it.

Firstly, there is a new map made by Klassix that takes advantage of new game features and dynamic script commands. Namely the messages with buttons to allow to choose difficulty level.

Here’s description by the map author – Klassix:

In the map you have to defend an old Romans Fort for as long as you can. You have to develop a working economy while fighting off waves of enemies that randomly spawn from one of four directions. As you progress in time random leather-tier and later iron-tier-troops, start to join the offenders and attack from multiple directions. There are various resources spread across the map just waiting to be picked up by you, but watch out for wild animals and deserters.

This map features:

– Handcrafted terrain
– Two selectable difficulties on mission start,
– An ‘Incoming Attack’-Indicator which tells you from what direction the enemy attacks,
– An acoustic warning signal by your scouts as soon as hostile troops move into the map,
– Randomly generated attack directions and troop constellations every time you play,
– Tons of pickable resources that need your attention and
– a lot of care for details and balance.

Have fun holding your fort!

Bug reporting is very welcome.

Another neat addition are new music tracks by Juan – Dark Banners, Harvest. There’s also a third yet unnamed track, which is my current favorite and which I will add as soon as the name is chosen. I’m very happy with how the game gets more and more great music!

Alpha 11 wip builds (as always) can be found in the Discord channel.

Posted in Live progress, News, Sidenotes | 2 Comments

Knights Province got a Steam page

I’m really excited to have Knights Province Steam page registered! 

It took a while, but finally it’s there. So far only a page. There’s no known release date and no “Early Access” there yet (you know where it is ;-)). The game is listed as “coming soon” and it means ~2024-ish or so, given solo development tempo xD.

So .. add the Knights Province to your wishlist and keep on following the project in here, on Discord, Patreon and now on Steam!

Posted in News | 1 Comment

More player choice comes to missions in Alpha 11

A long ago requested feature from mapmakers and player is to have a choice in missions. It is coming to Knights Province Alpha 11. With this new feature missions can ask player in a convenient way to make some choice. No more “enable this house repair to get A and train a scout to get B”.

Let’s explore the details. This is how the typical script for the interactive messages going to look like:

procedure OnMissionStart;
begin
Actions.PlayerMessageWithButtons(-1, 'MessageWithButtons prompting player to choose an option', ['Option 1', 'Option 2'], [1,2], True);
end;

procedure OnScriptButtonClick(aPlayer: Integer; aTag: Integer);
begin
Actions.PlayerMessageOpen(-1, 'Player ' + IntToStr(aPlayer) + ' has chosen button #' + IntToStr(aTag) + ' how cool is that!');
end;

The script above has 2 main parts: message instantiation and click event handler. Instantiated message looks like so, with up to 8 buttons for now:


When a button gets clicked, the message closes itself and sends an event to the script.
In our example we just show another message with the event arguments, but mapmaker can write any other script (give wares, destroy houses, spam enemies, reveal fog of war, proclaim victory or defeat and much more):



And now to some technical details for mapmakers – click event has to be separate from the message instantiation (aka asynchronous) because of several reasons:

  • Dynamic script occurs within the main game update loop, which is separate from UI loop. This means that script can request a message to be shown, but the message can be shown (and processed) only after the game tick is done.
  • All player input has to go through recording mechanism (which is required for replays) and that mechanism basically works as <game update> <player input> <game update> <player input> … Since button clicks are player input, then need to go into the next tick.
  • Messages can be blocking (modal) or non-blocking. With non-blocking messages player can click the buttons at any time later in the game (or do not click any of them at all).
  • Since messages do not get deleted, player can click the same button over and over again. Emitting the click event again and again.
  • Last, but not least – given multiplayer architecture, player input needs to be sent to all other players and acknowledged before it can be executed. This can take up to several dozens of ticks

Finally, this is just a prototype. If all goes well, choice and interactivity can become much more sophisticated. Dialogs, other kinds of controls (text inputs, checkboxes, etc.), controls in the overlay area, etc.

Posted in How things work, Live progress, News | 8 Comments