Everything Is Connected: Warhorse Studios’ Quest System for Kingdom Come: Deliverance II

Every bigger game or at least every game that's similar to ours, open world RPG, you have all these dialogues that you can go into, and there's a huge complex quest logic that goes into it. And you have someone like technical designer or scripter, Multiple people usually on one quest that are making this happen, that they are doing and telling the NPCs what to do, how to behave, where to go, and so on. All this information is basically stored in this system that we have. We call this application Scald. And as as you mentioned, it's a standalone tool because we had so many users for it. It was not only technical designers and gameplay designers and people who actually wrote the dialogues, but it was also, like, sound designers and sound directors when you were recording voiceovers.

Welcome to In Development, the podcast about the real technical challenges and trade offs behind building complex games and digital worlds. I'm your host, Jayce Lingren. And today, I'm joined by Peter Nohel, a developer at Warhorse Studios to talk about Kingdom Come Deliverance two and what it actually takes to ship an open world RPG with hundreds of hours of content without it collapsing under its own complexity. We dig into Scout, Warhorse's in house tool for managing quests, branching dialogue, world logic, and why they kept it separate from the main game engine, and how they automated validation and testing to prevent a single broken connection from blocking progression for everyone on the team.

Peter also walks through how small teams build tools that scale to hundreds of contributors. And then we have a little bit of fun looking at how some memes from Kingdom Come Deliverance one ended up in the second one as an intentional design. If you care about narrative systems, internal tools, scaling complexity without losing control, there is a lot to learn here. So I'm really excited to get into this conversation with Peter.

So Peter, thank you so much for joining me today.

Yeah. Thanks for having me.

Awesome. So we're here to talk about Warhorse and Kingdom Come Deliverance two and some of what went on there. And so first, I kinda wanted to set the scene.

So first, have an interesting story is that I kind of came across the game by accident. I was not I did not play Kingdom Come Deliverance one, but recently my wife was playing Ghost of Yotei I was like, you know, I wanna play an open world kinda game too. What's what's out right now? What's going on?

And I saw Kingdom Come Deliverance two. I was getting good reviews. I was like, alright, I'll I'll check that out. And I got totally hooked on it.

Played it a ton, played it all the way through which is not something I normally do. I play a lot of games because I wanna see what's out there, I wanna see what people are doing, but I rarely play a game all the way to the end. But I did with Kingdom Come Deliverance two, even though it's super long because of how much depth and detail and nuance there was throughout that, which is really exciting to me whenever a game studio can do that. So can you tell me a little bit about the history that led up to this? One, like how long were you working on Kingdom Come Deliverance two? And then also, kinda what's the story of Kingdom Come Deliverance into the sequel?

Sure. So I basically joined the studio when we were transferring from Kingdom Come Deliverance one and two. Okay. I joined on the DLCs, basically, after the the release of the first game.

And so, basically, I worked on KCD two for, like, the whole development when it started. And the first game actually came out, it had, like, few tiny little issues and bugs here and there. So we were actually, like, fixing the game for quite some time. After the release, I think that, like, the the last patch which actually still included major changes in code was released like a year after the game was actually in the whole state and actually playable without, let's say, major bugs that would be Right.

And, yeah, about the game itself, we are super super happy that people are actually playing it from the beginning till the end, because definitely not the case for most games, you know. Some people just, like, buy it and have it inside their Steam library or wherever and they just say, okay, one day I maybe play it.

Yeah. I've got a lot of those. Yeah.

Yeah. But from the data we have, we actually see that people actually enjoy the game a lot and they're spending a lot of times inside it and it's not just only tens of hours, but maybe hundreds, some people even thousands of hours inside the game. Yeah. So that's pretty cool to see.

Yeah. That's great. And I think you hit on something interesting with talking about the first game coming out and how there were, you know, some issues with that. I feel like at this point that's become kind of as an audience what we expect from any kind of big open world game. It's almost like there's this expectation there's gonna be weird stuff that breaks, especially when it's first released. And, you know, we've seen this with everything from the Elder Scrolls games like Skyrim to, you know, Cyberpunk or this. And it's so interesting to me that that plagues the entire genre because of just how many moving parts there are, how many pieces there are, that there's so much content, it's basically impossible for any human to have actually explored the whole state space and test it all.

Yeah. Yeah. That's very much true. But also, not only designers, but everyone in the company thinks that the game should be like super immersive.

And basically, every bug you introduce, it breaks that immersion. So it was for our technical departments, was crucial thing to have everything running smoothly. Ideally, bug free, no like showstoppers that you would, I don't know, enter a dialogue or something and then be stuck in the game and need to restart it if you're like in the middle of the conversation with some NPC that's really important in the story and so on. So as you said, there are many titles that struggled with it and the KCD one definitely struggled with it as well.

But I think that overall, we did a good job for for the sequel. And I don't think that it came back free, but it was much, much better than the first game, and we all were super happy about about the outcome, I think, the technical perspective. Not only technical perspective, but I see it mostly from technical perspective. So Right.

When I saw, like, Digital Foundry videos, when they said, okay, this is running smoothly on console, sixty FPS, no HAs. This is the industry standard that it should be. I was like super happy and Yeah. Also other guys from programming department, they were super super happy when this video came out and even other other like references and fans that were posting that the game is actually running well.

Of course, always there are some bugs, but we tried to tackle them throughout this last year that we we did a lot of patches, but most of them were just like a new content, not really like bug fixes.

Yeah. I haven't played any of the DLC yet. Just played through the main story so far. But I will say that, yeah, I I can only think of maybe one kinda weird issue, but it was like I got stuck on geometry somewhere.

It wasn't even really like a real game breaking bug so much and I was able to get out of it. But I've been really impressed with how big the world is and how many things are going on but also that it has been quite stable. And so can you tell me how long did it take to develop KCD one and then how long for KCD two? How did those compare?

Warhorse was founded two thousand eleven and it was released two thousand eighteen, so that's seven years. Okay. And then you had k c d two, which you would say, the development started right after k c d one, which was not really true. Partially, some people worked on it, but mainly most of the people were still concentrating on DLCs and bug fixing. And like the basically, the whole programming department was just still on on the bug fixes for at least a year.

So you had, like, this one plus year period on on the first game. So maybe summer two thousand nineteen. It was the time when actually, like, the whole company started development on on the k c d two. K c two was released last year, two thousand twenty five, so it's been like six years versus seven to eight years. So pretty much like similar timeline.

Right. And what was the size of the team for k c d two, for most of that at least?

It it varied a lot. When I joined the company, there was around a hundred people. I think right now we are almost three hundred and it grew over time. So I cannot say because it it was just like rising and rising.

I everyday I met someone new in in in the office and I was trying to find out from which department he is. If it's not in poster, that's just like trying to get into our studio Yeah. Yeah. To get a free tour or something.

But yeah, it it was at the end, it was like two hundred fifty when when we like a year ago when we were finishing the project, think.

Okay. Got it. So quite a large team And quite a lot of that was also in house then, right? Like a lot of the art and design. How much how much was this having to get, you know, co development studios or contracting versus how much do you tend to do all of this in house?

I cannot speak for like all the individual departments, but mostly we were doing everything in house. There were some exceptions, of course.

One is localization Right.

Which I think every studio or most of the studios, if it's a huge game, then you don't just have the capacity and and the experts on the language. So Right. It doesn't make sense to do it in house. But mostly, other than that, there there are some animations, but other than that, I think it was you can see in in the credits at the end of the game that there there were some studios that were help helping us. For example, in code, we had old cat games, which were few programmers that were helping us with the CryEngine, but mostly it was it was all in house.

Nice. Yeah. And so before we get into the main topic, which is gonna be about how you manage to have such a complex system of quests and dialogue and things like that, I had a few questions about just the process of managing as many assets as there were in the game and kind of the scope of the world. Because something that I found I kept pausing at certain points in the game to just go and like look at a stained glass window or to look at, you know, a brocade pattern on some fabric that was draped over a chair or something like that.

And as I would get closer to them, I would see like these are really high res textures. Right? There's a lot of details here in just every little thing in the world. Or one particular moment I remember was I was exploring this house and and this is my wife was in the room at the same time and she was like, what what is that in the corner there?

I was like, yeah, you're right. It's just kind of a pillar here or like a block out of the corner. Is there a hidden thing in here? What is it?

And she's like, oh, maybe there's a chimney that runs through there. And I was like, oh, let me check. And so I ran downstairs to the next floor. I'm like, no, it's still here.

And then I went down one more. I was like, oh, yep, there's a fireplace here. Like that everything kinda had this internal consistency to it. And I just thought about what an undertaking that is to coordinate so many people working on something, but to have kind of this internal consistency in the world.

Like you said, you don't wanna break that illusion. You don't wanna break that immersion. What is that process like when you're dealing with those big of teams? You know, how are you keeping this all coordinated and organized and having everyone work on those same assets and same levels Yeah.

And stuff?

Oh, well, that's a hard one for sure, you know, because as you say, like, people are they they just try to contribute and they they are doing their profession. And you as a programmer are are telling them all the time, you cannot do this. And they they are frustrated because they have to obey all these rules. But if they didn't, it would be such a mess, you know.

It it would then look like a student project when when you have, like, this new file and you call it final, and then you call it final final, and then you call it master final version two and so on. So this is something that we always need to take account that people are gonna change things and we need to think in advance what it's gonna look like in two years, three years, five years because as I mentioned, we worked on the the same project for seven years. That that's quite a long time. Like, many babies were actually born when we were here, like, developing the game.

I remember our head of development, Martin Klima, he was, like, at one meeting and he said, okay, we are releasing the game. And just, like, if you think about it, like when we started, the the babies were born and now they are actually in the first grade. Yeah. They are going to school now.

So this was kind of interesting to hear, you know. And if you think about it, it's quite for all of us, it's been a huge project and it's like not a small portion of of your life, you know. If if you're like attending some university, you're probably there for a shorter amount of time than we did on on just one project. So Yeah.

Yeah. Yeah. But I I don't wanna, like, run away from the question.

It was a challenge, of course, but the things that are being placed in the level, like, in the open world

Per se. The designers and artists, they they try to make it look that everything's there, visible, and they they they can show all the different things that are happening and all the houses are different and, like, there are these tiny little details and so on. But honestly, it's not that many assets in the open world. The the complexity goes into the quests because some designer comes and there is, like, one scenario that's only been done in the game once. So you need you need to create all these assets just for that one quest that you play for like thirty minutes.

Right.

But then everything else you can pretty much reuse, you know. So you have apples and you have apples inside every village.

Sure. Yeah.

You have benches and every every you name it. They are all the same assets, you see the tiny little differences and environmental level artists they can do, but it's yeah. It's reusable.

Right. You know, I think I think that's a good point that the assets that you have in the game have a lot of care put into them. Like like I said, the textures are really detailed, but it's not that everything is unique in every area, but that your level designers were very intentional about placing things in ways that feel realistic, that feel meaningful.

Yeah. Yeah. Exactly.

Yeah. So that that's a great point for how to keep that sustainable. It's kind of have keep the limited number of things, but then you can try to be creative in how you place those and how you use those. That makes sense?

Yeah. Yeah. Exactly. And but there's like problems from the actual graphical assets into problems with Windows.

You cannot name a file that has more than two hundred and sixty characters Right. Inside it because then everything breaks. Yep. And people are like, okay.

It's year two thousand twenty. What the hell are you telling I cannot have, like, this long name and, you know, they they cannot understand some some of these things, so you need to explain. And then you are on those meetings that where people are just angry that that they cannot work because there is some validation and so on. So Right.

Sometimes it's a little bit stressful to just like explain it all over again, but that comes with the process.

Yeah. I feel like that's a theme that has been recurring in a lot of these podcast interviews is that push and pull between creativity and then either needing to keep things organized to keep them performant or, you know, something like that. Like the validation versus creativity. And I think that's a valuable push and pull. Right? Like both teams need to be able to pull on each other to try to get the right result at the end.

Yeah. Yeah. Definitely. Definitely. They they try to multiple times, they come to you with one problem and then then you're telling them no for, I don't know, like fifth time and then sixth time, you're like, okay, well, let's do something about it.

So you just like Yeah.

Don't come to me again. So yeah, this happens quite a lot as well.

So yeah, finally, you have to make it possible.

Yeah. Exactly.

Nice. So you teased the quests earlier and how that's kind of a unique area where animations, some of the assets, and then also, you know, the dialogue obviously is gonna be unique for all of those. And for this, you developed a tool in house that's separate from the game engine itself. Tell us a little bit about about that. What is that?

Okay. So I think like every bigger game or at least every game that's similar to ours, open world RPG, you have all these dialogues that you can go into. And there's a huge complex quest logic that that goes into it, you have someone, like, designer or scripter. Multiple people are usually on one quest that are making this happen, that they are doing and telling the NPCs what to do, how to behave, where to go, and so on.

And all this information is basically stored in this system that we have. We call this application Scald. And as as you mentioned, it's a standalone tool. Usually, some studios integrate it into the engine.

For example, it's very similar to, Unreal Engine's blueprints that these days are very popular. So but we were on Grindgen and, this was not something that we could, we could use.

Right. But by making this tool exist outside of the engine, did that mean that people who don't work in the engine could also use it? That it kinda made it more accessible?

Yes. Definitely. Because we had so many users for it. It was not only technical designers and gameplay designers and people who actually wrote the dialogues, but it was also, like, sound designers and sound directors when you were recording voice overs and localization.

So it was also usable for cut scenes that you could actually see the script for the cut scenes as well. And for the localization studios, as I mentioned, we could distribute it outside to our, like, external partners. This this was stand alone, so we could, like, easily tell them, okay. Here, you have the application.

You know how to set it up and you don't need our engine and some custom pipelines. It's just all in bundled inside this standalone application.

Right. Yeah. That that's fascinating to me that something that maybe started as a limitation became a feature like that that then you're able to ship this around separately.

Yeah. It was basically like a feature from from the beginning or It's it basically started only as a tool for designers. It was only for for the dialogues at the beginning. And the quest logic was basically written inside Lua script, which is not visual, or it was inside the engine itself. And then after k c d one was created, we decided, okay, we want to extend this tool. And actually, right now, it can do so many different things, as I mentioned.

Got it. So was this used on k c d one or it started with k c d two?

Like, partially. As as I said, it it was used for the dialogues, but not for much else.

So Okay.

It it's like completely different application. If you would compare these two, you would probably well, you would recognize it, but it it has like completely different functionality right now.

Yeah. So so that's what I want us to get into today is kinda looking at this tool, not just at how it works, but also why it was important. And so so you developed this tool with a team of how how big is that team relative to the whole team?

It's kinda hard to say because you have programmers that are working on the tool, like in c sharp, so they they do all the features. But then you have the other programmers that are working on the game, and they need to cooperate because they say, okay, in the game, you want to add this functionality, and this functionality needs to go into into the Scout application. So there was a team of few programmers and basically full time on the c sharp part itself. There were two people.

And then on on the c plus plus side, it depended on what features we needed to add. So sometimes it was two people, sometimes four, sometimes one. It's like really varied throughout the development. But there was like one person only responsible for the concept graph, which is basically all the Quest logic inside the C plus plus inside the engine.

And he was basically working on this Scout tool but inside the engine.

I see. Like the hooks for how it could talk to and get information from the engine.

Exactly. So at least three people all the time, but sometimes more.

Yeah. Wow. Okay. So so let's talk about, like, how does the tool work? I think we've got a little bit of a sense where it's for was originally for dialogue, but now you said it's been expanded to do more than that.

Yep. So that includes things like triggering certain animations or like pathing for NPCs, those sorts of things. Is am I getting the right idea?

Yeah. I I I didn't mention one thing, and that's the NPC logic, like all the what we call AI systems. They are mostly in c plus plus or they are in the trees inside the engine. So all the NPC logic, like navigation on the nav mesh and so on.

This is not part of this tool. This is only, as I mentioned, for dialogues and for the quest logic. So it collaborates with the game and sometimes it, sends the signals in between, like, back and forth, but it's not, like, one hundred percent of the logic, but, like, very, very big part of it. So it's not a straight line.

It's usually depends on the script or, like, how much of it he wants to do inside Scald, how much of it he wants to do in some other tool. And it it's based on, like, individual features and quests, so it's really hard to tell.

Got it. Got it. But so in Scald is where you would say, now this character is gonna go over here, but then the engine logic takes care of the pathing of how they get there.

Yeah. If we oversimplify it, let's say, it could could be like that, but it's more like a state based or trigger based if if there's some some logic triggered from, like, there is a signal inside c plus plus that say, okay, player entered this area, then some logic happens. Like, some things are streamed in. For example, you enter some area, so you need to stream in, like, a grave or something that's something's gonna happen with that grave. So the old descriptor does is he needs to like basically prepare the parts of the levels and prepare everything so the quest is ready, the NPCs are ready and yeah. So it's it's as you say, like, yeah.

Got it. Got it. So so yeah, talk to us a little bit about, you know, what's the process like of working with this tool? And how did this make this scale of world possible?

Okay. Well, as I mentioned, there's like many, many users. So if I take it from like what the position we call, like, scripter mostly, it's, like, technical designer. So you are working on some quest. And so you mostly use this tool alongside with the editor or or the game. And I can actually share the screen and show the basics of the tool. Like, I I think it would be like a good time right now.

Okay. Great. So this is what it looks like.

It's not *** link really, but I feel like development apps usually have kind of a a more functional interface and less of a Yeah.

Pretty one. Yeah.

Yeah. But since we are on Perforce podcast, I can, like, mention that we have, like, p four connection here. So you can Oh, yeah. See see the workspace, see the server, my name, unfortunately, not my password.

And and you can see that the integration is active, so which is the first thing you want to do. Right? Because then if you would start working, you would not actually be able to save your files and work with them. It's like probably the similar thing as in editor inside Unreal.

You always want to be connected to Perforce. Right?

So Right.

This is the first thing. And then I have, like, this project and everything I show here is basically part of the k c d two modding tools. So anyone who sees this and looks at it and thinks that it's cool how we created quests, you can actually create your own. It's super hard because the documentation, it's not ideal, let's say, But you can actually do it, and I've I've seen online that some people actually did parts of of these quests.

So Yeah. They created new ones. So it's I admire that. And so once you load the project, actually, I can go here into the design and you see this hell.

This is something we call ton of nodes all interconnected with each other.

And this is something we call like electrical switchboard or something like that.

Yeah.

And this is basically if I just show it here, Trotsetsko, which is the name of the first map. And if I zoom in, you can actually see the individual quests. And these purple ports are just the data just the data that are being sent, like, from one quest to another. Part of these things are in check. I have everything switched into English, but it's not ideal.

So No. That's okay.

Sorry about that. But you can actually see, like, the code name for the quest, which is s ten, which is SiteQuest ten. Right now, I don't remember the name in English, but I don't think that's that's important. So if you're actually a scripter and you need to work with this file, you see it's not ideal and it's probably not something that we should be proud of, but just so you can see how hard it would be for some quest when they were being created for the first time to actually have it somehow aligned and put it inside place that it it would actually work. It was not an easy task.

Yeah. So so just to kinda get a sense of this, so each quest in this graph is its own little node and then it has a bunch of inputs and a bunch of outputs.

Yeah. Yeah.

Yeah. And so as examples of what some of those inputs and outputs would be, what kinds of things are those?

Yeah. You can see that there are all different colors. So some are just the data and there are these, I don't know what color it is. It's probably brownish or whatever. This is basically like an execution line, so it's something similar to execution inside Blueprint.

Okay. But just saying like this is finished now, you can start the next one?

Yeah, kind of. Like, let's oversimplify and you have basically these icons that will that will just like put me inside this quest logic. So if I just go here, I will probably be able to see. I mean, here actually inside the quest, can actually see some of the real logic, you know. So for example, here you have some or statements, you know, and if statements and you have some state state boxes and so on. So here you can actually see some real logic. So for example, this quest should happen only when there is this if statement triggered and so on.

So Okay. So like you had to have done certain things in previous quests or you had to have met certain characters or advanced to certain levels Yeah. Things like that to enable And then that those also might change how the quest plays out depending on, you know, which Yeah. Characters you're closer to or things like that.

Yeah. Yeah. Yeah. Definitely. Definitely. This is the case and some of the logic is still like very complex.

So we have graphs inside graphs inside graphs. So you can see these modules that there is another graph inside this.

I see. Yeah. Nested graphs. Okay.

Yeah. And inside here, so you can like orient, you can go back or up always to like see where you actually are. And the hierarchy is also here on the left side, so it's not ideal, but you can orient pretty pretty fair inside it. And, yeah, it has some outputs then and it goes into another quest and this is basically how how the whole logic is being written inside here.

It's interesting to me too because anytime I think about these sorts of open world games where there's just so many different factors that could affect things of, you know, which characters are alive or which things have you done or not done or how do people in different areas feel about your character, all these things that you you keep saying, oh, you know, this is a little bit chaotic or this is a little bit hard to look at because there's so many connections between all of these. But I I also think there's really no way around that because there's just so much information that needs to go from one place to another.

And so Yeah. It feels like this constant struggle for people developing games that want to have these very complicated, very open paths for you to explore as the player. So you're not just forced down this one narrative path, but there's a lot of different ways it could go. I feel like designers who are designing tools like yourself, this must be a constant struggle of how do we allow this to expand and do all these complex things while still being manageable to work with.

Yeah. And this is this is a really good point. And also, it's good to mention that one of the design decisions of this tool was let's see the complexity actually because we could do it in a way that all of these things could be like hidden somehow and encapsulated and so on. But if you actually look at it and you see all the mess, you can actually see the complexity of the game, you know.

Like, when I open up the switchboard, first time I saw it, my head exploded almost. So Yeah. This is something, like, if you look at my mouse here, there are so many lines. And if I just remove one, this could result in some blocker in the game that you would not be able to continue.

And this is also insane that you would just, like, delete one line accidentally and it would just go nuts. So you need to have all these processes that are being done after someone changes something inside the game. So the whole QA and automation framework for tests and so on, this needs to be complex and, like, on very good level. Otherwise, the game would just not work.

Yeah. And I think that's a great point you bring up about validation and tests. So, you know, QA is one thing. And I think for a lot of people starting out as an indie developer or a small team, that's kinda their only testing is QA, which is usually themselves playing it.

Right? They're just kinda trying things and seeing if it works. But with a system this big and this in-depth, that's just not feasible to spend a thousand hours after every change you make to make sure that everything works. So what's what is that process like of making those tests and validations automated?

Yeah. I'm I'm just gonna oversimplify a lot because it it would be just for another podcast just to Sure. Explain everything. But basically, what it does, if you're a scripter, then you make some changes inside the Quest.

The first thing you do before you submit, it will actually run like server side validations. So on Perforce, we have some triggers that are triggered, like, before you submit and it tells you, okay, here you have some issues. Go and fix them. And so we have another c sharp application that's that can actually work with all these graphs and it will just, like, load them and it will basically go through a lot of things.

I don't want to get into the details, but those things need to be checked before that. And those are the first tests that are being done only like that you have it can be compared to like a code compilation. If it compiles, then you're good to go. If it doesn't, then, well, you need to fix it.

So just like everything required has been connected and the right type of data goes into the right types of pins, that kind of thing.

Yes. Exactly. And this is basic by the way, all text based. So all these things that you see here are serialized inside XML files, which is a great advantage because if you had blueprints, it's much harder to work with.

Right. Yeah. You have to have your own special thing to read them and display them and all that. Yeah. Yeah.

This is all all being done inside Perforce basically. As I mentioned it, there is a trigger. We have like a separate server that's only running these validations for for the clients, and then it just, like, tells the Perforce server, okay. This is fine.

You can proceed with the submit. And after that, if everything goes right, then it goes into a build pipeline. Right? So then you get a new build, new package, and then, of course, we have QA, so they test some of the things manually.

Each quest have a different tester or maybe some testers have, like, few quests. And they need to go through some of the scenarios manually. But as you mentioned, it's super complex, so they cannot do it. And so we have something we call automation framework.

And this basically what it does, we have, like, a build farm that is running there's one pool only for profiling and testing. And this pool is basically running constantly, like, nonstop every day, every night, and it's going through all the different quests. There are priorities, of course, so some things are more priority, so they are being tested more often. And these tests actually produce some results.

If there's something that has broken, then it notifies descriptor or the QA, and they need to go and fix fix the logic. And these automation tests are there's ton of them again, and some of them are maintained by the QA, some of them by the code, some of them by by descriptors. So it's it's like a really huge and complex system. Basic basically, this is this is the pipeline.

This goes all all over again.

And is that automation that you're talking about essentially doing a build of the game and then manipulating the character through it? Or is it doing that kinda statically somehow, like a static analysis type approach?

It's actually running the game. You have all these tests and the game is then booted up. It loads into the level and then it does the logic. Most of the logic is actually being done inside the actual level, not not some gym or some Fake level that you would only use for one feature because all of these things are tightly coupled into the environment, you know.

So you cannot really have a gym for for such a complex quest. We had this approach for k c d one, but it was not working that well. So We actually said, okay. This is probably not a good idea because when you are moving from the gym into the actual level, a lot of things break again.

So you need to run run it inside the actual level.

And Yeah. Yeah, there's bunch of code inside it that needs to go into implementing all the test commands so the player is teleported somewhere, and it needs it needs to wait for the streaming, for the rendering, and so on so on. So it's another complex system that that does this.

Yeah. Yeah. Absolutely. And so then when it comes to these quests that are scripted in Skald, that then when those are in the game, imagine there also needs to be some logic in there about how to preload assets like the dialogue lines that are coming up or the animations that go with those so there's not like a weird delay or things getting out of sync.

Yeah. Yeah. And this really depends on what kind of assets they are because Grungeon has all different kind of systems for localization, for animation, for brushes, which is basically like a geometry and so on so on. I I mean, there's tons of them.

And each system behaves differently, have different streaming rules and so on. So this is another thing that's kind of painful to actually want to fix some bug. It might be multiple bugs because you don't know if the problem is inside the streaming of I don't know, one thing or the other. Like, some rendering programmers, they they they got a bug and the bug says, okay, something is blinking in the far on the horizon.

I see.

Like, I don't know what that is, you know. I I cannot even see if if it's like a house or if it's a tree, and those are two different things or it might be something else. So this is something we changed a lot for KCD two. All these systems were not entirely rewritten, but they were modified heavily, all the streaming and so on. This was for the optimization purposes, this was modified a lot.

Yeah. Yeah. Absolutely.

And then so when it comes to optimization, you mentioned when we talked before this interview that this tool itself, SCALD, also needed to be optimized quite a bit Yes.

Because not everyone running it is on a computer that can run a game engine.

Yeah. Yeah. Definitely. Yeah. As I mentioned, I I have it still shared here, but let's say you only are interested in in the dialogues or in the translation or something. So you would just, like, use this part of of the sculpt and you don't need anything else and you want to run it on notebook or whatever and you you only are doing some sessions inside recording studio and you have an actor and he's like recording something.

So you only use it for this for example and See, so you would load your audio files directly into here then?

Yes. Yes. See.

So when you're in the studio, it just goes straight into to this tool.

Yeah. Yeah. Yeah. They they are actually streamed in from Perforce, so it doesn't need to have everything like locally. So for example, if you just want to play some line, here, I I I it will be, like, streaming when I when I want to or when I click this, it's basically it loads all all these inside this table.

I see. So all of those are just on the Perforce server and then when you click play on one, it'll download that asset so that you can play Wow. Fascinating.

Exactly.

Yeah. It makes a lot of sense with such a big game too where that would be a lot of data that everyone would have to pass around if they needed all of it all the time.

Yeah. Yeah. So basically, these are like very similar optimizations as in the game itself, you know, because you cannot have all inside memory inside the game because it contains a lot of assets. They can be audio assets or whatever.

So this streaming, as you can see, happens inside this tool as well. So you cannot have everything inside or you could, but then it would eat up all the memory and it would load for I don't know how long. So Yeah. We we need to go go through these things and optimize as well.

And so right now, you can actually run it on almost everything. You have like some small notebook inside the studio for a director or someone and he can just like run this application easily.

Yeah. Great. So so something that you pulled up a second ago was this random encounter. And so first of all, I I think it's interesting that this tool is not just for quest quests, but also for any kind of little scripted interaction that goes back and forth. So one question I have first before we get into this particular interaction is Does this include interactions that don't directly involve the player character? Like the conversations that you'll overhear NPCs having with each other?

Yeah. Yeah. There is as you can see here, there's something called open world here and there's a lot of things that you could actually hear inside it. So, yes.

Got it. That's basically the answer. So, yeah. Basically, this is a script logic and it's part of the script logic.

So, yes.

I see. So, yeah. So it's I just wanna get clear that this is more than just quests. It's it's kinda anything that involves cause and effect Yeah.

It's the whole world.

Little interactions or one thing has to happen after another.

Very interesting. So so this one that you pulled up and I mentioned this to you before is this random interaction that happens. And this happened to me when I was playing the game where you're walking down this road and there's an old lady there. And this kind of thing happens a lot in the game, right?

Where you're traveling somewhere and there's a person on the side of the road, someone wants to talk to you, whatever it is. But then this woman was just being kind of creepy and mysterious and I was like, I think this is death. I think this lady is death. What's going on here?

And then we talked for a little while and then she just walked away into the distance and I followed her for a while across the field and then eventually just let her walk away. I was like, that was that was so weird. So tell me a little bit about that particular interaction since we can actually see everything that goes on inside of it here.

It's one of many. As you can see, like, we have these random events.

And again, sorry for this, we call it Cenglish, which is like Czech and English Sure.

Yeah.

Together. And yeah, so this means like wanderer. So you have all these different wanderers inside.

Got it.

So you you have like a riddler and prisoner and so on.

Yeah. Okay. And I'm looking at the names. I'm like, yeah, I've seen a lot of these people. Okay. I know I know what's going on Yeah.

So so so some of these you might know and one of them is the death as as as you mentioned. So which is the lady that you might you might actually come across and you have something we call this, like, dialogue visualizer. So you can actually see here. I can even, on the left, see the lines here.

They are in English. So which is Henry in in English, try saying, what are you doing here? And it goes on and on. And which means, like, wonder death.

And she's answering and resting and so on. And you have all these decisions. If I go here, I can, like, scroll down and it will actually like pop up here where inside the tree it is.

So we can see different decisions you make of how to respond goes off into a different branch and that might end the conversation or have other choices.

Exactly. This is basically the decision tree and this one's pretty straightforward, but you can see some trees with that are so so branched that you you cannot even visualize properly.

Right.

Right. But this one's really straightforward and it just like says a few lines and this is only like the dialogue logic. But if I go inside the concept graph here, it will just take a moment. So this is actually the logic that the scripter writes.

I see. So the kind of the script logic and the dialogue logic are separate from each other.

Yeah. Well, the dialogue logic is basically here, but it's triggered from the code. So it's only like here, but like some other part of it is inside the actual game. So when you press e, some magic happens and then the this dialogue plays.

Right.

But you can see part of the logic inside the script. So, basically, when when you spawn this event, there's some things that happened. There's some timer and some uninteresting stuff that's happening, but then there's some, like, check so you can see that this is actually City Wanderer. If it's not City Wanderer, then you can proceed, and it has to be a knight. So if Got it. These balls are through, then something can happen.

Yeah. And so I see that there's a trigger to enter this particular one that says death is enabled.

I'm assuming then that something must happen in the game that allows this one to end up in the random encounters that can happen.

Yeah. Exactly. But but if if I go like, I have only this small node open, so if I go up, so you can actually see this huge tree again, and it's it's just a mess. So it's these are all the the events and all these data is coming from somewhere. I don't know where they're coming from right now. I would just like need to follow the line.

Right.

Eventually, at the end of the day, I could tell you what it does.

But that's like, if something like this, you you need to know the the very details of it, you just go to the script or the direction And you can just follow this all the way back through the logic to figure out Yeah.

What caused that.

Exactly. So this is basically this is basically it. This is how it's scripted. And if I go, I can show one more cool thing.

I can go into the decision tree and let's say I'm a designer and I want to see how the desk is actually talking. I can actually select, for example, this decision and I can go into IDA here, which is a tool that is used for, like, custom animations, facial animations And you can also see, like, different audio files and I can actually play it. And this is something you actually as a player hear inside the game. Right.

This is the actual English dialogue. And this is not really very there there are not many modifications that you would see, like, some special animations, but you can see that where where the Henry should look, that he he's looking at at the depth, so he's not, like, just, like, randomly wandering with his eyes.

Right.

Yeah. This is another tool that you can actually use inside Scout and this is tightly connected to to the game. Unfortunately, don't have the game ready right now. But you could actually change something here and then, like, in real time, just like reload this part of the dialogue and actually see the change.

So in this tool, the lip sync, I'm imagining, is handled automatically through some other system. But that this is where you would do things like what their facial expression should be here or whether they should be like pointing at something or gesturing in a certain direction, things like that you can control in here.

Yes. This is exactly right. These are all like tiny little modifications that the NPCs actually don't look robotic, that they they just don't stare. They're staring at each other, but they are just, like, doing these things that I'm doing, hopefully, inside of this podcast that I'm just trying to, like, a little bit wander around with my hands or, you know Right.

Just sliding from side side to side and so on. So this is this is part of it. And we have animation department. And part of this animation department, we have, like, these gesture experts and they are Basically manually trying to make some of these dialogue nicer.

If it's a dialogue inside the main quest, it's obviously Right.

Basically seen by every player. So we try to take time and make it as eye appealing as possible.

Yeah. Yeah. So that you have this kind of library of different gestures and different, obviously, facial expressions and moods and things that then the actual level designers can come in here. Or not level designers, but the, I guess, sort of dialogue directors or something can actually tweak those right in this tool without having to go get custom animations for every single piece of dialogue.

Yeah. Exactly right.

Nice. So I wanna hit you with a few kind of rapid fire questions that came up for me while playing the game. And the reason why I mentioned that my wife commented on this is because I was playing this on the PlayStation actually instead of on my PC. So, you know, just be there in the living room.

And it was interesting hearing from her what things she noticed about the game just from the lines of dialogue that she would hear often. And one that like from the other room, she came in, she's like, wait, what? Was when Henry yelled out, I feel quite hungry when he was fighting and that would happen fairly often because I had a perk where yelling at my enemies would shake their resolve or whatever and maybe make them give up. So I would use that taunt or not taunt, but the yell button and often he would say, feel quite hungry.

Tell me, how did that end up in the game? There are occasional things like this that were just so silly. It felt like someone had to know this was a joke when they put it in.

Yeah. And so so when the first game released, it basically became like a meme because it was just part of the the dialogue when you were actually hungry inside the game. So when I see. You So when when you haven't eaten for a while, then there's there are few lines and one of those lines was, I feel quite hungry.

And it became like an Internet meme. I don't know how, but that that's just how things happen usually. And then when the second game was in development, of course, people knew about it, that people were making fun of it. So they say, okay.

We have, like, these battlecries inside the game. So when you're fighting, wouldn't it be fun if if he would just say, I feel quite hungry when he's, like, smashing you with a hammer Yeah. Or something like that. So yeah.

And we we had, like, all these different lines when you were fighting, and one of them was this one. And yeah. So so that's that's why it's kind of weird for people that haven't heard about this because if you're just, like, running around and you just start fighting with someone Yeah.

You're just like expecting to say some swear words, you know, or just like some I don't know, completely different thing than I feel quite hungry.

And by the way, I I think that we can actually find it here inside if I just write the line.

I see. So you can just search. I feel quite hungry.

And yeah.

So Wow. It can actually find a few things and you can see it's here in the battle cry. So for example, if I go into the dialogue again, just give it a second.

Yeah. So here you can see it's inside this decision and it basically, like, has all these different possible things that inside the battle cry you can say.

Got it.

It's basically branched by it means, like, is player father Godwin. So father Godwin is Okay. So there are separate things for him and then there are separate things for Henry because father obviously cannot say this cool line.

Right.

And I think it should be still like a bark that you do when you're actually hungry. So here, you can see it as well.

Got it.

So yeah. We as you can see, we still have it in the game.

Wow. Yeah. So so that one's a a holdover from a meme from the first one. So another one that I thought was funny was the word wares is said a lot.

And this was another one that I didn't notice at first until I'd been playing a while and with every merchant that Henry would go to, very often he'd see like, show me your wares. And that would be this kind of it became a meme in our house actually. It was anytime we're gonna go shopping or something was, I'm gonna go look at some wares. Okay.

And so for those sorts of things about the words and the dialogues that come up, were there any of these that happened in the studio that that the developers kinda latched onto or started to say in their lives?

I'm I'm not sure if it's for the dialogues. Well, actually, it is. There's inside the deal because we are Czech, so a lot of things are, like, Czech oriented Right. Because it doesn't hurt the people, like, from America or somewhere else. They they just don't understand the, you know, the actual meaning of the line.

Right.

But there are some, like, Czech memes that only Czech people get, and it's maybe better if not everyone on on the earth actually gets the reference because it might not be the most polite one. But there were definitely some things. There is one Czech guy who's actually repairing a tractor, and the it's like a meme video. For ten minutes, he's just swearing, and some of these dialogues are actually in the DLC.

I see. So that's one I I can think of, but these are not only the dialogues. I I mean, our sign sound designers are trying to be funny as well. So Right.

There there are some, like, lines if you're going through the Gothenburg city at night, you can actually hear some homeless person shouting something and you cannot understand it because it's in Czech, but that's another Czech meme.

I see.

That's like very very popular here. And yeah. So but there are also some Easter eggs that hasn't been found yet.

And Really?

Yeah. They they are just so obscure. I remember one of my fellow programmer colleague, he he did that.

I I don't know if I should actually speak about it because it has a You don't have to give it away.

Yeah. Don't have to give it away. But just that's good to know for all of you out there that there are still undiscovered things in KCD two.

Yeah. So I believe it's connected to some some specific chest inside the game, a specific item, maybe. I don't know. Something like that.

Alright.

So maybe someone someone will find it in the future.

Nice. Yeah. That's so interesting. So you also then get a certain amount of data back so you can kinda tell what's been explored in the game?

Yeah. I mean, like so many people play it and then when someone finds something really cool, they just tend to do a YouTube video about it or they just Got put it on Reddit or something like that. And our community managers, they just, like, scan everything, I feel like.

I see. Trying to keep track of what people have found and what Yeah. Yeah. What's happening.

So so may maybe I'm wrong. Maybe I just don't have enough information. But I think that if it would be found, I would I would know about it.

So Okay.

Yeah. Nice. But there were even, like, some bigger features in the game, for example, cats. This was a feature that was cut from the beginning and they said, okay, we don't have time for another pet or another animal inside the game.

Ah. But there were so many cat lovers inside our studio that they they just, like, did it and just asked no one, basically. And then they just came and said, okay, it's in the game. And so someone said, okay, let's if it's ready, then let's put it inside.

And it was, like, effort of a lot of people. It was maybe, I don't know, like five or six people working on on this feature after their hours. They they just went home for a weekend. And after the weekend, the colleague showed me, okay, I have this goal for for this cat that she like, it can play animations and jump and so on.

Was like, okay, cool.

Nice. That's great. One other kind of random question that I had is I noticed that a lot of this game is very historically accurate. It feels like it's actually going for that. There's a lot of the codex things that will give you more context about historically what this actually was or who this character is based on, which I thought was really interesting.

We have a few people, like historians, inside our design team or they are just advisers only for these kind of things and they go, like, very into a very detail. And I was surprised actually sometimes what what details are they, like, going to.

Right. There were some kind of food that they need to be redone or just completely scratched from the game because someone modeled something, and it was they found out that it was not accessible back then. Oh, wow. And there there was some kind of a tree that they somehow found out that it couldn't grow back then inside Central Europe and so on.

So a lot of lot of detailed research went into this. And so I was surprised into the detail and effort they put inside of studying these things. So Yeah. It's interesting for me.

But I I don't know much about history, which is a shame and probably a disgrace for me as a dev developer working on this kind of game. But I'm always, super curious when they come up with these details, and we talk about it sometimes in Popover beer.

Yeah. That's awesome. That's very cool. I I also spent a lot of time while playing the game looking things up on Wikipedia to be like, wait, what actually was the deal with King Wenceslas? Like, what what happened at that time? What was going on here? So I I definitely learned some things from this game as well in addition to enjoying it.

That's cool.

So as we're wrapping up, I want to end with a question. So if you have any advice for someone who's maybe newer in the game industry or newly getting into a job making more internal tools like Skald that you're working on, is any particular advice that you would give to them?

Yeah. It it might be one of them. To be curious is I I think the most important thing because such a project is so complex. And if you're curious and if you just, like, go to your colleague to show you something, you can just, like, learn so much from just talking to other people. You don't actually need to develop something, but you're just like talking to some designer or environment artist or whoever. It it's like you just have the big picture of of the whole project and it can, like, help you in your profession, whatever it is. I just wouldn't be afraid to ask to start and now everyone has AI, but to be asking your colleagues about some specific stuff that's like a tribal knowledge inside your studio, that's that's also something that I think a good developer should have not be afraid to ask for help.

Yeah. I love that. And I love the idea of connecting with the other people that you have access to within your community, within your group of game developers, or if you're part of a larger community because, you know, with AI, we have a lot of access to information, but it's kind of this I think of it as like the average information of everybody. But what you get from your colleagues is the stuff that's not average, the stuff that's surprising or unique or maybe isn't a standard, but could be useful for you. And so getting that kind of information, I just find to be so valuable, being able to have those conversations with people who have opinions or different experiences.

Yeah. Yeah. Definitely. Definitely. I I think that you have, like, this the AI for these generic things, but according to game design that's just specific for your game, you you can get that out of AI just yet.

I don't know, in a few years, but Yeah. Right now, we are still not being removed. Yeah. We'll see.

Yeah. Well, and I think just the amount of care, but also the creativity and surprise that happens in the game, like these memes, random references and things like that. I I love having that human touch in the game too. So thank you so much for joining me today and for sharing all of this. This is really interesting and people who are really interested in how this tool works can download these as part of the modding tools?

Yes. Exactly. They are part of the modding tools on Steam. So if you want to just like wander around, see the individual lines that are in the game or you want to tweak something, you can definitely do that.

And if you're brave enough, I think you can just do your own quest, but be prepared that it's a lot of work. Yeah. And I think, like, only a few people have actually done it. If you go through the individual modes of our game, you can find some, but it's definitely not an easy task.

And I'm not sure even if I would be able to do it. If I if someone would tell me just like do this.

I probably would, but it would take me a lot of time because you basically need a knowledge of all the different departments inside the studio.

You need to be partially programmer, partially scripter, partially designer Yeah.

And so on. So you need to have all these different things that you need to combine and then maybe if you're lucky enough, you can actually create your own quest.

Awesome. Well, I'm excited to see what people come up with. If anyone's made a quest, let me know. I would love to check it out. So thank you so much, Peter, for joining me today.

Yeah. Thank you very much as well for the talk. It was very pleasant time. So thanks.

If you enjoy this kind of in-depth conversation with leaders in the media, gaming, and visualization world, be sure to subscribe so that you get new episodes as soon as they come out. Subscribing and giving a review or rating is the only way that we know you enjoy this content so that we can keep making more of it. Reach out to me via email or LinkedIn with feedback, guest suggestions, or to connect if you'd like to be a guest yourself. I'm always looking for great stories and I love learning about the many ways that game and real time technologies are being used today. Links for that are in the episode description.

Be sure to check out perforce dot com for information about our full p four platform based on the industry standard Perforce p four version control. Special thanks to our production team, Ella Reiswig, Emily Matlak, Kaylee Torres, Luisa Puchala, and Chris Perez. I'm Jace Lindgren and I will see you next time on In Development.