If Bethesda's detailed GDC presentation about modular level design kits for Fallout / Skyrim showed me anything, it's that modularity is actually a huge pain in the ass -- and not the good kind of ass pain either. Why should we keep building 3D levels in this slow, totally unnecessary way, with a workflow that's at least a decade old?
I remember a time when level design was slightly faster, and that time was the time of the brush. What if we could combine the benefits of modularity (variety / adaptability / abstract detail out of design) with the benefits of a brush-based workflow (simplicity / speed / focus on "platonic forms" of design)?
The Unreal Engine has a "procedural building" tool that automatically makes buildings based on a brush volume and it seems ideal, but you can't actually use it to design levels -- in the way that Epic appears to use the tool, these buildings don't have interiors and so they exist mainly as elaborate set dressing instead of something functional that affords exploration. That isn't what I want because I think it's way too specific to be useful. Instead, I want something one conceptual level lower: instead of a building that assembles itself, how about a floor or a wall that can detail itself?
These "AutoBrushes" would basically be design primitives that can be programmed to detail or deform themselves. Imagine a "rock" brush that automatically tessellates / deforms itself to make seamless caves, or a "forest" brush that randomly places trees and plants and birds, or a "Call of Duty" brush that scatters rubble along corridors, etc.
An AAA studio might divide the work like this: (1) an environment artist builds a tileset of 3D meshes, (2) a "world coder" would program a brush solid that automatically tiles, subdivides, deforms, and mutates these meshes -- and (3) the level designer would place these procedural brushes to make buildings and environments.
An indie workflow might look more like this: (1) an environment artist builds a tileset and shares them freely, (2) developers hold a "proc jam" to code the most interesting procedural brushes, (3) the brush data is stored in a special platform-agnostic XML format that can be fed into UDK, Unity, or any 3D game engine for people to use.
This is my current AutoBrush prototype in Unity:
- Each brush is technically planar and takes its rotation / scaling into account.
- Brushes have sets of "rules", which each spawn a random object every X units within the brush volume.
- In Unity, I hide all the resulting objects from the hierarchy and inspector, so I only deal with the brush object itself.
- Spawned objects are just regular Unity gameObjects; they could be NPCs, or particle systems, or even other brushes.
So in this example, I have a STOREFRONT rule that spawns a storefront piece on the bottom level, and a WALL rule that spawns windowed pieces above the storefront, and a FIRE_ESCAPE rule that spawns fire escapes haphazardly. I could also add an OCCUPANTS rule that could automatically spawn an NPC in each window, or maybe a PATHFINDING rule that automatically spawns pathing nodes for each floor, etc.
The exciting thing about AutoBrushes would be their procedurality and possible recursion: they could instantiate other AutoBrushes, so you could probably program a floor to grow its own walls. However, chances are that this building probably wouldn't look "real", i.e. crafted by a human. Handcraftedness and humanity is great and all, but they are just tools -- and if we worship tools as ideology, they become oppressive standards. I think a lot of the difficulty in using procedural generation is less about the engineering, and more about the politics / context that frame procedural generation in games. It's about ceding control to an algorithm and learning to be okay with the results, or even valuing strange glitches over "what looks right as crafted by humans."
When procedurality tries to pretend it's human, you get Oblivion's randomized NPC faces, jarring and grotesque. But when it stops pretending, then we can accept it for what it is and learn to value how utterly strange and surreal the faces are. The lack of humanity is what makes these things compelling, e.g. dungeon design in the roguelike genre, or the infinite landscapes in Minecraft.
There, the politics of procedural level design imposes a certain flavor of harsh realism. I marvel in the beauty of getting fucked, how all these random coincidences snowballed with my choices into calamity... into me, being utterly unable to find a single block of coal in Minecraft for an hour. Now, was that an unbalance to be eradicated, or did it produce a fantastic desperation of dark fire-less nights spent huddled in damp caves? Unfortunately, Mojang treated it as an unbalance and added charcoal in Beta 1.2, thus removing the possibility of that edge of experience from the game, forever.
Yeah, the ProcWorld guy, Miguel Ceprano, is doing great work... but I don't know if I care for the results so far. So far he's just focusing on another safe idyllic landscape that anyone could've pulled out of World Machine; at this point, you're basically training a computer to make a Thomas Kinkade painting.
A procedurally generated Thomas Kinkade painting cannot fuck me. They fuck no one. These landscapes are utterly incapable of fucking. That's why my mom decorates her house with them.
(Counterpoint: Joan Didion would disagree with me, and argue that Kinkade was actually the most cynical / sinister painter in the history of evil who fucked everyone and everything. "... Every window was lit, to lurid effect, as if the interior of the structure might be on fire." Oooh, creepy!)
To me, the most important question to ask is, "what are the politics of procedurality?" What values do certain uses of procedurality connote to us? What does it mean to players, developers, and communities, and what are our futures? What are the actual images and visions that we will produce -- a Kinkadian hellscape of pastoral 1950s American utopias, or something that's actually interesting?
PREVIOUSLY: "On Joiner, detail, and the cult of greeble."
