← Software Engineering Daily
Software Engineering Daily
Caves of Qud with Brian Bucklew
00:47:06
Caves of Qud is a roguelike game set in a richly detailed, post-apocalyptic world blending science fiction and fantasy. The game is known for its deep lore, emergent gameplay, and wildly creative character customization. It is a massive indie success,
Loading summary
Transcript42 lines
- [00:00]
Brian Buckleu
Caves of KUD is a roguelike game set in a richly detailed post apocalyptic world blending science fiction and fantasy. The game is known for its deep lore, emergent gameplay and wildly creative character customization. It is a massive indie success and recently hit a major milestone with the release of version 1.0 after 15 years of development. Brian Buckleu is the co founder of Freehold Games which develops Caves of Cuddle. Brian joins the show to talk about his engineering background and the development of his 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.
- [00:59]
Joe Nash
Foreign.
- [01:05]
Host
Welcome to the show. How are you doing today?
- [01:07]
Joe Nash
Hey, I'm doing fine. Nice to be here.
- [01:09]
Host
Awesome. So before we get into card, which as we mentioned covers a lot of time, what was your journey into game development? What led up to the entry into the caves?
- [01:17]
Joe Nash
Oh boy. I guess I got started in the 80s. My father was in a software engineering class, ended up in nursing, but at the time was in college and for that class had an Apple IIC in the house. And so I got started on Apple IIC basic, just really wanting to play games, right? We had like an Atari 2600 in the house and we had an Apple IIC in the house. And I was you know, seven or eight years old and at the time you had like Bite and Nibble magazines. So I got started just printing stuff like everybody did at the time, right? Like you could print little text based games. So my first games were real simple, simple text based games, right? You know, whatever, choose your number stuff and little terribly engineered adventure games. And in Byton Nibble magazine at the time you could go in the back and they would have whole video game programs just in text that you could type in, right? Like that you couldn't download anything from anywhere unless you were really advanced at the time. And so you could type in these kind of pretty cool little like Asteroid clones and Space Invader clones. And I got started from there. I sort of self taught up through today. I right, like there's no real. I guess nowadays there are places you can go to learn video games. But at the time when I grew up there was not right. There was eventually like Game Developer Magazine, but it was just a thing you figured out on your own or not at all. And so that's sort of what I did that's awesome.
- [02:51]
Host
Yeah. It's especially funny to hear. I don't know. I think you play in a genre of video games where there is, like, things that are, I don't say harder to learn, but, like, there's a lot of, like, as we'll get into with some of your proc. Gen algorithms, there's some like, esoterica there that I don't think I've seen covered elsewhere. So I think you definitely a lot of forging your own path there, which is very cool. So obviously we had to talk about Caves of Kurd, which I've been having a lot of fun with in this holiday break. I have a little bit of trouble telling people what this game is about. Coming from, like, the Dwarf Fortress fandom, that's very much my lens. But how would you describe the game?
- [03:23]
Joe Nash
Sure. I think, I mean, someone from a Dwarf Fortress fandom is coming from a place where we were at when we were working on the game. Dwarf Fortress released sort of in the time when we were very early in working on the game, and it was a big inspiration. But again, my history with video games goes pretty far back. Not as far back as it goes, but, you know, Apple IIC, TRS 80 games that were often really simple games. I grew up in a Seventh Day Adventist household, like on church grounds. And so the only video game I could play was. I wish I could find it now. Maybe somebody on the podcast can tell me what it is. But it was basically a roguelike exploration game about Bible trivia, where you were Moses, you know, like traveling from Egypt to Canaan through like a really simple text based terrain of carrots and ASCII signs. Right. But it was clearly rogue inspired even at that time. And so I would play that all Saturday, this little Moses, roguelike. And of course I played rogue growing up out in the hills in West Virginia, where the only thing was like an 8086 that could only play Rogue back in the days where you would pick up software at ham radio conventions, right? Like, we got Rogue. I remember my uncle, I must have been 11, we went to a ham radio convention and bought a bunch of like, bootleg software on floppy disks from a ham radio guy that had him in a cardboard box beside the HAM radio, right. And got some stuff that could play on the computer. One of those games was Rogue. And of course, I was completely infatuated having never heard of it, and stumbling into rogue at like 11 years old. And so Jason and I have played these games sort of our whole life. We've known each other since we were 13 or 14 and been playing these games. And so we've played roguelikes like Ragnarok. I really liked Omega. Jason was big into like a PvP text based mud in the 90s called Rites of Passage. So this was like the preliminary multiplayer MMO ganking, but sort of in text. You would type really fast because you would have to fight in real time with a text based terminal. And so we've had kind of a strange non modern route through video games. Though of course we play the modern stuff too. And you see those influences in Caves of Cud, right. Like Rogue. And you'll see like the ASCII coloring is all stuff pulled from muds more than roguelikes. And so those. A lot of what Caves of Cut is I think is sort of a hauntological experiment in video games that it feels like what I thought a video game would be like in 40 years rather than what they actually ended up being in like 1988. Right. Like what could a video game be in 40 years? Oh, like this, like Caves of Cut. Of course video games aren't like this now. Right. But they could be. So it's not. It's not trying to recapitulate the experience. Games weren't like this in 1980. Right. There are aspects of them. But what would happen if you kept trying to make games like this right. From 1983 in the same kind of format but took some of the modern cues in terms of UI design, you don't lose the density. You know, you don't try to go into 3D representational graphics. You sit in the space of really using the player's imagination a lot. But you can still play it with GamePad. Right. What would that look like? And Caves of Cut is sort of that experiment.
- [06:40]
Host
I think that's an incredible description of it. Yeah. Hauntological exploration of gameplay is amazing. Also I'm not going to be able to get over Moses Rogue. Like if you are listening and you know what that is, please write.
- [06:49]
Joe Nash
I really don't know what it was. I would love to know exactly what the title of that game is. I've tried to find it and I just can't. It was obviously like somebody, probably my step grandfather found it in some church exchange and got it on my. So it's probably like 80 people played it and it was programmed by somebody in the church. Right.
- [07:06]
Host
What an incredible artifact that would be. We need to get our hands on it. Yeah, I think that's a very vivid description of it. You mentioned some inspirations there from the video game side. I think this was actually something I only found out today immediately for this interview is that it's also inspired by. Well, I mean you've got lots of literary inspirations, but one of them being the work of Gene Wolf and the Book of the New sun, which is possibly one of my favorite series of books. So I was like, literally squealed with joy and I was like, oh, now so much makes sense. This is obviously a reason why I love this work. Can you talk a little bit about, I guess like the world building and the lore side of it?
- [07:35]
Joe Nash
Oh, sure. That's a huge question. And a lot of that question's for Jason too, right. Jason does all of the amazing writing. Right. Like my contribution to the literary side is like a couple bear puns though. I appreciate it deeply. Right. Like I'm very glad to be part of this team that includes a literary writer. Both of us are sort of broad ranging nerds and always have been. And CUD is an expression of that. Gene Wolf is kind of a post launch inspiration. We were pretty deep into building CUD when Jason discovered Book of the New Sun. It was like you have to read the book. And it turns out when you go at sci fantasy with a particular set of influences and interests, right, like religious interests and interest in deep history, I think we shared with Gene Wolf, you kind of end up tumbling down some of the same caves. Right. And so it looks a lot like Gene Wolf, though we weren't trying to duplicate it. He just had long before, you know, spelunked these caves and we were like stumbling on his old campfires going deeper into this particular earth. Both of us have long histories of being interested in like physics and human history, just the deep history of the world and literature in general. Sort of both bored rovers of information rather than just playing video games. Right. We took a pretty broad sort of like add inspired exploration of human history and stuck it in the game.
- [09:04]
Host
Yeah, you mentioned some of the caves. I guess. Like I think one of the big things that really rung true to me about that and the path you tried before is like, you know, going through certain in game locations and just trying to think like, okay, what was the purpose of this place like before the collapse, like the rust wells I think about a lot and like that's like it was a big thing and a big like reveal moment in the new suns. I could definitely see those caveswell trolls. So I guess into the game and into the tech part and into the mechanics of it. So, you know, broadly Plays out as an rpg, but has these really deep simulation elements, or at least that's, you know, some of the things that stick out to me as they're coming from your fortress. But obviously also a mix of handcrafted. Not everything is procedurally generated. Can you talk about the mix of what is handcrafted, what is simulation in the game, and where those two things overlap?
- [09:49]
Joe Nash
Yeah. So a couple of the games that were big inspirations. One of the things about layering in Caves of CUD is that you're playing through not only a design set of layering with respect to the world generation, but also a sort of layering of our sensibilities as game designers. Because the earliest parts of CUD that you play through, we built in our mid-20s. And the latest piece, when you go up to the final endgame, we built in our 40s. And that's a huge amount of time as human beings to develop our sensibilities and our capabilities. And so when you play through the layering, we did eventually go back and redo Red Rock and redo Rustwells with a modern sensibility because they were just so early. If you go back a couple years in game versions and play that, it didn't feel like the same game, basically. So at the very beginning of this journey, right, we're really building intuitively, we do not know why we're designing a game the way we way it is. We only know that these games are games that we enjoy. And some of those games were games like Omega and games like Atom, and they had some handcrafted elements and they had some procedural elements. I think, intuitively, we were also big fans of games like Morrowind and Skyrim and the Elder Scrolls 1 and that set of games, Elder Scrolls 1, Daggerfall. Right. Like, those games had explored a procedural space as well. Elder Scrolls 1, if you haven't played it, is a really, really interesting game that's built out of volumetric blocks that you can actually just fully destroy. You can go into these dungeons that are procedurally generated and just like blow through the walls in a way that they never really returned to. But it had heavy procedural elements. And so I think we had, in the Cauldron of Intuitions, these games that were successfully pairing these handwritten pieces and these procedural elements. And we just kind of jumped in and said, well, we're going to do a similar thing. We have this world. We had been building a big sci fantasy world, me and Jason, the background for it, for different kind of game for like a web game, for, like a tabletop RPG. And at the same time, since the 90s, I had been building these roguelike engines, like just full of vim and hubris, thinking I could do a big contiguous open world. Why was that going to be fun to play? I didn't, wasn't thinking that at the time. I was just thinking, oh, I like, look at Adam. It's just like it's chunked up into pages and I bet I could just do a paginated world that's infinitely big and you'll be able to explore it. And I can do that. And so I'd been trying to do that in like C for years and kind of failing. I have a talk out there about the data driven engines, which is good to watch if you want to watch a little bit deeper into that history of failure. But like, classic object hierarchies just don't really work when you're trying to, you know, like, it's fine if you want to make a sword and a shield, but as soon as you want to make like a sword shield, well, you're like, classic inheritance hierarchy just fails. Right, right. And this is a big problem in like 1997 when, you know, everyone was like very firmly attached to object hierarchies and object oriented programming. And it was the stuff that's pretty common now with respect to compositional programming just didn't exist. So I had been struggling with this for a few years and the Dungeon Siege team, in particular, Scott Bilas, released some papers about a tool called FUBI and the engineering behind Dungeon Siege. And they took an approach which they called ECs. And this is a point of confusion because there's a modern programming technique that's basically an optimization technique called ecs, which is not what I'm talking about when I talk about ecs. And there isn't really a good term for what I'm talking about, but what I'm talking about is that they used a compositional pattern for creating these game objects instead of an inheritance pattern. So you could have an empty game object that did nothing. Right. And you could say, well, it's a liquid volume. Oh, it's a shield, it's a sword, it's a piece of armor. And you could composite those behaviors together and they would relate to one another with an event based structure. Right. Rather than a functional hierarchy, a virtual call hierarchy. And that really blew open the gates. I was like, oh, this is cool. I'm going to try this and I'm going to try this in. I'm going to learn Net I was working as an enterprise software architect and I was like, well, I have to learn NET for what this is. Net 2.0. Net framework 2.0 is coming out in 2005, 2006. I'm like, let me try this. I was experimenting with this frankly, at the same time that Unity is experimenting with it. If you look inside of Cut and inside of Unity they take a compositional approach that I think was driven by the same papers. Because I was building the Cut engine at the exact same time the Unity was being built using Net using this compositional system. It ended up being very effective. Of course CUD still runs on it and you can see how far it's gotten and you're able to build complex structures with a sort of linear growth of complexity for maintenance rather than exponential growth. So that now you can have 100,000 objects and it's in instead of 100 billion, which I think a lot of these traditional roguelikes like NetHack run into problems with long term maintenance because they're in old styles that have the exponential complexity growth. And so I had been building these engines. I didn't know what game I was making. I was an engineer. I'm like, I'm just making this engine that's going to be cool and I'm going to do like I guess the most basic fantasy roguelike of all time on it for whatever reason. But at the same time Jason and I were building this sci fantasy world and at some point we were like literally sitting in my garage and said, what if we try taking some of these tabletop influences? Because we were big tabletop gamers like Rifts and Gamma World and this fantasy world which is much bigger than cud, right? This sci fantasy world, CUD was a little corner of it. We said, well, let's find a place in the sci fantasy world that fits the genre of Rifts and Gamma World and see what happens when you put it in this roguelike. And so we came in with a bunch of hand built content from this world that we wanted to get in there and a roguelike engine that was trying to be random and said, well, what happens when we ball it up? Be fun. Like what happens when you try to play a Rifts or a game world roguelike? No one knows, right? We think it could be fun, but you know, whatever. 20 years later, it's pretty good.
- [16:15]
Host
Yeah, yeah, absolutely. It is definitely pretty good. The whole emergent, like the length of time of development of this game is like. And you know, obviously how that has boiled out into how it was built and the layers of it is really interesting. I definitely want to talk about, you know, how you kept the code base manageable at that time with all the shifting, you know, stopping things from bit rotting is an endless struggle on year timescales, let alone decade timescales. I definitely want to get to that. But still the simulation stuff for a moment. So one of the. I guess there's a bunch of systems that are very clearly simulated in the game that I think are really interesting, and one of which you wrote an ACM paper on with your co founder, which delighted me particularly. Some of the quotes in the abstract are already incredible. So I want to talk a little bit about history because that's a big part of cud. I think one of your lines about it in the press kit is it play as a chisel through the layer cake of a form of civilization, which is fantastic. But in particular, I think one of the things you mentioned in your. The first thing that gripped me about your description of how you're approaching history generation was that you're approaching it with the recognition that history is written by the victor and you've also got to deal with, okay, it's not just a retelling of these facts. We're not just generating facts, we're generating the telling. So can you talk a little bit about that and how you approach that problem?
- [17:26]
Joe Nash
Well, I think people treat history like objective nonfiction. And in fact, the way a lot of games generate their worlds, and this is. I'm not knocking anyone for this. I'm just trying to explore the space. Is that the way a lot of games that use a procedural volume of world building is an objective one where you say, oh, I'm really going to simulate sort of at the atomic level, the objective history that happens. And the fact is that the history that you engage in every day isn't like that. It's a completely subjective retelling that's much, much closer to fiction than any kind of objective telling. And you can realize this when you think about, like, try to tell me what happened to you and your closest circle of 20 friends over the last year. You could never do it, right? Like, it's impossible. You just start pulling out these symbolic themes about how people act, right? And when you try to do that over 2000 years for all people, it's just made up, right? And so one of the things, again, I think intuitively at first, but later very deliberately, that we wanted to do was not simulate an objective atomic clockwork behind the scenes, but rather Simulate the kind of subjective contextualization that happens. And this makes people very angry, right? This really gets at people, the core. They're like, oh, there's nothing going on here. This is just Barkov chain garbage, right? This isn't a real generator or real history. And I think they're reacting to the kind of facade of truth that history gets for us, that this is the way things really happened, right? We can put 100 years of history in this 500 page textbook and you'll totally get what all these people were doing, right? When in fact, what happens is almost immediately everything that happens that's done by a thousand people is collapsed to a single person. Even in this conversation, the work done by me and Jason has collapsed to talking to me very quickly, oh, well, which of this was done by Jason? Which of this thinking was done by me? Well, it's a media collapse to. You're talking to Brian and all the viewers are like, oh, Brian, the creator of Caves of Cud. And there's just nothing you can do about it. It's the way the human brain parses the world. We engineered a bit of that context collapse to say, well, we know we have some things that are happening in history. Why did this, like, cat Sultan invade this city? Well, there's probably. If you really got down and tried to simulate at the molecular level, there's probably a lot of reasons, including, like, she just didn't like the way the hills looked, right? But those are never recorded in history, so you might as well just pick a reason, right? Which fits the Sultan because, well, we know that she didn't like frogs, right? And there was a frog person in the city. So probably she destroyed the city because there was a frog king in it, right? And so what we do is we do a lot of the kind of reverse psychology of historical actors that real historians do in trying to figure out why people, each person is like, as complex as the universe. Why are they taking these actions? Well, it's probably because of some, like, very obvious reason that had nothing to do with their actual actions. And that's what's happening here. When we generate the history, we say, okay, well, we have a concrete action that happened here. We know that a city was sacked. What are historians going to say about the rationale? And it frankly doesn't matter why they did this, right? Either way, the city is destroyed. And so we thread that rationale back into some context that we have from that sultan. And that's actually true, both engineering wise as it is. Sort of like when you're reading it. We build these contexts for the sultans that say, well, the sultan hates this person and loves this person and is married to this. And then we have systems that will take, for instance, a quest, like a dynamic quest for a city that's like, oh, you have to go get an object for a reason. Right. And those are kind of blank. We don't fill those in purely randomly. We take a village context and the village context has a bunch of information that says, like, oh, they really love these kind of objects and they hate these kind of objects and they love this village and they hate this village and they have immigrants from this other village. Right. So it's a little box of context. And what we do when we generate these quests is we have a template and it has a bunch of blanks and we attach that context to it. Right. And we sort of suck the blanks out of the context. So it always makes sense in the context of the village. Right. But we sort of built the template completely devoid of the context of the village. They just, they want something from somewhere for some reason. Right. And those come out of the. Sometimes you can't find a match and then you do make up something completely at random, but that then becomes part of the context. Oh, they don't have an object they love. Well, we need one now. The village loves rats or whatever. Right. Like magic flutes or very comfortable beds. Right. Oh, well, that's cool that. Now go sleep in the very comfortable bed. But now we have a new piece of context. The village loves very comfortable beds that didn't come from a simulation. Right. There wasn't like some immigrant that really loved comfortable beds. But the truth is that there's no real difference in the plate experience. Right. Like, and often history is like that. We're like, well, why does your town have like a leopard mascot? Oh, well, we love leopards. Right, Right. Like, nobody knows anymore why. And it doesn't matter. It doesn't matter that it was like Jim in 1890 that, like, I don't know, had a leopard, like, stuffed toy from somewhere that's lost, it's deleted almost immediately from history. The true atomic reasons for actions.
- [23:12]
Host
Oh, that's awesome. Yeah. I mean, very real. It's a very cool system, I think. Yeah. Particularly the difference in. And you explained this better in the paper that I'm going to quote now, or you explain it better just now than I'm going to quote now, but not bothering to generate the logic behind why the event happened and just focusing on the post rationale I thought was really fantastic. So you touched on it a little bit there. But the other thing that upon reading about how you generate history and seeing a little bit of, I want to say Jason's GDC talk about village generation. When I first read the history paper, I was straight away like, how on earth do they then generate everything else? Because you've got these histories and these events. How do you go about layering these generation systems so that things are congruent and make sense? Again, you touched on a bit there about when you come to generate the village, you draw on the elements of history that exist to like and fit in with its properties. But can you talk a little bit more about that?
- [24:07]
Joe Nash
There is some good GDC talk on this where we talk just like for a whole hour on the layered process of generating just villages. And the truth is that this is like very artisanal depending on what exactly we're building and why we're trying to build it and what purpose it's serving for the game. Villages are a particularly interesting one. But the overall approach is sort of to start at a level of very high abstraction and reduce that abstraction by steps so that we start with a very abstract village that just has some context. Like we said, oh, well, it's in the marshes. It was founded at a particular time and like with a particular sultanate or whatever. It is the same thing for like a sultan historic dungeon. It's from this sultan, it has a particular set of cult members. Right. We then fabricate the layout of the dungeon at a slightly less or city at a slightly less abstract level. We say, well, it's part of these nine parasangs, right? Like these nine screens worth of content. And then next level abstraction is maybe. Well, let's assign some flavor to each square. Okay, well maybe this one is agricultural content outskirts and this one is the village center. Right. Then we, for the villages, we run terrain generation algorithms, which is a whole, you know, 10 hour aside. How do you do each of these?
- [25:38]
Host
We're coming to wave function collapse, don't worry.
- [25:40]
Joe Nash
Yeah, like they're mostly like layered noise. And then we do some terrain analysis. So I do, I do a lot of like deekster mapping where I just drop a bunch of individual seeds across the map and do basically which seed is each cell closest to. Right. You get a nice compartmentalization there that you can control roughly the. And then we say, okay, well we got eight of these little cell grids. Maybe I can place those randomly or maybe I can place those in an ordered way. If I want the village to look a little more ordered. And I know each of these has at least 200 cells in them, so I'm going to put a little building in each of them. And now you look like you have a nice little building then between them. Well, they need to walk. Well, okay, well, let's find the center of each building and let's path to some town square. Right. Okay, well, now I've got footpaths. Let's find the edges where a road has come into the village and let's connect those to the center. Let's run a river through it and put a bridge if it passed through the road. Let's try to avoid the buildings when we do that. And so each of these steps is sort of increasing the concrete reality of the thing and reducing the level of abstraction. Where at the top, we don't know anything about where it is in the middle we know, oh, it's kind of in the center here. And we know there's a river passing from east to west, but we know exactly where that is. And by the end, you've got an object in every cell and you've got like people smoking yogas at the side of the village and whatever. But it's basically just an iterative process where each. Each step is solving a little problem. You have to get from abstract to concrete. I would say. One way to think about it, if you've never done procedural generation, is that often like pixel shaders for complicated things work in the same kind of piecewise way. If you're. A lot more people have built 3D renderer, then they have a procedural generator. It's a very similar process where you have some output buffer that's going to look like a sword. But how do you render that? It's often 20 or 30 passes, each one doing a particular thing. That gets it a little closer to a concrete reality where you're doing, okay, let's clear the background. Okay, let's do the Z buffer for it, whatever that happens to be. But you're doing those kind of incremental passes that build up the result.
- [27:50]
Host
Right, right. That makes total sense. That makes sense to the procedural generation, I guess. One element that I was interested in, and this may turn out to not be that interesting, but is how that then interacts with the Handcraft elements. So I think this first occurred to me, I had, and I know this is a fairly common experience, argive getting sight of the Mechanist in Joppa and just going crazy and murdering him and then thinking about how that must be a. Well, nightmare might not be the right word, but like how the generated politics.
- [28:15]
Joe Nash
Nightmare is a pretty good word.
- [28:17]
Host
Well, like how the generated politics interact with like locations where there are static quest people that like, know the things that don't change. Is that a problem? Like what are the boundaries between your handcrafted content and generated content and how do you manage those?
- [28:29]
Joe Nash
It's on a location by location basis. So a lot of it's just about what kind of explicit second by second play experience we want in each place. We have very few explicitly handcrafted areas. They're often sort of chapter milestones, cities that you reach, or real climax set pieces that don't change from time to time, but everything in between sort of at the. It's kind of a waveform, right. Where you start very high in Joppa, right. Which is completely handcrafted. We know everything that happens there and what's. What's sort of where every box is going to be, right. And by the time you're in between Joppa and trying to get to Grit Gate the next one, you're just out in the jungle somewhere and you're kind of at the bottom of the. Of the handcrafted. You don't. Any character is going to be having a different experience having been lost in the canyon, in a canyon and stumbled into some ruins or lost in the jungle or exploring for, you know, some particular injector they need. And then you get to the sort of the next checkpoint and you've. You've reached another high. In Gritgate where this is completely handcrafted, it's something you can look forward to that gives some structure to your experience for any character, but you don't really know for any character exactly what the route from Red Rock to Gritgate is going to be because there is that kind of nadir of generated material that we've still thought a lot about. Right. Like we have an idea of the breadth of encounters you're going to have, but there's so much of the. Of it and that they can intersect in so many ways that we are still often surprised at the kind of encounters that people have in that kind of low point of handcraftiness between the chapter set points.
- [30:11]
Host
Yeah, that makes sense. Yeah. I mean, I'm often surprised. I feel like I've done a lot of runs now and then sometimes I'll do a run and I'm just like. That made absolutely no sense. That was wild. Okay, so we've already touched on this a bit and I know you Said it could be 10 hours. So I don't want to pressure you on it too much, but when we're talking about terrain generation, and particularly generation of, you know, given region, you mention again, in one of the GDC talks, you mentioned a lot of techniques. So I was just like, okay, some of these are familiar to me. Wavefunction collapse was not familiar to me and seems to be a quantum thing. But of course you then go on, define it. Can you talk a little bit about wave function collapse and where this idea comes from and how you use it?
- [30:47]
Joe Nash
Yeah. Wavefunction collapse isn't a technique invented by a developer, Maxim Guman, brilliant guy, a brilliant mathematician. It's basically a constraint solver. It's a sort of very straightforward sort of. I mean, compared to like feeding the thing into a neural net or whatever. Right. It's a pretty straightforward constraint solver that you give it a little pattern and it will take all the possible combinations of sort of input relationships in the pattern for a given sub square and then sort of regurgitate that pattern at any scale and you can seed it. It's basically a texture synthesis algorithm. And there are quite a lot of texture synthesis algorithms. It's a particular one that has some really nice properties. It's fairly quick, it has fairly low memory overhead for if your input window is small, if you try to like synthesize 20 by 20 blocks or whatever, it's not going to work. But at the time it was, it was a real leap forward because there weren't any commonly used procedural systems. There was a lot of use of noise and there was a lot of use of tools like long tiles which allow you to build little pieces that have matching edges and sort of put the blue edge versus the blue edges and it fits. But there weren't any great commonly used mechanisms outside of like a few really smart people for saying, well, I want a dungeon that kind of has this character. But still, but at this scale and be able to have a designer be able to do that rather than a coder, just you can write the input, Ms. Paint for wfc. And so it's a really cool tool and it opened the world for me, at least to the wider world of sort of texture synthesis and constraints, constraint solvers that you can use to do this kind of development where you give it some kind of input that maybe someone who isn't technical can design. Right. Like you can go into Ms. Paint and scribble a little dungeon and say, I kind of want this. A bunch of narrow corridors with you know these little shapes and it'll. It'll generate a bigger, bigger replica of that that isn't the same every time, but it's sort of locally the same. If you look at the little subunits of the output, they'll all be locally identical to a subunit of the input, but the broader output is not the same because it's just those subunits shuffled up. It's a neat technique. We use it a lot to generate ruin interiors, non ordered ruined interiors or cool structures inside of larger areas. It's not very good at non symmetrical areas over large distances. Right. If you say do this for the whole screen for a particular input, it'll kind of be samey across the whole screen because it's only right the on the order of the input will be the order which it feels same even though it's not exactly the same. And so what we do is we generate higher level structures via other algorithms. Space partitioning or whatever it is. Laying down a bunch of random boxes, whatever, however you want to do it. We fill those in with WFC to give them each interior complexity and interest.
- [33:47]
Host
Awesome. So talking about the local units being similar, I guess kind of brings me to the topic of perception of proc gen games and proc gen elements by players and you know, especially in the last God, what was the timeline here? I don't know, two, three years. There's been some titles that have, you know, gotten put on the much I said it's kind of sine wave of like proc. Gen in favor, proc gen out of favor. But like one of the perceptions I guess at the moment is swung back the other way in that, you know, these games tend to be very broad and very shallow in what they generate or how the. How they're used. How do you avoid some of the common pitfalls of these approaches in your work? Is it through combining those mechanisms like you said or.
- [34:26]
Joe Nash
I mean, I'm not sure. We do avoid them. I think part of the way we avoid it is just by having worked on it for 20 years. And so there's a lot of stuff. Right. So while yeah, the desert. Each desert canyon is a little samey. We just have built so much garbage for the game that it's easy to stumble around seeing new garbage for a very long time on. On any practical human timescale. Right. I think it's a really interesting time for procedural systems because kind of procedural systems have gone from a curiosity to kind of like one of the apex problems of human civilization right now as procedural generative Systems kind of just rip apart the static reality that we have on the Internet and start, like, just pumping it full of generative garbage. Right? Like, I'm not a huge AI proponent in the context of generative AI. And so we've done some things recently. Like, we had our random books used to just be Markov chains, which are sort of like very, very simple versions of attentional Transformers, right? But they produce kind of locally coherent but not globally coherent text output that's funny to read sometimes, but in the modern era, very quickly, within the last two years, the vibe of those books changed a lot because it's like, really, that kind of text gibberish is, like, directly damaging our everyday experience as human beings. And so we were like. We kind of, like, don't like these as much anymore. And so we pulled that back a little bit so that now when you read those books, you get, like, one sentence snippet, which is still random, but at least, like, doesn't feel like you're just slamming directly into an LLM's output because you have fairly unsophisticated people going like, oh, why don't you just generate these with LLMs, right? And it's, like, really, really painful to feel those comments. Right.
- [36:17]
Host
Yeah, I think there's still. This is not an original thought at all, but there's definitely still a charm to older methods of text generation. LLMs, like Markov chain output especially often gets a giggle out of me that. In a way that LLMs sometimes feel quite soulless.
- [36:31]
Joe Nash
Yeah, yeah. No, I mean, that's like all these generative AI, right?
- [36:34]
Host
Yeah, exactly. Speaking of the timescale. And so this was something that fascinates me about. Whenever we have a guest who's worked on something, especially in a smallish team, for a long time, I'm always fascinated about how you keep the project workable, because I feel like I would be rebasing everything every other year. How has the game changed in the 20, well, 15 years technologically? And how have you kept it as a workable project?
- [36:58]
Joe Nash
The short answer is, at this point, we're all very old, very experienced engineers. Everybody on the team is just. Is just ancient and extremely good, which helps a lot. And essentially everybody that's contributing to the code has a lot of experience building projects, big projects. So Jason was a technical writer at Salesforce before coming on. I was a principal engineer at Dell, having previously founded a tech startup, Script logic, in, like, 1998, which maybe somebody on the. I live in a world where nobody in my entire sphere in Games would know what Script Logic is, right? But somebody on the podcast might be like, oh, this is the place. Yeah, I made Desktop Authority and Caves of Cud. So there will be one person on this podcast that is like, whoa, I love Desktop Authority and Caves of Cud. And so like, I have a lot of experience running teams, having been the technical co founder of Script Logic and having grown that company from me and the co founder to Dell. Jason has a lot of experience in teams. Our other developers are also experienced software developers. So we don't have to train anybody to sit down and scrum and put together stories and write design specs. And we do all that. And we have done all that by the time I started Caves of Cud in the year that I sold the first startup to Quest. So by the time Caves of Cud was started, I was already a relatively mature engineering manager and had lived through the development of Agile. And everyone loving Agile and hating Agile and realizing, oh, it's cool, it just means to plan what you're going to do. We've been doing that since the beginning. In that context. Cud grew from a RAW.NET 2.0 console app. It was a true console app. I had to learn. Net, but I really didn't like enterprise software engineering. It was something I did because you have to live in capitalism. It was fine, but it was never really a passion. So I was like, well, what can I do to really learn. Net? Well, what if I try this roguelike engine that I've been trying to make and failing in C for a decade and do it in. Net and have it be a console output that's fun, that'll get me to sit down and actually learn. Net. I did that in the evenings and eventually it was like, well, the console isn't working for a few reasons and we want to give it a bitmap font. So it was a.net 3.5 app with OpenGL rendered bitmap fonts. And then Jason and I were like, well, we kind of want to do games for a living. And so we did, and I took the engine and I guess what we did is we made a Sproggywood, which is a little mobile roguelike. And it was successful enough to have Steam say, yeah, you can put CUD on Steam without going through greenlight, which was the process at that point. We were like, oh, cool, we'll sell like 100 copies and it'll fund like some music for it or something. And so I said, well, let me try porting this into Unity. And so What I did is I took this raw. NET app that was still running in a console. I said, let me try. I don't know if this is going to work, but I'm going to run it in a second thread. The whole game, this game was maybe 500,000 lines of code at this point. I'm going to put that on a thread and I'm going to have Unity do the ui and it still runs like that. This was very painful at the start of the journey because Unity couldn't profile across several threads. I was one of the main drivers, me just complaining to their performance team that I couldn't profile caves of cut. I had to write separate tools because their profiler couldn't see non Apple threads at first. Their garbage collector wouldn't collect garbage generated on separate Net threads. It was a whole journey in Unity, though. It works quite well now. But basically my threads. The game still runs on the second thread, waiting on Gaches, waiting on shimmed keyboard input, emitting console output, which is now quite a bit different than it used to be. But it's still essentially just writing, emitting these screen buffers and saying, this is your frame for the console. And it ended up being really nice recently, like Unity had a big flare up. And I said, well, that really irritated me. So I wonder how hard it would be to demo Godot. And I know that the main game runs on a second thread, so I wonder if I can showboat a little and just in public port it to Godot over a weekend maybe. I was not certain that it would work, but I was like, if it works, it's going to be epic. So let me try to do it. And I did actually successfully rip that whole. I mean, it's five or six hundred thousand lines still. I ripped that whole thread out, tore Unity off of it and stuck a Godot on top of it running in. Net and got the core game thread to boot and start emitting console buffers. Right. It's really like, you should probably build it that way though nobody actually does because it's so much work. But I backed into the complete separation of presentation and game logic there. It's not perfect by any means. It's very, very complicated. But it does work pretty well and it does give us some portability. If Unity ever has a problem, we really can go. We could build our own front end for it if we wanted to. And maybe we will someday. Though right now I think Unity's on a relatively good path. It seems like they are compared to where they were Two or three years ago.
- [42:32]
Host
Yeah, absolutely. We've come a long way since the implosion, but watching you port that, you know, live tweeted a lot of it. It was incredible to port. And I had a question here about how that was technically feasible because there was obviously some separation going on and lots of observing where we were like, well, this is happening very quick. How is the engine interaction here? So it's awesome to hear how that worked. So that's kind of getting towards the end of my Bolt questions, I guess. Two more to wrap up. Obviously, I have to ask, when you come to make a new caves of card character, what is your favorite starting build?
- [43:03]
Joe Nash
I either play a Trueken Tinker, so I often just play random characters just because I like that vibe and I'm experienced enough at doing that. And that's just how I play games anyway. I just sort of like to play with what I'm given, but when I pick one, I either play a really basic, true kid Tinker just because I don't want to mess around with the systems and I want to hit things with my club, or I play a mutant with all unstable genomes so that it's like an advanced random character. Unstable genome is a kind of strange little design. It serves a bunch of purposes, but it lets you. It basically every level you have a chance for one of the unstable genomes to become a mutation and it costs three points, but you might get a four point mutation out of it. So it's a little better than taking those mutations and it means you have to sort of grow into your character, which will be on average a little more powerful than a character that you get the mutations to start with. And that really serves my own desire to just sort of play hand I'm.
- [44:02]
Host
Dealt and enjoy it, maximizing randomness in a positive way. And then totally understand if the answer to this is no idea yet. But you know, now that cud is 1.0 and in fact 1.1, I believe, or 1.01, what is next for Freehold and CUD or otherwise?
- [44:18]
Joe Nash
Well, launch went pretty well. I think that that means that CUD will continue to be developed. We do have other games we want to make. We made one of them kind of in the middle of cud. So, like, I think we have a lot of games we're interested in making, and so one of the things we want to do is sit down and really decide what the next, you know, which of those we're really going to pick off and explore. And that probably means some Prototyping, but we will be doing that. We will be continuing to develop hud, which will get expansion releases. We. We have, I don't know, another 85 years or something of those in buckets now, and we don't know exactly what that'll look like, whether that'll be free or paid, and what the timeline will be. We got to figure that out. And we will be porting, which will be a lot of my actual grunt work over the next, probably three years. I don't know how long it'll take. It's still largely me doing the porting. Maybe we'll bring on some porters to help, but we definitely go to mobile. I've had it running on mobile for years, so technically it works. Yeah, I can pull it up on my phone and have since like 2017. Unity makes that fairly straightforward.
- [45:24]
Host
I'm fascinated by the UI.
- [45:25]
Joe Nash
Well, the UI is the challenging part, right? It's not a technical problem, it's a UI problem. But you can look at, like, DCSS has a mobile port that works. Shattered Pixel Dungeon works quite well. So it'll be a real tricky challenge. Probably the hardest UI I've built so far. But on the other hand, people said that about putting it on a gamepad and I think it works on a gamepad quite well. And so, like, I'm pretty optimistic. I have some preliminary designs for mobile that I think it's actually going to work and people are going to be like, wow, I can't believe it works on my phone in portrait mode or whatever. Right. Like. So we'll see how it goes.
- [46:00]
Host
That really encourages me. I've been putting off doing Steam Deck, mostly because I like the keyboard drivenness so much, but hearing your fingerprinting the mobile, I might have to give Steam Deck a go.
- [46:09]
Joe Nash
We spent quite a lot of time, we moved from basic input to rewired to Unity's new input system. And it was a very painful move to eventually get to where we are. But we do now fully support GamePad and a lot of people who played keyboard and mouse now say that they played GamePad and can't go back to keyboard and mouse just because it's so nice to sit back with the GamePad. So if you're holding off because Caves of Cut is hard to play, but it doesn't. It's not like it doesn't have to be physically painful to hunch over your keyboard to play. It actually doesn't play quite nice on your Steam Deck or like just chilling on your couch, casting your Steam deck. Deck to your TV works really good.
- [46:44]
Host
Awesome. Well, that's going to fill up the rest of my time until the New year. Brian, thank you so much for your time today. It's been wonderful. Thanks.
- [46:51]
Joe Nash
It was a nice chat.