Hello everyone, seasonal greetings from our hall to yours!

Before the year comes to a close, we wanted to share one last small glimpse of Chronicles: Medieval with you. Think of it as a little end-of-year snack from the team, something to enjoy before we all step away for the holidays and gear up for what's up next. This update takes a look at the underlying structure of our combat system and the iterative process that guided its development.

When development began on Chronicles: Medieval, it was clear that combat would require careful iteration to get right. It has to feel rewarding every single time, whether you are engaged in a duel or fighting in a larger battle with hundreds of enemies around you. It should not only feel fun. We aim for something plausible and flexible enough to support a wide range of encounters, rewarding to master, and built from the ground up to be moddable.

Of course, that is easier said than done. Game development is constantly in motion, and we’ve gone through countless experiments, some that worked, and others that looked great on paper but didn’t feel quite right when put into practice. We are still moving things around, so treat this as a peek behind the curtain. Everything is still subject to change. But we still wanted to shed some light on the foundations we’re building stuff on.

Medieval combat is often portrayed in exaggerated form in various media as elegant duels or endless sword-clanging. But in reality, as we stated in our previous FAQ, polearms ruled the medieval battlefield because their long reach, leverage, and diverse heads, like blades, hooks, spikes, and hammers, allowed troops to control space, stop cavalry charges, pierce or crush armor, and kill efficiently while keeping the enemy at a deadly distance. Knights carried swords as they had social, legal, and cultural meaning, but when facing heavily armoured opponents, the knightly pollaxe was a far more effective weapon. This perspective is rooted in HEMA, which draws directly from period sources rather than modern interpretation.

HEMA stands for Historical European Martial Arts, meaning combat based on historical sources, such as Medieval and Renaissance fencing manuals written between roughly the 14th and 15th centuries. Instead of relying on fantasy moves, HEMA uses authentic techniques taught by historical masters.

From the very beginning, Björn Rüther has been a constant part of our combat development. As our HEMA expert, he advises on historical fighting techniques, weapon behaviour, and battlefield use, and performs motion capture to bring those movements directly into the game. In the video below, he focuses on the pollaxe, explaining why it became such a valuable weapon from the 14th century onward and how it was used in combat. If you don’t know him already, you should totally check out his content! 

For our game, drawing from these HEMA sources means that the combat system and animations are inspired by these original manuscripts, aiming to give players a sense of how real European swordfighting may have looked and felt: effective, tactical, and grounded in history.

Source: Snapshots from the raw mocap recordings by Bjorn, side by side with old manuscripts

Designing a combat system that performs across all scenarios required a focus on adaptability. The same mechanics that drive a duel also need to function when hundreds of characters collide on a big battlefield. That’s why we emphasized clear combat signals, consistent timing, and strong feedback, so players stay aware of what’s happening, even when chaos erupts around them.

That also meant moving in a different direction from the directional fighting system you might know from other games in the genre. During our research and internal play sessions it turned out that clarity, control, and consequence are more important than the freedom the directional system provides. Every swing should be readable. Every hit should tell you why it landed, and every decision should carry weight.

What differs us from what you might already know is our implementation of the variables we call “Energy” and “Posture” (naming is still subject to change, everything is WIP). Energy governs your endurance, how long you can attack, block, or move before fatigue sets in, while posture reflects your balance and stability when being challenged by the enemy. Lose too much of it, and a strong hit can stagger or break your guard and set you up for a nasty finishing move. One that you might have seen in our Vision Video back in June. Together, they form the rhythm of every fight: a dance of risk and reward that rewards timing, control, and composure.

We want players to improve on two fronts: player skill and in-game character skill. Meaning that your personal timing, movement, and understanding of distance matter. But your character's perks unlocked on a skill tree also play a role. As you progress, you will unlock new weapon perks, advanced combos, and attacks designed for different purposes, some of which are more effective against armour or strong defenses. Fighting a levy or dueling against a seasoned knight with the same weapon will feel like two completely different experiences.

Check out those two examples of moves we recently captured with Bjorn for one-handed sword and its two veterancy levels (again, naming is subject to change). There’s a noticeable difference, not only in how many attacks you can chain together, but also in how fluent the character feels in handling the weapon.

Use the one-handed weapon a lot, and it will become an extension of your hand. You will be able to stagger enemies more easily with a chain of attacks. But in the beginning, you will have to work hard before winning your first tournament.

Every weapon category has its own progression path that increases the more you use it. While you progress in a path, you will earn small passive boosts, e.g., it could increase your damage a bit, in case of a melee weapon, or tighten your control over a bow.

But by leveling up your character overall, you will earn points to spend on perks in weapon category specialization trees, where the real variety begins. These perks unlock new techniques, from apprentice and journeyman moves to more advanced chains that expand a weapon’s rhythm and flow. They also include broader improvements that can make you more powerful or efficient overall, or give you better performance with higher-tier equipment. These help shape your character’s identity and give each weapon path its own flavor.

The medieval arsenal was vast, and we wanted each weapon type to have a reason to exist. Choosing what to bring to a tournament, siege, or a field battle should feel like real preparation, not just a cosmetic choice. A spear dominates in open ground, a mace comes into its own against heavy armour, and a longsword shines in versatility. Even during a siege, your weapon choices can depend on whether you’re assaulting or defending the walls.

Each weapon has its own role to play. No weapon is meant to dominate, and each has its advantages and drawbacks. This will encourage players to find the playstyle that best suits them.

We recently wrapped up work on some more weapon models that we didn’t show before. For all of you pixel hunters out there, here’s a small treat. How many new ones can you find?

The same principle applies to mounted combat. We merge the strength of the horse with the skill of the rider, turning every charge into a moment of tension and precision. Each lance behaves differently depending on its quality; some lower smoothly into a couching position, others feel heavier and more sluggish. Your character’s proficiency refines those values, improving how quickly the lance can be readied, how steady it remains, and how easily you can adjust aim mid-charge. Here are some of our experiments in timing around lance controls, which we are also researching with Björn.

But horses are characters of their own! Every horse has its own characteristics: top speed, turn rate, health, and even the power to trample your opponents. We are currently developing a complete locomotion set that will be responsive and blend naturally between states. Still ironing out the kinks, but we wanted to share an early look.

Our early prototypes relied on a historically inspired combat system built around complex combos and detailed stance transitions. And yes, we looked into the directional combat approach, too. It looked impressive, but as soon as multiple enemies entered the fight, the overall experience quickly became unwieldy and not well-suited for those scenarios. In late 2024, we evolved the approach toward greater clarity, readability, and consistency. Still grounded in historical influences, but more manageable and accessible in practice.

Since then, we have refined how weapons feel and behave, tightened posture and stamina mechanics, and expanded the same design principles to ranged and mounted combat. Each iteration has brought us closer to a system that’s deep enough to reward mastery, but intuitive enough to pick up and enjoy. The idea is to have a less steep learning curve without sacrificing depth. It’s a tough thing to do, that’s why it’s taking us so long to make it work.

What you bring into a fight matters just as much as how you fight. You can carry up to four pieces of equipment and swap between them freely during battle. This creates meaningful decisions before every engagement: whether to bring a spear for reach, a bow for ranged pressure, a sword for tight spaces, or a mace for armoured opponents. Your mastery progression naturally informs these choices, shaping the loadouts you rely on as your character develops.

We are hard at work on our inventory system, and below you will find a first look at one of the designs we’re cooking (did we mention that everything you see here is WIP? Well, so is this inventory design screen).

UI text shown is placeholder, and the helmet depicted is a great helm, not a bascinet.

We keep saying it, but we really mean it - we cannot wait to show you how it all works together on a big battlefield. Since these systems are still evolving, we’re pairing early looks with detailed write-ups to provide the right context. We were debating whether sharing the raw (no pun intended) motion capture recordings is not peeling the curtain too much, but we decided that you will be able to squint a little and see where we are going with this, even though it is far from finished for now. We are perfectly aware of that. Like that strap disconnecting from the saddle here on the horse locomotion video:

It is an easy skinning fix. But it is the Holiday season, so we have that bugged in Jira for early next year. Rather than waiting until everything is polished, we wanted to share this small update with you before the holidays. We would love to hear if you enjoy seeing more work-in-progress moments like this!.

That being said, have a wonderful Holiday break, and we will see you in 2026!

In this blog, we’ll take a closer look at how our dev team approaches building settlements in our game. That means anything from small villages to big cities that you, as a player, will get to explore. We’re building a large, immersive world in Chronicles Medieval. And a world like that needs more than open fields and forests. It needs places that draw you in.

The goal was simple - we set out to handcraft beautiful, historically sourced assets and build a system that could take care of their layout and distribution. We leaned heavily on Unreal Engine’s Procedural Content Generation (PCG for short, which allows us to scatter assets that are distributed by a set of variables) and used it to feed our own, proprietary tools.

We knew early on that hand-placing every building across each and every town wouldn’t just slow us down, it would limit us (and deplete our budget quite quickly, too). We’re building a world with scale, variety, and enough ground to get lost in. That meant we needed tools that could support that scope without losing the detail and character that make each location worth visiting.

The procedural generation of villages also can’t be random. It has to follow certain rules to make everything look and feel believable. We also take great pride in creating state-of-the-art environment assets, and we needed everything to be highly art-directable. Putting the art and design teams in control over how the final result looks like.

Over time, our tech artists and tools engineers built a toolkit that’s grown into a full set of internal tools called Skapa, Borg, and Ymir. In short, Skapa allows us to create varied asset compositions that rely on PCG graphs. Ymir is a modular, data-driven tool designed to generate landscapes and biomes procedurally. And Borg is what we use to build settlement layouts. In this post, we’d like to shed some light on how those work together and how you, as a player (and modder!), will benefit from those.

The development of Borg started years ago. From the very beginning, we knew it was going to be a challenge to populate our huge map with varied, interesting, and organically looking villages or towns. 

First, we started researching how medieval villages actually looked like. After studying historical maps and books on the topic, we identified layouts that kept repeating the most. Towns that were settled along a main street. Ones that were more circular, with a marketplace in the center of the settlement. Or ones that were more dispersed and irregular.

Source: Dorftypen nach Robert Mielke, Siedlungskunde des dt. Volkes, München 1927There’s plenty of historical data that we tried our best to base our generation on. And we wanted our tools to match this data as close as possible, while at the same time also being friendly from a game design point of view - i.e. most important places to visit, those that the player interacts with the most when playing the game (tavern, quartermaster, marketplace etc.), need to be fairly concentrated so that you don’t have to run around too much without any idea what’s where. But what’s really interesting is that this gameplay vision aligns with how medieval settlements were actually built. Historically, towns were built centralized around key institutions that formed the core of the communities day to day lives. That corresponds perfectly with our goals, and we’re able to create organic spaces without compromising core gameplay principles.

After some research and development in Side FX Houdini, our strike team of tech artists, designers and tools engineers ended up with a prototype that allowed them to quickly generate satisfying village layouts. It utilizes parameters like village size on the X and Y axis, plot number, plot density, road entry and exit points, and much more. It then places them using a mathematical diagram called Voronoi.

Additional features included multi-center options, border deletion, and wall addition for defenses. The tool aimed to provide user control over settlement creation without introducing complex setups. And one that we could adapt for our Unreal Engine pipeline once we started developing how settlements are generated in-game.

Below is a short video on how that prototype looked, and the examples of generation results we were able to achieve with it.

This was a great starting point from where we could move on to experimenting and testing ideas inside Unreal Engine. While it might have been easier to rely on the Houdini engine or roll out our tools in Side FX software, we want to embrace mod support. That means we want as much as possible of the game content to be authored inside Unreal Engine, without requiring any 3rd party tools, so that modders can build their creations freely and not care about any extra software licensing fees.

Using the same principles we established while working in Houdini, we built Borg inside UE5. To not overcomplicate things - Borg is a procedural settlement generator for Chronicles: Medieval, built to support creation of villages, towns, cities, tournament grounds, etc. It integrates environment assets composed in Skapa (we’ll get back to that one a bit later), such as buildings, and interacts with Ymir (our landscape generation tool) for terrain processing, such as foliage and hills. Borg places the environment asset compositions into zones using a Voronoi diagram that divides space into regions based on distance, so each region contains all the points closest to one specific center point (it’s math, ok? And for those who really want to go deeper, click HERE[en.wikipedia.org]). This diagram is composed of multiple Voronoi cells. Each of these cells is used as a settlement zone.

A lot of hard work and iteration went into the development of Borg. We had to find out how the systems are tied together and how to optimize them best for the creation of desirable results. Right now,  Borg is still in development, and we’re waiting for additional support for spawning rivers and other bodies of water.  But we are already in a position where we can replicate a lot of the desired layouts that we found during our historical research.

There is a lot of cool stuff happening inside Borg each time we define how we’d like a settlement to look like. The foundation of the system builds on parameters adapted from the original Houdini prototype. By adjusting how the Voronoi pattern is generated, we can shape both the size and distribution of the cells - giving us direct control over the overall structure of the settlement. We’re never letting the machine fully control the process. There’s a human touch behind each and every one of the towns we build.

Each settlement is composed of several zones, and each zone defines a unique configuration of buildings (represented as Skapa compositions). These configurations determine what types of structures appear and how they’re arranged within the settlement.

Placement is guided by a density setting and a placement algorithm, which together influence how many buildings are generated and where they appear. Depending on the setup, buildings can cluster near the center to form a radial layout, or line up along the main roads to create a more linear pattern.

To keep each settlement unique, seed values introduce a degree of controlled randomness - affecting everything from the Voronoi point distribution to how individual building variations are selected within each Skapa composition.

What’s really interesting is what’s happening inside each and every one of these Voronoi cells that Borg is populating with assets.

In Unreal Engine, PCG stands for Procedural Content Generation. Very important thing - it has nothing to do with generative AI. To quote Epic Games on it:
The Procedural Content Generation Framework (PCG) is a toolset for creating your own procedural content and tools inside Unreal Engine. PCG provides technical artists, designers, and programmers with the ability to build fast, iterative tools and content of any complexity, ranging from Asset utilities, such as buildings or biome generation, up to entire worlds.

Think of it as a way to quickly populate an open world map with a lot of trees in order to create a forest. In principle, when using PCG, first, you have to model the trees and then use a PCG graph to scatter them in the desired area, defining things such as the density and other variables.
We use the same principle when creating our Skapa Compositions - a set of combined assets that allow us to construct anything from simple, let’s say, fences, through village huts, and ending on entire plots of land that are populated with houses and other functional buildings.
Let’s break it down and see how we approach building a village house for example.
First, we create a modular building set. We think of all the components that might be needed to construct a variety of shapes of medieval houses. This is a pretty standard technique used to build architectural assets in game development. The modular kit would consist of walls, wall corners, roof elements, doors, window frames, etc. Anything that an artist might think of to fulfill their creative vision. It’s like building a set of modular toy bricks that they invented in Denmark a couple years back (They even had a cool medieval castle set!). And then, instead of making an instruction manual to build a specific construction, printing a document of all the possibilities that the blocks give you.

After the set is done, our artists use them to create different shaped houses. But, we do not only do it by hand. Using the Skapa Compositor, we can define rules on how to connect different pieces to create varied results. Then, by simply regenerating the seed, we can create virtually infinite variants of different looking houses.

After adding different attachments (which are also created using Skapa Compositions that have their own variants themselves), we can combine different Compositions together, adding even more variety to the look of the house. Additionally, introducing shader variety, like moss distribution on roofs driven by world position, allows for organic and distinctive results with very little effort.

We apply the same principle to every piece of procedurally generated content we make. Not only houses, but also all the marketplace stalls, functional buildings, fences, crop fields, etc. This allows us to populate the cities with great-looking, handcrafted assets, but composed in a way that has enough variety to look believable, both in detail and from the bird’s eye view. And it allows us to do it fast. Without the tedious work of placing things by hand. But with great control on the tools side of things, that empower artists to craft beautiful looking settlements.

What begins as a single model can quickly grow into a full village scene, with houses naturally lining the main street.

What’s great about this approach is that, since we’re building everything with modders in mind, you’ll be able to edit and replace every single asset within these compositions. So let’s say that you’d want to create a mod that would set the game world back a couple of hundred years to ancient Rome, you’d totally be able to do that by replacing the modular kit with appropriate looking assets. And leveraging the procedural workflow, you’ll be able to generate Roman villages in no time.

In the end, after we click “generate” (Sometimes when we play around with the tool, we can’t believe how cool and effortless it is to spawn an entire settlement with just one click.), we get something like in the video below. Here’s a first look at one of our many generated towns. This is the kind of settlement you as a player will step into when Chronicles: Medieval enters Early Access next year.

Every composition you see here was distributed dynamically. By dedicating a lot of artists' attention to handcrafting individual Skapa Comps and putting a lot of effort into making those look as good as possible, and then combining them through the Borg system, we empowered ourselves to work efficiently at a bigger scale. Everything is driven by a procedural workflow that we’ve been refining for quite some time. It helps us build varied and dynamic environments faster, but it’s still a complex process that takes a lot of care and iteration. The result: worlds that feel handcrafted, full of detail and character in every corner.

We’re still a long way from the place we’d like the tools to be when it comes to the speed of each generation, the complexity of it, and how it interacts with landscape elevation for example. But still, as you can see in the video above, the layouts already look pretty nice and the assets hold up, both in close-up, and when looking at them from a distance. And of course, we’re working super hard on making them look even better as we speak.

And yes, we can scatter anything around the towns. Even some ridiculous details like horse dung. It’s all about making it feel believable, right?!

Borg helps us generate diverse, grounded, and functional locations at scale. It gives us the flexibility to create believable layouts using handcrafted content, historical research, and rule-based placement.

Borg is one part of a much bigger effort to bring the world of Chronicles: Medieval to life. Combined with tools like Skapa and Ymir, and backed by a lot of hands-on design, it lets us build settlements that aren’t just technically functional, but feel like they belong in the world and are plausible enough to feel like a page from an old history book.

Have in mind that this is just the beginning. All the tools that are the backbone of Chronicles: Medieval are still in active development. We expect that each settlement that we spawn in the future will get much better over the course of the game’s development cycle. The huge upside of the entire toolset (and there’s more happening under the hood besides mentioned Borg, Skapa and Ymir) is that we retain absolute control at the low level of generation (Skapa compositions, seed values, layout templates, architectural styles), we delegate some control at the high level (settlement layouts) but we can quickly regenerate layouts until we are happy or set very specific outcomes by controlling the seed values exactly. Additionally, when our artists begin the polishing phase of the Skapa compositions, we can utilize nightly regeneration of all affected settlements to update every instance that uses said Skapa composition instead of doing it by hand. That way we have more time to spend on creative and fun aspects of the job instead of tedious tasks.

We hope that you enjoyed this look inside our proprietary toolset. Maybe there’s anything specific about the tools that you’d like to know more about? Or maybe you have an idea for a mod that would leverage the tools? Let us know!

Until next time!