Kingdom Come: Deliverance

Designer/Writer: Ondřej Bittner, Lead Designer: Viktor Bocan, 3D Animator: David Sarkisjan

Realizing Medieval Bohemia in Kingdom Come: Deliverance


Developer: Warhorse Studios Game Title: Kingdom Come: Deliverance Release: February 13, 2018




Warhorse Studios’ goal with Kingdom Come: Deliverance was to place the player specifically in the harsh, unforgiving world of Medieval Bohemia: a world where combat is realistic – fast and first-person. It’s a world where quests are open-ended and can either be solved with words or with the blade. How the player navigates the world and solves problems is up to them.


EFG spoke with Warhorse to discuss the role of motion capture and their animation process, the importance of open-ended quest design and how it creates satisfactory gameplay, and how they adapted realistic Medieval combat for a video game.



Hi, my name is Ondřej (yes that is an “r” with an accent, Czechs are weird) and I am a designer/writer in Warhorse Studios. I mainly focus on quest design and dialogue writing although I’ve tried many different things here in Warhorse, for example, voice over direction.


I guess at first glance it works the same way as in any other RPG, you talk to an NPC, receive a quest, and then you go and try to do your best. We have a quest journal, objective markers, and all that. But that is just the first glance, and I guess that is where all similarities end. I guess that our quests (even the small ones) are more non-linear and convoluted. And although the game will tell you what to do, it often won’t tell you how to do it. I guess that is the main difference between KC:D and other RPGs.


Tools and software

We started from scratch; you cannot start otherwise. We had to build our own tool called Skald to write branching dialogues, and over time we integrated other features. Now Skald keeps track of the locations, NPCs, and their loot. I guess you can say there is a lot of bookkeeping in an open-world game.

Building organic quests

Well, we tried to integrate as many mechanics into one quest as possible thus allowing to player to choose how he wants to solve the problem. So in this regard, we do not have “types” of quests because even if a quest looks like a combat quest, for example, there might be another solution using dialogue or stealth.


There are about eighty quests in the game. It might seem that it is easy to track them all but over time there is a lot of build up in residual chaos, I would say. Quests change name from internal “WIP” title to the nice in-game UI name; some are canceled, new ones are added, some are split, others are joined together. Technical professions generally dislike our designer names, so they label quests with numbers and characters to categorize them. So, in the end, every quest has like four internal names plus in-game names, and then you add all the localization. Well, it’s chaos, but it’s manageable over time.


KC:D takes place in real locations; the map is an actual piece of Bohemian landscape, the castles and other buildings are reconstructed to be historically accurate. Some characters in KC:D are real historical figures. This puts a lot of design resources in the game I can work with. When you put all of the world-building pieces together the topics, themes, and stories naturally emerge, so you don’t have to go looking for them.

The role of dialogue and lore

Major one. There is a lot of conversations in the game, and we tried to build our dialogue gameplay as robust as possible.


As I said, the game takes place in a real location, and there are real events that happened in 1403 that are integrated into the game. Basically, the whole main story is driven by some huge political shifts that happened in Bohemia in 1403, and there are a lot of sidequests whose story stems from the contemporary issues.


Determining the length and gratification of quests

We have main quests, side quests, events, and something we call activities (real simple repeating quests). General rule of thumb is that the main quests should be the longer than sidequests, but hey, rules are meant to be broken.


I personally loathe the instant gratification player gets in some of the AAA games. I feel that instead of enjoying the gameplay itself I get praised for every little thing I accomplish. I get it, everyone needs some sort of recognition, but sometimes it is simply too much. So I guess for me, rewarding is fun. I don’t need a gazillion of achievement trophies and praises from NPCs.


Every design has its low points and high points. Sometimes you have a grand vision which you are really thrilled for, and the result is far from your expectations, which is frustrating. And sometimes people love it, despite that it is totally different than what you wanted. And that is awesome.


My name is Viktor Bocan, and I’m lead designer of Kingdom Come. My main responsibility is systems design, polishing RPG mechanics, and combat.

Essential software and hardware

Software: our minds and experts’ knowledge. Hardware: swords and shields! No, really, we actually started with training to get a feel how those medieval combat techniques work. And we built upon this experience.


Creating the feeling of realistic combat

What we’ve tried to achieve was to recreate realistic melee combat in first person view. It’s our own system, developed with the help of people who have been studying Medieval European martial arts for decades. Our main aim was immersion: the player should feel the sword in hand, be scared of enemy attacks, experience the thrill of a battle. All that with a fighting style that is very similar to moves that were really used in middle ages on the European battlefield.


Kingdom Come is a “realistic” RPG in terms of no spells, no dragons, no magical artifact that will save the world once the hero finds it after two thousand years of being lost. So when you make a game like this, and you write a story that could really happen back then (and part of it actually really happened), you automatically think about the realistic approach in other supporting systems. Like horse riding, eating, and combat. So we approached swordmasters studying old martial techniques I’ve talked about and started to work on ideas on how to turn these techniques into a video game.

Determining correct combat techniques

There are actually two main aspects: it should be a combat technique really useful in a fight, and it should work from a first-person perspective. For this reason, we have slightly unorthodox (but still real) combat stances, and also we tried to avoid moves that were very effective but would happen almost completely off-screen. Another important part is that combat itself must be compatible with the game, support limited controls, and players should quickly understand what is actually happening on the screen and why this particular technique works.


As in the real world, the combat in Kingdom Come can end quite quickly. The most important part is to be ready, get appropriate equipment, and look around. If you are ambushed by bandits you have seconds to decide what to do. If you are careful and spot them first, your chances to survive are much higher. All this is supported by gameplay: you should avoid dangerous areas when you are weak, you should travel on roads, you should sleep in cities or at least in the pub during the night. Once the encounter begins, you should read your enemy, choose appropriate equipment, and be ready to run away when something goes wrong. Or train a lot, get better and kill them all, approaches may vary – why not thin their numbers with a bow first?

Any tuning the combat for video games?

To some extent, yes. The main problem we had to solve was that in a real fight you want to make the smallest moves possible. You want to conserve your energy, and also you need to hide your intentions from your enemy. In a game you want quite the opposite: if a player should block the strike, the strike must be obvious. So for this, we made all animation slightly bigger with larger swipes that a real professional would actually try to avoid. We compensated it a bit with speed: the strike begins slowly, and you as a player has a time window to react, but then the attack is fast and devastating, and animation can be nice and very realistic at the end.


Aside from realistic and first-person part, I’d pinpoint the technical background. We’ve developed a special physics engine with solvers that assure that swords actually physically collide. It means that when you strike someone, and he parries, he will really strike your sword and physically move it away. When you hit someone, the sword will slide along the armor or body, if you are standing near a wall and an enemy tries to hit you, he may actually clash to the wall, and it makes his attack much weaker, etc.


Balancing weapon and armor types

It’s actually how it really worked – every armor type and every weapon is good for something else. A good sword is the best versatile weapon, and you can kill unarmored opponents very quickly, but it does nothing to plate armor. We have made tests ourselves and tried to break armor with various weapons (don’t try this at home!), and proper plate armor really is almost impenetrable. So if you really want to beat someone in plates, you must bring a really heavy weapon like a mace and actually break his bones under the armor. And that is how it works in the game: every weapon has three attack numbers, and every armor has three defenses. What you want to do is bring proper equipment. Fight knights with heavy blunt weapons, use swift blades for quick dispatching of unprotected targets, and bring large weapons like polearms if you want to keep an enemy at a distance.


We actually have almost every type of weapon available back then, and we have thousands of animations for each of them. This doesn’t mean that you will use thousands of combat techniques – but there is a huge system in the background that supports the realistic feeling of the combat without sacrificing fun or simple controls.


Implementing RPG systems

RPG systems are a very important part of the combat. As the combat is real-time and first-person, it means that you need some skill to beat an enemy. This is supported by an RPG: it makes the game significantly easier if you level-up your character. I can demonstrate it on two systems: the actual speed of your (and your enemy’s) attacks is defined by skills of the combatants. If you train with a sword, the hero becomes a swordsman and enemy attacks are suddenly much slower because “he can see them more clearly.” It is easier to parry them, it is easier to avoid them, it is easier to strike first. The other aspect is that hero learns new techniques and skills. He can, for example, counterattack enemy strikes and this ability gets easier with higher RPG stats. So in the end, there are two skills in game: player’s ability to control the combat and fight and the hero’s RPG stats. These work well together. If you are a good action player, you can beat tough enemies just with your personal reflexes and ability to correctly press the buttons, move on the battlefield, and choose the correct technique in a right moment. You can support it by the stats of your hero: if you are not that fast or the enemy is too good, you can just level up, and the enemy will be slower, his moves more predictable, and your own techniques much more devastating.

Combat design challenges

Connecting it all together is still the biggest challenge of them all. We want the player to feel how a real combatant in a dangerous situation could feel. We want to make our hero fight for his life and let you experience the tension of it from first-person. Still, it should be fun to play.


There are many combat activities in Kingdom Come. You can train, you can participate in tournaments, you can just roam the wilderness hunting bandits (or killing traveling merchants if you are that evil). The combat is not a main part of the game as it wasn’t the main part of life in the middle ages. But if you happen to become a seasoned medieval warrior, you are free to grab your sword and go use it to your advantage. To allow this is the main goal of combat design – and also the biggest challenge.


Hi, my name is David Sarkisjan, and I am a 3D animator at Warhorse Studios. I am one of many folks in the studio who are obsessed with storytelling, gameplay, and everything in between. Our department has worked tirelessly on a variety of animations for Kingdom Come: Deliverance and its medieval world. Just like every animator in our team, my role has been to create gameplay and cutscene animations of the game.


Workflow and production pipeline

Our game world is a realistic depiction of medieval Bohemia. Therefore, we work in 3D authoring software to fully realize its characters and their emotions. To do so, we go through multiple phases, from motion capture using OptiTrack’s Prime cameras, clean up in Motive, and motion editing in Autodesk MotionBuilder. Before our team can do anything worthwhile a lot of characters have to be modeled and rigged in Max and Maya by our talented character art/tech team.


A lot of creative and technical work also means that multiple people have to take care of each phase until animations can be exported and integrated into CryEngine, which is KC:D’s game engine. Our technical lead, Jan Zamecnik, has supported our pipeline by maintaining a bunch of in-house tools we use to compile FBX data into engine supported formats. A lot of moving parts had to come together in order to successfully execute what you will finally experience in Kingdom Come: Deliverance in February 2018. Some of them had to be maintained in-house, some by third parties.

Translating motion capture data

Motion capture is a crucial part of our creation process. 99% of our humanoid characters are animated by optical data captured in-house and heavily edited later for in-game purposes. Even our horse has been motion captured.


However, you might spot some fully keyframed animation in the game. We initially prototyped by keyframing character animation but switched to motion capture due to the sheer volume of animations required to jazz up our open world environments.


When our department knows what to capture and how it will fit into the game’s systems, we simply visit our motion capture studio, which is about five steps away from the door of our office. There is usually a motion capture operator who wakes up early in order to calibrate motion capture cameras by covering big, empty space with sample data by swaying what looks like Poseidon’s trident. We call this empty space “The Volume” and it is all the space that multiple synchronized infrared cameras can see in conjunction with each other using their wide FOV lenses.


When the system gets calibrated and “sees” the Volume with its unified, high fps cameras, it is ready to observe people and usually also a bunch of props, like swords or shields. However, both people and props need to be characteristically marked or “markered” by asymmetric pattern of markers so the system can differentiate and capture anything remotely useful.


Markering, or what I call Christmas tree dressing of human figures, is usually done by animators. When one or multiple people dress up in rather tight Velcro suits, they have to be markered by 41 retroreflective spherical markers. These look like glowing golf balls and are placed onto various parts of the Velcro surface to reflect light back to all the cameras, which process them in real time and in sync with each other. You can imagine that when we perform “medieval theatre” it all seems like a playful, but technical act of a bunch of crazy animators.


Of course, it is not just animators in the Volume. When we get to shooting combat moves, stunts, and cinematics, we have a more specialized cast of actors who are by chance also incredibly curious about motion capture. They are often very amused by the whole process and take selfies of themselves in T-Pose while in space suits covered by odd white balls.

Making this all look natural requires a lot of organization, effort, and cooperation by everyone involved.

After markering and a short physical exercise with each actor that involves a series of T-Poses, and other, rather uncomfortable robotic poses, we shoot a bunch of animation takes of everything we need. We then use the exercises, or range of motions, of each live-action actor and translate marker motion to drive skeleton animation of 3D humanoids using both Optitrack’s Motive and MotionBuilder’s set of flexible solvers. The latter requires a good eye and technical know-how and is called retargeting.


However, each take of optical data (or cloud of markers resembling a human figure and swords) is usually a long 3D record of live-action motion inside the Volume and needs to be cleaned up selectively. We usually cut parts of data we don’t need and focus on the important clips (or frame ranges) of animation.

Motion capture post-production

When animators receive FBX scenes of character skeletons and props driven by trimmed and cleaned up takes of optical data, it needs to be edited to cooperate with the interactive environment of video game systems. Video game characters are driven by clips of animation (idle, walk, run, etc.), which are triggered by state machines of game engines. Each state (idling, walking, running) is created by an animator and requires common poses which seamlessly connect each animated action with a blend of two states. These actions are performed real-time by the player via input of a game controller or pre-defined by instructions of AI programmers. Making this all look natural requires a lot of organization, effort, and cooperation by everyone involved.


In order to create a library of animation clips with common poses (usually first key of idle animations or loops), we have to edit raw motion capture clips using what is called a control rig. A control rig is like a bunch of strings on a puppet which procedurally controls various limbs and body parts. The strings or “controllers” are used to pose characters and offset their original motion by placing keys onto animation layers at various points on a timeline.


It takes a few passes of motion editing to achieve visually appealing and technically viable animation clips, which works well within the set of constraints of state machines and the game engine. As it goes in the game development world, animation clips need to be exported and integrated into games sooner than later in order to test and iterate on their functionality.


Animation teams are led by experienced animators who are aware of the resources and time constraints of game development and direct their effort to work on a particular set of animations. Our combat system is driven by multiple sets of clips, and it is usually ones that the player uses and sees the most that are prioritized.

Attack priority

When comes to systematic priority during development, I believe our combat system was initially prototyped with one-on-one longsword encounters, and we worked off of already established rulesets for other combination of weapons. And since we use physical collisions to determine if a sword hits or misses the target, slash or stab animations took priority over parries, which were created based on sword trajectory of the former. This method ensured that the collision of swords during synchronized attack-parry animations occurred in the right place at the right time. When it does the game reacts, and our procedural solver calculates and influences the motion accordingly.


The testing process

There is a variety of processes that ensure that meshes are skinned properly, and character animations are behaving in an anatomically correct fashion. Character artists model characters in an ideal stance pose, every bone in a character’s hierarchy is oriented the right way; its mesh is skinned with a range of motion playing on loop to visualize extreme poses, etc.


When it comes to animations, it is a calibration of motion capture cameras (placement, stillness), technical supervision of each shoot (occlusion, number of actors, markerset) and retargeting of motion capture data (range of motion, marker-to-bone assignment, clean-up), which all play a role in the accuracy of animation compared to the real-world motions.


Degradation of data during capture, bad clean-up, and forceful motion editing are the usual pitfalls when it comes to believable motion. Bad shoot? Reshoot. Too much smoothing during cleanup? Tone it down with filtering. Raw animation data does not match your vision, timing, or common pose requirements? Don’t force it, reshoot and plan in advance. Of course, sometimes time is short, and you don’t get what you want. You have to make a call and own it.

Polishing the animations

As I mentioned before, it takes a lot of planning and motion edits to end up with solid animation clips. If they need to change too late in the process, there is a cost. Inevitably these changes are sometimes required to make the gameplay experience more responsive or visually believable. Animators would rather be more accurate during the initial shoot than to edit the motion forcefully.


Shooting proper animation data requires planning and solid knowledge of how state machines work and if the animation involves player input or it is driven exclusively by AI. What does the player expect? Is animation clear enough? Is it responsive enough? Is animation blending visually acceptable? Maybe the state machine involves too many transitions and blends. All these questions and findings come to play, and it is the developer’s iterative cycle that pushes everything to where it needs to be.

Advantages and disadvantages of motion capture

Our in-house motion capture studio has made our lives so much easier, and the delivery process is rather fast. Shooting and having raw animations ready in a few hours after the end of the shoot is incredibly helpful. Yes, the process requires a lot of pipeline planning and solid execution to work, but when it works and the data is solid, it keeps us developers and players happy.


There are disadvantages, but with a proper technical attitude and attention to precision, they can be avoided. Constraints of the technology are disappearing. Bad data is bad data only because the tool was not used properly at the time and during the occasion. Bad animations are bad because they were edited incorrectly and without care.

Animation challenges

I believe every animator on the team would give you a different answer. I found the entire process challenging because working on Kingdom Come has been my first professional game-making experience. Maintaining a big game animation library is one thing that comes to mind, but I bet more experienced animators found it manageable. Capturing and polishing four hours of cutscenes involving a lot of characters on screen has been challenging as well, especially due to a tough schedule and resources available.


The ride is almost over, but I (probably) won’t forget it. Delivering a game unlike any other is always challenging, but that is sort of the point, is it not?




We thank Ondřej Bittner, Viktor Bocan, and David Sarkisjan for talking about the development process on Kingdom Come: Deliverance.