Written by a game developer and professor trained in architecture, An Architectural Approach to Level Design is one of the first books to integrate architectural and spatial design theory with the field of level design. It explores the principles of level design through the context and history of architecture, providing information useful to both academics and game development professionals.
--
You received this message because you are subscribed to the Google Groups "Game Design Book Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to game-design-book...@googlegroups.com.
To post to this group, send email to game-desig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/game-design-book-club/4d94bee5-3cb0-4de0-b500-31519d3da026%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Game Design Book Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to game-design-book...@googlegroups.com.
To post to this group, send email to game-desig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/game-design-book-club/5cbf36f2-527a-4119-8bb1-20f3d2a31b67%40googlegroups.com.
" A low wall becomes a point of ambush. A walk to a cafeteria becomes a challenge of bravery. The shadow makes you feel safe... Your eyes become hyper-aware of sudden movement. Any sound moving toward you makes you freak out."
So I have been trying to write about this book for some times now. When I read this book there's a lot of neat architectural anecdotes, but over all it feels like something is lacking. I first tried explain it by how the book tries to talk about level design without a specific game system in mind. It makes the book kind of general and it feels like it actually is written for implicit unstated game systems. After a while I realized that its kind of got covered by using a lot of game examples and expect the reader to figure out how to apply them on s/he's specific game in mind. I still don't think that its a good premise for a book. It's kind of unsatisfying but doable.
It kind of clicked when I wrote what I expected the book to deliver. It became easier to say what parts some of the different chapters lack.
What I want from the book:
Examples from architecture
Explaining the transfer from architecture to games - some words on how to transfer the examples to games. Comparing the difference between the purpose of the example and the purpose of the games system.
Examples from games - examples from games that apply the architectural example in a meaningful way, and examples where the architectural approach doesn't work as well.
Why:
Examples from architecture, because the book focus on architecture. Theres a lot of other interesting information in the book about other things, but most of it can be read elsewhere and kind of distracts from its core themes.
Explaining the transfer from architecture to games - Because most of the time its not self explanatory why something that work in architecture also should work in games.
One example is about city planning on p.353 where one of the aspects are: “1. Multiuse districts that encourage constant use by people” which is directly translated into the rule for level design :”1. Multiuse gamespaces that give players access to a variety of mechanics (shopping, talking, fighting, recharging, etc)”. I'm not saying that its wrong to have multiuse gamespaces, but as I understand it, the reason the architectural rule exist is because its a hassle to travel far to different places in real life. In games the same practical problem don't exists. You can have shops with identical supply everywhere or let the plays teleport between places. Or you can make it part of the game experience. One counter example to the rule are dark souls where you have to walk to different places to upgrade equipment and buy antiposion potions. The real world hassle becomes a “engaging” player experience. Its not that I think that the “rule” is wrong, its just that there are no reasoning, forth and back, how to transfer the architectural principles into games in the book. Its not that the examinations are wrong, there are no examinations so I can't say if its neither right nor wrong, to be honest.
Examples from games – Its easier to understand concepts if they are in a concrete form. The book contains a lot of general rules, but to be honest it doesn't feels like it clicks. Because the opposite of the rules could also work. Therefore examples show clearly when it works, and if its not noted why it works I can at least checkout the game and see why.
One great example in the book is the part about Tours one page 316. Totten(2014) describe the rock and roll hall of fame in Cleveland by architect I.M. Pei and compares it with Mario 64s bob-omb battlefield. The level's first mission leads the player right through the level, giving the player a overview of the level for the subsequent missions, like the tour built into the building in rock and roll hall of fame, giving a overview of its different floors.
I also think that its necessary to have examples on how to misuse the rule. Because its very easy. It feels like theres more possible ways to use the rule “wrong” then to use them right. I tend to learn more from bad games. One of the interviews from the book said something similar p.240.
Over all the book show a lot of examples from games. The thing that annoys me the most is that a lot of chapters have other theories then architecture and some chapter have no theory at all or example from architecture that are presented in a anecdotal way. Theres close to none description on how to transfer the architectural concepts into game centered systems. And theres no examples of games that use the concepts in a bad way.
That said, theres still a lot of interesting content in the book.
Some of the things I like are:
Not about environment art or “how to” implementation (xxiv) – I read the introduction online before I bought the book. This thing totally sold me on the book, mostly because theres this widely spread misconception about level design being about other things. (I love Liz's article compare level design and environment art http://www.lizengland.com/blog/2014/06/the-restaurant-analogy-of-level-design/, I wish more people online had read it)
Nodes / proximity diagrams (129) – Like, the only doable way to sketch 3D spaces and other complex structure, like metroidvania maps. Moves the focus from specific shapes to its intended functions.
“Nintendo Power method” (82) – Making a overview of the level with specific highlights the way nintendo power made guides. (I recently checked the mario guides from nintento power, they lack enemy placement so they are not super useful for level design. All of them are hand drawn because it wasnt possible to make screenshots and screenshot maps before) If I had the time I would make all of my levels look like this. It usually takes a lot of time to make them, time that could have been spent to make levels instead. But its very nice to have afterwards as reference.
Oku (258) – Winding streets in between open spaces. I don't know how this exactly can be applied in level design, but it would be cool in 3D.
Japanise gardens (310) – Not so much about the deisgn rules, but more about the fact that nintendo was inspired by it in mario / zelda. A kind of aha moment.
All of the hand drawn pictures – It looks very clean and I don't want to know how much time it took to draw all of them. Its pretty hard to get overview pictures of 3D games. Thats a skill that clearly would be handy to be able to do from architecture.
And more...
It feels strange to spend a page rant about the book, and then post a list of 5-10 interesting concepts. Well thats how it is.
It feels like the format of this book is less rule of thumbs and more in the form of a question; “would this work in my game?” And that is probably the take away: heres a lot of aspects and let the reader answer how they work in different games.