- Joined
- Jan 28, 2011
- Messages
- 99,616
Tags: Adam Heine; Chris Keenan; Eric Schwarz; InXile Entertainment; Techland; Torment: Tides of Numenera
With the conclusion of Gamescom and PAX West, inXile have published a new Torment: Tides of Numenera Kickstarter update with a recap of their visits, including links to the media coverage the game received. Naturally, the Codex has already reported on most of that coverage, but as with most Torment updates, inXile have added a little something extra. In this case, an overview of the development of the Necropolis, a massive network of hexagonal tombs that they designed in order to house the nearly 4000 tombstones and epitaphs owed to high-tier backers. By using procedural generation techniques and fancy visual effects, inXile scripter Joby Bednar was able to make one room stand in for 625 different tombs, each one accessible by entering the proper code. Here's an excerpt from Joby's report, plus a new Torment trailer from Techland to spice things up:
With the conclusion of Gamescom and PAX West, inXile have published a new Torment: Tides of Numenera Kickstarter update with a recap of their visits, including links to the media coverage the game received. Naturally, the Codex has already reported on most of that coverage, but as with most Torment updates, inXile have added a little something extra. In this case, an overview of the development of the Necropolis, a massive network of hexagonal tombs that they designed in order to house the nearly 4000 tombstones and epitaphs owed to high-tier backers. By using procedural generation techniques and fancy visual effects, inXile scripter Joby Bednar was able to make one room stand in for 625 different tombs, each one accessible by entering the proper code. Here's an excerpt from Joby's report, plus a new Torment trailer from Techland to spice things up:
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.
As for the future, Colin McComb will be attending EGX on September 25th to talk about Torment's story some more. But beyond that, I'm not sure. The game is content complete now, so I guess they're just going to release some hype material every now and then until it releases early next year.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.
