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 overlooked) 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?
Mein Anspruch an gutes Leveldesign wäre
1) Gaudium, fun. The amount of joy while actually playing a level of a certain game 😉
Aber ich sehe ein, deine Punkte sind wohl die Zutaten dafür.
The point is that you can’t “design fun”. Fun is what happens when the player uses what you built. Granted, the Utilitas quality kinda deals with this but even if you’ve got a level that’s working with the game design and that’s enjoable it won’t be fun if it’s broken, and it might not be as much fun if it’s ugly.
i don’t want to be beotchy, but i think there’s a typo ( overlooked) in “A quite important (and easily overooked) one is that they can create associations.” Great article BTW.. i like your writing on level design and i hope to see some more in the future!
Thanks! Just fixed it. Also glad you liked it and enjoy the blog. It’s nice to get some positive feedback. I sometimes feel like I’m writing just for myself here.
Good stuff, now that we know the WHAT onto the HOW to put each one in effective use.
Heh. Yeah. And that’s a lot of work.
Firmitas is pretty specific to the engine you’re using but there’s lots of tutorials and tips on how to optimize your levels. I don’t think that’s ground I need to retread.
Utilitas is the big one for me. I’ll try to talk about that one but it’s such a huge subject (as mentioned in the article) that I’ll just be able to deal with splinters of the whole. Also just like firmitas is based on the engine, utilitas is firmly related to the kind of game you’re making.
Venustas is also quite important. I already have an idea for a post on an aspect of venustas in the pipeline. Also my recent article about player navigation – the immersed tools squarely fit into this category.
Does that make any sense?
Yes it does.
To me explaining these 3 is an attempt at writing a 500 page reference book, where you give examples of different type of scenarios and their optimum Firmitas, Utilitas and Venustas. Such as a Board Game. The Firmitas would be simple peice of cardboard with perhaps cards, tokens, stop watches, etc. The Utilitas would be the rules of the game applicable to the level movement and design. And the Venustas would be the actualy art and them of the board game, perhaps a Space Adventure board game would have stars and solar systems drawn on the board to represent systems the player can travel to.
But it would be a nice reference. I have a book “John Perry On Game Design” and it is pretty much the same thing; a huge listing of design principles and more example listings of each one. It’s a great tool to use when one is in the process of developing as you can get ideas from simple things you might not have thought of.
This sentence has so many spelling errors I meant to say :” And the Venustas would be the actual art and theme of the board game.”
Pingback: Twitted by CaribouLighting
Oh yeah. I got that big book here too. Didn’t really get to check it out yet though. It’s on a big pile of books I haven’t read yet. I’m guessing it’s a good reference though, sorta like the 400 project I mentioned upthread.