Evolving Worlds from Chaos: The Art-Led Approach of 'Darkest Dungeon 2's' Procedural Generation

[Music] This is evolving worlds from the crumbling chaos and it's the artled approach of Darkest Dungeon 2's procedural generation system. Uh this was a feature that was built by my colleague Colin and I and so today this presentation will be hosted by the both of us. So who are we? My name is Marielle Fox and I'm the lead environment artist on Darkest Dungeon 2 at Red Hook Studios. I have been a professional 3D artist for about 15 years now and across all of those years I've been in various industries such as the film, television, animation, and now the video game industry as well. And I'm Colin Tol. I was co-tech director on Darkest Dungeon 2. And I've also been in the industry for about 15 years. Uh, and I've worked from AAA down to one person studios, which is what I'm doing now. uh at my own studio called Two Blocks. So before we get started, uh we'll do a

quick presentation overview. Uh today we're going to be talking about Darkest Dungeon 2's art direction and specifically Darkest Dungeon 2's environment procedural generation, which will be the meat of the talk. Uh we'll also see some quick artist tools that we use to make all of that happen. and we'll finish with a bit of a retrospective of how the artist programmer relationship worked out to make that feature work. Before further ado, Ariel, thank you. So, today we're here to talk to you about Darkest Dungeon 2. It is a rogike strategy game that came out May of 2023 and it's available now on PC and all major consoles. Uh, for those of you who are not familiar with the game, I can give you the briefest of rundowns on some of the major gameplay pillars. Darkest Dungeon 2 is all about taking a road trip through the apocalypse. So, you as the player get to load up your stage coach with all of your favorite heroes, driving through all of our beautiful environments, fighting our enemies and bosses. It retains the same iconic strategic combat as the first

Darkest Dungeon game, and is also about managing the relationships of all of those heroes. So, with that as a very brief overview of Darkest Dungeon 2, Colin will now give you a very brief overview of what procedural generation actually is. Yeah. So during this talk, we're going to be talking about procedural generation quite a lot. So we wanted to make sure everybody kind of had the same idea in their heads while we were doing that. So if every we mention the system, the algorithm, procedural generation, that's kind of all the same thing here. Uh specifically in our talk, we're talking about uh systemic randomization. So this isn't rolling for damage. This is about shifting the initial variables and the the environment in which you're playing. It's what makes the game different every time you play it. So games that do this, it could be, you know, really basic like shuffling a deck of cards for something like solitary, but most of the time it's more foundational uh with games like Terraria, uh Civilization, which kind of reshuffle the whole world that you're working with.

These are very big programmer centric features and because of that art kind of gets slapped on after the fact. And so you'll see the systems kind of bleed through uh the art of the game. So games like Minecraft, for example, everything's a cube and that reflects the system behind it. But you'll have more egregious uh examples like Dwarf Fortress, which feels like you're kind of staring into the monitor of a of the Matrix, you know, like the like the movie. So what makes DD2's procedural generation any different from all of those examples that Colin went over? And at the end of the day, it really comes down to the game's art direction. From a technical standpoint, Darkest Dungeon's art direction can be summed up in a few key points. First and foremost, when we're creating the art for Darkest Dungeon, we want to make sure that we're using a lot of hardlined pooling black shadows. This is us establishing the ink work pass across all of our assets, um, whether they're characters or environment art assets. This is the most

important part of creating darkest dungeon theme art because this is what establishes these assets as looking uniquely like they're from a darkest dungeon world. After we've confidently confidently established that, we make sure that we render solid black silhouette outlines across all of those assets to kind of like tie that stylization together. And then when it comes to colors, we take a secondary pass and apply them in a painterly fashion. So, within the Darkest Dungeon franchise, there are two games. The first Darkest Dungeon game is a 2D sidescrolling dungeon crawler that was created in a custom game engine. And for the second Darkest Dungeon game, we wanted to take all of those things that people loved from the first game, like the map generation, the difficulty and combat, and the art direction, and translate that to a fully 3D world space, which is what we did in the Unity game engine. So today we're specifically going to be talking about Darkest Dungeons environments. Um, and this image is a visual target for our city biome that

was painted by our creative director, Chris Barasa. Uh, I like this image a lot because to me, this picture really encapsulates exactly what I think a Darkest Dungeon environment should both look and feel like. From a technical standpoint, it's executing on all of those points that I just went over. So, if you strip away all of this color information, you're getting a lot of like confidently applied solid black ink work with those pooling black shadows that are really telling you that this is a darkest dungeon environment. Um, and from an emotional standpoint, you're also hitting all of the same kind of feelings that we wanted, which is that we wanted to convey to the player that they're almost fighting these insurmountable odds within an environment that's just outside the realm of possibility. So with that as our art direction established, this is visually what we knew we wanted to achieve when we were creating Darkest Dungeon 2. Yeah. So now we've got a really good art direction and uh but we have to remember that this is a video game. So there's a

bunch of game design constraints uh to keep in mind. Uh so the idea is like how can this procedural system merge those two together? And to do that what we did is set ourselves a set of goals that we knew any successful system would kind of check all the lists there. Um so the first of these goals was that we wanted the world to be an inter a series of interconnected nodes. Uh so these are the main interaction points that the player is going to be uh dealing with. These can be finding a big cache of loot somewhere um or even fighting a mini boss. The idea is that you're going to be going down that mini map on the side that's scrolling uh and choosing a path and forging a strategy that'll be effective or not. We also wanted these to be to give the players kind of short and long-term consequences so that if you choose a path that's let's say on the left, you're emitting potential uh nodes that you could interact with on the right side of the map as you go down.

We also needed the map to be generated in a way that was fully traversible. We wanted to make sure that the stage coach that you're going to be driving around in this world could actually uh you know interact physically with the roads, but we wanted we didn't want to fake the map. Uh we wanted each of the choices to actually generate and exist in the world so that if you picked one path, you could see kind of the other one trailing out in the distance as a path not taken. Uh, another goal was that we needed uh to bring all of the choices kind of in a single intersection point, which is what you see in that little animation. Uh, because we wanted to make sure the players had a clear view of uh what they were picking when they entered an intersection. So going left would mean something right, etc. Finally, we needed to make sure that whatever the system we chose had a nice uh breadth of uh expression. So that means that you could create a biome that felt unique and different from all the

other ones. Uh for example, this farm biome is very open and uh kind of empty, but we also wanted to be able to create things like the city uh that Marielle talked about. It was very claustrophobic and close to the stage coach. At the end of the day, we needed to make sure that we maintained Darkest Dungeon 2's art direction. So how do we make this happen? This was a really hard task. Uh it had a bunch of twists and turns of our own and decision points that we had to choose. Uh and we actually ended up choosing or trying very uh very different approaches along the uh along the development of this game and we'll be talking to you about those different approaches. So with the first one, thank you. Uh, so the very first iteration of Darkest Dungeon 2's procedural generation is something that I'm going to refer to as the sequential plate system. Um, and what that is is we the idea behind it was that we were

going to create these enormous plates that housed a whole bunch of different compo components. And so within a singular plate, we wanted all of those um game design features and art features as well. So, we wanted all of our uh player interaction nodes within a singular plate and we wanted all of these roads connecting these nodes. Uh and then all of our 3D art kind of set dressing this plate to look like whatever biome we wanted. Uh and then once we had finished completing one of these plates, we were going to feed it into Unity and then Unity would randomly pick and generate one of these plates one after the other uh in order for it to fully create a biome run from beginning to end. Yeah, on the tech side of this, uh, this was actually a really simple system, right? So, the only thing we really care about when it comes to the plates is how many roads are going in, how many roads are going out. And we just standardized the entrances and exit positions of the of those so that it was really easy to just take one plate that had say two exiting roads and just pick any other

plate that had two entering roads and just snap them together one after the other. Uh, this was actually so easy in fact that I had it all running uh before Marielle even joined the team. Uh, and from a technical standpoint, I thought, "Oh, we're done here. I'll just move on to something else uh in the game." Uh, so here's some really early footage of the sequential plate system kind of working for us. So, like Colin said, it met our technical goals. Um, and so you see here like a very early version of our stage coach kind of driving through this enormous plate system. Um, and this footage is kind of cool to see because it also has some of the first art that I was working on for the game. So, while we were trying to get the sequential plate system up and running, our environmental art director, Trudy Castle, and I were actually trying to figure out how to make Darkest Dungeon art in 3D. And so, this house that you see is actually the very first asset that we created for the game. And it actually no longer exists in the game, sadly. But, um, but it was kind of cool.

Like, a lot of things were kind of coming together at the same time. And so these first kind of tests with this sequential plate system were kind of hopeful for us. Like we thought it might be something good. But the more time that I spent working with it and the more time that I spent trying to create everything we needed within a singular plate, um I quickly realized that this kind of sucked for me personally. Uh first and foremost, the art authorship time was just way too high. So, um, at the time the environment art team was just one person, me, and so I just had to I was fully responsible for everything that had to go into one of these plates. And so, not only was I trying to figure out how to create Darkest Dungeon art in 3D, um, I was also doing a little bit of game design work. So, within this enormous plate, I had to figure out where we were going to put all of our player interaction nodes, uh, figure out where we wanted to draw all these roads, and then after all of that stuff was decided, I had to create all of the 3D art for this plate, and

then go back into the plate and set dress this plate with all of the art that I made. So, it was uh quite an abundance of work on my end. uh because this was a system that was created uh prior to my involvement with the team in 2018. Um I didn't really get a say into its creation or ultimately how work would be divided amongst different departments. So that was kind of one thing that led to this system not really being the silver bullet for us. Um and things were also really repetitive visually. So we knew we were making a roglike game. So assuming that the player liked playing DD2 and wanted to play it multiple times, they were going to be seeing a lot of these biomes every time they ran through a game, hopefully multiple times. So what would happen is that with every subsequent run through of a singular biome, they would start to recognize different visual landmarks uh within all of these plates. And what that meant was once they started to pick up on like visual

patterns or landmarks, they would start to learn exactly which plate they were on at any given time, which means that they would know what kind of choices lay before them. Um, so it also didn't help us like support uh the game design direction either, but ultimately it really didn't help us execute on our directions vision, which was um always going to be our number one priority. Yeah. So this system was really problematic because the workload was heavily skewed towards the art team. So we decided to come back and take a step back and and redesign the system to try and balance that equation out. And so what we did is pivot to a grid system. Uh essentially the idea was that maybe the procedural system could take uh some of the level design constraints off of the art team and and lessen their load that way. The problem is we weren't sure if we could both do that and maintain the art direction. However, uh the grid system actually had

a lot of benefits that we really enjoyed. The first one is that it reduced the unit size way down uh to bite-sized things that we could do and then just combined them kind of like Lego to generate environments out of them. The advantage of that was also that uh these were were would give essentially uh little pieces of content that the team could make and then uh essentially give little dopamine hits whenever we'd create them. Seeing the system kind of grop gradually rather than attacking these giant mountains of work that the plates were. Another reason that I liked working with a smaller unit size is that it actually helped us achieve that visual variety that we were hoping for. So with a smaller unit size, it meant that I could feed more assets and more prefabs into Unity at a quicker pace. Uh ultimately giving it a larger bank of assets to choose from when it went to go generate our biomes. So it was still randomly

picking and generating tiles one after the other, but with a smaller unit size, I was able to give Unity way more options to choose from. So whenever you went to go run through a biome, hit play on the game, um you were getting a different configuration or randomization of all of these assets um every single time you played. So it was helping us execute on art direction's vision in that regard. Yeah. So then what type of grid? Uh there's a lot of exotic choices out there. Uh but we decided to keep it kind of simple. So we looked at the triangle, square, and hex grids. uh in and in our case, we knew that we had uh road constraints to keep it in mind. And so at the maximum a player would ever have to choose between three different choices at an intersection. Uh so with that in mind, we looked at the hex grid and hex's are actually pretty cool because you have a road that could come from the bottom and it naturally kind of splits up top into three different branches. So that's what we did. Uh, I

asked Marielle to mock up some basic tiles and we placed them in editor to see what it would look like and if on an engineering engineering standpoint if that would kind of tick all the boxes we needed. Uh, and right off the bat we saw that indeed uh the roads are splitting pretty nicely. We can get them to branch out, branch in really easily. Uh but we the only little uh issue we saw is that we we kind of wanted all the nodes to line up uh in a single row and that's not quite possible with hex uh a hex grid because it kind of zigzags up and down. Uh but it's really not a big deal. So as far as like engineering was concerned, none of these are deal breakers and we can move forward with that. So I sent it over to the art team to see what they thought about it. Uh once I started working with the hexagon shaped tiles, uh we realized that there were a couple small details that didn't help us uphold art direction, um one of the things we noticed was because of the shape of the hexagon tile, uh we weren't able to control the rotation of our

assets in a way that we wanted. So, with something like the city biome, we knew we wanted all of our buildings to run perpendicular to the road. But with the hexagon-shaped tile, the tiles would randomly be rotated in 60° angles sometimes, and so we'd get uh some buildings that were a little bit of skew, which, you know, wasn't great for the look of the game. Um, we also knew for the same biome that we wanted all of our buildings to be generated really close to each other and also really close to the road. But with a hexagon shaped tile, there's just enough dead space around the edge um around the perimeter of each tile that that dead space added up once you started to connect a lot of them together. And we weren't able to get our buildings as close together as we wanted or even as close to the road as we wanted. So ultimately we felt like this grid shape wasn't helping us serve our direction. So back to the drawing board uh you know just kind of going down the list we tried square shapes. Uh but again it's

like can this work with what we need? Can it hit the art direction uh so same idea ask for some basic tiles to try and place around and mock uh road generation. Uh, and we saw immediately it's kind of helping as far as the little engineering issues we had before. Things are lining up nicely. Uh, the roads take up uh, you know, 95% of the width of a tile now, so things could be much tighter. Uh, and so everything's kind of lining up in the right direction. We also uh saw that we could do road uh, splitting and intersections correctly. So from my point of view, everything's good. Let's move on to the art. Okay. So, when we started working with square shaped grids, one of the first things I tried making were every kind of tile or road shape that I thought Unity would need to make that full biome run from beginning to end. And so, I took a 1x one square tile and ended up making um all of the kind of road shapes that I thought Unity would need. So, I made a straightaway, I made

a 90° turn, a three-way intersection, and a four-way intersection as well. Um, I had all those tile shapes ready to go. So, I plugged them into Unity and we tried driving around in a map with all of these tiles. And it immediately sucked. It felt terrible to drive through a map with all of these kinds of tiles. Um, what would happen was the stage coach would take a turn and the camera would swing around wildly and then try to snap back to the center of the coach as quickly as it could. Um, and then before you knew it, the stage coach was taking another turn and the camera was just swinging around way too crazily, um, too quickly and trying to reenter itself, um, just way too many times. And so what I thought was happening was that, um, the 90° turns were occurring over too quick a period of time. And so I figured, uh, instead of maybe like a one by one tile, what if I spread out these 90° turns over a larger space? And so I tried making uh

all of these same road shapes, turns, and intersections um on tiles that were a lot larger than one by one. And so I tried to spread it out over tiles that were like 3x two or 4x two uh to see if I could ease out that camera transition a little bit. So with these larger road uh road tiles working, we plugged them into Unity and it spat out some maps for us. And at a glance, it kind of looks like what we wanted it to do, which is that like the road could properly split into different intersections and go off into three different aisles. Uh, but once we started driving, it was still giving us like the same just terrible feeling. Um, it turns out that like no matter how long you spread them out over, if you still have 90 degree turns, this map is still going to have all of these like lumps and bumps in it. and the camera's just never going to be able to accommodate these turns properly. So ultimately we decided that 90° turns uh with all these lumps and bumps in these maps were like not at all what we wanted

out of like a gameplay feeling. Yeah. But then uh essentially what we needed to remember is that we're masters of our own domain. We're creating this world and so we can impose rules that we want on it. Uh, and so we decided to just uh programmatically remove the idea that we could turn 90 degrees. So this world is only 45° turns or less. Uh, this had a bunch of advantages. Uh, one, it's it saved us from giving players whiplash with the camera turning. Uh, but it also kind of focused the players attention forward, giving it giving them constant momentum towards the end goal of the biome. Uh however, on the technical side of things, it forced us to deal with 45 degree diagonals. Uh which kind of sucks when you're talking about square grids. Uh but we put it into action and we looked at it and all of a sudden kind of all the issues for the uh the whiplash camera and all that

were kind of getting solved and we finally thought we were officially onto something uh and we decided to go forward with that. So, what we needed to figure out at this point was something that we refer to as our minimal set of tiles. And what that means is we needed to figure out what all of those road shapes ultimately had to look like in order for us to give Unity all of these different road shapes and have it generate our biome from beginning to end without any interference from the development side of things. Um, this was not easy immediately because with a one by one tile, if we had our exits um or entrances on all of the edges, that's kind of easy for us to visualize and figure out. But once we knew we were working with diagonals that had to cut across all of our square tiles, um, it became kind of confusing to figure out like what all of those road shapes had to look like. Um, and also we knew that once we figured out what all those road

shapes had to look like, we still had to maintain the art direction um for the game. Uh, so we knew that no matter what kind of grid system we were using or whatever kind of road shapes or tile shapes we discovered, we still had to make sure that this unified system could support us creating environments uh of so many different like flavors and varieties. So no matter what kind of uh grid system or procedural system we were coming up with, we wanted to make sure that it was able to handle creating something that looked more like our coastal biome, but at the same time creating something that maybe looked like our valley biome. Yeah. The big issue with this is that we had no guide book uh for a system like this. There's actually not very many uh games that do procedural generated worlds in general, but much less those that have road systems that cut across them. and then even less the idea that you don't have 90 degree turns. Uh so because of that uh you know we we knew that we were potentially creating a

system that could break in the hands of players and if anybody that's done anything with a procedural system knows that if there's something that can go wrong once it's in the hands of players especially potentially millions of players it will definitely go wrong. So, we set to test the system and we knew we needed uh to test it really thoroughly. However, we're still an indie team and we only had a QA team of two people. Uh, and that's way too small to test a system of this scale, much less considering that they have a full game to test as well. Um, so what we did is essentially co-opt our co-workers into testing it uh for us. And the the you know, without their knowledge actually. So, what I did is I rigged the game to generate a new world, a random uh biome every time someone would test the game and uh and then we rigged it to explode

uh if ever there was something missing and I would crash their test. And people don't like having their test crashed. So, they would come knocking at my door immediately. and we left enough breadcrumbs along the way to be able to reproduce the thing on my side and then I could identify any missing tiles quite quickly. Uh this actually worked really great if you think about a team our team who had about 25 people. If they're testing 20 times a day over the scale, you know, the the length of four years that it took us to release early access, that's hundreds of thousands of tests, which was really at the scale of what we needed to make sure this was robust. And it worked really great. We actually launched early access uh with zero generation bugs which I think was a huge success. And now this is uh essentially the 10 minimal set tiles that you need to create uh every map that's generated in Darkest Dungeon 2. If you're going to

take a photo of something, this is probably it. Here's your your your guide book. Uh so once we had these uh we could then set out to making variants and make the world beautiful again. And one of the advantages of having a grid system uh and in our case a square one is that you can rotate every piece of art that the team makes 90° and then you can mirror it as well which gives you eight basic variations of any one asset that the art team does. We also added some mutators so parts of it could appear, disappear and change. And combined that actually was a huge production boost uh for our art team and so much so that uh the art team that created all of the environments in Darkest Dungeon 2 is actually just three people which I find is quite impressive. Uh we'll have a quick little video demo for you now um from one of our newly created biomes. This is the catacombs biome. Um, and it's a cool example for us to show because it's the only biome

in the game that's really generated using only road tiles. And I'll explain what that means in a larger context in a second. Um, but it's just a really good example to show you all of these uh road tiles at work. [Music] So, right away when you start driving through the biome, um, you're already coming across all of these different no tiles and all of these different road tiles. Um, at this point you've probably driven through at least 10 different kinds of tiles. Uh, but because of how we set up the system, I feel like they all kind of come together pretty seamlessly. Um, sharpen your to make a cool doesn't really look like it's on a grid at all. So, no, I think it looks great. Yeah. So, at this point, knowing what kind of road shapes we needed, um like I said, for the most part, most of the biomes in Darkest Dungeon 2 are created using more than just row tiles. And so, at this point, we knew we had to kind of come up with um the different kind of t

different types of tiles that we knew we would need to create uh these full Darkest Dungeon themed environments. So, I'm going to quickly go over what all of those other tiles that we came up with are uh had to be. So, like I said, the first priority for us was our road tiles. These are the only tiles that the player really interacts with. They're the only tiles that the stage coach drives over. So, um they need to house all of the technical components. Uh they need to house all of the road bounds and all of the information that Unity needs to sew all of these road tiles together. Uh because they are the tiles that generate closest to the camera or closest to the player, they also have a lot of our environmental high-res art. Next one down the list are decor tiles. The these are the tiles that we had generating um right next to all of our road tiles. So they were very similar to the road tiles in that they had to house all of our high-res environment art, but they didn't need to have any of those technical components. After decor tiles

were generated, then we just kind of fill out the rest of the space with something we call background tiles. So, these were mostly there just to fill in the gaps in map generation so that you don't stare off into the void at any given point. Um, but because they're pretty far away from the camera, they didn't need to have any high-res art. They just kind of had low res art or even just in a lot of cases grids like 2D grids with um images with like alpha channels on them. And so now we'll have a couple examples for you um showing you all of these different uh like tile types getting generated one by one so that you can actually see the work that each tile type is doing. Yeah. So this is the farm biome which was a big open space that we mentioned before. Uh the algorithm begins by placing nodes which is that shrine you see uh at the right there. uh and then links all the nodes with roads and then paves those with road tiles. After that, it encircles all

the roads with the decor tiles, which is the high-res art that Mario was talking about. Uh and then this is what takes most of the players camera space uh as you're trudging along in this world. And if you see the little blank spaces that are left, those then get filled out with the background tiles and we slap a skybox on it to finish the whole look. This is our uh valley biome. And here we have uh like Colin said uh just the the first nodes getting generated getting tied together with all of our roads. Um and then after all of the roads are established uh the game will fill out the next space with decor tiles. Um, and decor tiles are really where we get to olude the fact that we're using like a pretty rigid square grid. Um, the decor tiles were created in a huge variety of shapes and sizes. So, we didn't just have decor tiles on a one by one space. We had them um in spaces that occupied like as big as a like a 6x6 grid and

everything in between. So once we created enough variety in our decor tiles as far as their shape and size goes, once Unity stitches them together, we get a lot of that art just like um layering each other nicely, really covering the fact that we're using like a pretty rigid um one planained square grid to create everything. Same kind of idea with our background tiles. We created them using a variety of different shapes and sizes. And as such, once everything was layered with all of those decor tiles of different shapes and sizes, we really just started to like lose the idea or the vision that we were using a square grid to create all of these worlds, which is exactly what we wanted. Y once we knew what all of these tiles had to be and what they had to look like, we knew that we had all of our puzzle pieces. Um, so at this point we wanted to try and figure out if we could take all of those pieces and assert a certain amount of control over them. Um, and so we knew at this point

we wanted to it was it's pretty much like we wanted it a way to control things so that we were choosing to paint things with a heavy-handed broad brush at any time or at the next moment choose a finer brush for some micro detail painting. So essentially what we wanted to do was we wanted a way to control Unity in order for us to generate biomes that maybe looked a little bit sparse like this, like our coast biome, but later on within that same biome tell Unity, hey, now we want to ramp up um how much art we see and have it be a little bit more densely packed. And so one way that we kind of uh set out to control this was with something that we called the placement value. And what that is is a numerical value tied to every single tile that we created for the game. Um that essentially told Unity its priority for um when it went to go pick each tile. And so ultimately um a

higher placement value was telling Unity, hey, we want you to pick this way more often than something with a lower placement value. Um, the problem with this though was that I just didn't understand what a specific numerical value meant uh to my outcome visually. And so in this example, we have a tile with a placement value of nine, but I had no way to like comfortably predict what nine meant to what I was going to see. And so, did nine mean I was going to see this tile like once every 10 seconds, or was I only going to see this tile like once per biome? Um, and I struggled with that for a long time. And this is where our artist programmer communication started to break down a little bit because like I said, I understood like what the numbers meant and like how the math was working, but I just couldn't like figure out like what I was going to be seeing visually and I just kept like trying to understand this and trying to like gro all of this

information and it just like wasn't clicking for me for like whatever reason. Um, and then this is when I started to feel like a little bit resentful, but mostly frustrated with myself because like it started to feel like we had this incredibly powerful system, you know, in our hands. But I just had no way to comfortably control it. And so, uh, when we wrote this talk, I actually tried to go back and look through my messaging history with Colin because I was like, I feel like this is something that I brought up like a whole bunch. And and it was it was something that I brought up multiple times over the course of about a year. Um and I just kept going back to him messaging him like asking, "Hey Colin, like you're going to need to explain this to me again because like for whatever reason, I'm just not understanding how I can like wield this placement value properly." Um and to be fair, I mostly thought it was a problem with me. I thought it was a problem with like my fundamental understanding of how the system worked.

So to be fair, she was really nice about it for a year. Um, uh, essentially what happened is that the moment that programming took over the idea of level design, uh, that's a really interesting problem to solve for an engineer, right? Uh and I might have gotten a little selfish and a little stuck into making the perfect algorithm. Uh you know that did all the placement of everything optimally and shifted the tiles and optimized shapes and you know trying to compose a beautiful environment. Um and essentially I got a little stuck in or you know in a in a rabbit hole trying to make something that was too perfect and high-tech. uh when actually what we needed was not that I make a beautiful environment but that I empower the artists who are the ones that make things nice uh to do that themselves, right? And so what we actually needed was a system that was really robust and

predictable that the artists could wield uh to make the environments beautiful. So uh after a year uh we I finally got the message and we kind of took a step back to find uh a solution to kind of reempower the uh the artists uh to do their best work once more. And the solution we came up was uh was something we called a tile balancing tool. So, this was uh kind of a command center that regrouped all the tiles for a single biome. Uh all their placement values and priorities and placed them all into one spot uh where Marielle could kind of sit like a, you know, someone that's at a mix table and adjust all those values in one localized location. Uh so that they would now be in context with one one another. Uh but more than that, there's a little te test button at the top there that might be hard to see. Uh but that button allowed

Marielle to adjust the settings and then press the button and immediately get a biome generation with actual data. Uh and then statistically analyze that and get feedback from the system of how often each of these tiles would appear. And then from that you can go back and readjust. So finally we kind of gave the artists uh the p the control over the system back again with this system. So this was a huge game changer for me. Um, at this up until this point, what I was doing to try and test my placement values were essentially just running booting up the game and running through these biomes myself and then kind of trying to take like a mental note of like how many times I was seeing all of my tiles, which is not the most like reliable way to gather statistics. Um, and so using this tile balancing tool was uh was awesome for me because all I really had to do was hit that test button and it would immediately spit out

exactly how many times Unity was picking all of my tiles. Um, so I didn't even have to load up the game or like run through any of these biomes to see my tiles in action. Um, this tile bouncing tool was telling me exactly how many times all of my tiles were getting picked. And so, um, with this full list of assets that I had fed into Unity, I could see if maybe a tile was getting picked more often than I had wanted or less often than I'd wanted. And from this same window, I'd be able to adjust its placement value, hit the test button again, and see if that affected things in the way that I was hoping. So, without this kind of control over the system, um, here's an example of what our farm biome looks like with all of our tiles at equal placement values. Uh what happens is that Unity ends up prioritizing all of the tiles exactly the same as one another. And so you start seeing all of the tiles all the time for the entire biome run. And as awesome as the art does look, um this isn't ultimately what we wanted for this

kind of biome. We wanted something much more sparse and open. And so once we were able to confidently apply that kind of control to all of our tiles in the system, then we're able to achieve something that art direction sets out to to want our farm biome to look like, which is great. So now we're going to talk a little bit about the artist programmer relationship. And now with hindsight and beyond the one year stint where we our communication maybe wasn't ideal, we actually think the results of this uh collaboration were really great and the environments that we generate were super beautiful and uh we wanted to bring kind of how that came to be uh to light. And so one of the main um lessons that we got is that uh the result of our cooperation was always better uh than our individual capabilities. Uh and this you know particularly uh with the

previous example with how uh empowering Marielle to do her best work clearly outpaced uh what my algorithm could ever do. Right. Uh another and the another thing that we thought went really well was that there was no clear owner for this feature. So this was a co-owned feature. Uh and because of that there was no decision like single person that could take a decision without consulting the other one. And so we would address any problems by coming to a table with solutions that we both thought were adequate to solve a problem. uh but then we'd have to negotiate it and see which one would actually be best and often it was always something that was a compromise between the two of us. Uh and particularly the advantage of something like that is that you can start taking a holistic view of the project in mind. Uh there's some cases where we were trying to hit a particular deadline and the art team uh had more time on their hands

than the programming team. And so we ended up doing a solution that was more art focused than it was programmer focused because we could balance out the needs of a team, the needs of the project as a whole. Lastly, um this this system once implemented uh gave the pro the artist um a a really unheard of uh amount of independence. actually uh so for our third biome, Marielle actually asked me uh to come to her uh to to her desk at some point. And when I sat down, I knew that they were talking about making a third biome. So I was expecting that it was about to set up all the v the variables and the environment for her to start working on it. Uh but to my surprise, she had actually already completed a first pass on the biome and had a fully drivable uh biome that I could even I could try. She was asking me for something completely different. And that was really shocking to me

because this was really early in the systems lifespan. Uh so getting your artists uh or giving them the capability to just work on their own without having to constantly negotiate for programmer time was a huge boon for us. And so much so that actually Marielle now I've like I've said at the beginning I'm now on my own uh doing my own thing at my studio. So I've left the project for about three years now but Marielle is the torchbearer for the system as a whole and the knowledge bearer for it. And so now whenever a programmer needs to modify something they'll come and see Marielle to see you know how does this work? We want to make sure we're not breaking anything and she gets to kind of teach them how it works which I think is really awesome. It's very empowering. It's awesome. Um, and so now we'll have a quick little video demo for you for from that uh biome that Colin was talking about. The one that I surprised him with was the forest biome. Um, this wasn't what it looked like at the time. This is what our forest biome looks like currently. Um, but it's a good overview

to kind of like show all of those systems in place and working beautifully. And so again, once you start driving through this biome, you're already going through all of these different roads, uh, no tiles, and even our decor tiles as well, seeing all of them kind of coming together pretty seamlessly to olude the fact that you're on a pretty rigid square grid. Um, and it's nice to see all of these um this like robust procedural generation working in conjunction with all the other systems in the game like VFX, UI, audio, and um and music as well to kind of like what I like build what I think is a really awesome Darkest Dungeon experience. Yeah, I love like scenes like this where the camera kind of dug digs in and really puts you inside the world. Um, I think at the end of the day, we did something really cool and I'm glad she understands of her work, but undertakes

it nonetheless. Okay. Uh, we'll have a couple quick takeaways for you now. Um, just to wrap things up. So, firstly, we learned that procedural generation can indeed prioritize art direction if that's important enough to your project. Um, like Colin said earlier, procedural generation systems are usually like a big uh programmer centric techled thing. But if it's important important enough to your game or to your project, you can kind of like uplift and uphold art direction and and crush and bend this system to your will if you need to. We also learned that uh the tile balancing tool for us uh was a really important milestone. So this is something that you'll have to figure out what the equival equivalent of that is for your project. But finding something that empowers in in this case the artists uh really has huge uh kickback for the project as a whole. So keep that in mind when you're making tools uh for

your project. Uh ultimately we learned that success looked like artist independence as well. Um, so like Colin said, we knew that we had succeeded and made something like pretty special or pretty robust when um it was clear to us that anyone on the art team could properly and confidently wield and control this whole system. And finally, that cross-discipline compromise is a bond to be counted on. Uh, in in this case, it's about the whole being greater than the sum of its parts. Right? Games are a hugely cross-discipline. uh piece of art and to keep that in mind essentially when you're actually developing it. So working with your other team trying to keep that on a level playing field so that their opinions don't get kind of overshadowed by anybody's ego uh you know for a year and uh and taking that into account uh will yield a much better product at the end of the day. Uh so yeah that's it.

That's our talk. Thank you for coming. Yeah, thank you. We have time for a couple questions. Yeah, if anyone has any questions. If you don't, great. Don't forget to fill out your evaluations. Thank you. Hello. Hi. Um, yeah, it looks really good. Uh, I saw you did a lot of like testing on the the programmatic side to make sure that the the generation system didn't break. Did you have testing or anything on the artistic side to avoid visual artifacts like just by random the same tree going past three times like Oh yeah, that was part of the whole testing process as well. Um and those things we kind of just fixed on the fly. So any kind of like art bugs we came across um if they were like rendering related then we'd have to come up with like a tech art solution. if there was like art that was overlapping things um or like kind

of covering up the camera in ways that we didn't like. Um that's actually something that came up a lot. Uh and we have a variety of ways that we solve that in the game. Um the materials are able to dither out objects that are close to the camera. Um and that's something that we can set ourselves per material. Uh we also had one of our programmers, Galen, work on a system that made sure that the camera never like uh ended up sliding like horizontally out of bounds um over some of the roads so that it never kind of floated off into any of our decor tiles. Uh yeah, there's a there's a whole bunch of systems that kind of like are in place to keep art on track as well. There's also for repetition uh you know, for the the idea of having like the exact same art like side by side. There's uh limits for when the generation creates segments of the biome. We kind of break it up into chunks and we can limit how often a tile can render in those chunks. And so by

setting that to usually like one per chunk, you're pretty guaranteed that you'll never have the exact same permutation like right next to each other. It'll it'll at least come up later on before there's a duplication. Yeah, sure. Could you bring up that slide again that had all those very important road tiles? Oh, the Yeah. Yeah. the guide the the guide book, right? Like the Yeah, those are all 10 shapes that you need to create uh Yeah. A procedural generation road system that uses diagonals and you want the roads to split into three. That's that's every single shape that you need. And you you need to cool. Yeah. You need to combine them with like rotation and mirroring to fix all cases. But uh but yeah, that's the minimal set. That's what you need. Awesome. Hey, so I have two questions, one for Ariel, and one for Colin. Uh the art question is is often when you're making these kind of talis systems, like visually the silhouette or or punchiness of a

particular asset only looks good from one orientation. Like for example, in the catacombs, it'd be very difficult to have like a statue facing the wrong way or or or a grave marker facing the wrong way, and it would just look wrong. How did you deal with the fact that like because it's a really sort of punchy art style, like how did you deal with the fact that a lot of those orientations would make like the silhouette look really good? Like how did you balance this looks good, but we want a lot of variation on the art side? Um, for the most part, we just tried to make sure that assets look good from most angles. um which is which was a lot of work, but um we ended up leaning I think a lot on just like hoping that the environments looked organic enough. We knew we were going to get like a lot of randomization. Um and so if there was anything, we never really had any like really ugly backside of like all of our buildings. Like we knew that we'd only ever see them from like probably one or two angles. And so there are a lot of cases where we take like the really nice side of a building

and put it on the complete opposite side as well because you're never going to see both of those sides at the same time. And so no matter what rotation the tile kind of ends up in like you might always just see like the nice looking side of it. Um, we also did have like uh rotation limits as well, which we didn't mention, but the tiles do have like on every edge of them, we say exactly what's allowed to be beside that edge. Um, so having a couple tiles with like some limitations on them. Um, also helps that. Yeah, some of the shapes also are not allowed to rotate or flip and so you could determine like, okay, well, this one needs to always face this time this way. So you could limit that, but that wasn't used very often because the arts always eventually was just kind of nice from every angle. Yeah, except for the node tiles. So those are the player interaction points. Those always looked good from one angle, but we had things set for the node tiles that were like whenever you come across a node tile, the camera is going to do the exact same movement and land in the exact same place. So we had control over that. And

in in terms of filling out like because it's not a regular grid system like you have like not one by one tiles if you had a particular arbitrary set of tile space how did you deal with like what do we put in it like you've got a 6x6 does it prioritize a 6x6 tile to put in it like I was just a little curious how that got decided outside of the placement value. Yeah. So so that was a original thing I had which was like prioritizing based on size with the assumption that like the bigger the tile the nicer it should be. And I had a whole system with that with like replacement values and it's like an empty problem because as you place something you're disallowing other things and that kind of thing. Uh and eventually uh you know ingrained in that part where I kind of rabbit holed like that that was into that and and part of the stepping back and kind of making something more robust was removing some of those kind of fancy algorithms. Uh and at the end of the day was just kind of okay like make sure we we wanted like

a even randomization. So we just kind of shuffle up the available uh tiles that can be picked to place something. We pick one and then we check what fits and from the high priority ones we'll pick one of those at random based on the placement values and all that. And then it's just like so long as it fits, we use it and then eliminate everything that got occupied by that tile as a future pick. Uh so yeah, so it it wasn't as complicated as it ended up being. It's just like try a bunch of variables and and then uh the constraints kind of clear each other out that way. Cool. Thanks. Awesome. Awesome talk. Um I wanted to talk about uh biome evolution. You showed a slide that had a fairly like empty road and then one that was more filled out with the uh the water level um with your tile balancing tool. Was that something that was like an animated value that changed over time or is that in the game or uh how does that go? What was that say? Like so so the question is about like biome variation.

Uh so for the the coastal biome how at the start it's kind of sparse and at the end it gets more populated. Yeah. Uh so you you know that system better than I can. So you Oh, like how did we Yeah, like so so he's asking if it's if the value changed over time and oh no the value was consistent but um what would happened was we actually had uh there there's another set of constraints that we didn't mention which is that we had like uh subtypes essentially. Uh the best example of that is in the farm biome. If you've ever played the game, there are sections that are just full of um only crop fields. And so we would come up with on top of the placement values, we also had like a tile subtype. And so for the farm, we had like here's our placement value. Uh this is a regular farm tile or it's a crop farm tile. And so we created like different sets of tiles for the same biome. But then knowing that we had different subtypes, we said like I I then had to take those subtypes and be like um this

crop subtype will only happen between like rows 2 and four, 8 and 10, and then rows like 12 to 13 or something. And so we had like another set of constraints saying like, hey, in these sections, use these tiles with these placement values. So it's Yeah. And they're like sub biomes. Yeah. Cool. Thank you. Yeah, no problem. Uh, hi. It was a great talk. Um, I was curious a little bit about what the loop with the art director was like and getting feedback for what was being generated. Like did you find that the tile management tool was basically the only tool that you really needed for, you know, generating consistent results? like did you find that you needed more of like a smoke test type tool to you know take screenshots or video of what was being output or what were you able to get it so consistent that you were able to just show it and it was right uh it was so the way that uh Chris Barasa

likes to art direct is very like he will closer to the end of a milestone he will just run through the biome itself or he'll look at screenshots that other people are posting and then if it looks bad he lets us know. Um, it's very like stream of consciousness like on the fly like he will he will be looking at the fans Discord and somebody will be posting like a photo of something unrelated and if he looks that if he looks at that screenshot and thinks that like something in the art direction looks bad, he will just cross-ost that screenshot to us and say this looks bad and that and then we get to figure out how to make it look better in all cases. is moving forward. Um, but for the most part, like when we're working on biomes, there is a pretty rigorous like feedback process where um, we're consistently taking screenshots and sending them to both Chris Barasa and our environment art director, Trudy Castle. Um, for all of our combat

arenas, it's the same thing. I take a screenshot um, with characters, without characters, like desaturated so that you just see the values. Um, and then we go through kind of like a feedback process uh, that way as well. So, we are consistently taking uh screenshots and sending it to Art Direction to make sure that we're like on the right path, right? So, just kind of as you're going, you're constantly, you know, taking screen grab constantly. It's it's a thing all the time. Even like the game's fully launched um and we're like still supporting it, but like it's the same thing all the time. If Barasa sees a screenshot that he thinks looks kind of bad, ugly. He let he lets us know. Yeah. Yeah. And it's pretty apocalyptic sometimes like the the pivot the pivot from like the plates to the grid thing was we had the plate system working went out for Christmas and in a standup 10-minute thing he was just like oh yeah yeah we're doing grids now and it's and I was like really like what and then it's just like scrap like months of work

but uh but it you know he knows like the where the art needs to be and and uh yeah know we got there So yeah. Yeah. Great. Thank you. Yes, please. Hello. Uh yeah, thanks so much for the talk. Um the art direction on Darkest Dungeon Games is fantastic. So you really great work. Um so the question I had, it might be kind of specific, but on an art style that relies so much on procedural generation and like heavily hand painted textures. How did you all approach like lighting your biomes within Unity? Did you rely on real-time lighting at all? No lighting. No lighting. Um, we don't we don't try to paint too much like very specific lighting into our environment art assets. There are a lot of other things that kind of uh like infer what lights kind of do. So, we have like a global fog system which helps us like layer distance and colors across all of our assets. Um, and on our characters, we have like a pretty robust

like lighting rig. Um, especially when you see them like up close in combat arenas and stuff like that. But for um for the most part, we don't we don't really have like a a full global lighting rig for our environments. Um that it's mostly driven by texture work. Okay. Okay. Yeah, I think there's a few dynamic lights on like the torch and stuff, but we got Yeah, we got some point lights, but that's mostly just to create like a bit of like interest points or slightly different color gradients across some of our assets and and no shadows and just because you want just the art to to be the star, right? Yep. Right. Okay. Cool. Thank you so much. Thank you. Thank you. Hi there. Uh, thanks for the talk. Uh, there were a few points where you guys kind of you said that you handed it off to Unity and it kind of stitched it together, right? When you were speaking about moving tiles, like how much of Unity's tools were you able to use out of the box? Oh, zero. None. So, when you say you massage, like you use Unity's standing for like procedural generation system

here for Yeah. Yeah, like I put it into the Unity project folder, but that was Yeah. No, all custom, all bespoke for for this game. And and yeah, if anything, Unity was a roadblock and like trying to slow us down, right? And we just had to plow through it like in the game. Yeah, that makes sense. Thank you. Yeah, no problem. All right, I think that that's 10. I think we're done. So Oh, sorry. I didn't see you. Yeah. Um given that it's such a artistd driven system wondering if you made use of any um like painting process like you would have a grid and be able to paint you know colors that would represent nodes or particular things like that. We we did for a little bit we tried using like vertex painting to come up with a little bit of variation in textures but um it just became a little bit unnecessary at a certain point because we're already hand painting all of our textures for all of our assets. And so any kind of like visual variation we wanted or got

out of using vertex painting, we just painted straight into the texture. Um, we tried it and we tried using like uh the poly mesh and poly brush tool in Unity, but again it just wasn't like it actually just wasn't a system that was strong enough to like support the art that we were trying to create. So no, we didn't really use any painting at the end of the day. Awesome. Thanks everyone. Thank you. [Music]