"I’m a programmer. I can push around the producers, but the level designers won’t listen to me."
— Jeremy Wood

Veteran programmer Collin Murray described Jeremy Wood, whom we hired straight out of college, as “a guy who is scary-perceptive for someone who’s never worked before.” It’s a universally perception that level designers don’t listen—that we build however we please, regardless of limitations set by the programmers. But let me take this opportunity to offer a bit of defense for my fellow level designers: We listen, but we also have other considerations. We’re the center of development’s Venn diagram. It’s our job to make locations render smoothly; while telling a story; while making the world beautiful and immersive; while providing areas suitable for gameplay. In serving our varied masters, we sometimes forget our limitations. When we discover something cool, concessions often must be made. Sometimes our hacks create more work for other departments, who help us pull off our tricks. It’s a balancing act of robbing Peter to pay Paul.

For instance, I once butted heads with the programmers over transparent water. Our opaque water wasn’t popular with the art team, and it prevented me from seeing my submerged temples in Blackfathom Deeps. I’d asked repeatedly for transparent water tests, but the programming staff said they were swamped with higher priorities and didn’t have time to fix “sorting issues”—which were graphical glitches when multiple transparent objects appeared in front of one another. If spell effects (which used transparent textures) were cast in front of transparent water, they would appear to be underneath the water’s surface. Not good, right? And sorting issues were a messy video card problem, and since all video cards worked differently, it was a major pain in the ass to correct.

However, I wasn’t convinced. I scaled-up one of our props that used transparent textures and used it as a mock-waterline to see how bad sorting would look—and the result wasn’t bad at all. The sorting issues were only noticeable when I channeled from the shoreline into the water. The “ribbon” VFX hiccuped when they overlapped the water, but it was utterly unnoticeable in the heat of combat. The entire dungeon team was so excited that we showed the producers, and Shane gave me his thoughts. “John, I know you’re super-excited about this, but you have to let us handle it,” he explained. It was a delicate situation, and he just wanted to be the one telling the programmers they were wrong. Everyone had been working late hours and Shane didn’t want to upset anyone. “I promise you,” he continued, “we’ll implement transparent water, but it might take a little time. Please, don’t tell anyone else.”

Shane was talking to me like this because I had a reputation for being a ninja and sneaking things into the build of the game that weren’t approved or on a task list. I’d always earned autonomy in the workplace by working longer hours than anyone else—and my situation at Blizzard was no different. I established a gentleman’s agreement with the producers that I could build extra dungeons on weekends and after hours if I completed tasks already assigned to me. I found trust like this to be liberating, empowering, and generally made my time on the job more comfortable. I ended up making so much content, the game designers urged the producers to treat me with a hands-off approach. Because I worked on whatever I wanted, people often came to me if they needed something major to be improved—or ninja’ed in. Since the producers were wise to my ways they always kept an eye on me to make sure I wasn’t creating work for other people.

But transparent water was a different story. This time I had gone behind the backs of programmers after they had doubled-down on insisting that they didn’t have time to fix sorting issues. In truth, the programmers were correct—there were sorting issues, but what they didn’t realize (and what my test had demonstrated) was that the sorting errors were mostly unnoticeable. Aside from myself, the programmers were working longer hours than anyone else on the team, so reversing one of their vetoes would be a touchy prospect. Shane was perfectly reasonable in wanting the news to come from him instead of a rabble-rousing level designer. I certainly didn’t want the heat, so I let Shane add the task to the programmer’s workload in his own time, so I promised to keep my big mouth shut. But what Shane didn’t do was tell the other level designers the same thing, and they promptly blabbed about the discovery to half the office.

Later that day, a group of artists came over to my desk and insisted that I show them this Promethean miracle of transparent water. I protested, but they weren’t having any of it. They told me the whole team already knew and crossed their arms, saying they wouldn’t leave until I showed them. I relented just to get them out of my office. And wouldn’t you know it, Shane walked into my office at exactly that moment. Before I could get a chance to explain what had happened, he walked away, shaking his head in exasperation. That should illustrate what it was like to work with level designers. We are troublemakers by nature. We spend so much time on a single file or area that sometimes we become too fixated on forcing things to happen.

I’ve always found case-by-case problem solving yielded better results than fiats coming from department leads who didn’t quite realize the whole “robbing Peter to pay Paul” thing. For instance, I ignored our object size limits while building the thorn canopies for the Razorfen dungeons. After Scott Hartin informed me why the engine couldn’t handle my giant canopy I built it a different way and he subsequently gave me a different veto. Over several weeks we went back and forth until eventually we ended up working out the problem together (Scott tweaked the code to make an exception). The result was that Chris Metzen’s vision of being inside a giant thorn bush was realized.

And I wasn’t the only one making waves. When Aaron Keller was told we couldn’t place freestanding buildings directly on the terrain for complicated pathing code reasons, he placed tepees and tents in Thunderbluff anyway, and we discovered that the pathing problems weren’t as bad as initially feared. Dana Jan built his Deadmines bigger than our engine’s “farclip limit,” which forced programmers to increase it—and we learned bigger rooms didn’t produce performance problems. This proved to be a valuable lesson for creating “epic” areas.

As ornery as the dungeon builders were, the exterior level designers were worse (or so we were told). The programmers were so frustrated by the overuse of props in some areas (which deteriorated the engine’s performance), that they often went to the producers to arbitrate compromises. Butting heads was a good thing; it meant employees were passionate about their jobs, new things were discovered, and the game’s limits were stretched with coolness.