A rough initial attempt at level generation.

About one month ago, I saw a job posting for an associate level designer for Diablo 4. The top-down, isometric, hack-and-slash ARPG that the original Diablo defined has held a strong fascination to me for quite some time. While I’ve never gone too far into the grind on any single game, I have completed the original game twice and got to torment…2 or 3 on Diablo 3. This, combined with interests in level design and procedural generation made this small project too irresistible to pass up.

The first stage in any project is research, so I scoured Gamasutra for resources. The most useful came from Youtube, a short talk given by Ed Hines about Diablo’s level generation. The talk was presented at Blizzcon 2016 and provides a rough overview of how the designers used their tools to create algorithms to generate the dungeons and the tile-based nature of the generation. I was surprised to find out the Diablo 3 utilized a tile-based approach, as it’s dungeons and environments felt very organic. I was able to identify that it was the offset tile entrances and large size of the pre-designed tiles that helped to mask the underlying system.

With this in mind, I needed to decide an engine for my project. I choose Unreal Engine 4 to use the level streaming systems I learned from Edinboro University. Each tile would be built as an individual scene, then a separate scene would be the master and load them into their appropriate locations, based on the tile’s location in the pre-built dungeon.

Before worrying about how to generate the dungeon dynamically, I first needed to make sure I could create a dungeon manually. This helps to elucidate much of the underlying structures and classes that the generator will eventually need. The FGenericTile structure, implemented in UE4 as a UStruct, is a data only structure that indicates which exits are opened and closed. A UGenericDungeon class was then created to be the abstracted container for the tiles. The tiles are stored in a TArray, a UE4 friendly array that can be manipulated in blueprints, but the Dungeon class also has several helper functions, such as converting an integer to X Y Coordinates and vice-versa.

I originally created the Dungeon class in C++. I would like to get to the point where I take care of game logic in C++ and only use Blueprints for visuals and animation, so I’ve been pushing myself to put more into C++. After several weeks of crashes, however, I was convinced to implement the dungeon in Blueprint.

I originally wanted to keep the class that generates the dungeon structure seperate from the actor that loads the tiles in, but they ended up merged by the end. For initial testing, I specified a path from 0,0 to 4,4 in the dungeon, then tweaked the scene loader until the correct scenes were being loaded in. Once this was lined up, I began to implement an algorithm for generating the dungeon.

I pulled Spelunky’s critical path generation as a starting point. A quick summary for those who don’t know, Spelunky uses a 4x4 grid for its tiles. It starts by picking a random tile on the top row, then traveling left, right, or down into it would leave the grid. I figured additional wander nodes can be added to create branching paths, however I was unfortunately never able to get the generator to work quite as intended. However, the results I got are not horrible, so I figured I had a good enough minimum viable product for level generation.

The tiles themselves were the next step. Instead of using a traditional dungeon setup, I thought I’d spruce things up and go for a forest aesthetic. Going forward, I;’m hoping to add more tile sets, but this was enough for now. I purchased a humble bundle some time ago that had several of Synty Studio’s polygon packs, so I used the Adventure pack to create one tile for each configuration. In theory, my tile level streamer can pick one tile randomly from each category, but each category only has one tile at the moment.

I’m sure I missed things in this short term retrospective. Going forward, I’d like to add additional abstraction so the levels can be given different generation algorithms more easily. I’ve got plenty of bugs to work out first though, and of course more tiles should be added and the noticeable issues in the current ones should be cleaned up. I’ll probably be increasing the size of the tiles in the future and adding a trigger in map at the end of the dungeon to load the next level.