EPISODE 1801

[INTRODUCTION]

[0:00:00] ANNOUNCER: Caves of Qud is a rogue-like 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 Bucklew is the Co-Founder of Freehold Games, which develops Caves of Qud. 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 Gary's Mod, and game development remains his favorite way to experience and explore new technologies and concepts.

[INTERVIEW]

[0:01:05] JN: Brian, welcome to the show. How are you doing today?

[0:01:07] BB: Hey, I'm doing fine. Nice to be here.

[0:01:09] JN: Awesome. Before we get into Qud, 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?

[0:01:17] BB: 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. For that class had an Apple IIc in the house. I got started on Apple IIc Basic, just really wanting to play games. We had an Atari 2600 in the house, and we had an Apple IIc in the house. I was seven or eight-years-old. At the time you had Byte and Nibble magazines. I got started just printing stuff, like everybody did at the time, right? You could print little text-based games. My first games were real simple text-based games, whatever, choose your number of stuff and little, terribly engineered adventure games. Byte and Nibble Magazine at the time, you can go in the back and they would have whole video game programs, just in text that you could type in like that. You couldn't download anything from anywhere, unless you were really advanced at the time.

You could type in these pretty cool little Asteroid clones and Space Invader clones. I got started from there. I self-taught up through today. I guess, nowadays, there are places you can go to learn video games. By the time when I grew up, there was not, right? There was eventually Game Developer Magazine, but it was just the thing you figured out on your own, or not at all. That's what I did.

[0:02:50] JN: That's awesome. 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 want to say harder to learn, but there's a lot of like, as we'll get into with some of your procgen algorithms. There's some esoteric out there that I don't think I've seen covered elsewhere. I think you definitely a lot of forging your own path there, which is very cool.

Obviously, we had to talk about Caves of Qud, which I've been having a lot of fun with in this holiday break. I have a little bit of trouble telling people that this game is about coming from the dwarf fortress fandom. That's more and much my lens. But how would you describe the game?

[0:03:24] BB: 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 in the time when we were very early in working on the game and it was a big inspiration. Again, my history with video games goes pretty far back, not as far back as it goes, but Apple IIc, TRS 80 games that were often really simple games. 

I grew up in a Seventh-Day Adventist household on church grounds. 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. It was basically a rogue-like exploration game about Bible trivia, where you were Moses traveling from Egypt to Canaan through a really simple text-based terrain of carrots and ASCII signs. It was clearly rogue inspired, even at that time. I would play that all Saturday, this little Moses rogue-like. Of course, I played rogue growing up out in the hills in West Virginia where the only thing was an 8086 that could only play rogue back in the days, where you would pick up software at Ham radio conventions. We got rogue.

I remember my uncle. I must have been 11. We went to a Ham radio convention and bought a bunch of bootleg software on floppy disks from a Ham radio guy that had them in a cardboard box beside the Ham radio, and got some stuff that could play on the computer. One of those games was rogue. Of course, I was completely infatuated having never heard of it and stumbling into rogue at 11-years-old.

Jason and I have played these games our whole life. We've known each other since we were 13 or 14 and been playing these games. We've played rogue, so like Ragnarok. I really liked Omega. Jason was big into a PvP text-based MUD in the 90s, called Rights of Passage. This was the preliminary multiplayer MMO ganking, but in text. You would type really fast, because you would have to fight in real time with a text-based terminal. We've had a strange non-modern route through video games, though of course, we play the modern stuff, too. You see those influences in Caves of Qud, like rogue and you'll see the ASCII coloring is all stuff pulled from MUDs more than rogue-likes.

A lot of what Caves of Qud is I think is a hontological experiment in video games that it feels like what I thought a video game would be in 40 years, rather than what they actually ended up being in 1988. What could a video game be in 40 years? Oh, like this, like Caves of Qud. Of course, video games are like this now, but they could be. It's not trying to recapitulate the experience. Games weren't like this in 1980. There are aspects of them. But what would happen if you kept trying to make games like this from 1983 in the same format but took some of the modern cues in terms of UI design. You don't lose the density. 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. What would that look like? Caves of Qud is sort of that experiment, I think.

[0:06:40] JN: That's an incredible description of it. Yeah, hontological 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 in.

[0:06:49] BB: I really don't know what it was. I would love to know exactly what the title of that gave is. I'm trying 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 - it's probably 80 people played it and it was programmed by somebody in the church.

[0:07:06] JN: 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 of the video game side. I think, this is 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 inspiration, but one of them being the work of Gene Wolfe and The Book of the New Sun, which it's possibly one of my favorite series of books. I was literally schooled of 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, the world building and the lore side of it?

[0:07:35] BB: Oh, sure. That's a huge question. A lot of that question is for Jason, too. Jason does all of the amazing writing. My contribution to the literary side is a couple bear puns, though I appreciate it deeply. I'm very glad to be part of this team that includes a literary writer. Both of us are broad-ranging nerds and always have been and Qud as an expression of that. Gene Wolfe is a post-launch inspiration. We were pretty deep into building Qud when Jason discovered Book of the New Sun. I was like, "You have to read this book."

It turns out, when you go at sci-fantasy with a particular set of influences and interests, like religious interests and interest in deep history, I think we share with Gene Wolfe, you end up tumbling down some of the same caves. It looks a lot like Gene Wolfe, though we weren't trying to duplicate it. He just had long before spool onto these caves and we were stumbling on his old campfires going deeper into this particular earth. Both of us have long histories of being interested in physics and human history, just the deep history of the world and literature in general, both board rovers of information and rather than just playing video games. We took a pretty broad ADD inspired exploration of human history and stuck it in the game.

[0:09:04] JN: Yeah. You mentioned the case, I guess, like, I think one of the big things that really rung true to me about that and the part you talked before is going through certain in-game locations and just trying to think like, okay what was the purpose of this place before the collapse of the rust wells? I think about a lot. I was a big thing and a big reveal moment in the New Sun. I can definitely see those cases were trodden. I guess, into the game and into the tech part and into the mechanics of it, so broadly plays out as an RPG, but has these really deep simulation elements, or at least that's some of the things that stick out to me it says that come from Dwarf 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?

[0:09:49] BB: Yeah. A couple of the games that were big inspirations, one of the things about layering in Caves of Qud is that you're playing through not only a designed set of layering with respect to the world generation, but also, layering of our sensibilities as game designers, because the earliest parts of Qud that you play through, we built in our mid-20s, and the latest piece when you go up to the final end-game, we built in our 40s. That's a huge amount of time as human beings to develop our sensibilities and our capabilities. When you play through the layering, we did eventually go back and redo Red Rock, and redo Rust Wells with a modern sensibility, because they were just so early. If you go back a couple years and game versions and play that it didn't feel like the same game, basically.

At the very beginning of this journey, we're really building intuitively. We do not know why we're designing a game the way it is. We only know that these games are games that we enjoy. Some of those games were games like Omega and games like Adam, and they had some handcrafted elements and they had some procedural elements. I think intuitively, we were also big fans of games Morrowind and Skyrim and the Elder Scrolls I. That set of games Elder Scrolls I, Daggerfall, those games had explored a procedural space as well. Elder Scrolls I, 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 blow through the walls in a way that they never really returned to, but it had heavy procedural elements.

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 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 a different game, for a web game, for a tabletop RPG. At the same time since the 90s, I had been building these rogue-like engines just full of vim and hubris thinking, I could do a big contiguous open world. Was that going to be fun to play? I wasn't thinking that at the time. I was just thinking like, "Look at Adam. It's just like, it's chunked up into pages, and I bet I could just go into a paginated world that's infinitely big, and you'll be able to explore it and I can do that."

I've been trying to do that in C++ for years and 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 classic object hierarchies just don't really work when you're trying to - It's fine if you want to make a sword and shield, but as soon as you want to make a sword-shield, well, your classic inheritance hierarchy just fails. This is a big problem in 1997 when everyone was very firmly attached to object hierarchies and object-oriented programming. It was the stuff that's pretty common now with respect to compositional programming, just didn't exist.

I had been struggling with this for a few years. The Dungeons Siege team, in particular, Scott Bilas released some papers about a tool called FuBi and the engineering behind Dungeon Siege. They took an approach, which they called ECS. 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. 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. You could have an empty game object that did nothing, 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. You could composite those behaviors together and they would relate to one another with an event-based structure, rather than a functional hierarchy, a virtual call hierarchy.

That really blew up in the gates. I was like, "Oh, this is cool. I'm going to try this." I'm going to try this. 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. Like, .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 Qud and inside of Unity, they take a compositional approach that I think was driven by the same papers, because I was building the Qud engine at the exact same time that Unity was being built using .NET, using this compositional system. It ended up being very effective. Of course, Qud still runs on it and you can see how far it's gotten, and you're able to build complex structures with a linear growth of complexity for maintenance, rather than exponential growth, so that now you can have 100,000 objects in instead of 100 billion, which I think a lot of these traditional rogue-likes NetHack run into problems with long-term maintenance, because they're in old styles that have the exponential complexity growth.

I've been building these engines, I didn't know a 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, I guess, the most basic fantasy rogue-like of all time on it for whatever reason. At the same time, Jason and I were building this sci-fantasy world. At some point, we were 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 Qud, the sci-fantasy world. Qud 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 rogue-like.

We came in with a bunch of hand-built content from this world that we wanted to get in there, and a rogue-like engine that was trying to be reined of and said, well, what happens when we ball it up? Be fun. What happens when you try to play a rifts, or a gamma world rogue-like? No one knows, right? We think it could be fun. But, whatever, 20 years later, it's pretty good.

[0:16:15] JN: Yeah. Yeah, absolutely. It's definitely pretty good. The whole emergent, the length of time of development of this game is, and 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 how you kept the codebase management of that time with all the shifting, stopping things from bit rolling is an endless struggle on year timescale, let alone decade timescale. So, definitely want to get to that.

Still, the simulation stuff for a moment. 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. 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. I want to talk a little bit about history, because that's a big part of Qud. I think one of your lines about it in the press kit is it plays a chisel through the layer cake of form a 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 a deal with okay, it's not just a retelling of these facts, not just generating facts, we're generating the telling. Can you talk a little bit about that and how you approach that problem?

[0:17:26] BB: I think people treat history like objective nonfiction. 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 at the atomic level the objective history that happens." 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.

You can realize this when you think about, try to tell me what happened to you and your closest circle of 20 friends over the last year. You could never do it. It's impossible. You just start pulling out these symbolic themes about how people act. When you try to do that over 2,000 years for all people, it's just made up. 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 subjective contextualization that happens. This makes people very angry, right? This really, gets at people at the core. They're like, "Oh, there's nothing going on here. This is just bark off chain garbage. This is a real generator, or real history."

I think they're reacting to the facade of truth that history gets for us, that this is the way things really happened. We can put 100 years of history in this 500-page text, so you'll totally get what all these people were doing. When in fact, what happens is almost immediately, everything that happens it's done by a thousand people, is collapsed by to a single person. Even in this conversation, the work done by me and Jason has collapsed to talking to me, very quickly, right? Like, oh, well, which of this was done by Jason? Which of this thinking was done by me? Well, it's immediate collapse to you're talking to Brian and all the viewers are like, "Oh, Brian the creator of Caves of Qud." 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 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. But those are never recorded in history. You might as well just pick a reason, which fits the Sultan. Because, well, we know that she didn't like frogs, and there was a frog person in the city. Probably, she destroyed the city because there was a frog king in it.

What we do is we do a lot of the reverse psychology of historical actors that real historians do in trying to figure out why people - each person is as complex as a universe, why are they taking these actions? Well, it's probably because of some 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? It frankly doesn't matter why they did this. Either way, the city is destroyed. We thread that rationale back into some context that we have from that Sultan. That's actually true both engineering-wise, as it is 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.

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. Those are 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 objects and they hate these objects and they love this village and they hate this village and they have immigrants from this other village. It's a little box of context. 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, and we suck the blanks out of the context, so it always makes sense in the context of the village. But we've built the template completely devoid of the context of the village. They just, they want something from somewhere for some reason.

Those come out of, sometimes you can't find a match, and then you do make up something completely 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, magic flutes, or very comfortable beds. Well, that's cool. 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. There wasn't some immigrant that really loved comfortable beds.

The truth is that there's no real difference in the plate experience. Often, history is like that. We're like, well, why does your town have a leopard mascot? Oh, well, we love leopards. Nobody knows anymore why, and it doesn't matter. It doesn't matter that it was like Jim in 1890 that I don't know, had a leopard stuff toy from somewhere that's lost. It's deleted almost immediately from history, the true atomic reasons for actions.

[0:23:12] JN: Oh, that's awesome. It's such a, yeah, I mean, very real. It's a very cool system. I think, yeah, particularly the difference in, and you explain this better in the paper that I'm going to quote now, or you explain it better. Just now that I'm going to quote now, but the not bothering to generate the logic behind why the event happened and just focusing on the post-rationale, I felt was really fantastic.

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, well, how enough 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 makes sense? Again, you touched on a bit there about when you come to generate the village, you draw on the elements of history that exists and fit in with its properties. But can you talk a little bit more about that?

[0:24:07] BB: There is a good GDC talk on this, where we talked just for a whole hour on the layered process of generating just villages. The truth is that this is 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 particularly interesting one. But the overall approach is 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 with a particular Sultanate, or whatever it is. The same thing for a Sultan historic dungeon. It's from this Sultan. It has a particular set of cult members.

We then fabricate the layout of the dungeon at a slightly - or city at a slightly less abstract level. We say, well, it's part of these nine parasangs, these nine screens worth of content. Then next level abstractions maybe, well, let's assign some flavored each square. Okay, well, maybe this one is agricultural content outskirts and this one is the village center. Then we, for the villages, we run terrain generation algorithms, which is a whole 10-hour aside, how do you do each of these.

[0:25:37] JN: Oh, well, come into Y function clouds. Don't' worry.

[0:25:41] BB: Yeah. They're mostly layered noise. Then we do some terrain analysis. I do a lot of extra mapping, where I just drop a bunch of individual seeds across the map and do basically, which seed is each cell closest to. You get a nice compartmentalization there that you can control roughly the size. 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.

Okay, well, now I've got foot paths. 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. Each of these steps is 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 in the center here and we know there's a river passing from east to west, but we know exactly where that is. By the end, you've got an object in every cell and you got people smoking, because at the side of the village and whatever. It's basically just an iterative process, where 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 piecewise way. If 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 a little closer to a concrete reality, where you're doing, okay, let's clear the background. Okay, let's paint, do the Z-buffer for it, whatever that happens to be. But you're doing those incremental passes that build up the result.

[0:27:50] JN: Right, right. That makes sense. The next then is the procedure generation, I guess, one element I was interested, and this may turn out to not be that interesting, but is how that then interacts with the handcraft elements? I think this first occurred to me I had, and I know this is a fairly common experience, our guy of getting sight of the mechanist in Joppa and just going crazy and murdering him. Then thinking about how that must be a, well, nightmare might not be the right word, but how the generated context of that -

[0:28:15] BB: Oh, murdering is a pretty good word.

[0:28:17] JN: Well, how the generator politics interact with locations where there are static quest people that the things that don't change? Is that a problem? What are the boundaries between your handcrafted content and generated content and how do you manage those?

[0:28:29] BB: It's on a location by location basis. 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 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 it the, it's a waveform right where you start very high in Joppa, which is completely handcrafted, we know everything that happens there and where every box is going to be. 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 at the bottom of the handcrafted. Any character is going to be having a different experience having been lost in the canyon and stumbled into some ruins, or lost in the jungle, or exploring first some particular injector they need.

Then you get to the next checkpoint, and you've reached another high in grit gate, 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 grit gate is going to be, because there is that nader of generated material that we've still fought a lot about. We have an idea of the breadth of encounters you're going to have, but there's so much of it and that they can intersect in so many ways that we are still often surprised at the encounters that people have in that low point of hand-craftiness between the chapter set points.

[0:30:11] JN: 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 push you on it too much. When we're talking about terrain generation and particularly generation of given region, you mentioned, again, in one of the GDC talks, you mentioned a lot of techniques. I was just like, okay, some of these are familiar to me. Wave function 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?

[0:30:46] BB: Yeah. Wave function collapse is the technique invented by a developer, Maxim Gumin. Brilliant guy. A brilliant mathematician. It's basically a constraint solver. It's a very straightforward, sort of. I mean, compared to feeding the thing into a neural net, or whatever, it's a pretty straightforward constraint solver that you give it a little pattern and it will take all the possible combinations of input relationships in the pattern for a given sub square and then regurgitate that pattern at any scale, and you can seed it. It's basically a texture synthesis algorithm. 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 synthesize 20 by 20 blocks, or whatever, it's not going to work.

At the time, it was it was a really 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 put the blue edge versus the blue edge and it fits. But there weren't any great commonly used mechanisms outside of a few really smart people for saying, well, I want a dungeon that has this character, but at this scale and be able to have a designer be able to do that, rather than a coder. You can write the input in this paint for WFC.

It's a really cool tool and it opened the world for me at least, to the wider world of texture synthesis and constraint solvers that you can use to do this development, where you give it some input that maybe someone who isn't technical can design. You can go into MS Paint and scribble a little dungeon and say, I want this a bunch of narrow corridors with these little shapes and it'll generate a bigger replica of that. That isn't the same every time, but it's locally the same. If you look at the little sub-units of the output, they'll all be locally identical to a sub-unit 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 ruin interiors, or cool structures inside of larger areas.

It's not very good at non-symmetrical areas over large distances. If you say, do this for the whole screen for a particular input, it'll be samey across the whole screen, because on the order of the input will be the order which it feels samety, even though it's not exactly the same. 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, however you want to do it. We fill those in with WFC to give them each interior complexity and interest.

[0:33:47] JN: Awesome. Talking about the local units being similar, I guess, brings me to the topic of perception of procgen games and procgen elements by players and especially in the last, God, what's the timeline here? I don't know. Two, three years, there's been some titles that have gotten put on the, much I said, it's sine wave of procgen in favor, procgen out of favor, but the one, the perceptions, I guess, at the moment is swung by the other way in that these games tend to be very broad and very shallow in what they generate, or 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?

[0:34:26] BB: 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. There's a lot of stuff. Well, 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 any practical human time scale. I think it's a really interesting time for procedural systems, because procedural systems have gone from curiosity to one of the apex problems of human civilization right now as procedural generative systems just rip apart the static reality that we have on the Internet and start just pumping it full of generative garbage.

I'm not a huge AI proponent in the context of generative AI. We've done some things recently. We had our random books used to just be Markov chains, which is very, very simple versions of attentional transformers, but they produce locally coherent, but not globally coherent text output that's funny to read sometimes. In the modern era, very quickly within the last two years, the vibe of those books changed a lot, because it's really, that text gibberish is directly damaging our everyday experience as human beings. We kind of like, don't like these as much anymore. We pulled that back a little bit, so that now when you read those books, you get one sentence snippet, which is still random but at least doesn't feel like you're just slamming directly into an LLM's output, because you have fairly unsophisticated people who are like, "Oh, why don't you just generate these with LLM's?" It's really, really painful to feel those comments.

[0:36:17] JN: Yeah. I feel it's still, this is not an original for 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, I don't know, in a way that my LLMs sometimes feel quite soulless.

[0:36:31] BB: Yeah, yeah. No, I mean, that's all these generative AI, right?

[0:36:34] JN: Yeah, yeah. Exactly. Speaking of the timescale, this was fascinating to me about whenever we have a guest who's worked on something, especially in a small-ish team for a long time, I'm always fascinated about how you keep the project workbook. So, I feel like, I would be rebasing everything every other year. How has the game changed in the 20, or 15 years technologically and how have you kept it as a workable project?

[0:36:58] BB: The short answer is at this point, we're all very old, very experienced engineers. Everybody on the team is just ancient and extremely good, which helps a lot. Essentially, everybody that's contributing to the code has a lot of experience building projects, big projects. 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 1998. I live in a world where nobody in my entire sphere in games would know what Script Logic is, but somebody on the podcast might be like, "Oh."

[0:37:43] JN: This is the place. Yeah.

[0:37:44] BB: I mean, I made Desktop Authority and Caves of Qud, so there will be one person on this podcast is like, "Whoa, I love Desktop Authority and Caves of Qud." 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, or other developers, or also experienced software developers. 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. We have done all that. By the time I started, I started Caves of Qud in the year that I sold the first startup to Quest. By the time Caves of Qud was started, I was already a relatively mature engineering manager, and had been 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, Qud 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. I was like, well, what can I do to really learn .NET? It's like, well what if I try this rogue-like 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.

Eventually, it was like, well, the console isn't working for a few reasons and we want to give it a bit map font, so it was a .NET 35 app with OpenGL rendered bitmap fonts. Then, Jason and I were like, well, we want to do games for a living, and so we did. I took the engine and I guess, what we did is we made Sproggiwood, which is a little mobile rouge-like. It was successful enough to have Steam say, "Yeah, you can put Qud on Steam," without going through green light which was the process at that point. We were like, "Oh, cool. We'll sell 100 copies and it'll fund some music for it or something."

I said, well, let me try porting this into Unity. 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 to do the UI. 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, we're just complaining to their performance scene that I couldn't profile Caves of Qud, I had to write right separate tools, because their profiler couldn't see non-app threads.

At first, their garbage collector wouldn't collect garbage-built generated on separate .NET threads, so it was a whole journey in Unity. Though, it works quite well now. Basically, my threads, or the game still runs on the second thread, waiting on getches, waiting on shims 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. It ends up being really nice recently. 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. I know that the main game runs on a second thread.

I wonder if I can showboat a little and just in public for it to Godot over a weekend. Maybe. I was not certain that would work, but I was like, if it works, it's going to be epic. So, let me let me try to do it. I did actually successfully rip that whole, I mean, it's 500,000, 600,000 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.

It's really, 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 frontend for it if we wanted to. Then maybe we will someday, though right now, I think Unity is on a relatively good path. It seems like they are compared to where they were two or three years ago.

[0:42:32] JN: Yeah, absolutely. They've come a long way since the implosion. But yeah, watching you port that, you live tweeted a lot of it, it was incredible the port. I had a question here about how that was technically feasible, because there was obviously, some separation going on and lots of observing, where, well, this is happening very quick. How is the engine interaction here? Because it's awesome to hear how that worked.

That's getting towards the end of my boat questions. I guess, two more to wrap up. Obviously, I have to ask, when you come to make a new Caves of Qud character, what is your favorite starting build?

[0:43:03] BB: I either play a true can tinker. I often just play random characters, just because I like that vibe, and I'm experienced enough of doing that, and that's just how I play games anyway. I just like to play with what I'm given. When I pick one, I either play a really basic true can 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. It's like an advanced random character. Unstable genome is a 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.

It's a little better than taking those mutations and it means you have to grow into your character, which will be on average, a little more powerful than a character that you get the mutations to start with. That really serves my own desire to the playing I built and enjoy it.

[0:44:03] JN: Yeah. Maximizing randomness in a positive way. Then totally understand if the answer to this is no idea yet, but now that Qud is 1.0 and is at 1.1, I believe, or 1.01? What is next for Freehold, and Qud, or otherwise?

[0:44:18] BB: Well, launch went pretty well. I think that that means that Qud will continue to be developed. We do have other games we want to make. We made one of them in the middle of Qud. I think we have a lot of games we're interested in making. One of the things we want to do is sit down and really decide what the next - which of those we're really going to pick off and explore and that probably means some prototyping. We will be doing that. We will be continuing to develop Qud, which will get expansion releases. We have, I don't know, another 85 years or something of those in buckets now. 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.

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. We definitely know to mobile. I've had it running on mobile for years. Technically, it works. Yeah, I can pull it up on my phone and have since 2017. Unity makes that fairly straightforward.

[0:45:24] JN: I'm fascinated by the UI.

[0:45:25] BB: Well, the UI is the challenging part. It's not a technical problem It's a UI problem. But you can look at DCSS has a mobile port that works. Shattered Pixel Dungeon works quite well. 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. 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. We'll see how it goes.

[0:46:00] JN: That really encourages me. I've been putting off doing Steam Deck, mostly because I like the keyboard-drivenness so much. But hearing your finger bringing the mobile, I might have to give Steam Deck a go.

[0:46:09] BB: We spent quite a lot of time. We moved from basic inputs to Rewired, to Unity's new input system and it was a very painful move to eventually get to where we are. We do now fully support gamepad. A lot of people who played keyboard and mouse now say that they play a gamepad and can't go back to keyboard and mouse, just because it's so nice to sit back with the gamepad.

[0:46:27] JN: Fascinating.

[0:46:29] BB: If you're holding off because Caves of Qud is - Caves of Qud is hard to play, but it doesn't have to be physically painful to hunch over your keyboard to play. It actually does play quite nice on your Steam Deck, or just chilling on your couch, casting your Steam Deck to your TV works really good.

[0:46:44] JN: 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.

[0:46:51] BB: Thanks. It was a nice chat.

[END]