​

First up, how are the tombs arranged and how does one navigate them? We went through a number of designs to try to make things work, each of which ended up being their own stories to tell – suffice it to say though, they didn't fully meet the needs set by Adam or had weaknesses that made them hard to implement or difficult for the player to navigate through.

Eventually, after many discussions, what we decided on was a massive honeycomb of hexagonal tombs. Within each tomb, you can see the neighboring tombs. There is a central control room overlooking them all, where you are able to punch in an address on a hexagonal keypad where the player could enter a specific code. Within each tomb, there is a duplicate control panel that allows you the additional option to press one of the six outer hexagonal segments to teleport to one of the six neighboring tombs. Below you can see roughly what this would look like when represented visually.

[...] But those are just empty rooms. It became clear that while we wanted each tomb to look similar, we also wanted them to appear slightly different from each other so that players would know something changed when they went to a new tomb. This meant creating quite a few art assets that we could populate each tomb with for each individual backer tombstone and monument. Our artist Daniel Kim created a lot of these designs which we were able to assign to each individual tombstone and monument.

To create the hundreds of combinations of these assets and make each tomb look random, but not actually be random, I leveraged Unity’s built-in functionality for Perlin Noise. If you’ve played or seen Minecraft, then you are familiar with Perlin Noise and procedurally generated content. Two-dimensional Perlin Noise is effectively a grid of random-ish values, and by using a set algorithm we were able to generate the massive amounts of content, but have it be the same for every player rather than changing every time you play the game.

Furthermore, by leveraging an algorithm instead of needing to predefine everything, we could protect ourselves from memory bloat and the true beast of game development: iteration. I’ve never worked on a game where the initial design was implemented exactly as initially designed. Iteration on your design is always going to happen, and you need to expect it when developing system architectures. If I had developed a system where all this was pre-generated and stored in data files, my job would have been much harder if anyone was inspired and had a "great idea." Any changes would have required a lot of work to modify, show, refine and iterate upon again, so the algorithmic approach saved time in the long run.

This became relevant when it came time to start playing with the Necropolis in the game engine and design feedback began to come in from Adam, George and others. For example, to help ensure that each tomb felt interesting to visit and somewhat distinct from the last, I set up different configurations so even if multiple tombs had just four tombstones, those tombstones would be arranged differently. For the tombs that had a single epitaph, the epitaph might be in the center of the room or against the back wall so that it would stand out better and look like it was placed naturally.

So, what does this end up looking like in the game? When the player reaches the Necropolis, what they'll see is a massive expanse of tomb chambers before them, a control panel at the center, and the option to enter a 4-digit numeric code to navigate from tomb to tomb. And of course, each backer who has a tomb will be given the code to theirs so that they can go and find it in the game – but you'll also be able to visit the tomb of anyone else, either by exploring manually or entering their specific address.
​