Developing Multiplayer Games in Godot

Multiplayer games are among the hardest software systems to build, requiring developers to synchronize state across unreliable networks while maintaining fairness, performance, and a responsive player experience. Latency, cheating, server costs, and debugging distributed game logic all introduce complexity that single-player games never encounter. Dome Keeper 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. René Habermann https://x.com/Bippinbits is the founder of Bippinbits https://bippinbits.com/ and the creator of Dome Keeper. Chris Ridenour https://x.com/cridenour is the founder of KAR Games https://kargam.es/, which is Godot focused studio that developed Drift: Space Survival. Chris is now working with the Dome Keeper team to bring multiplayer to the game. René and Chris join the show to talk about the origins of Dome Keeper, 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. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/06/SED1903-Dome-Keeper-1.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Developing Multiplayer Games in Godot https://softwareengineeringdaily.com/podcasts/developing-multiplayer-games-in-godot/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Multiplayer games are among the hardest software systems to build, requiring developers to synchronize state across unreliable networks while maintaining fairness, performance, and a responsive player experience. Latency, cheating, server costs, and debugging distributed game logic all introduce complexity that single-player games never encounter. Dome Keeper is a minimalist tower defense game with rogue-like 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. Rene Haberman is the founder of BipinBits

• 0:45Speaker 00

  and the creator of Dome Keeper. Chris Ridenour is the founder of KAR Games, which is a Godot-focused studio that developed Drift: Space Survival. Chris is now working with the Dome Keeper team to bring multiplayer to the game. Rene and Chris join the show to talk about the origins of Dome Keeper, 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 a start in software development by creating mods and running servers for Gary's mod. End-game development remains his favorite way to experience and explore new technologies and concepts.

• 1:41Speaker 01

  Rene, Chris, welcome to the show. Thanks for joining me today.

• 1:44Speaker 02

  Hello, thanks for having us. Hello, glad to be here.

• 1:47Speaker 01

  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?

• 1:53Speaker 02

  I did actually, once upon a time, study computer science and then work in IT, but my heart truly 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 a publisher, 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, BipinBits. We made the first game, Dome Keeper, was quite successful, and now we are working on some new titles. And the biggest one announced is PBKK, Planet Verteidigungskanon Kommandant. Which is a nice name for English speaking people to pronounce.

• 2:33Speaker 01

  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? What's your journey?

• 2:45Speaker 03

  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. But 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 Dome Keeper stuff and took the chance to help with that as well.

• 3:11Speaker 01

  Amazing. Yeah, that leads us very nicely into what we're here for today, which is, you know, Dome Keeper'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 Dome Keeper is. Rene, do you want to kick off on talking about what Dome Keeper is as a game and how it works?

• 3:41Speaker 02

  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, a tile-based map, where 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.

• 4:24Speaker 02

  But you also know you need to be back in time and you need to find some resources, otherwise you might not make it.

• 4:31Speaker 01

  Yeah, I'm startled to hear 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. And so I know that Dome Keeper came out in 2022, but what was the origins of Dome Keeper? Where did it come from?

• 4:43Speaker 02

  In 2021, we participated in Ludum Dava 48, which is a game jam. And it was our 10th time participating in that game jam. 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. And the funny thing is, we took two parts that feel very familiar to anyone playing games, so it's very understandable.

• 5:25Speaker 02

  But in the combination, it still felt fresh to many people, so it wasn't as un-innovative as I had thought. Yeah, 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 Dome Keeper. And then it went quite quickly that the publisher, Raw Fury, was interested in this. We signed a deal and then spent only nine months in production. I released basically in 2022 and that's over three years ago. And 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.

• 6:11Speaker 01

  Yeah, which tells us something of the journey, I guess we're gonna go on shortly.

• 6:13Speaker 02

  Yeah.

• 6:14Speaker 01

  Before we get to that, so I played Dome Keeper 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?

• 6:31Speaker 02

  Yeah, sure. Dome Keeper as a rogue-like is 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 spent nearly half of that time basically for marketing stuff, for preparing a demo somewhere, for preparing an expo build. So 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.

• 7:12Speaker 02

  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 is sort of starting to be slower. So 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 other promise of that.

• 7:56Speaker 01

  Awesome. Yeah, that makes sense. And then I guess last question before we go into multiplayer. So obviously I noted that Don't Keep It's Godot. Was it always like, when was the Ludum Dare version of Godot? What led you to choose Godot?

• 8:06Speaker 02

  Yeah. I was, I think the first six or five Ludum Dare 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, like 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 a UI, you program a bit of the UI, launch the game and see if the UI is how you expected it is.

• 8:51Speaker 02

  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. Compare 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 put it 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 like composition over inheritance.

• 9:31Speaker 02

  And Unity didn't have that. Unity had just had these prefabs, like you can pre-make a thing, but it didn't have the strong composition aspect. So 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 an 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.

• 10:10Speaker 02

  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. But I wanted to make 2D games anyway. I think back then it was the best 2D engine, at least for me. And yeah, we started with it and I never looked back. I'm super happy with it still.

• 10:29Speaker 01

  Nice. That's awesome. And I guess it would have been 3.0 at the time.

• 10:32Speaker 02

  Yeah, I think 3.2, something like that. Yeah.

• 10:36Speaker 01

  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?

• 10:48Speaker 03

  Correct. Yeah. So Drift was my first kind of commercial game project. So I decided to use the alpha version of Godot for 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.

• 11:13Speaker 01

  Nice. Yeah. So I guess the alpha 4.0 at that point, I know there's, there's some new multiplayer features in 4.0, but I've not done a whole bunch of multiplayer in Godot. So 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. Would that be accurate?

• 11:26Speaker 03

  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, they are so powerful for prototyping. They 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.

• 12:09Speaker 01

  Awesome. Cool. Now I'm going to ask a series of questions. It's probably awkward, given that Renee is here. As someone coming in, like, I think the setup's really cool. Like, 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 codebase and stepping into Dome Keeper?

• 12:34Speaker 03

  Oh, man. Yeah. So I never went super deep in the Dome Keeper. 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, um, 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 Godot 3 to Godot 4. 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 codebase that they had been trying to think about multiplayer from the get-go. Like, in some

• 13:18Speaker 03

  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 mind. So there are definitely some things there that kind of gave a launchboard 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.

• 13:35Speaker 01

  Right. Yeah. So I guess let's get into. That in an idea, I think if 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 Domekeeper-esque game from scratch, what would be some of the design or architectural decisions that you think were not here?

• 13:53Speaker 03

  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. Cause it really took a mental shift for me, like coming from the web world, which we all kind of did, like especially from a backend 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. 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? Where is everyone?

• 14:36Speaker 03

  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 were 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.

• 15:16Speaker 03

  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. But also it's why that'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 determined to sick and good though,

• 15:58Speaker 03

  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? There'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, witch keepers 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. This is how the game played before.

• 16:40Speaker 03

  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. But and you just, why again, who's going to change the order of this and why?

• 17:23Speaker 03

  But yeah, and also 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.

• 17:31Speaker 01

  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 and dome keeper before we get into some of the other. So Rene, what is the game mode? How does it work? I guess you've still got, if you've still got one dome, I guess is my fundamental question.

• 17:47Speaker 02

  Yeah, 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.

• 18:07Speaker 03

  Yeah.

• 18:08Speaker 02

  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 just 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 you can reach each other and steal resources. And you can buy upgrades, so the other team gets stronger waves. So you think about, okay, do I increase my mining in defense? Or do I really like pressure the other team?

• 18:50Speaker 03

  Right.

• 18:50Speaker 02

  So that was the mode I was most excited about for multiplayer. But there's a 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, eight players definitely works.

• 19:10Speaker 03

  Let's say eight, yeah.

• 19:11Speaker 02

  Yeah, let's say it 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. You 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.

• 19:52Speaker 02

  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:00Speaker 01

  Yeah, that's really fascinating. And I, 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 multiplayer peer to peer? That's not, you're not going like a dedicated server setup?

• 20:13Speaker 03

  No.

• 20:14Speaker 01

  Okay, awesome.

• 20:14Speaker 03

  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.

• 20:43Speaker 01

  Yes, I guess at least my question, which was, so from your Godotcon 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 some like multiple keepers locally? Because then that's obviously, surely that's so much more data that you need to send to the online player.

• 21:05Speaker 03

  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 troubles. Like, how often do you have to send these updates? Because that's really going to impact your bandwidth. So like, moving a keeper 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, well, 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

• 21:48Speaker 03

  in the talk, I talk about how we went from like just sending 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. When we pack all the rotation data, the location, who's carrying and 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. Cause 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 that data for every resource that someone's carrying at the time.

• 22:32Speaker 03

  If no one's carrying it, it goes asleep and we don't send data about it, but that can really just start to balloon 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.

• 22:48Speaker 01

  Right. Yeah, that makes sense. So I guess also these, so that's the resources. How does it work on the monster phase? Cause you can have a lot of projectiles and all kinds of stuff flying around at that phase.

• 22:59Speaker 03

  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. And 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 have, we had to sync positions every frame 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.

• 23:41Speaker 03

  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. But generally that's more of like a, 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 talked 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

• 24:27Speaker 03

  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 and it just doesn't really make sense for this game. This, you know, 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.

• 24:56Speaker 02

  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, you will call him or punish 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 hammer this into the existing single player game.

• 25:33Speaker 01

  Yeah, yeah, it'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 server authoritative 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, when 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 you're just, you're just like, eh, it is what it is for the multiplayer or?

• 26:00Speaker 02

  That's another thing I will never do again. 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 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. 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.

• 26:42Speaker 02

  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.

• 26:51Speaker 01

  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?

• 27:14Speaker 02

  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 play费bill is 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 from sales. So that's generally fine. I don't think there are really like complicated economic calculations going into this.

• 27:59Speaker 02

  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.

• 28:07Speaker 01

  So I guess you incur play费bill. Is that only cross player? Or is that also like if a console player plays for a console player?

• 28:14Speaker 03

  I think it's any time it leaves the Xbox network. So Xbox, Xbox is free, but any sort of cross play will incur.

• 28:21Speaker 01

  Interesting. Okay, cool.

• 28:22Speaker 03

  Yeah.

• 28:23Speaker 01

  So to go back a bit, Chris, you mentioned that you found some of Godot's and built multiplayer stuff didn't disco and 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?

• 28:34Speaker 03

  Yeah, Godot, it's really interesting. They have their kind of like high level networking, but Godot doesn't really prescribe anything. Like, 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 their kind of like built in RPCs, there's nothing stopping you from just making your own just network library in JavaScript or C++ or C#. 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

• 29:17Speaker 03

  or on everyone's simulation. They 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. And 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 have 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. So the high level networking in Godot 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 Dome Keeper and same with my other game, Drift, it was drop in dropout.

• 30:00Speaker 03

  So you might have people at different stages of the simulation. They might be loading, they might be currently spawning the keeper, but or maybe they're ready for everything. And so one of the things we did specifically in Dome Keeper is kind of create our own kind of like network state manager for each client. And everything that talks to the network in Dome Keeper recognizes this and only sends these packets to people who are in their correct state for that. And it's a let's just 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, okay, 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.

• 30:42Speaker 01

  So you've mentioned the drop in dropout. That was really interesting. And I thought how you how you got into the mechanics and complexity of that and 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 dropout as like, you know, oh, I've disconnected and need to reconnect? Or is it truly like, hey, I've seen that my friend's playing Dome Keeper. I want to jump into that session midway? Or which way around was it?

• 31:06Speaker 03

  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 it would have, 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.

• 31:45Speaker 01

  Yeah, absolutely. Yeah, that's what came to mind, especially when you were talking about how it worked earlier, Rene, when you, you know, individual upgrades. My, I was like, okay, someone's going to come in, stack all the individual upgrades and then leave. What happens at that point? So I guess one question I had for you, Rene, about, you know, this new loop. So obviously, as we kind of spoke about at the beginning, a big part of the single player experience is balancing the the mont, I keep wanting to say day night cycle, but I guess that's not accurate, but the monster mining cycle. Well, you've got multiple players and obviously you want to go up the dome. That feels like it fundamentally changes that. How do you see that working?

• 32:13Speaker 02

  The most difficult thing that we cannot really get around is normal single player. You go into the upgrade menu and you have this big, big list of upgrades. And the game pauses while you are in this upgrade menu. In multiplayer, it's not very fun if you play with seven people and every time one person is in the upgrade menu, the game pauses for everyone. So the game kind of needs to keep running, which has this balancing impact already. And also it's a little bit of tension. So it's, I guess it's it's harder definitely if you play for the first time and never have seen the upgrades. So that's one thing where we need to compensate a little bit. So the the cycles are just a little bit longer to make room for the game not being paused.

• 32:54Speaker 02

  At the same time, with two people, you are so much faster with with mining that you don't need to like scale one to one with the pause, for example. And generally, it's mostly down to how fast the monsters scale. So depending on the amount of players on a team, you get stronger monsters. It's definitely tricky to get right, because in a single player game, you have this variety on how the run can go. But now, if you have two people, it's basically kind of multiplied, because if you have two excellent people, it's multiplicative in some way. So they would need a way harder difficulty than two very weak players. It's a bit tricky and we're still playtesting, getting feedback and then tuning accordingly.

• 33:38Speaker 02

  The the balance is really key to get it right. If it's too hard, it's no fun, because you just die. But if it's too easy, you don't feel the pressure of the like this time pressure. And then, without any of the pressure, it's just work, basically. It's more of a chore. You might still enjoy the chore, like some people do do that. Some people mine like every tile there is in the whole mine. But generally, you need this bit of pressure for it to stay fun for most people.

• 34:06Speaker 01

  Yeah, that makes sense. And yeah, on the topic of the mining game, is it the same map settings? It makes me think that the maps probably need to be bigger for an A play game mode, or is it just shorter sessions?

• 34:15Speaker 02

  Yeah, that's a good question. We haven't actually like made the maps bigger in general, which just means if we have these missions in Domekeeper. So if if you go on the same mission, you will just be able to do it more quickly if you achieve it. But also, I mean, the monsters are still scaling up. Generally, it comes back to the same question about joining. So you start with two people, then two people join. Should the mine? The mine cannot expand anymore.

• 34:43Speaker 01

  Yeah, of course, yeah.

• 34:44Speaker 02

  It might be something that we also find during a future playtest. We still have like the ability to change map sizes. I I haven't yet changed it, actually.

• 34:54Speaker 01

  Cool. So I guess zooming out from Dome Keeper a little bit. One of the questions that this raises for me is, you know, if you were, well, I mean, obviously you are doing, again, you've got multiple games in development. But you know, if you were to do this again, would this experience of having added multiplayer on later change the way you design games in the future? Or is it working out well and you would, you know, the vision worked? How would you approach this?

• 35:17Speaker 02

  Looking back, it really is kind of a budget and validation constraint. So if I don't know if I have a game that works and that has optional multiplayer, do I really want to spend half a year longer or maybe more on the game? Before I get kind of this validation, okay, there's a market for this game, people want to play this. And with Dome Keeper, it was much in that way that we just wanted to make this game as quickly as possible. It works without multiplayer. And then I think it was the right decision. And then it's more about, okay, how much trust do we have in the new game? And how complicated is it? Or is maybe multiplayer prerequisite to the game existing?

• 35:56Speaker 02

  And now that we had our first success, it becomes a little bit easier to also take a little bit longer before needing to validate. But still, if you make five games and they all take half a year and none of it ever works out, even with success, full game out, you still go bankrupt eventually. So it's still smarter not overdo this, like not to spend too much time in a thing you don't know if, if anyone wants to play it. Yeah, but generally I like multiplayer a lot, but it really needs to be a thing for me that is essential to, maybe not essential, but really elevates the game. There needs to be this huge benefit from it. And I'm also more looking towards, okay, what are cheap ways to do multiplayer?

• 36:36Speaker 02

  It doesn't need to be always the real time, shared world, stutter free thing. Sometimes it can be an async multiplayer of some kind that, that still elevates the experience and is way easier to do.

• 36:48Speaker 01

  Yeah, when you said earlier about doing the friends only prestige mode that immediately, well, like where, you know, friends only prestige scoreboard, that immediately made me think of the Saxtronics games. I don't know if you've played any of those, but I think that's a really good example of like a game that feels like it's got multiplayer. When really it's just like, you know, that casual scoreboard on, but you see your friends optimizing against challenges. And you're like, oh, I now need to go compete with them. Right. And it's like, not, not actually playing the same session, but like, it feels like a collaborative experience. And what I imagine is a very cheap and cost effective way. Um, so yeah, it's a really interesting point. Oh yeah. So you've already mentioned it already, you know, you've been working on the last update was a year, two, year and a half. And obviously now you've been working multiplayer for a while and you're in the QA phase currently, is that correct?

• 37:29Speaker 01

  Bashing bugs. Yeah. Cool. How, what is your QA process? Is it just getting a bunch of people in the game and hashing it out? Cause I, you know, as complex and, you know, a many headed Hydra that multiplayer is, I imagine it must be hard to even design a process where you can hunt down some of these edge cases, right? Like, how do you approach multiplayer testing, Chris?

• 37:50Speaker 03

  Well, luckily we have a fantastic QA team through Raw Fury that knew the game really well coming in, which was really beneficial for me. Because there are things that I would break that I didn't even know were in the game, especially when coming in. And so it kind of gave me a lot of liberty to come in and make the changes and, you know, obviously do some surface testing and make sure I didn't completely break the build. But otherwise kind of put that out there and, uh, and they were able to kind of dive in and really find these edge cases and put that together. And so it's been really nice. We've had a public play test now in the Discord where people can come in and kind of find more of those cases. So definitely some of the more hardcore players who have very specific things they're looking for have definitely told us where we've gone wrong.

• 38:33Speaker 03

  And a lot of the technology behind the multiplayer build is actually behind the console build as well. So with Xbox out there, you know, we're still getting more feedback and more testing underneath changes to the game that are giving us a lot of confidence for this as well. So.

• 38:46Speaker 02

  I think the testing process is not very different to before. It's just like the QA of all is like five times as high. Because you have all these scenarios you need to cover and you can have stuff that works perfectly fine in co-op and works perfectly fine in online multiplayer. But it breaks in single player. So you cannot make assumptions about, okay, if it works here, it also works on the other bit.

• 39:09Speaker 03

  Yeah, testing with multiplayer when you're developing is actually something where Godot really shines. One thing you can do is on, I think, 4.2 and later, you can go down to the debug menu and tell it to launch multiple instances. And you can use kind of launch arguments to make them automatically connect to each other. And so when I hit play in Godot, I have two or sometimes four windows pop up. They automatically connect to each other. We're just dropped right into a game and they're all connected to the debugger. And so when I'm testing something, I can hit pause, everything will pause. I can dive into the scene tree of the specific instance that I'm looking forward to figure out what's going on. And so that has been just so powerful compared to like trying to do multiplayer on Unity or Unreal,

• 39:54Speaker 03

  where you kind of have like one that's running outside of the editor environment and then one that's inside and you have to like, oh, is this a host problem, a client problem? With Godot, you just kind of get all of that right for free. And so since we have that like E-NET, we can run it all locally, connect to each other. But then obviously we then move to Steam. Testing Steam multiplayer is very difficult. You need two Steam accounts, you need two physical computers, unless you're doing some VMs or sandboxing or whatnot. But even then, you're still not, you know, attached to debugger and everything like that. So we try and do as much as we can locally. And then once we're going, then we luckily, we have QA, but other people, that's when you annoy your friends, is when you just want to test the kind of like the Steam specific stuff.

• 40:35Speaker 01

  Yeah. Yeah, the breaking things in single player is really disappointing. I'm trying to remember which game it was, it was a pass guess, but we had a game at one point where their multiplayer was a completely separate build and they added multiplayer on. But it was like, you know, none of those changes are made about the single player. And I guess that's the main issue, main issue you avoid if you're doing that, aside from the fact that it's a nightmare to maintain forevermore. Yeah, really interesting.

• 40:57Speaker 02

  That's another reason why we put multiplayer and console reporting until after we were done with making content, because making content in that setup suddenly is so much. Slower and more complicated.

• 41:08Speaker 01

  Yeah, that was the when you mentioned the physics objects being the the main constraint. I was immediately imagining if you had built this all out before you added the accessory, you know, like the the gravity slinging things and how that would probably break a lot of assumptions made of just the engineer. Yeah, cool. So I know we're running close on time. So before we run out of time, I do obviously have to ask about PVKK, which I think a lot of folks are waiting with bated breath for. My first question is honestly, what is it about bunkers being in a bunker that's appealing to you as a game designer?

• 41:41Speaker 02

  The pragmatic answer is that limiting your game to a single room means you can make that room really nice. It's a smart decision in production. Like, that's a thing. But also, it's part of the fantasy and this appeal. And we also play with it narratively in that you are confined to this bunker. So it's basically a point in the narrative that you are essentially a prisoner. And that's so interesting in itself, maybe more interesting than if you would be free to leave and we can explore the whole facility, something like that.

• 42:11Speaker 01

  Yeah, cool. And then tech wise, so obviously we spoke about you chose Godot for its its 2D capabilities. Is PVKK, I mean, it looks very shiny. Is it a Godot game or you moved over to a different engine? Awesome.

• 42:22Speaker 02

  Yeah, it's in Godot. I think so. We could not have made it in Godot 3. So it's it's something enabled by this huge push by the thousands of people working on Godot to make Godot 4 like a more capable 3D engine. Then it's already down to, okay, who's working on the game? What's their eye for beautiful things and what can they do? And of course, it looks different than an Unreal game or something like that. But it still looks nice enough that as a player, you can be happy with it and enjoy the graphics, I think.

• 42:53Speaker 01

  Yeah, no, I think it looks incredible. I saw a comment recently, someone who had seen the trailer was like, is this real? This looks like a render. This just looks really good. And I was like, yeah, I'm pretty sure it's real. It looks good. It's like, cool. Awesome. Obviously, I desperately want to ask when we can play it, but I was just asking the cursed questions. And I guess the next additional thing I was gonna ask is about, this is somewhat not related to the game, but as someone who was playing Xbox during the Steel Battalion era, obviously I was very excited by the huge control that you took to, was it Gamescom?

• 43:23Speaker 02

  Oh, yeah. Yeah, it was at Gamescom. It was in Tokyo Games Show and in TwitchCon San Diego.

• 43:29Speaker 01

  How did you go about, like, what was the development process for that? When you first thought of the game, you were like, okay, we need to build the bunker, or is this something that came out just planning for booths?

• 43:37Speaker 02

  I think during the development, this idea of making something physical popped up like 20 times independently of each other. It kind of is, is a natural thought, like, okay, you have this very hectic tactile feel in the bunker. Could you have a controller for that? And also, a lot of people are still like fans of Steel Battalion, like the Steel Battalion controller. So we always maintained the thought a little bit, and then towards Gamescom, after we signed with Kepler, we suddenly had this, it was a little bit of a, yeah, out there idea to actually build something significant. And not just like the single red button you press to fire the cannon, but the whole big station.

• 44:16Speaker 02

  And with the help of Kepler, like, it was possible for us. I don't, I don't think we would have taken the investment alone to do this, because it's, if you only build a single one of a new thing, like, you take the price for the single thing is very high. Like, if Ford wants to build a new car and they only build a single car of their own model, it will be a very expensive car. We were looking for partners to do this, because at PIP and BID, we're not like electric engineers. Some of us can do some things, but not in that, like, full-fledged vision. We got a few concepts from different people. Some were a little bit underwhelming, where it's more like, okay, you have a gorge, but it's actually just printed on the panel. It's not real. And for me, the fantasy of PPK is really like that everything is real.

• 45:02Speaker 02

  And then eventually we found with Mother Ultimate and Throw Switches, we found a partner to build it. We still needed to do a lot of integration work, like, the game needs to run on this thing, then it's not a, it's not a given. But it was quite crazy. How it came out was really a highlight, I think, for many people, how much they got out of this. And the same for us. It's incredibly fun to play.

• 45:24Speaker 01

  I hope after at least it ends up installed somewhere where people can, I would definitely travel for the experience. Well, I know we're running out of time. Chris Rene, thank you so much. Obviously Rene, we've spoken about Bimbits and Domekeeper a lot. Folks, I'm going to find you. Chris, where can people find your work?

• 45:39Speaker 03

  Yeah, on Steam. You can search for Drift Space Survival.

• 45:43Speaker 01

  Awesome. Perfect. Well, folks, thank you so much and enjoy the rest of your day.

• 45:47Speaker 02

  Yeah, thank you. Thank you for having us.

• 45:48Speaker 03

  Thank you, Joe.