About Game Development are short essays exploring the world of game development at Bethesda Game Studios. Today’s post is about broken windows.

Our games here at Bethesda Game Studios are complex, sprawling epics with layers of systems, reams of data, stunning art and audio and hours upon hours of fun made by our talented creators of all stripes. Underlying all of that is thousands upon thousands of lines of source code to make it all go, from editing gameplay data to exporting and placing art to actually running the game itself on one of several platforms.

This makes for lots of challenges, and among those challenges is the shifting sands of years of development by dozens of programmers. In the sixteen years since we released The Elder Scrolls: Arena, there have been a lot of changes in the ways games are made (and in the sizes of teams needed to make them) and choices that made sense on the PC-only market we started sometimes make less sense in the light of changing times. Taking this with the constant influx of gameplay, art, and code to a running game in development, one of the biggest hidden risks is “Broken Windows.”

“Broken windows” is a term taken from sociology, specifically criminology theory. The basic idea is that while few people will vandalize a public space, once it has already been vandalized there’s a lower barrier to entry. For example, an unoccupied house without any broken windows will stand unmolested for a long time — but as soon as one window is broken, other broken windows and forms of vandalism are not far behind. It’s actually even a little fun to break a window when lots of others are broken, as even as estimable a character as It’s A Wonderful Life’s George Bailey would tell you.

One key to a successful neighborhood is to keep those broken windows to a minimum; to fix them as fast as you notice them, so you present a great place to live that people want to keep looking nice. For those of us who get to make games for a living, fixing our own broken windows quickly makes an already great job even better.

Some of our broken windows are obvious — they’re the little crash bugs that crop up as new systems are added or as we optimize the code to squeeze every bit of performance we can out of a machine. Others are less so, like missing normal maps or quests that aren’t quite wired up right, though often we can provide warnings to the content creators to let them know the data looks a little askew, and those warnings are themselves broken windows.

The engineering team strives to minimize the time we allow broken windows to stay in the code. We leverage our tools to give us better information about what windows might be broken by turning up all the compiler warnings and fixing even the ones that don’t seem to matter all that much. We do peer review of code, whereby every bit of code that goes into the game gets looked over by another programmer to check for any gaps where crash bugs or other errors might creep through. And we commit ourselves to keeping our artists and designers productive: every time anyone crashes in code we wrote here, we give them an opportunity to tell us what they were doing via a pop-up dialog and put as much information we can about that crash into a database so we can both track it and identify it.

Our artists create great art by constantly keeping each other to higher standards of beauty (though in the case of a super mutant, beauty may be in the eye of the beholder). Our designers constantly push each other to reach higher and higher quality gameplay and narrative. As software developers, the programmers in the engineering department are trying to find ways to do the same thing. We hope you like the results.

[Our artists create great art by constantly keeping each other to higher standards of beauty (though in the case of a super mutant, beauty may be in the eye of the beholder). Our designers constantly push each other to reach higher and higher quality gameplay and narrative. As software developers, the programmers in the engineering department are trying to find ways to do the same thing. We hope you like the results. ]

Yay verily tis good like thee frothy mugament Thank you Bethesda for so many years of joyful spirits. Wow 16 years and so much new technology has evolved from the days when a 2 meg game was considered humongous.

I like this essay. I would paraphrase it as “the more appealing an environment, the more time people want to spend in it,” a worthwhile lesson for pretty much anyone who creates anything. One implication is that I assume the same principle applies inside and outside the company — just as I’m more likely to spend time gaming in a nice neighborhood, I imagine content creators are more likely to put in a little extra work when they enjoy what they’re creating.

I love the results, even the ones that now look outdated (Arena, Daggerfall). I still play Morrowind, and would be perfectly happy if the graphics were dialed back in future in favour of more complex game mechanics. (I’m in the function over form camp!)

Although the only thing I truly want from TESV is Inteligence, no more dumbing down!

“We leverage our tools to give us better information about what windows might be broken by turning up all the compiler warnings and fixing even the ones that donâ€™t seem to matter all that much.”

It’s a good practice (ratcheting up the compiler’s warning level). It used to be an even better practice, before strong LINT packages were so easy to find. But I hesitate to call it a “best” practice for two reasons:

– Compiler warnings in Visual Studio (and comparable compilers) are poorly designed. Poorly worded, poorly framed, and (occasionally) inconsistent. But the big problem: too many false positives. Although it’s nice to talk about max conformance and Warning Level 1, no compiler was actually built with this in mind. Compiling with warnings ratcheted up is a usability mess.

– Although compiler warnings can help you triangulate potential errors/impedance mismatches at the syntactic level (the classic case would be those legal-but-occasionally-harmful-and-crash-inducing data conversion mismatches), most of the broken windows don’t originate in syntax, or in anything that the compiler actually checks. They originate at the level just above syntax, or in the detailed design.

– Which is why I’ve said for years that major C/C++ compilers should ship with a robust, customizable LINT module, integrated into the box. There are add-ons that will do this but they’re not used widely enough. It needs to be something that runs by default. Compile, Lint, Link.