Developing Multiplayer Games in Godot

0:00Multiplayer games are among the hardest software systems to build, requiring developers to synchronize state across unreliable networks while maintaining fairness, performance, performance, performance, performance, diversity, rating, performance, performance, tá? all introduce complexity that single-player games never encounter. Domekeeper is a minimalist tower defense game with roguelike elements where players must protect a fragile glass dome from relentless waves of alien attackers. The game was developed with the Godot engine and released in 2022. More recently, the development team embarked on the challenge of adding multiplayer to the game.

0:42Renee Haberman is the founder of BipinBits and the creator of Domekeeper. Chris Ridenor is the founder of KAR Games, which is a Godot-focused studio that developed Drift, Space Survival. Chris is now working with the Domekeeper team to bring multiplayer to the game. Renee and Chris join the show to talk about the origins of Domekeeper, developing the game, and the process of adding multiplayer to a Godot game. Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got his start in software development by creating mods and running servers for Garry's mod, and game development remains his favorite way to experience and explore new technologies and concepts.

1:41Rene, Chris, welcome to the show. Thanks for joining me today. Hello, thanks for having us. Hello, glad to be here. So let's kick off with, I guess, an introduction from you two folks. For anyone who's not familiar with your work, Rene, do you want to start us off? I did actually, once upon a time, study computer science and then work in IT. But my heart really lies in game development. So eventually, I always did this on the side while working in IT. Eventually, I made something that was at least impressive enough to publish our Raw Fury to fund the project, which is when I immediately left the IT industry and went making games full-time with the company I founded, PippinBits.

2:19We made the first game, Domekeeper was quite successful, and now we are working on some new titles. And the biggest one announced is PVKK, Planetenverteidigungskanonkommandant, which is a nice name for English-speaking people to pronounce. Yes, we'll probably get to talking about PVKK. I will not attempt to pronounce the full name. So I'm glad that we've got that in there at least once. Editors, you can just paste that over every time I say PVKK going forward. And Chris, how about you, Goose for Journey? Yeah, I spent about 10, 12 years in the startup world doing various startups as kind of founder and CTO, living in that like web world.

2:54But like Rene, my heart was really in games, doing it on the side. And a few years ago, decided to just make the jump into full-time indie. We have one game on early access called Drift Space Survival. But then I got a chance to work with Rene on the Domekeeper stuff and took the chance to help with that as well. Amazing. Yeah, that leads us very nicely into what we're here for today, which is you know don't keep it's been out since 2022 i'm a big fan and we've noted it as it's one of the godot hits which is always great to see but we wanted to put this podcast together particularly today thanks to your talk at godot congress which was revealing that you folks have been tackling what i think is quite an infamously cursed problem which is adding multiplayer to a game after the fact so before we get into that and all the hairy bits i guess we should talk about what domekeeper is renee do you want to kick us off on talking about what domekeeper is as a game and how it works yeah it's a rogue like it feels a little bit retro and the things it does do feel familiar like you mine down into this tile map at hell based map you find resources and bring them up to your dome with which you landed on the planet and from the resources you buy upgrades for your keeper so you can mine better carry more stuff but you also build up basically your defenses because you are attacked by monsters cyclically on this planet and that's basically the whole loop switching between this mining and combat maybe like one minute one and a half minute of mining and then 20 seconds of combat and it has sort of this nice ebb and flow where the combat is a short intense moment and then you get back to mining which is quite peaceful but you also know you need to be back in time and you need to find some resources otherwise you might not make it yeah i'm startled here you describe it as peaceful i always find the mining sequence like very race against the clock to get in as much as I can before getting back up.

4:39And so I know that Domekeeper came out in 2022, but what was the origins of Domekeeper? Where did it come from? In 2021, we participated in Ludum Dalve 48, which is a game gem. And it was our 10th time participating in that game gem. And the ninth game we made was sort of a smart game where I had this smart and fancy idea about the game design I wanted to try. And it did work out, but it's not like a lot of people enjoyed it or even were intrigued by the concept. And so we went into the next game jam going like, okay, let's make something very stupid, not innovative, and just do something that we know we can do and try to polish it.

5:18And the funny thing is, we took two parts that feel very familiar to anyone playing games. So it's very understandable. But in the combination, it still felt fresh to many people. So it wasn't as un-innovative as I thought. Yeah, and we kept working on the game in our free time because we noticed, okay, people are really digging this. We were working on a bigger project that we basically paused in favor of Domekeeper. And then it went quite quickly that the publisher, Raw Fury, was interested in this. We signed the deal and then spent only nine months in production. I released basically in 2022, and that's over three years ago.

5:55And during that time, we did continue to make content updates bigger and smaller ones. The last content update is over like one and a half years ago already now. Because like the big focus after that content update was really getting started on multiplayer. Yeah, which tells us something of the journey, I guess we're going to go on shortly. Before we get to that, so I played Donkey of the Year. It came out, I haven't touched it for a while and then jumped back in anticipation of this. I was quite surprised how much stuff had been added in the menu. now is like interactive and in the mind all kinds of neat things can you talk about like the things you've added and why you chose to add what content and where the expansions came from i guess yeah sure don't keep it as a roguelike it's very expandable in any case so that always made more sense like you can just add a new dome add a new keeper and that gives you like new toys to play around with but for me a key thing was that i had these nine months of production planned but then i I spent nearly half of that time basically for marketing stuff, for preparing a demo somewhere, for preparing an expo build.

6:54So what we released with was way less than I wanted to have in the game. Then I basically pushed the following years just to catch up and bring it to a level where I felt like, okay, this is close to what I had in mind in terms of variety and how varied the runs can be, but also how much you can replay it. And once that was kind of settled, where I felt like, okay, now it's in a good state. That's the time when for me, porting the game to console got relevant, but also doing the big final thing, which is multiplayer, because I thought about doing multiplayer earlier. But then I was like, okay, if we do it, basically, immediately after release, and we are thin on content, it's not super interesting as a mode, you can maybe get five hours out of this, and then multiplayer sort of starting to be slower.

7:40So I always wanted to add more content, make the best possible game first before we tackle multiplayer. Because my hope is that multiplayer really has this big impact and brings back a lot of people and also brings in a lot of new players just because of the promise of that. Awesome. Yeah, that makes sense. And then I guess the last question before we go to the multiplayer. So obviously I noted that Don't Keeper is Godot. Was it always like, was the Ludum Dare version of Godot? What led you to choose Godot? Yeah, I was, I think the first, six or five Ludumdach games I still made with like my previous tech stack, which was libgdx, which is basically a framework for making games in Java, which does sound strange.

8:22Like why would anyone want to do games in Java? And it's not a fully fledged engine. You don't have an editor or like anything visual. It's just a framework, but it was okay. But then I knew it was by that time, I think in 2017, just not the best tool to make games because I was seeing those fancy engines with editors and just making like, if you have a framework and you want to build an UI, you program a bit of the UI, launch the game and see if the UI is how you expected it is. And it never is. So you have to do that process like 20 times and then hope eventually you punch it into the right behavior.

8:59Compare that to making a UI in an engine editor. Like that's a whole different world. By then, I knew I wanted to switch, and I'm always a kind of late adopter. So I tried a few different engines. I booted up Unreal, Unity, and Godot. But Godot immediately clicked for me. It had this component system, basically. It's how it's structured with scenes and nodes. And you can compose nodes within nodes, under nodes. Each node can have a script. And that is incredibly powerful, because that's the huge thing about composition over inheritance. And Unity didn't have that. But Unity, it just had these prefabs, like you can pre-make a thing, but it didn't have the strong composition aspect.

9:38So I really loved that, how powerful it felt, how easy it was, how clean it felt, like you can compartmentalize features. Also, just how fast Godot was, like it boots up in two seconds. It's 100 megabyte large as executable that you download. It's not like eight gigabyte installer or something like that. And then you launch the game and the game is running in 300 milliseconds and not in like after compiling after 15 seconds or worse, something like that. There were so many things that I loved about Godot. And Godot was mostly good at 2D. It did have 3D capabilities, but those were not as advanced and not comparable to Unity or Unreal.

10:19But I wanted to make 2D games anyway. I think back then it was the best 2D engine, at least for me. and yeah i restarted with it and i never looked back i'm super happy with it still nice that's awesome and i guess it would have been 3.0 at the time yeah i think 3.2 something like that yeah awesome so chris i'm aware that you have so you know you mentioned your game drift and i believe there's a bit of a journey into how you came into this project with that right that you've got some multiplayer experience on godot through drift is that right correct yeah Yeah, so Drift was my first kind of commercial game project.

10:52So I decided to use the alpha version of Godot 4, make it 3D and multiplayer. So it was a lot of fun, but it ended up working out. And so, but I did obviously have to like pick up that like multiplayer mindset and have to like learn all the quirks of multiplayer specifically in Godot, which was really beneficial in this project as well. Nice, yeah. So I guess the alpha 4.0 at that point, I know there's some new multiplayer features in 4.0, but I've not done a whole bunch of multiplayer and good hosts. I'm not terribly clear on them. But I guess that you were dealing with features that weren't completely cooked as well at the time.

11:25Would that be accurate? Yes, I would say so. Yeah, it was worth it for a lot of the rendering improvements for 3D, like moving from OpenGL to Vulkan and the new multiplayer nodes in 4.0. They are so powerful for prototyping. They'd just be able to say, hey, I want to sync these properties between every client connected. And you just drop in that node in that composition way that renee mentioned you pick out which properties you want to sync and it just will automatically sync it across any node from and there's a the equivalent spawner is a hey anytime we spawn one of these spawn it on everybody they kind of break down i think in a lot of large scale projects so we end up not using them in the long term but in terms of just like getting things moving getting things out the door those nodes are really valuable awesome cool now i'm going to ask a series of questions that's probably awkward given that renee is here as someone coming in I think the setup's really cool.

12:15Like, you know, you've got two indie studios and one studio bringing someone in who's got expertise to help. I think that's just like a really refreshing way to see indie studios work together. It's super interesting. But I'm really interested in your perspective, Chris, as like someone coming into this hugely successful project from the outside to do what is already infamously a hard thing. What was that like stepping into the code base and stepping into Domekeeper? Oh man, yeah. So I never went super deep in the Domekeeper. So I did not realize the depth of content in there. like there was a little bit of regret like that first time I opened the project and like saw how many different gadgets and how many different like types of monsters there were and it's just like what have I done yeah I think I ran like one of those like lines of code and it was like 60 something thousand lines of GD script in the project and they had just transitioned from good 03 to good 04 and so you had like a lot of just cruft from from that as well but it was a lot but you know it was really interesting you could definitely tell in the code base that they had been trying to think about multiplayer from the get-go like in some of the data structures and things like that and like as you mentioned how the menu system you're now moving around the cave like that was done with multiplayer in mind so there are definitely some things there that kind of gave a launch board for us to kind of dive in but there's obviously a lot of things that just weren't designed with multiplayer mind with some of the data structures so right yeah so i guess Let's get into that.

13:39In an ideal, I think we could start in an ideal world. If you were designing these data structures in multiplayer mind, what does that look like? Like if you're approaching a multiplayer, if you were doing like a 2D Dome Keeper-esque game from scratch, what would be some of the design or architectural decisions that you think we're not here? So some of the biggest things, I'll take a step back because I think what was really difficult for me when I was getting into multiplayer networking and it's thinking about what you're actually sending back and forth because it really took a mental shift for me like coming from the web world which we all kind of did like especially from a back-end perspective I think about things in like a request response or when I'm on a front end everything's responding to an event now obviously some people like you know I have friends who used to work on rendering at Figma they had to think about like frames per second in the browser and things like that but we never really did it's from for most web developers but like in the game world you're thinking about what is happening every frame, the game engine asking 60 times a second, what am I drawing?

14:34Where is everyone? And so it's simulating this world that is finally ending up as pixels on your screen. And so for multiplayer, you now have two computers that we're trying to get to simulate the same world. And what we're trying to do is just send enough data between those computers that they end up with the same simulation. So with that in mind, things happen like physics simulation in Godot is not deterministic and it can't be based just with the way they've built the engine and so in Domekeeper when you're carrying iron and different resources those are physics objects and they're bouncing around and it makes it so much fun but it's impossible to get two computers to simulate that in the same exact way so then we end up in a situation where now we have one computer has to simulate everything and then send all of that data down to every single client And so those are the kind of decisions that like where things can't be deterministic just by their nature that make multiplayer really hard.

15:34But also it's why it's fun. Carrying resources, which normally isn't like something you think about as fun in a game, is actually fun in Domekeeper. You know, in a lot of cases, especially when you add a second player and then two people are trying to grab it and things like that. Like that is why that is so fun. But it also is a huge challenge for that reason. So if I had a magic wand, maybe I would have like had a separate physics system that was deterministic in Godot or something like that. But beyond that, it really comes down to some of these data structures. So like, how do we think about who's doing what?

16:05There's a lot of times where, before we even get into versus mode, but there's a lot of times even just in co-op where it kind of matters who's doing what and whether you're grabbing something, which keeper's doing that. There's a lot of things that just weren't in there across these systems because it was a single player game. Like you pick it up. You are you. You don't have to worry about anyone else. And so those sort of things can be really difficult. And so as we kind of like approach each system, obviously, since we're adapting a single player game, which kind of has like a right answer, which is like this is the game field.

16:38this is how the game played before. We kind of have to like break the system, break the data structures down and then rebuild the same features, which was probably still like 90 % code reuse, but build those same features back on top of these new data structures so that we can have multiple keepers. Or a big one is like we do things in a different order now. So there's a lot of times a lot of bugs as we go through QA where things break down because there was never imagined that this cave could come at a different stage. It could come after the player instead of before the player or things like that where there was just no defensive programming and there's really not in games because you don't have really time to do that.

17:19But you just, again, who's going to change the order of this and why? But yeah, all of a sudden now we're waiting on network packets to come in and decide when these things are happening. And so it's that ordering and things like that that kind of can really break down on us. Interesting. Okay, I'm realizing as you answer some things that it'd probably be useful for us to talk a bit about how multiplayer works from a gameplay perspective in Domekeeper before we get into something. So Rene, what is the game mode? How does it work? I guess you've still got, have you still got one dome, I guess is my fundamental question.

17:48Yeah, we went quite hard on what you can do in multiplayer. So you can play the normal game you always play just with a different person or multiple different persons. So they all get their own keeper, they get their own upgrades for the keeper, but you share upgrades for the dome, which already makes the upgrade system really complicated because you have all these different kind of types of upgrades and different ways to count stuff upgrade system is also the one that where there's this one function whenever we touch it we introduce three new bugs it's really bad so that's one thing you can also do like prestige runs that is like a high score attack with one other person but you also have a versus mode where you actually have two domes and two mines, one mine below each dome, but the mines are connected so we can reach each other and steal resources.

18:39And you can buy upgrades so the other team gets stronger waves. So you think about, okay, do I increase my mining and defense or do I really pressure the other team? Right. So that was the mode I was most excited about for multiplayer. But that's the second layer to it. You have local multiplayer, up to four players in split screen. But you also have online multiplayer where you can have more people. I'm not even sure if we have a strict limit right now, but eight players definitely works. I'd say eight. Yeah, I'd say eight. Officially, it's eight. Yeah, and you can also, it's one of the things I'm most doubtful about if it was a good decision or more like, I don't think I will ever decide the same thing again in the future for other games.

19:22You can also mix this. You can also have two local players playing online with three other people that are online. And this really, really makes stuff so complicated because the whole local co-op from a code perspective works so much different than online multiplayer. And now you have to mix this and also have it work in single player. And you also have teams suddenly where you not only like share one dome, but it could also be that the upgrades for a dome are also on the other team. So code-wise, it just exploded this sort of space or the state, how many different setups can you have? And that's really complicated.

20:00Yeah, it's really fascinating. And it's made me think of a question that I think to not jump the gun a bit. So I guess let's start with talking about how you approach this networking perspective. Are you doing this multi-players all peer-to-peer? That's not like a dedicated server setup? No. Okay, awesome. In mobile application security, good enough is a risk. GuardSquare uses advanced, multi-layered code hardening techniques and automated runtime application self-protection and mobile application security testing. combined with real-time threat monitoring to deliver the highest level of mobile app security.

20:35Discover how GuardSquare brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com. Most AI frameworks started with voice and bolted on video as an afterthought. Vision Agents by Stream was built video-first from day one. It's an open-source Python framework that lets you build real-time voice and video AI agents in minutes, not months. With 25-plus integrations for models like OpenAI, Gemini, and Claude, sub-500 millisecond latency on Stream's global edge network, and support for YOLO, Roboflow, and custom CV models, you get a production-ready stack without the infrastructure headache.

21:20Whether you're building coaching tools, multimodal assistance, or real-time security pipelines, Vision Agents handles the hard parts. Get started free at visionagents.ai. Yeah, so as we think about it, you can do like a LAN game and just play locally, which we use ENET under the hood for. You can do peer-to-peer, which is on Steam. We'll just use Steam's peer-to-peer system. Or we have a cross-play system, which makes sense as we, you know, Xbox just launched. And they're going to have cross-play with that. And that all goes through Microsoft PlayFab. So there's three different layers of networking on top of it as well, just to add more of the possibility space for bugs.

22:02Yeah, so I guess at least my question, which was, so from your Godocon talk, which is wonderful, highly recommend listeners go watch the talk. A lot of what you dealt with was, which we'll get into, is optimizing the bandwidth and how much data you're sending to represent the game state. How does that work when you've got multiple keepers locally? Because then that's obviously, surely that's so much more data that you need to send to the online player. so i would say the majority of the bandwidth optimization we had to do was in all with the resources because when you think about like even if you came into the game with four local keepers that's you only have four people moving around like that's where you get into trouble is like how often do you have to send these updates because that's really going to impact your bandwidth so like moving and keep around we want to send as many packets as possible as fast as we can just to keep that smooth and keep it feeling like that person is really playing next to you But the keepers, let's say you have four keepers.

22:55Well, the same thing applies to the resources. And so if four of you are then carrying eight resources, that's usually where we get into trouble and having to send those 32 resources and things like that. So all of the, especially in the talk, I talk about how we went from like descending naive data structures to going down to individual bytes. And then we're now at the individual bit level thinking about like, well, I only need a six bit integer to really represent all the positions this thing could be in. And then you can start to pack those together into we get it down to like two 64 bit integers for each resource.

23:29And then we pack all the rotation data, the location, who's carrying it, all those things down into that. and that has really helped into because before I say like eight is like probably really where we're still going to max out because that's really when like you have to have a really strong host sending a lot of data to everyone because it's going to have to calculate and send the data for every resource that someone's carrying at the time if no one's carrying it it goes to sleep and we don't send data about it but that can really just start to bloom really quickly and so for each person you add you're adding more things that could be carried you're adding more people you need to send that much bandwidth to and so yeah that gets out of hand really quickly right yeah that makes sense so i guess also these people are so that's the resources how does it work on the monster phase because you can have a lot of projectiles and all kinds of stuff flying around at that phase yeah so with monsters we were actually luck i don't know if lucky oh we'll say lucky a lot of what the monsters do end up being pretty deterministic or it could be So, one thing we do is when the monsters are generated, we send their kind of UID with them, their unique ID, and we use that to seed a random number generator on everyone's client so that their behavior is kind of mapped out from the moment they're spawned.

24:42And then everyone can respond to the events of like the monster getting hit. But the monsters end up being very event-based, which is really thankful because if we had to sync positions of reframe for monsters and projectiles and things like that, it would end up in a really bad place. But yeah, the monsters, like when they shoot, it's kind of predetermined. And even if it's not, we still send a packet when they shoot anyways, just to make it's kind of like a chance to catch up. And so we have a lot of these full sync check ins for monsters just to make sure that if someone's running a few frames behind or just generally running a lower frame rate, we're just making sure that they catch up and hit things in the right order.

25:15But generally, that's more of like an oh no rather than a requirement. But yeah, the monsters end up being pretty deterministic. and we're in a lucky case where, and I talk about this in the talk a bit, but like even when you're playing versus or the leaderboard prestige, we made a decision at the beginning of this project that we're going to trust the clients. Like if a client says, hey, my laser just hit this monster and it took damage and maybe the server is like a little bit, a couple of degrees off, it doesn't agree, but we're just going to trust that the client made that damage because if you start treating the clients as kind of adversarial, that's when you absolutely need dedicated servers and then our cost balloon.

25:55And it just doesn't really make sense for this game, this type of community. It's not that competitive of a community. So I think that for this game, this player base, it made a lot of sense to like, it's friendly. Even when it's not friendly, it's friendly. If you have friends who want to cheat, then you should talk to your friends. Even before Multiplayer, we decided to not have the sort of public lobbies where you play with random people. so instead you do play with your steam friends which really takes off the pressure of kind of okay now you have to prevent cheating because yeah if your friend is cheating yeah you will call him or punch him when you see him the next time i'm not sure i think that was also just like a mandatory thing to decide to even attempt to do this because like the super tricky stuff is okay if this needs to be like server authoritative i don't think it would have worked to like ham on us into the existing single player game yeah yeah that's a whole different set of challenges we had a great episode with gabriel ages ago listeners go check out the real-time multiplayer conversation with gabriel to learn about several fordative stuff when i saw you talk about the friendliness and now knowing there's a prestige mode because i don't think that you'd mentioned that in your talk that is really interesting because i know that you've obviously what i was like poking about the menu i saw the big warning next to prestige mode about people using like you know cheating and keep an eye on it so i guess so you just you're just like yeah it is what it is for the multiplayer or that's another thing i will never do again yeah like a public leaderboard with global high scores the only thing i will do in the future is high scores among your friends because we always have cheaters i ban people sometimes and then it's okay but there's an just this infinite amount of people coming back as cheaters and it's like the effort to maintain this and just keep it roughly fair is stupid or it's not fun and we do have like the prestige players are hyper competitive and they really take that serious and we had people do like 10 hour runs although the game is like more structured towards like one to two hour runs and they would do endless grinds in those in those 10 hours but it's only like this tiny fraction like the 100 200 people in the world who really compete on this but it's a lot of work yeah and for multiplayer yeah it's not getting better yeah i mean i guess that was and i know this was a factor in your choice technology but that was one of the things that was really interesting i think especially coming from you know an indie project obviously it's been a very successful indie project but still an indie project and there's so much discourse now about what happens to the multiplayer elements of games like after the company has moved on how did you know i guess the economic constraints factor into the technical decisions for you folks with choosing how you're going to set things up for me it was mostly about i mean multiplayer has this big potential as i said like bringing in a lot of new players and old players so there's definitely a reason to do this kind of big investment in development i think that makes sense at the same time we cannot do this like high server cost where we would need to monetize the people that keep playing in some way that's really the reason to go peer-to-peer and now it's more like hoping that our playfab bill is not it's not exploding luckily for example the people playing on steam together steam is not charging for their services it's within the fee they get anyway for from sales so that's generally fine i don't think there are really like complicated economic calculations going into this it's a premium game in the sense that you buy it and then you own it and then you can play it forever for free and you don't need to do more but that restricts what we can do also so i guess you incur play for bill is that only cross player is that also like if a console player plays for console player i think it's anytime it leaves the xbox network so xbox xbox is free but any sort of cross play will incur interesting okay cool yeah so to go back a bit chris you mentioned that you found some of godos and built multiplayer stuff didn't scale when you built your own can you talk to us about that what challenges do you face and where did you have to find new solutions yeah godot it's really interesting they have their kind of like high level networking but Godot doesn't really prescribe anything.

29:59Like you don't actually even have to use the high level networking or the multiplayer peer system that they have if you want to use like they're kind of like built-in RPCs. There's nothing stopping you from just making your own just network library in GDScript or C++ or C Sharp. And so I appreciated that. But what I did like about the built-in high level networking is that it'll let you just, it kind of highlights when you actually have an issue. So like one of the things in Godot is if you have an object in the scene tree and you want to call a remote procedural call an RPC on other clients, that object has to exist on everyone's computer or on everyone's simulation.

30:36They need to have the same object at the same place in the scene tree. And that kind of throws a lot of people for a loop. And it threw me for a loop a lot of times because like, well, it doesn't exist yet. But then the question is, well, if it doesn't exist yet, why are you actually trying to call this on it? Like you're highlighting an ordering issue, a race condition that you may not had to think about otherwise. Otherwise, you might just be sending packets to people who don't know about it or aren't ready for that packet. And so I think you can end up in a lot of bad situations if you're just kind of like naively sending packets about everything to everyone and let them kind of figure it out.

31:06So the high level networking in your dough kind of forces you to think about ordering and think about when you're doing things, why you're doing things, who's ready for what, especially for with Domekeeper and same with my other game Drift, it was drop in, drop out. So you might have people at different stages of the simulation. They might be loading, they might be currently spawning the Keeper, or maybe they're ready for everything. And so one of the things we did specifically in DomeKeeper is kind of create our own kind of like network state manager for each client. And everything that talks to the network in DomeKeeper recognizes this and only sends these packets to people who are in the correct state for that.

31:42And it lets us avoid just a ton of different race conditions. Not that we have none because we still have them all the time. But it does let us think about like, OK, this person is still in the loading screen or this person is currently spawning the keepers. So we shouldn't be berating them with a bunch of different packets, maybe about resources and things like that. So you mentioned the drop in, drop out. That was really interesting. And I thought how you how you got into the mechanics complexity that talk was really fascinating. One of the questions I had was what the design intention was. So is that just if like basically were you seeing drop in drop out as like, you know, oh, I've disconnected and need to reconnect?

32:17Or is it truly like, hey, I've seen that my friend's playing Domekeeper. I want to jump into that session midway or which way around was it? We had talked about both. We ended up just for for game design reasons. It's more of I want to reconnect after I've dropped out because from a technical perspective, it's both. But it makes it really difficult of like, are you scaling the whole game when a new person joins in? and there's just some considerations yeah it makes it really difficult i think you could definitely get there but i don't know that it was worth you know the juice wasn't worth the squeeze you know like i don't know how often that's really happening to really have this whole very dynamic difficulty system that kind of can flex up and down when most people are just want to get together and do a run together you know it's not like a 60 hour run it's you know it's one gameplay session for most people so yeah absolutely yeah that's what came to mind especially when you're talking about how it worked earlier, Rene, when you, you know, individual upgrades, I was like, okay, someone's going to come in, stack all the individual upgrades and leave.