(This article is a repost from my personal blog at www.gamearch.com)   

In this post I’ll talk a bit about the goals and requirements of good level design. This thing has grown out of my architecture degree and the numerous lectures I held on the subject of level design – especially those with architects-in-training as their audience. So if you’ve sat in on one of them, this will propably be familiar.

So before I get into level design, I’ll first have to talk a bit about architecture. Thousands of years ago, the roman architect Vitruvius identified what he called the three “qualities of architecture”. They are as follows:

• Firmitas, stability. The building stands stable on it’s own
• Utilitas, usability. The spaces created by the building are suited for their intended use
• Venustas, beauty. This building has a beautiful aesthetic

They do make sense, right? Admittedly categorizing things is often arbitrary and can be argued for or against but I kinda liked that setup, where each layer is building on one another. If your building isn’t standing safely, it doesn’t matter much if your kitches is perfectly laid out. And if your doors are too small for people to get in properly, then it doesn’t help that the aesthetics are wonderful – the building itself is still a failure.

Now I tried transporting this divide over to level design, and this is what I got:

• Firmitas, stability. The level runs well without any technical or performance issues
• Utilitas, usability. The space does a good job at leveraging the game mechanics
• Venustas, beauty. The environment creates an atmosphere and provides affordances.

I’ll elaborate a bit on these three qualities and how I think they relate to level design as a discipline:

Firmitas
As mentioned before, this is a pretty basic category. A sort of minimum requirement if you will. If a level fails to fulfill it, it ceases to be properly playable due to technical issues. The two main areas here are stability and performance.

Stability as I see it refers to the level not crashing and breaking the game. Nowadays it’s usually quite hard to do that with a level itself since most engines are quite robust. It could be doable though with the level referencing a file that doesn’t exist or something similar. Also if there’s some sort of level script then that might be another source of errors. Of course if such a crash is very very rare it might not affect playability too much because it’s really hard to cause it. Still it’s a flaw in the “foundation” of the level. This can be avoided by working cleanly and paying a lot of attention. It might still creep in but that’s what the QA is for…

Performance is the other side and means that the level is running properly. Again this has become a bit less of an issue with higher end systems but it basically just means that your level doesn’t suffer from stuttering and frame-rate drops. In small amounts this can still be bearable but if your multiplayer level slows down to a crawl because there’s 6 players and 2 explosions, then you’ve done something wrong. This is often at odds with the graphics of a environment – the more detail you have the more your performance will drop. In the end it comes down to a balance between the two. And of course there’s a lot of clever tricks and thught out optimization involved. Everything from detail brushes to visportals and distance fog/culling. Whatever will do the trick.

Utilitas
This aspect of level design deals with the design of the actual play space. That is to say it defines the space within the player moves. I’ve talked (or at least tried to) about my definition of the digital play space some in my last (somewhat controversial) rant about how level design is game design. I’m afraid I failed somewhat since there were a lot of misunderstandings there – but I’ll try again sometime, maybe visually. Alright, slightly off course here, Let’s get back on track.

Utilitas defines the boundaries within which the player(s) move(s). It directs the flow of play and it’s job is to iteract closely with the game design to provide the intended experience (which doesn’t neccessarily have to be “fun”). It’s worth to note that these spatial constraints are what make the game possible and if they are changed, the possible experience is too.

The details of what Utilitas actually entails are too many to mention. This surely would be a great project quite similar to the 400 Project from Noah Falstein and co. but goes beyond the scope of this article, especially as these are highly dependent on the genre and game design involved.

These goals can range from anywhere between controlling the flow of players within the space to providing obstacles and challenges for the player to overcome.

Venustas
The words original meaning and the quality as it relates to architecture refers to beauty. That is to say that buildings are supposed to be pleasant to look at. This makes a lot of sense if you consider the fact that buildings are quite permanent construct and having a disgusting building in the middle of town could be considered visual terrorism for some sensible eyes. Of course back then Vitruv didn’t know or write about theme parks and other types of experiential architecture. There being “ugly” can sometimes be goal.

And the same’s true for levels. They don’t need to be beautiful, instead their goal is to evoke a mood, an atmosphere. So following that tenet, everything that relates to the creation of mood and visual references is part of this category.

Admittedly there’s some overlap with Utilitas since the visuals affect usuability. For example when putting moody lighting in a scene the designer needs to take care that the important areas are still visible. Or when trying to use visuals to steer the player. That said, for the sake of easier categorization it’s safe to put everything that doesn’t affect the space (textures, light etc.) directly into this category.

Besides mood and atmosphere, there’s a few other jobs that the audiovisuals of a level can do. A quite important (and easily overooked) one is that they can create associations. Familar visuals can cause certaun expectations in the player and they establish a frame of reference. If there’s a castle on a hill, odds are that there are going to be guards and that there’s something worth guarding there. Expecting some sort of ruling body there wouldn’t be too far fetched either. Of if there’s a door it might suggest that it can be opened. All of this are helpful cues to help the player figure out what he can do.

Additionally the audiovisual elements can help tell a story. Both in the larger sense of selling the setting (castles for traditional fantasy, spaceports for science fiction) and in smaller instances of telling small stories within the world. The entire topic of spatial storytelling is actually a fascinating one that I plan to write another article on in the near future.

So that’s it. That’s my rundown of the three Qualities. Now what do you guys think? Is that a sensible system to categorize and analyze by?