War in the North, the Character Pipeline in Production
Severing, status-effect materials, and character lighting, on a game that shipped.
The Lord of the Rings: War in the North is a co-op action game where enemies come apart, get bloody, and get covered in snow. Every one of those is a character pipeline problem, and each one multiplies against every character in the game. Solving them per character was not affordable.
Making characters sever properly was harder than I first estimated. Material IDs had to be organized in a specific layout to keep draw calls down, and we found that layout by trial and error. Every character needed two versions: a cheap one with few materials and no severs, and an expensive one with roughly two dozen sever points and the materials to match. Maintaining both by hand was the real cost, so I wrote a design document for a build-machine feature that did the copying and renaming of meshes, materials, and material IDs to produce the cheap model automatically. After that, technical artists worked on the severed mesh only and the build machine generated the other one.
I designed the material structure for every character in the game. Artists customized a base shader for the needs of their character, and a second shader layered over it carrying the procedural status effects: blood, water, frost, dirt, and snow. Our engine and tools, which I helped design, let the procedural materials update as a template that populated to all characters automatically, so I could iterate on the look quickly. I had damage and wear driven by the durability attribute as well, but scope cuts left that on player weapons rather than armor.
Lighting in the Snowblind engine was separate from environments. I set up all character lighting for the game, with multiple zones in each level, and lit the cinematics and conversations. I also took a large role in designing the lighting system itself: suggesting features, developing techniques, and driving the feature set.
I noticed the undersides of skirts were reading too bright, because our lighting did not shade them the way a player expects. I worked out that I could solve it with simple material adjustments: two-sided lighting on a planar mesh, with a falloff driven by distance to the ground, so the underside darkens as a character jumps. It approximates bounced light from the ground closely, and it took no engineering support.
None. This work predates the tools by more than a decade.
The Lord of the Rings: War in the North shipped in 2011. A new character could enter the game and pick up severing, damage materials, and lighting without a technical artist touching it, and the build machine removed the duplicate-model maintenance that would otherwise have run the length of production.
The severing work taught me to look for the maintenance cost rather than the authoring cost. Building two versions of a character is a day. Keeping two versions in sync across a two-year project is the thing that actually breaks a team, and that is what the build-machine feature removed.
Nobody assigned me the skirt fix. I noticed the undersides were reading wrong, worked out that the material could handle it without engineering time, and did it. I am picky about how a character reads in motion, and most of what I catch is at that scale: a value sitting too bright, a deformation that pops, a highlight where the eye does not expect one. Small things at that size are what separate a character that looks finished from one that does not.
Handing the repetitive half of character setup to a machine, and keeping the judgment half with the artist, is a decision I first made here in 2010. I make the same decision now when I decide what an AI tool should do and what stays with me.