Developing Multiplayer Games in Godot

Summary

---

Software Engineering Daily – Developing Multiplayer Games in Godot

Air Date: June 11, 2026
Guests: Renee Haberman (Founder, Bipinbits; Creator, Dome Keeper)
Chris Rydenor (Founder, KAR Games; Multiplayer Dev, Dome Keeper)
Host: Joe Nash

---

Episode Overview

This episode dives into the technical journey of adding multiplayer to Dome Keeper, a hit indie roguelike tower defense game built in Godot. Guests Renee Haberman and Chris Rydenor discuss the game’s origins, Godot’s strengths and quirks, and the immense challenges of retrofitting multiplayer onto a game originally designed for single-player. From network architecture and debugging hair-pulling edge cases to economic constraints and the balance of gameplay, the conversation is a masterclass on real-world distributed game development.

---

Key Discussion Points & Insights

1. Introductions & Backgrounds

• Renee shares her journey from IT and computer science to full-time indie games (“...my heart truly lies in game development…” [01:54]).
• Chris comes from a startup/web background but embraced full-time indie development with a multiplayer focus, especially learning Godot’s quirks through his own game Drift Space Survival ([02:45]).

---

2. The Making of Dome Keeper

• Game Loop: “You mine down into this tile map... bring resources up to your dome... buy upgrades... build up your defenses because you are attacked by monsters cyclically…” – Renee [03:41]
• Origins: Born from Ludum Dare 48, with the goal to “make something very stupid, not innovative... but in the combination, it still felt fresh.” ([04:43])
• Content Growth: Post-launch content updates were a top priority—new domes, keepers, and features, to match Renee’s full initial vision. This “catch-up” phase delayed multiplayer because a richer base game would make multiplayer more meaningful ([06:30]).

---

3. Choosing Godot: Engine Insights

• Renee’s transition to Godot: Favoring a strong composition system, blazing fast load times, and best-in-class 2D support. “You can compartmentalize features... Godot was mostly good at 2D... I never looked back. I’m super happy with it still.” ([08:06])
• Chris’s experience: Drift Space Survival used Godot 4.0’s new multiplayer nodes; powerful for prototyping but limited at scale. "They kind of break down...so we end up not using them in the long term, but for getting things moving, really valuable." ([11:28])

---

4. The Herculean Task of Adding Multiplayer

Technical Deep Dive

• Codebase Shock: “There was a little bit of regret like that first time I opened the project and saw how many different gadgets and how many different types of monsters... what have I done?” – Chris [12:36]

• Transitioning from Web to Realtime: Chris describes the shift in mindset from request/response to continuous simulation:

  "You're thinking about what is happening every frame... For multiplayer, you now have two computers that we're trying to get to simulate the same world." ([13:54])

• Physics Challenges: Godot's physics isn't deterministic. For example, iron/resources are physics objects—so “it's impossible to get two computers to simulate that... now we have one computer who has to simulate everything and then send all of that data down to every single client.” ([13:54])

• Data Structures: Many parts of Dome Keeper’s code assumed only one player, making upgrades and certain mechanics much more complex to retrofit.

  “The upgrade system is... also the one where there's this one function, whenever we touch it, we introduce three new bugs. It's really bad.” – Renee [17:47]

• Modes & Flexibility:

  • Normal co-op (shared dome, each with unique keepers/upgrades)
  • Prestige (co-op high score)
  • Versus (two domes/mines, teams can ‘attack’ each other, resource stealing, etc.)
  • Split-screen local, online, and even mixed multiplayer—“the whole local co-op...code-wise it just exploded this sort of space or the state.” – Renee [19:12]

Network Architecture

• Peer-to-peer design (not dedicated servers): “No.” – Chris, immediately & simply [20:13]
• Supports LAN (ENet), Steam P2P, and crossplay (Microsoft PlayFab): “Three different layers of networking... just to add more of the possibility space for bugs.” – Chris [21:32]

Bandwidth Optimization & State Sync

• The bottleneck is synchronizing moving resources (physics objects) as player count grows.
• Optimization from sending naive structures to “individual bit level” – “We get it down to like two 64 bit integers for each resource...that has really helped... 8 [players] is probably really where we're still going to max out.” – Chris [22:23]
• Monsters are more deterministic and event-driven. Chris explains:

  “When the monsters are generated, we send their UID... use that to seed a random number generator... if a client says, ‘my laser just hit this monster,’... we’re just going to trust that.”
  “If you have friends who want to cheat, then you should talk to your friends.” – Chris [24:18], [26:13]

Cheating & Leaderboards

• No public lobbies—friends-only multiplayer, which influences cheating risk:

  “If your friend is cheating... you will call him or punch him when you see him...” – Renee [26:14]

• Maintaining public high score leaderboards is a Sisyphean task:

  “The only thing I will do in the future is high scores among your friends. ...the effort to maintain this and just keep it roughly fair is stupid or it’s not fun.” – Renee [27:18]

Economic Realities

• Peer-to-peer chosen to control server costs:

  “...cannot do this like high server cost... That’s really the reason to go peer to peer.” – Renee [28:32]

• Crossplay via PlayFab incurs costs per session where the connection leaves Xbox’s network; Steam P2P is covered by Steam fees. [29:26]

Custom Networking & Godot Experience

• High-level Godot networking enforces ordering/race condition thinking (must exist in scene tree):

  “...if it doesn’t exist yet, why are you actually trying to call this on it?...You’re highlighting a race condition.” – Chris [29:52]

• Built a custom network state manager for each client to avoid common sync disasters.

Drop-in/Drop-out

• Supported only for reconnect-after-disconnect, not mid-session join for new players:

  “...for game design reasons, it's more of I want to reconnect after I've dropped out...” – Chris [32:24]

---

5. Gameplay & Balance Challenges in Multiplayer

• Major change: No pausing for upgrades in multiplayer, increases time pressure and tension.
• Balance: Monster difficulty scaled with player count; challenging to tune, ongoing playtesting. “Balance is really key to get it right. If it’s too hard, it’s no fun...if too easy, it’s just work.” – Renee [33:31]
• Map size is not dynamically increased for more players (yet)—sessions just go faster. [35:33]

---

6. Retrospective & Advice

• Would they do it again? Only if multiplayer is clearly core to the vision; validation and budget concerns mean it’s smart to build fun, small, and single-player first unless multiplayer would “really elevate the game.” Async features (like scoreboards) may offer a lower-cost boost.

  “...if you make five games and they all take half a year and none...ever works out, even with successful game out, you still go bankrupt...” – Renee [36:35]

---

7. QA and Bug-Hunting

• Massive QA lift: “...the QA effort is like five times as high...all these scenarios to cover...Co-op [and] online multiplayer...breaks in single player suddenly.” – Renee [40:04]
• Godot’s local multiplayer testing is a strong point, allowing multiple debug instances in-editor. Steam/online testing is far more cumbersome.

  “With Godot, you just kind of get all of that right for free.” – Chris [40:27]

---

8. Looking Forward: PVKK & Godot 4

• PVKK (PlanetEnferegungskanonekommandant) is the next big project, also made in Godot—made possible by Godot 4’s improved 3D capabilities.
• Bunker as a setting: “Limiting your game to a single room means you can make that room really nice. It’s a smart decision in production.” – Renee [42:59]
• The legendary PVKK bunker controller:

  “The fantasy...is really like that everything is real. And then eventually we found...a partner to build it...It was quite crazy. How it came out was really a highlight...” – Renee [44:55]

---

Memorable Quotes & Moments

• “There was a little bit of regret like that first time I opened the project and saw how many different gadgets and how many different types of monsters there were and it's just like, what have I done?”
  – Chris Rydenor [12:36]

• “With one of the functions, whenever we touch it, we introduce three new bugs. It's really bad.”
  – Renee Haberman [17:47]

• “If you have friends who want to cheat, then you should talk to your friends.”
  – Chris Rydenor [26:13]

• “The only thing I will do in the future is high scores among your friends... the effort to maintain this and just keep it roughly fair is stupid or it's not fun.” – Renee Haberman [27:18]

• “You can compartmentalize features. Also, just how fast Godot was...and then you launch the game and the game is running in 300 milliseconds...I never looked back. I'm super happy with it still.” – Renee Haberman [08:06]

• “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... it’s just work.” – Renee Haberman [33:31]

---

Timestamps for Important Segments

• 01:54 – Renee’s journey from IT to indie game development
• 03:41 – Dome Keeper’s gameplay loop and design
• 08:06 – Why Godot was the engine of choice
• 12:36 – Chris’s first impressions of the Dome Keeper codebase
• 13:54 – Challenges syncing real-time game state (physics and determinism)
• 17:47 – Multiplayer game modes and upgrade complexity
• 22:23 – Bandwidth optimizations, resource synchronization explained
• 24:18 – Cheating, trust models, and a “friends only” approach
• 29:52 – Godot’s networking paradigms & building custom solutions
• 33:31 – Multiplayer balance and mining/combat cycle
• 36:35 – Would they design for multiplayer from the start next time?
• 40:04 – QA challenges and Godot’s multiplayer debugging workflow
• 42:59 – Why bunkers make good game settings
• 43:40 – PVKK and Godot 4’s 3D support
• 44:55 – Building the physical “bunker” controller for PVKK

---

Closing

A must-listen for anyone interested in game engine decisions, post-launch tech pivots, and the realities of multiplayer engineering for indie games. Dome Keeper’s journey, as told by Renee and Chris, is a perfect illustration of pragmatic innovation, patience, and technical creativity.

---

Find Renee’s work: Pippinbits (Dome Keeper, PVKK)
Find Chris’s work: KAR Games (Drift Space Survival)
For more, find full talk links and code samples at [Software Engineering Daily].

---

Transcript

[Narrator]

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. Renee Haberman is the founder of Bipinbits and the creator of Dome Keeper. Chris Rydenor is the founder of KAR Games, which is a Godot focused studio that developed Space Survival. Chris is now working with the Dome Keeper team to bring multiplayer to the game. Renee 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 in game development remains his favorite way to experience and explore new technologies and concepts.

[Joe Nash]

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

[Renee Haberman]

Hello, thanks for having us.

[Chris Rydenor]

Hello, Glad to be here.

[Joe Nash]

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?

[Renee Haberman]

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 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 found at Pippinbits. 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 PVKK. PlanetEnferegungskanonekommandant, which is a nice name for English speaking people to pronounce.

[Joe Nash]

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?

[Chris Rydenor]

Yeah, I spent about 1012 years in the startup world Doing various startups as kind of founder and cto, living in that like web world. But like Rene 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 Renee on the dome keeper stuff and took the chance to help with that as well.

[Joe Nash]

Amazing. Yeah. That leads us very nicely into what we're here for today, which is, you know, don't keep 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 Con, Chris, which was revealing that you folks 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 us off on talking about what dome keeper is as a game and how it works?

[Renee Haberman]

Yeah, it's a roguelike, 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. 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 and. But you also know you need to be back in time and you need to find some resources, otherwise you might not make it.

[Joe Nash]

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 Dome keeper? Where did it come from?

[Renee Haberman]

In 2021, we participated in Ludum Dive 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 a 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. 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 domkeeper. And then it went quite quickly that the publisher, Ral Fury, was interested in this. We signed a deal and then spent only nine months in production and 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 the big focus after that content update was really getting started on multiplayer.

[Joe Nash]

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 Dumpkin of the Year. It came out. I haven't touched it for a while and then jumped back in anticipation of this and was quite surprised at how much stuff had been added. The menu now is like interactive and in the mind and 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?

[Renee Haberman]

I guess, yeah, sure. Dome Keeper as a roguelike 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 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 bit. 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. 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. So I always wanted to add more content, make the best possible game first before we tackle multiplayer. Because my hope is that multiplayer already 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.

[Joe Nash]

Awesome. Yeah, that makes sense. And then I guess last question before we get to the multiplayer. So obviously I noted that don't keeper is Godot. Was it always like, when was the Ludum Dare version of Godot? What led you to choose Godot?

[Renee Haberman]

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 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. Compare that to making a UI in a engine editor. Like, that's a whole different world. By then I. 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 notes, and you can compose notes within notes, under notes. 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. Unity just had these prefabs like you can pre make a thing, but it didn't have the strong composition aspect. So I really love that. How powerful it felt, how easy it was, how clean it felt. Like you can compartmentalize features. Also, just how fast Godot was. It boots up in two seconds. It's 100 megabyte large as executable that you download. It's not like 8 gigabyte installer or something like that. And then you launch the game and the game is running in the 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. 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.

[Joe Nash]

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

[Renee Haberman]

Yeah, I think 3.2. Something like that, yeah.

[Joe Nash]

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?

[Chris Rydenor]

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.

[Joe Nash]

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 doses. 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? Yes, I would say so. Yeah.

[Chris Rydenor]

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

[Joe Nash]

Awesome. Cool. Now I'm going to ask a series of questions that's probably awkward given that Rene 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 code base and stepping into Dome Keeper?

[Chris Rydenor]

Oh man.

[Joe Nash]

Yeah.

[Chris Rydenor]

So I never went super deep into 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 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 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, 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 give 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 in mind, with some of the data structures. So.

[Joe Nash]

Right, yeah, so I guess let's get into that in an ideal. I think if it could start in an ideal world, if you were designing these data structures in multiplayer in 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 were not so

[Chris Rydenor]

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 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've 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? Where 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 Dome Keeper, 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 who has to simulate everything and then send all of that data down to every single client. And so those are the kind of decisions I 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 Dome Keeper. 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. 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 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 feel, this 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. But you just, why 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, of course, 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.

[Joe Nash]

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

[Renee Haberman]

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 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 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 and defense or do I really like pressure the other team?

[Joe Nash]

Right.

[Renee Haberman]

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. Like I'm not even sure if we have a strict limit right now, but eight. Eight players definitely works.

[Chris Rydenor]

Let's say eight. Yeah, yeah, let's say it.

[Renee Haberman]

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

[Joe Nash]

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 from networking perspective. Are you doing this? Multiplayer is all peer to peer. That's not. You're not going like a dedicated server setup.

[Chris Rydenor]

No.

[Joe Nash]

Okay. Awesome.

[Narrator]

In mobile application security, good enough is a risk. Guard Square uses advanced multilayered 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. Discover how Guard Square brings all these together to provide mobile app security for your Android and iOS apps or 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 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. Whether you're building coaching tools, multimodal assistants or real time security pipelines. Vision Agents handles the hard parts. Get started free at VisionAgents AI.

[Chris Rydenor]

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 crossplay system which makes sense as we, you know Xbox just launched and they're going to have crossplay 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.

[Joe Nash]

For bugs. Yeah. So I guess leads to my question which was so from your Godokon 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.

[Chris Rydenor]

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 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 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. When we pack all the rotation data, the location, who's carrying it, all those things down into that. And that has really helped because before I say like 8 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 that 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 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.

[Joe Nash]

Right? Yeah, that makes sense. So I guess it also leads me off. 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.

[Chris Rydenor]

So with monsters we were actually luck. I don't know if lucky, 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 if 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. But 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 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. And 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. 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.

[Joe Nash]

Yeah.

[Renee Haberman]

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 hammer this into the existing single player game.

[Joe Nash]

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 server authoritative stuff. When I saw you talking about the friendliness and now knowing there's a prestige mode, because I didn'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 keeping an eye on it. So I guess you were just like, it is what it is for the multiplayer.

[Renee Haberman]

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

[Joe Nash]

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

[Renee Haberman]

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 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 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 for forever for free and you don't need to do more. But that restricts what we can do also.

[Joe Nash]

So I guess you incur playfab bill. Is that only crossplay or is that also like if a console player plays for console Player, I think it's anytime

[Chris Rydenor]

it leaves the Xbox network. So Xbox Xbox is free, but any sort of cross play will incur.

[Joe Nash]

Interesting. Okay, cool.

[Renee Haberman]

Yeah.

[Joe Nash]

So to go back a bit, Chris, you mentioned that you found some of Godot's 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?

[Chris Rydenor]

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 GDScript or C or C. And so I appreciated that. But what I did like about the built in high level networking is it'll let you just. It kind of highlights when you actually have an issue. 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. They need to have the same object at the same place in the scene tree. 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, 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. So the high level networking Godot kind of forces you to think about ordering and think about when you're doing things, while 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, drop out. 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 domekeeper 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 the correct state for that. And 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 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.

[Joe Nash]

So you mentioned the drop in dropout. That was really interesting and I thought 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 drop out 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 their session midway or which way round was it?

[Chris Rydenor]

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.

[Joe Nash]

So yeah, absolutely. Yeah, that's what came to mind. Especially when you were talking about how it worked earlier Rene, when you're, you know, individual upgrades, my I was like, okay, someone's going to come in, stack all the individual upgrades and leave and 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 the beginning, a big part of the single player experience is balancing the monster. I keep wanting to say day, night, cycle, but I guess it's not accurate. But the monster mining cycle, when you've got multiple players and obviously one guard the dome, that feels like it fundamentally changes that. How do you see that working?

[Renee Haberman]

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 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 cycles are just a little bit longer to make room for the game not being paused at the same time. With two people you are so much faster with mining that you don't need to scale 1 to 1 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 play testing, getting feedback and then tuning accordingly. 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.

[Joe Nash]

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

[Renee Haberman]

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 Dome keeper, so 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 mind. The mind cannot expand anymore or something like that?

[Joe Nash]

Yeah, of course. Yeah.

[Renee Haberman]

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

[Joe Nash]

Cool. So I guess zooming out from Dome Keeper a little bit, one of the questions that this raises 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?

[Renee Haberman]

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 big game, people want to play this. And with Tomkeeper, it was much in that way that we just wanted to make this game as quickly as possible. It works without multiplayer. And there 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? 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 successful game out, you still go bankrupt eventually. So it's still smart to not overdo this. Like not to spend too much time in the thing. You don't know if, if anyone wants to play it. Yeah, but generally I'm, 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. It doesn't need to be always the real time, shared world, startup free thing. Sometimes it can be an async multiplayer of some kind that, that still elevates the experience and is way easier to do.

[Joe Nash]

Yeah. When you said earlier about doing the friends only prestige mode that like where you know Friends only prestige scoreboard that immediately made me think of Zachtronics games. I don't know if you've ever 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 optimising 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 in what I imagine is a very cheap and cost effective way. So yeah, that's a really interesting point. Oh yeah, so you've already mentioned it already been working on the last update was year two, year and a half and obviously now you've been working in multiplayer for a while and you're in the QA phase currently, is that correct? 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? Because as complex and 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. How do you approach multiplayer testing, Chris?

[Chris Rydenor]

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 bill, but otherwise kind of put that out there and, and they were able to kind of dive in and really find these, 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. And a lot of the technology behind the multiplayer build is actually behind the console builds 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.

[Renee Haberman]

So I think the testing process is not very different to before. It's just like the QA offer 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 suddenly. You cannot make assumptions about, okay, if it works here, it also works on the other bit.

[Chris Rydenor]

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 for 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, 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 post problem, a client problem? With Godot, you just kind of get all of that right for free. And so since we have that like enet, 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 the 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 to kind of like the Steam specific stuff.

[Joe Nash]

Yeah, yeah. The breaking things in singleplayer is really. I'm trying to remember which game it was. It was a past 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 be really interesting.

[Renee Haberman]

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

[Joe Nash]

Yeah. That was when you mentioned the physics objects being the main constraint. I was immediately imagining if you had built this all out before you added the accessor, you know, like the gravity slinging things, and how that would probably break a lot of assumptions made of just the engineer.

[Chris Rydenor]

Yeah.

[Joe Nash]

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?

[Renee Haberman]

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 interesting in itself. Maybe more interesting than if you would be free to leave and we can explore the whole facility. Something like that.

[Joe Nash]

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

[Renee Haberman]

Yeah, it's in Godot, I think. So we could not have made it in Godot 3. So 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 really 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's 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.

[Joe Nash]

Yeah. And 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 looks really good. And I was like, yeah, I'm pretty sure it's real. It looks like. Cool. Yeah. Awesome. Obviously, I desperately want to ask when we can play it, but I will resist asking the cursed questions. And I guess the next additional thing I was going to 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 controller you took to. Was it Gamescom?

[Renee Haberman]

Oh yeah, yeah. It wasn't Gamescom. It was in Tokyo Games show and in TwitchCon San Diego.

[Joe Nash]

How did you go about like, what was the development process for that when you first bought the game? You're like, okay, we need to build the bunker. Or is this something that came out just planning for booths?

[Renee Haberman]

I think during the development this idea of making something physical popped up like 20 times independently of each other. It kind of is a natural thought. Like, okay, you have this very haptic, 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 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. And with the help of Kepler, it was possible for us. I don't think we would have taken the investment alone to do this because if you only build a single one of a new thing, you take the price for the single thing is very high. 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 Pippinbits we are not like electric engineers. Some of us can do some things, but not in that like fully fledged vision. We got a few concepts from different people somewhere a little bit underwhelming, where it's more like, okay, you have a gauge, but it's actually just printed on the panel. It's not real. And for me the fantasy of PVK is really like that everything is real. And then eventually we found with mother ultimate and rethrow 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.

[Joe Nash]

I hope after at least it ends up installed somewhere where people can play it. 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 bitmits and dome keeper a lot, folks. Never to find you. Chris, where can people find your work?

[Renee Haberman]

Yeah.

[Chris Rydenor]

On steam you can search for drift space survival.

[Joe Nash]

Awesome.

[Chris Rydenor]

Perfect.

[Joe Nash]

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

[Renee Haberman]

Yeah.

[Joe Nash]

Thank you.

[Renee Haberman]

Thank you for having us.

[Chris Rydenor]

Thank you, Joe.