Why procedural levels were better than handmade ones for City of Brass

Down in Australia, a number of BioShock veterans have spent the last decade building their own studios, creating a succession of games that carry on some of the core game design philosophies of Irrational Games' adventure under the ocean. 

One of those  studios, Uppercut Games, recently released City of Brass, an early access dungeon crawler that feels like a faithful translation of some core BioShock mechanics. It has a clever one-two whip-slash system that recalls BioShock's "shock & wrench" mechanic, and even though its level design is procedurally generated, some of the core principles that brought Rapture to life have been rewritten in this game inspired by the classic story of 1001 Nights.

Since we're always curious to see how games like BioShock have impacted the game development world, we invited the Uppercut Games crew onto the Gamasutra Twitch channel for a chat about what's under the hood of City of Brass, and what they've learned since striking out on their own in the land down under. You can watch our full conversation up above, but in case you're cooking up some procedural magic yourself right now, here's a few quick takeaways to help your next game. 

Procedural generation can still use good level design logic

While talking with designer Ed Orman and art director Andrew James, Orman shared some of the core design logic that keeps City of Brass from feeling 'random' while still creating different spaces each time the player attempts a run. After starting work using a plugin from the Unreal store, Orman said that the Uppercut Games team began modifying the engine to generate spaces using some of the design tricks learned on BioShock, like building specific walls to limit player line of sight and clustering traps and stairways in order to create choke point obstacles. 

Like many developers we've spoken to about implementing procedural logic, Orman said that during development, the team learned that "random" levels never really felt random or fun, so the key for each successive level was to also give it an underlying logic that the engine could draw on to build spaces. For instance, the market level (which was...about as far as we could get during our stream) always generates as a kind of circular donut, mixing up the streets between rooms while relying on a set of specific room logic that creates unique challenges for that level. 

Why procedural generation helps game artists

While procedural generation can lead to some great games, it's also worth noting that it's not a magic problem-solver. But according to James, switching to procedural generation has increased the amount of time he's spent creating new art assets and implementing them across the game, rather than fixing art assets that have already been implemented. 

As an example, James pointed to a set of archways that acted as a "door" to split certain areas off, and explained that those were a relatively late addition in the development process. But through the procedural tech, he explained it was easy to see those arches throughout the generated levels, rather than diving in to add an arch to every specific opening. 

And, James adds, this kind of workflow meant whenever an art asset bugged out, a fix implemented for one part of the level design would also filter throughout all the assets elsewhere in the game. Both Orman and James said this kind of time-freeing solution meant while they might not do another roguelike after City of Brass, they would be interested in using procedural tech to build single-player levels before implementing them in their next game.

When working with changing levels, your players need all the anchor points they can get

As our conversation with Orman and James continued, we switched over to the game's art style, which the pair said is one part direct from One Thousand and One Nights, another part from European Artists of the late 19th century who drew paintings of Middle Eastern life (writer's note: this art obviously exists in an extremely political context). While it was interesting to hear James talk about building an art style out of history rather than just looking toward other games set in the Middle East, it was also interesting to hear the pair talk about how they were sometimes forced to rely on 'popular' understandings of Middle Eastern mythology rather than drawing on the book directly, because with the space around players changing constantly, there wasn't time to introduce them to unfamiliar ideas. 

For instance, there's the game's "genie" system (genie, djinni, the problem's already evident), where players can interact with the mythical beings in order to purchase items, save money for another run, etc. Originally, James says he designed these beings to look more like they were physically described in 1001 Nights, but players just didn't know what they were/what purpose they were supposed to fulfill. With Disney's Aladdin and other Western takes on the culture so prominent in media, players found anything other than something resembling the Robin Williams character to be confusing to look at. 

Both Orman and James, who excitedly rattled off examples from One Thousand and One Nights of what art examples they tried, admitted this is a problem they would have loved to have tackled in a broader context, but with such limitations on getting the game out the door, they chose to stick with the character currently seen in the game. While this example is definitely a lesson in understanding what your players know vs what you have to teach them, it also highlights the choices developers need to make when they need to decide how much they can even teach in the course of designing a fun game design loop. 

For more developer interviews, editor roundtables and gameplay commentary, be sure to follow the Gamasutra Twitch channel.