Supporting Thousands of Simulated NPCs in Kingdom Come Deliverance 2 | AI and Games Conference 2025

[00:00:11][applause] >> Okay, hello. Um as already said, I'm Better Smelchek. I came from Warhorse Studios from Czech Republic and today I will tell you something about maybe the slightly crazy amount of people we are trying to simulate in our game.

[00:00:28]This talk will actually be at least a little bit about both of the games cuz some of the techniques we are using in the Kingdom Come Deliverance 2 were developed already for the first game.

[00:00:38]If you somehow made it to this talk and you don't know what these games are, don't worry, I'll get you covered. Uh those are open-world RPGs and they are maybe a little bit unusual by uh having no fantasy elements in them.

[00:00:52]They are trying to be as historically accurate as the central medieval Bohemia was.

[00:00:58]Uh Although interesting property is it's kind of a medieval sandbox like a medieval GTA. There's a big main story, but you can also roam the world and mess with NPCs the way you want.

[00:01:11]Uh they are both running on CryEngine, although we have a little modified it.

[00:01:16]And it took us some time. We actually worked for like 7 years on each of the games. So the original KCD came uh in 2018 and the second one just earlier this year.

[00:01:28]First, just to see the scope of our game, uh we have two maps that are approximately 16 square kilometers.

[00:01:37]And on the one that has more people, there is 2,400 NPCs.

[00:01:43]And 1,500 of that is concentrated into a single big city.

[00:01:47]And those NPCs aren't just standing there, they are all simulated, they have complex behaviors.

[00:01:52]And uh if you would be making this game like several years earlier or decades, you would probably try to this one the NPCs are far away and simulate just the ones that are close to you. But, that's not what we do. We actually trying to make the game as immersive as possible. So, we are simulating all of them all the time. And that has really high cost. And that's what I am going to uh try to show you how we tackle that.

[00:02:18]So, the content of this talk will be first, the reasons why we are actually doing this, the reasons why I simulate the whole world. Then, I will want to show you maybe a knife solutions we did for the first game when we weren't as experienced. Then, I will go to the more major solution for the Kingdom Come Deliverance 2 that we are using right now.

[00:02:40]Uh there are all also special cases for the city which has a very high density of population. And finally, when we already had this tech to simulate a lot of people, we could use it to some other parts of the games as well.

[00:02:56]So, the immersion, first part.

[00:02:58]Uh we are trying to achieve with with these games an illusion of player being really there in person, living his medieval life.

[00:03:08]And what are using for that?

[00:03:11]First is the realism. The games are trying to be as realistic as possible.

[00:03:14]So, the people there are actually wearing the correct clothes they should have been wearing during that time. They are doing the correct things using the correct items. Even the most of the vegetables is the same.

[00:03:25]Uh and uh you as a player have chores.

[00:03:28]You have to sleep, you have to eat. You have to basically plan your day as we all do when we get in up in the morning.

[00:03:35]We also have quite a deep systems. So, for example, the NPCs are carrying items or clothes. They are putting them in the chest before they go to bed. You can loot it. Then, they don't have it. They have to deal with that. They will be probably naked or or spare clothes.

[00:03:48]And uh the behaviors are also very uh like complicated. The Those NPCs have basically their lives. They have a house they live, a bed they sleep in, they get up in the morning, have a breakfast, then they go to work. Uh in the evening they go they might want to go to pub to have some fun.

[00:04:05]And you can interact with all of that doing a small crimes and they are very, I would say, nitpicky. You can you can even stand in front of the door of some NPC for too long, they will get suspicious of you and ask what do you want.

[00:04:20]Uh So, we are simulating the whole world.

[00:04:23]And what are the main advantages of doing that?

[00:04:26]First, the NPCs are actually correctly positioned at all times. Because we have those uh complicated behaviors, the NPCs might not be at the same position during the whole day. So, they might be living somewhere and they might go to work to a field, which is quite far away.

[00:04:44]So, you can follow them and they will do all the correct things. You can even like be at the field and they will arrive at the correct time and interact with you, maybe.

[00:04:53]Uh although there are consequences that affect the world if you, for example, do some crime, run away, uh you won't get away with that. The guards will uh sim- simulate everything as if you was there and if you, for example, kill an innkeeper, the NPCs won't be going to that pub, it won't be open, so they will do some different behaviors, even if you are far away.

[00:05:16]And uh the player is actually not necessary for this world to work. And the big advantage is that it can be also scripted this way. So, uh the scripting logic, the quest logic can count on of on everything being there at all time during all the triggers at correct times and sending all the NPCs uh where it's necessary.

[00:05:36]Of course, uh it sounds really good, but it's really heavy with performance and that's uh why we are doing some level of detail of the AI simulation.

[00:05:46]So, the first game.

[00:05:48]And uh some of the things we did for the first game.

[00:05:52]Uh at the very beginning where we started to develop Kingdom Come Deliverance, we had the idea that the world should be deeply simulated, right? Everything should be as as in real life and not as in the games.

[00:06:05]And every good developer knows the first rule of optimization.

[00:06:09]First, make all the features, then profile, then optimize. So, we did that, right? We created one big level without any loading screens cuz we didn't want loading screens. We created all the behaviors, all the NPCs, and then we tried to turn on the console and it immediately crashed on memory, right?

[00:06:25]Uh so, when we fixed it a little bit so it could run at least not not crash immediately, it run 2 FPS. So, um we had to do something. And uh and uh the big issue was that we al- already had a lot of system done. So, we had to do something on the fly. We couldn't remake all of that.

[00:06:46]Um before I show you what we did uh to solve that, I have to at least briefly introduce you to uh the core of our technology, new modular behavior trees.

[00:06:57]We have actually custom implementation of modular behavior trees. Uh what is it?

[00:07:01]It's uh basically a visual scripting language. And our version is very low level.

[00:07:07]So, normally you have those nodes that uh you connect together. They are like line of instructions. Some of the nodes do something. Some of the nodes are just for branching. And we have even like loops, uh conditions, expressions. We even have a switch statement there. So, it's basically Turing complete twice over.

[00:07:24]And uh we run those trees to simulate almost everything. We do the behavior selection using the trees. We execute the behaviors using these trees.

[00:07:34]And we uh execute the reactions as well.

[00:07:38]So, this is an example of some a little part of a behavior. A woman is pulling a bucket of water. She has a empty bucket down there, and when when she pulls the water, the bucket will now look filled, right?

[00:07:51]So, this might be like a really simplified behavior to do for that. We are basically playing an animation.

[00:07:56]Somewhere in the middle of that animation, there's an event that will be triggered. We catch that event, and we react by setting the property of the bucket, so it changes model, and it looks filled.

[00:08:07]Okay. So, now you see at least a little bit of the basics of our script, and let's return to the place we were. We had all those trees, and the game didn't run.

[00:08:19]So, we tried to strip away things that were not necessary, right? When you have far away NPCs, you don't have to simulate a lot of things.

[00:08:26]They are definitely not visible, you don't have to render them. If you are not rendering them, they don't have to be animated. And if player don't doesn't interact with them, there doesn't have to be physics.

[00:08:37]But it turns out, if you turn out uh if you strip the animations, it breaks the script, cuz we are not running the animations, we are not getting those events, and uh the logic is not correctly simulated.

[00:08:51]It might seem that it's not as necessary to have a bucket filled with water for the world to work, but we have we had a way more complicated logic there. This was just a simple example.

[00:09:04]So, what we did to tackle that, we introduced the LOD branching in the script. We basically created another branch of uh in the tree that handles the simplified simulation.

[00:09:15]So, it looked somehow like this. You see, this is the exact same tree, but we added the part in the yellow rectangle, which has some uh LOD guardian node that is basically just branching based on which level of detail you are at. And the simplified version in the yellow rectangle is basically just waiting, and then doing the only consequence, which is this very the very same node that is in the full simulation. Just changing the market looks filled.

[00:09:44]This looks nice, but it turned out to be actually really complicated because this is really a simple tree. Our trees were more complicated. There could be many animations in a line and uh you must be able to switch at any time in in the correct consistent state. So, there was often a lot of nodes, a lot of logic handed ending just this transition to the other branch.

[00:10:08]Another thing we did is uh movement. It turns out if you turn off physics and animation, the NPC can't move, right?

[00:10:16]So, what we did was we were teleporting them, but we wanted NPCs to be at correct times at correct places, so we couldn't just teleport them to the end of the road. So, what we did we we run the normal pathfind and then along the pathfind we executed those small consequent teleports.

[00:10:36]Uh the big advantage of this approach or at least how we implemented it was that uh we made it completely transparent to the script. So, in the behavior tree we have just one node which is called move.

[00:10:49]And uh it doesn't matter in which branch you run it, whether the optimized or unoptimized, you don't have to be in any branch at all.

[00:10:56]The logic of the switching of the LOD is hidden within the node. So, um uh when you run the node, it just uh See, it just looks what the current LOD is and runs the correct simulation. And it reuses the pathfind when you switch the branch.

[00:11:14]Uh okay. So, we did some of these things and we optimized the fire NPCs and the game actually did run way better.

[00:11:24]Um but that was mainly the engine stuff we stripped. We also made some uh script branching, so our trees got right? So, that should be faster.

[00:11:35]That would be nice, but no, because this is actually our our behavior tree for a sitting at a bench in a pub.

[00:11:42]And and uh and only this small part down here is the behavior execution. And only small parts of that were branched by the LOD branching. Uh if you are wondering what most most of this does, it uh selects the behavior, then it selects the correct place you should sit at. There are more chairs at the bench. It handles like uh long-distance movements or some quest injections and stuff like that.

[00:12:11]So, we actually by the LOD branching we stripped only a very small part of this execution. So, it was still running for a uh with a lot of performance hit.

[00:12:23]It turns out if you are running some script, some AI logic, uh it will be interacting with a lot of systems. It will be touching movement, animations, everything. So, it has to run on the main thread.

[00:12:35]But our AI update was above 10 ms, sometimes even spiking to way more. So, uh if we kept it on the main thread, we wouldn't have many hopes for at least reasonable frame times, right? So, we had to do something bold.

[00:12:51]We moved it to a thread completely. This is our uh brief overview of uh the threads.

[00:12:59]Uh the top two threads are main thread and render thread, and the other workers they are basically running asynchronous jobs.

[00:13:06]And this is what we did.

[00:13:09]We We took the AI from the main thread, and we put it kind of neatly at the at the second half of the frame.

[00:13:17]The reason for that is that the physics and animations at the first half of of the frame are uh updating all the entities, all the positions, all the states are updated here, and then the those this informations are locked down, and the render on the main thread will try to prepare the next frame, the rendering for the next frame. So, the entities can be touched anymore, which has the advantage that we uh the our our AI update is not racing with any other systems. But, there is a disadvantage that the AI cannot change anything, right? So, what we do is we we actually do all the simulation, and we defer the results to the end of the frame.

[00:13:57]So, they are executed right when the render ends.

[00:14:01]This saved a lot of time. It might sound simple, but it was extreme amount of work, but it worked in the end. So, the results for the first game. This was all about the first game.

[00:14:12]Uh it we actually managed to simulate 600 NPCs at all times, but the frame times weren't that good.

[00:14:20]Uh I'm actually talking about the uh performance on consoles consoles of the time, Xbox uh One and PS4.

[00:14:30]Uh the visibility was 60 m, or 90 if you account for hysteresis.

[00:14:35]Uh but, we actually haven't managed to simulate all of the NPCs. Some of the less important NPCs in the villages uh were unloaded when you got far away.

[00:14:45]Also, our script logic was very bloated.

[00:14:47]Uh I showed you like the huge tree, and that that has had the branches which had to be handled. So, that caused a lot of bugs.

[00:14:56]And, also you were still simulating a lot of logic in the in the scripting trees. So, our faders or even NPC reactions were very long.

[00:15:07]So, but the game came out, and it was kind of success. So, we knew we could do better, right? We knew where where our uh like weak spots were, and what we could improve.

[00:15:19]For the second game, we got both. We wanted way more NPCs and a big city.

[00:15:25]And we also wanted to fix the issues we had with the first game. So, we didn't want the branching there in the script causing all the bugs.

[00:15:33]And we actually wanted the scripters to be able to ship the game, not like the low-level systems, right?

[00:15:39]Um and we wanted all the NPCs to be there at all times, like the original vision was.

[00:15:46]But we had a big advantage at this point. We were starting the development and we could design the game from the very beginning with the AI LOD in mind.

[00:15:58]So, without further suspense, let's see the core of our current solution.

[00:16:02]We actually now have three main LODs.

[00:16:05]The close one is basically the full simulation.

[00:16:08]Uh we do it only for 70 closest visible NPCs and only when they are at least 150 m far away.

[00:16:18]This is basically the same picture just zoomed slightly out. The blue dot is player and you can see the sum of the NPCs that are a little bit further on the outskirts of the village are already in the middle LOD, our second LOD.

[00:16:31]And the main the main like assignment for these NPCs is that they have to be able to quickly switch into the close LOD.

[00:16:42]And we can support up to 400 NPCs that are no longer than 600 m because then it then doesn't make sense to simulate more of them.

[00:16:52]Um Maybe you can see that together these two numbers, 70 and 400, are quite similar to the first game.

[00:17:01]Uh but we added a third LOD, which is for the NPCs that are basically at other villages and that enables us to heavily optimize those.

[00:17:12]So, this is the same picture again zoomed out with the player being the blue dot and you can see the other villagers in the country.

[00:17:20]So, the middle LOD, as I said, the main uh point of this LOD is to strip some things, but being still able to quickly switch into the correct simulation state. So, we actually have to simulate the whole AI. We need the position and the state to be precise. If we are playing several animations or a long animation, we still have to know exactly where we are.

[00:17:46]We did some We did similar optimizations to the first game. So, we stripped the physics, animations, rendering. We found some small other updates that could be skipped. When you looked closer to the grind engine, for example, the updates of water splashes and small things like that. But mostly the same. But we did a one huge change, and that is that we made the animation simulation transparent. So, we did our own animation simulator that doesn't care about the bones. It just runs timers and uh triggers the correct events at correct times.

[00:18:20]We also made the execution part of the behavior trees a little bit low-level, but that's actually a topic for another talk, which is hopefully or luckily already existing. If you have access to GDC Vault, my uh colleague Matej Marko actually had a great talk about the go go-oriented action planning and the changes we did with the model behavior trees to improve this.

[00:18:47]So, the middle LOD was very similar to the first game, but now the new technology, the far LOD.

[00:18:53]So, uh the far LOD is actually already quite far away. So, the player has to travel to reach those NPCs.

[00:19:01]That enables us to be less way less precise. It's enough with the position being up to 10 m, and we don't actually have to simulate the correct state or item handling because there's enough time to start it up when the player gets close.

[00:19:17]Uh so we actually don't execute the behaviors. We just run the behavior selection part of the algorithm. And here you can see a pub. The pub in our games are mostly outside like they were.

[00:19:27]And those red dots are the NPCs in far LOD and they are not correctly sitting at places at the tables. They are just in the pub because that's enough. And player approaches this village, they will start their behaviors and get to the correct place.

[00:19:41]We also have a fast behavior startup.

[00:19:43]That means that for example, the items or clothes of the NPCs will get uh will get synchronized right away instantly because if you were approaching the village and some of the NPCs switched to the closer lot uh and they would realize, "Oh, but I need this item in my hand." They might be mm mm uh forced to leave the pub, go to pick the item, and go back, and that we don't want that, right?

[00:20:11]So, uh this is actually one of the biggest changes we did for the second game. The selection of the behavior.

[00:20:19]We looked at the huge trees of the original game and we saw some repeating patterns actually.

[00:20:26]All this big tree was mostly handling the behavior selection and that was time of the day when the behavior should be played or some weather. Also, the properties of the NPC whether it's drunk, needs to sleep, or whether maybe social status or whether the gender.

[00:20:41]There are also constraints. So, if there is the woman pulling water from a well, no other NPC can be there at the time.

[00:20:50]And also, there were some uh random uh uh systems. If you select some behavior by chance, then you are locked into the behavior for a while.

[00:21:00]So, when we saw those repeating patterns, we actually realized we could get rid of the tree and simulate everything in the code and just made those patterns be parameters of a code execution.

[00:21:13]So, this huge tree got uh removed and that helped not only with the far LOD, but for all the simulation of everything.

[00:21:23]So, it is configurable uh in script, but it's executed in code.

[00:21:29]So, what actually do we do for the NPCs in the far LOD?

[00:21:34]The whole execution is now in code. Cuz we have the behavioral selection code, we can run it to find the behavior.

[00:21:41]Then, if the behavior is different than the one run up to this point, we do need to do the switch. And the switch will change some constraints. For example, there's the innkeeper in the pub. If innkeeper comes to the pub, he opens the pub and other behaviors will get open for the visitors.

[00:21:59]So, when we uh do have those global consequences settled, then we have to decide the position where the behavior is happening and we do this automatically as well cuz uh it's enough to be 10 m uh within the correct distance, so we can just pick any position of any animation that will be participating there and just teleport the NPC there.

[00:22:23]And uh if the NPC is too far away, we will move it. And we actually simplify that as well because we have this uh big graph of paths that's uh uh actually following the real roads and we don't run the full path find, we run path find only along those roads. So, the NPCs in the far LOD move only along the roads and uh most of the time that's enough to get them close enough and finally teleport them to the correct destination.

[00:22:53]So, uh by having those uh simulations being so simple, we could actually strip way more things in the far LOD. So, we could actually save some memory.

[00:23:03]So, what could we release?

[00:23:05]The biggest saves was in character, which is basically skeleton and mesh. We could completely delete it from the memory. We could delete the physical representation. We don't have just capsules, we have articulated physics.

[00:23:18]Uh then we could remove most of the behavior trees that weren't being run and some other AI components like combat or some perception stuff and basically some other engine stuff that were big enough to uh pay off to be removed.

[00:23:36]What we kept is some RPG representation. Well, this is the state we want to keep, the health stuff.

[00:23:43]Uh we had to keep some part of the of the AI to be able to react to things.

[00:23:49]Uh and then basically we kept systems that were small enough that it wasn't worth removing them.

[00:23:58]Uh doing this, we lower the memory for each NPC under 50 kilobytes, which is 25% of the original size approximately.

[00:24:08]So, I just said that we removed the most of the behavior trees, but we kept some systems for the reaction. So, what do the far LOD NPCs do when they need to react to something?

[00:24:19]They don't have any perception uh because there's rarely something to perceive.

[00:24:25]Even if player does something and runs away, only a very small amount of the NPCs in the world have to react to that.

[00:24:31]So, it would be a waste of resources if we simulated that for all of the NPCs all the time.

[00:24:38]So, what we actually do is that we have a representation for the crime itself.

[00:24:42]Uh it's uh it's this uh thing we call percep- perceptible volume. So, if you for example kill some guards and the system you would run away and they would switch to the far LOD, there will be those uh those uh perceptible volumes that are representing the crime you did.

[00:25:04]And those perceptible volumes are actually actively searching for NPCs around them and forcing them to be switched into the middle LOD.

[00:25:14]Uh so the NPCs, then when they switch to the middle LOD, can simulate the crime fully. So even if you kill someone and hide the body and run far away, uh it actually matters how well you hid the body because all the crime resolution will get simulated.

[00:25:29]If you want to know more about uh perception or crime, I can recommend uh talk of my colleague to tomorrow, Design for Everything in KCD2 by Vadim Petrov.

[00:25:40]Okay. So uh the general thing to take away from this is that if you can make something passive in the far LOD, do it like this passively.

[00:25:50]Okay. Next part is the city of Kuttenberg, which was the ultimate bottleneck for everything we are doing in the game.

[00:25:57]So the challenge was to make the city look busy. We actually didn't know how many people are necessary for that or how many people we can support, but spoiler alert, it turned out to be 1,500 NPCs.

[00:26:10]And uh we definitely couldn't increase the budget of the 70 70 uh closest NPCs.

[00:26:18]Cuz uh we were actually happy that we didn't have to lower the budget because the city was so such a performance everything.

[00:26:26]Uh but as I already said, we could start designing the systems from the very get-go. It was a huge help cuz we could make it a white box of the city and we filled it with dummy NPCs, so we could see how many NPCs are actually visible, how lively it would probably look like, and the city was designed in a way so that not too many NPCs were necessary to be visible uh at the same time.

[00:26:55]So, what we did, we didn't do any long streets that would be busy with too many NPCs.

[00:27:00]Uh if you actually pay attention, you can see that we don't have any see-through fences in the city. They're all opaque walls.

[00:27:07]Uh if the player is walking the city walls, which is something we wanted him to be able to do, uh he can't see into some busy squares, and he could see a lot of space under the walls, but those are the places where we put way less NPCs.

[00:27:23]We also added some soft vision breakers breakers like uh carts of hay or some stalls with shopping.

[00:27:31]And of course, there are speed limits.

[00:27:32]You can't dash with the horse with the horse in the city.

[00:27:35]And that is not only because of the NPCs, but also because of the graphic, of the streaming.

[00:27:43]So, we already had the city with the structure, but we still had to somehow leverage it to some algorithm that would use this structure.

[00:27:53]So, what we came up with were visibility areas. So, we split the city into areas that were approximately 100 square meters, and we defined their relative visibility. So, here you can see the player is in the yellow area, and he can see into all of the green areas.

[00:28:12]Uh we couldn't use occlusion that's used in rendering because we needed to know a little bit in advance which NPCs will be visible because the switch is still not instantaneous. It needs at least like 1 to 2 seconds. So, occlusion wouldn't be sufficient.

[00:28:30]Also know that this uh these areas are used only for the switch between close and middle LOD because the far LOD is so far away that the structure doesn't uh no longer has uh the same meaning.

[00:28:43]Uh so, we can see as the player moves, the areas that are containing visible NPCs actually change.

[00:28:49]And here you can see the border of the area and when the NPCs move, they naturally switch into the correct level of detail.

[00:28:58]This is the bird's-eye view of the city.

[00:29:01]The player is in the middle and you can see the green cross there probably because he's currently standing staying at the crossroads so he can see into two streets, but uh many of the NPCs that are actually close can be switched to middle LOD because they can't be accessed just quickly.

[00:29:19]You can also see that the far LOD is way closer than normally and uh that's why we have uh the speed limit there and also the behaviors of the people in the city are carefully selected so they can start very quickly.

[00:29:36]And when we had those visibility areas, we actually use them at other locations.

[00:29:41]So on the left, that's the Sigismund army camp and on the right, that's the Rosty castle. There's way more areas than in the city, but they help still.

[00:29:50]Okay, so results for the city.

[00:29:52]We actually managed to have 1,500 NPCs uh and still run 60 FPS. That's because we just kept the budgets for the rest of the game. We just more uh appropriately selected which NPCs are in which LOD.

[00:30:08]The vision distances are actually quite low. They can be as low as 50 m, but that's where we add some soft vision breakers and we also don't pop the NPCs into existence right away. We differ them.

[00:30:21]So uh if they are for example at the 50 m and there's some visual obstruction like the uh stalls, it uh does it's not really noticeable.

[00:30:34]There is a funny thing uh that when we actually found out we can run those 1,500 NPCs, uh we hit the bottleneck of the environment let's say environment settling cuz all our NPCs have to live somewhere.

[00:30:48]They have to need a house with bed and we didn't have as many furnished houses.

[00:30:53]And the environment team was always strained and couldn't make more of them. So we actually had to cheat it a little bit. Uh the the NPCs some of them are actually living in the inaccessible houses.

[00:31:06]They get close to the door if the player doesn't look they teleport inside. They pretend they're sleeping and in the morning when players not close they teleport outside and continue their day normally.

[00:31:15]Okay.

[00:31:16]So we had this technology.

[00:31:19]We could simulate far away NPCs cheaply.

[00:31:22]And we apply it to more more more things that just the regular simulation.

[00:31:28]Our skip time is actually simulated. We don't just switch the time to correct time of day.

[00:31:34]We actually run the whole simulation.

[00:31:37]So if you for example do some crime or are in danger and you try to skip time uh you will be woken up interrupted and everything will have to be resolved.

[00:31:48]Although the quests will progress as they should if they have some time limit or some triggers.

[00:31:53]Uh so what we do we actually can switch way more NPCs to the more optimized LODs. You don't see any of them so there are no in close LODs.

[00:32:03]And uh only a few of them are in the middle LODs only those very close to the player.

[00:32:11]Uh very similar thing actually happens during the fast travel. We actually run the player through the road and uh he can meet people.

[00:32:21]So um if there would be for example encounter you would be traveling the world you'll meet some bandits they are too strong for you so you run away back and then you try to fast travel over them you cannot you'll be interrupted again by the very same bandits.

[00:32:36]The battles are something slightly different.

[00:32:39]Uh player actually cannot leave the battle area, at least not without a game over.

[00:32:44]So, um we can switch almost all of the world to the far LOD.

[00:32:50]And it is still simulated. So, if you do something just before a battle, uh you have to deal with it after battle.

[00:32:59]Uh for the uh for the soldiers in the battle themselves, they are actually very differently because the use case is very different.

[00:33:09]They don't have any behaviors they would have to choose.

[00:33:13]Uh they are just standing there waiting for their turn, and they are always visible.

[00:33:20]So, what we do, we don't use LODs for them. We actually simplified them in a different way. We have sprites for the very far away NPCs that can't be reached anyhow, and we have track view for the closer ones, but still unreachable.

[00:33:35]That's basically uh they are basically pre-recorded and playing uh something like a cutscene. If you hit them, they will switch and and uh play a death animation and die.

[00:33:47]And uh sometimes they they will switch naturally to the correct NPC, and they might get close to interact. So, player is now at the battlements. This NPC now switches to the full simulation, and he can be fought.

[00:34:04]Uh for the animals, I mean mainly wildlife, we actually don't use the LODs as well because uh they don't have any identity. If you hurt an animal, it runs away, it won't remember anything. We don't use them in the global quest logic. They don't have to be referenced, they don't have to be there. So, it would be actually completely unnecessary to simulate them. So, that's why we are normally spawning them uh when player gets close.

[00:34:32]That's actually halves the NPC number in our game, approximately.

[00:34:38]Okay.

[00:34:38]So, uh, the conclusion.

[00:34:42]Uh, it actually is possible to simulate the whole world.

[00:34:47]It could improve the immersion a lot.

[00:34:51]You can have way more detailed behaviors of the NPCs and better reactions, but if you want to do it, be prepared that it it's a lot of work.

[00:35:00]If you want to do it, the good place to start is, uh, knowing the NPC position.

[00:35:06]And if you want to know the NPC position, you'll probably need to know the NPC behavior and the constraints, but that's the very basic.

[00:35:13]If you can use threads, it probably won't be easy, but today computers have a lot of threads, so there is it would be waste to run everything on the main thread.

[00:35:24]Uh, a huge thing we did was we found a standardized logic in in, uh, script and we moved it to the code, which helped not only by speeding up the simulation, but, uh, the code also had way more knowledge about what is happening in the game and could do some other optimizations.

[00:35:42]And to the last, but not least, uh, it's important to set early limits for the systems and environment, like we did with the city.

[00:35:51]I know this is, uh, easier said than done, but, uh, I when I was talking actually that for the first game, we first did all the features and then we optimized. I was making a little bit fun of it, but it's actually not a bad way to do a game.

[00:36:08]Uh, the important thing is that, uh, you have to have a plan what you will do in the future with the optimizations. So, we actually even for the second game, we actually did all the features and then implemented this LOD system, but we from the very beginning of the development knew this system will be there and uh what are the limitations? So, a good analogy would be if you are borrowing a lot of money, you have to have a plan how you are going to pay them back.

[00:36:38]Uh this is actually our 10 years worth of work almost. So, uh I couldn't write all the people there. If you want to see all the people that worked on this, uh play the game, run the credits, they are there. But, uh just uh the ones that did most of the work on these very things I was talking about, some people from the code, and some people from the script.

[00:37:00]And that's actually it. So, uh feel free to ask any questions here on or during the uh during the rest of the uh event, or you can even shoot me an email.

[00:37:14]>> [applause]