作者：Richard Rouse III

游戏设计师会创造规则。这便是我们的工作说明。作为游戏设计师，我们倾向于通过规则去看待整个世界，想象生活如何作为基于规则的系统而得到更好的理解，因为我们所创造的的便是基于规则的系统。特别是在数字游戏中，这些规则更复杂且更快速—-因为计算机只能理解对与错。因为我们花了许多时间去思考规则，所以我们并不会对许多游戏设计师尝试着使用统一的规则去创造游戏而感到惊讶。我们想要看到的是关于游戏设计本身的规则。

400 Project

在过去几年里有许多人尝试着去编写游戏设计规则。最持久的付出便是从Hal Barwood在2001年的GDC上发表的名为“Four of the Four Hundred”的演讲开始。在这次大会上，Hal尝试着假设存在“400左右”的规则在支配着游戏设计，并谈论了其中的4种规则。接着在下一届的GDC大会上Hal迎来了自己的伙伴，也就是Noah Falstein。Noah继续添加了一些内容，即整合了来自许多其他设计师的贡献。他们共同的努力成就了400 Project。今天我们可以从一张数据表中看到这一项目的发展—-大概写下了110条规则。

我发现这些编写规则的付出总是非常有趣，因为它呈现的是一些范围。存在着400种规则？那些规则是否真的普遍存在于游戏设计中？这是一种大胆的发言，但似乎也是合理的。当我询问Hal有关其开始这一项目的动机时，他说道：“存在许多粗略的经验法则威胁着所有的创造性努力（以及生活本身）。它们能够让一些令人生畏的可能性变得有意义。我相信正是经验法则的随性才让我们能够持有一些真正的内容—-这也是真正的智慧所在。”当我询问Hal在回顾项目时如何，他表示自己非常清楚这样的实践所具有的局限性，并且表示人们有时候对于游戏设计规则都太较真了：“我所反抗的规则是那些将游戏设计当成与编辑设计类似的内容。这是一种特别愚蠢的看法：一方面，相信遵循非常精确的规则将创造出一款吸引人的游戏；另一方面，相信所谓的吸引力是受到很酷的科学原理与逻辑的影响。”当我与Noah聊到项目的状态时，他说道自己已经开始致力于进一步完善列表，对其进行分类，但这只是他能做的项目中的一部分。尽管如此Noah还是非常看好400 Project，不过他建议人们要谨慎使用这些规则：“我认为规则本身的理念非常棒—-只要你不要太过认真地看待它们，就像我和Hal都引用了Captain Barbossa所说的那句话，‘代码更像是指导方针，而不是真正的规则。”

CodeIsMoreLikeGuidelines(from gamasutra)

规则问题

虽然仍支持着400 Project的价值，Noah和Hal都承认创造“明确的”规则集是存在问题的。使用“规则”这一词本身便是问题的来源。“规则”指代一些不可变的内容，如果你不想被游戏淘汰的话就必须遵循的某些内容。

Katie Salen和Eric Zimmerman的书籍《Rules of Play》的名字便带有“规则”这一词，但当你在阅读这本书时会发现它并不是真正关于游戏设计规则本身—-规则指代的是游戏自身的规则，而本书致力于为游戏分析创造一个框架，这不仅只是作为设计师所遵循的一种方法。在与Eric聊到这点时，我问他这是否是一种有意的设定，他给予了肯定的答案。“因为游戏设计师通常都是一些基于结构且擅于分析的思想者，所以为优秀的设计想出一套‘规则’是非常诱人的。对我来说也是如此！多年以来，我一直尝试着去创造对于这类型系统的怀疑。”Eric还指出了规则所具有的另一个问题：它们可能只适用于你自己。就像所有的艺术形式一样，为这些艺术创造严格的参数和规则都有可能被下一代所丢弃。Eric再次说道：“我们所想出的任何定义优秀游戏设计的规则都有可能在明天被推翻。”

曾经在自己的博客上写了大量有关游戏设计文章的Daniel Cook发现游戏设计规则比我所交谈过的任何其他设计师所说的更有问题。他指出：“它们都是与背景相关的，能够对即将诞生的项目作出有趣的预测但却没有多少分析能力。”Dan认为功能模式更适合开发中的游戏分析与完善，这些模式能够帮助设计师找到此时此刻所面临的开发问题。但他也承认功能模式并不是一些能在博客中轻松解释的内容，也不能用一条tweet进行概括。结果便是它们很难得到关注。他认为设计师能够为自己创造基于特定情境的规则，不管是长期的还是只是针对于特定项目。“作为创造者，有时候你需要定义明确的黑白世界以将自己带向一个有趣的方向。这只是一种表面上的目标，而不是普遍使用的一种结构。”

设计规则该如何发挥功效

我同意这些设计师指出的所有有关游戏设计规则的劣势。那么我为何还会被它们所吸引呢？

首先，作为一名新设计师，我认为阅读游戏设计规则是创造游戏的有趣入口。规则总是能够大胆地指出好奇的新手设计师所具有的问题。如果听到一个规则是对于特定区域的进一步阐述，这有可能是学习游戏设计的一个很好的开始。但就像之前所讨论的那样，如果规则未进行深入研究而只是着眼于表面价值，那么它的坏处将远远大于益处。

除了新手，我知道许多有经验的设计师也非常信赖自己的规则。我也是如此。当作为顾问与团队共事时，如果我发现问题所在，我便会使用自己过去的经验去解释为什么我会认为存在问题。通常情况下我会将过去的经验整合成一个规则，尽管我并不会基于这种方式将其呈现在团队面前。相反地我会专注于自己过去项目的种种细节，呈现出游戏所引出的类似问题，然后描述我们是如何解决这一问题（游戏邦注：当然了，失败往往也是非常有帮助的学习经验）。在这些例子中，我并不会专注于严格的规则“文本”，相反地我更看重它所呈现的更大的背景和框架。就像Dan Cook所说的那样，在这种情况下规则是作为“来之不易的机会的模因”。当我们轻松地说出这些教训时，它能够帮助我们基于经历创造一个书签。但是我们必须记得规则本身只是路标般的存在。为了真正进行游戏设计，我们需要理解一些更大的设计问题，而不只是我们所熟悉的一些内容。

最佳规则都是属于个人的

作为一名设计师，我发现一些最吸引人的规则都是与那些我非常欣赏其作品的特定设计师相关。举个例子来说吧，我非常喜欢Warren Spector与Harvey Smith为《骇客任务》所创造的规则集。Sid Meier也是为游戏设计创造“经验法则”的著名开发者之一。作为游戏粉丝的我非常喜欢创造者在致力于一款游戏前为自己所设定的规则；对于创造过程的分解本身就非常吸引人。但是作为设计师的我却不一定想看到这些规则并认为“我必须在自己的游戏中直接遵循这些规则，如此的话游戏便会变得非常完美！”这是一种愚蠢的看法。这些规则之所以适合Warren ，Harvey或Sid是基于他们创造各自游戏所面对的背景。如果盲目地扩展它们只会带来各种问题。

我认为所有游戏设计规则都是局部的—-针对于某种类型，某一个项目以及特定的设计师。当听到有趣的设计规则时，我们需要牢记分析背景。这一规则适合怎样的游戏类型？这一规则在这一类型中会产生怎样的影响？现在的用户和媒体是否足够成熟让我们能够分解这一规则？这一规则适合怎样的项目团队和开发环境？

就最后一点而言，我们需要思考在团队环境中游戏规则将如何发挥作用。当作为一支团队内部的设计师，对项目所遵循的基本设计规则达成基本协议非常重要。通常情况下这都是由项目设计领导所决定，就像我们上面所提到的Harvey和Warren为《骇客任务》制定规则那样。创造大家都认同的规则是确保游戏设计团队始终朝着明确的方向前进的重要工具。

作为致力于一个大型项目（另外一名首席设计师将作出重要决定）的游戏设计师，我们总是会不可避免地认为boss的想法是错误的—-他们是按照自己的规则作出决定，而不是按照你的规则。但同时，每一位设计师都在创造着自己的规则集，不管他们是否会使用这些规则。对他们来说最重要的事是什么？他们将如何违背其他设计师去做这些事？等等。基于这种方式，设计规则将变得非常个人化。

对于许多来自大型团队的设计师来说，独立开发具有很大的吸引力，能够让他们实现“按照自己的规则设计游戏”。我便非常幸运能在过去的一些项目中使用自己的规则。而其它时间我主要是扮演着顾问的角色，即帮助团队明确并强化他们的“规则”去创造更棒的游戏。在过去的半年里我开始了一个全新的独立项目—-现在我正享受着使用自己的规则去创造一款完全不同的游戏。也许其他设计师可能不会认同我的设计选择，但这又有何妨呢？

DeusExScreenshot(from gamasutra)

自己的设计规则

不管你是独自设计游戏还是致力于一家较大的公司的小型团队亦或者是来自一家巨大公司中的大型团队，你都会面对不同的设计规则。当你在Gamasutra浏览一些适当的设计规则时一定要记得进行筛选。考虑那些内容的来源—-是谁创造了这样的规则？他们的创造对象是什么？他们所创造的游戏与你所面对的游戏和问题是否类似？即使对方是位很出色的设计师并且你很喜欢他的作品，也要牢记他们所提出的任何规则都是个人化的。这些规则可能很吸引人且具有教育性，但它们却并不是绝对的真理。你应该按照自己的规则选择是该接受它们还是拒绝它们，并且添加你自己的创造规则将能够真正定义你作为游戏设计师的身份。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

The Rise and Fall and Rise Again of Game Design Rules

by Richard Rouse III

Game designers create rules. It’s practically the job description for what we do. As game designers, we tend to see the entire world in rules, imagining how life can be better understood as a rules-based system, because rules-based systems are what we create. In digital games in particular, these rules tend to be hard and fast – because a computer inherently only understands true and false, not shades of gray. And since we spend our time thinking in rules, it’s not surprising that many game designers attempt to apply the same rigor to the craft of making games that we do within the games themselves. We want there to be rules about game design.

The 400 Project

Over the years there have been many attempts to codify game design rules. One of the more sustained efforts started with a talk Hal Barwood gave at GDC 2001 titled “Four of the Four Hundred.” In this session, Hal started off with the assumption that maybe there were “400 or so” rules of thumb that governed game design, and then proceeded to talk about four of them. This was followed by another talk the next GDC, with Hal now joined by long time collaborator Noah Falstein. Noah went on to continue adding entries with his column in Game Developer magazine, incorporating contributions from many other designers. The collaborative effort was named the 400 Project. Today, there’s a spreadsheet that shows how far the project got – around 110 rules of this writing.

I always found this rule-cataloguing endeavor to be interesting because of what it implies about scope. There are 400 rules? And are those rules really universal to game design? It’s a bold statement, but also somewhat plausible. When I asked Hal about his motives for starting the project, he said: “There’s an almost inexhaustible number of rough-and-ready maxims — rules-of-thumb — that reflect the bemused bafflement that threatens all creative endeavors (and life itself). They help to make sense of the vast and daunting possibilities. I believe that the very informality of rules-of-thumb is what allows them to hold real content — actual wisdom.” But when I asked Hal how he felt about the project in retrospect, he was very aware of the limitations of such an exercise, and was concerned that game design rules are sometimes taken too literally: “The kinds of rules I rebel against are those that imagine game design to resemble compiler design. A two-fold folly: on the one hand, a belief that following very precise rules can result in an engaging game; and on the other, a belief that what is engaging is driven by cool science and logic.” When I talked to Noah about the status of the project, he said that he had started work on further refining the list, categorizing it, but that it’s a side project that he can only get to when his schedule allows. Yet Noah was still bullish about the 400 Project, though he too advised caution in using the rules: “I think the idea of rules is great – as long as you don’t take them too seriously, Hal and I quoted Captain Barbossa ‘The code is more like “guidelines” rather than actual rules.’”

The Problems with Rules

While still maintaining the value of the 400 Project, Noah and Hal both admit that creating a “definitive” set of rules can be problematic. The use of the word “rule” itself may be the start of the trouble. “Rule” implies something immutable, something one must follow if one does not want to be disqualified or thrown out of the game.

Katie Salen and Eric Zimmerman’s book Rules of Play has the word “rule” in its title, but reading the book one finds that it doesn’t really cover game design rules per se – the rules it refers to are the rules in games themselves, and the book endeavors to create a framework for game analysis and thought more than a recipe for designers to follow. Talking to Eric about it, I asked if this was intentional, and he confirmed that it was. “Because game designers tend to be structural, analytic thinkers, coming up with grand sets of “rules” for good design is very seductive. Including for me! Over the years, I have tried to cultivate skepticism towards those kinds of systems.” Eric pointed out an additional problem with rules: they can date you. As in all art forms, creating strict parameters and rules for what art should and should not be is inevitably discarded by the next generation. Eric again, “Any rules we might think of to define good design in a game will tomorrow become the Man that all the kids want to overthrow.”

Daniel Cook, who has written extensively about game design on his blog www.lostgarden.com, finds game design rules more problematic than any of the other designers I spoke to. As he put it, “They are highly context sensitive, rarely make interesting predictions for the project at hand and have very little analytical power.” Dan prefers functional models that are better suited to analysis and improvement of games in development, with these models helping designers find solutions to their here-and-now development problems. But he concedes that functional models are not something one can easily explain in a blog post nor do they boil down to a catchy tweet. As a result they tend to get less attention (though you can read a good write up of one such functional model on Dan’s site). He did say that designers can benefit from creating context-specific rules for themselves, whether for the long term or just for a specific project. “Sometimes, you need to define a radically constrained black and white world as a creator to push yourself sharply in an interesting direction. But that is an aesthetic goal, not some observable universal structure that is applicable most everywhere.”

How Design Rules Are Useful

I’m inclined to agree with all the disadvantages of game design rules that these designers pointed out to me. So why am I still fascinated by them?

First of all, for new designers I do think reading about game design rules can be an interesting entry point to the craft. Rules tend to make bold statements that can spark questions in a curious novice designer. If hearing about a rule is followed up with further reading in a particular area, that can be a great starting point for learning about game design. But as discussed above, if the rule is taken at face value without further study, that rule may end up doing more harm than good.

But beyond the novice, I know lots of experienced designers who swear by their personal rules. This is certainly the case for me. Specifically, when working with teams as a consultant or advisor, if I spot problems I tend to use past experience to help explain why I think there’s an issue. Usually I have distilled this past experience down into a rule, though typically I don’t present it that way to the team. Instead I focus on the details of my past project, show how a similar problem arose for that game, and then talk about what we did to fix it (if we were fortunate enough to fix it – of course failure is almost equally useful as a learning experience). In these instances, the strict “text” of the rule is not my focus, but instead the larger context and framework it provides. As Dan Cook put it, in this case the rule is functioning as a “Memetic for a hard won wisdom.” When we spell out these lessons in easily memorable sound bites, it can help as a way to plant a bookmark in our own experiences. But we must remember that the rule itself is just a signpost. To truly do the game design work we need to understand the larger game design problem, not just the catchy phrase we use to remember it.

The Best Rules are Personal

As a designer, I find that some of the most intriguing rules are ones associated with a particular designer whose work I admire. For example, I quite like this list of rules Warren Spector developed in collaboration with Harvey Smith for use on the original Deus Ex. Sid Meier is probably one of the more famous creators of “rules of thumb” for game design – a good summary of some of those can be found in this fine article by Civilization III & IV designer Soren Johnson. The game fan in me loves hearing the rules a creator set for themselves before working on a beloved game; dissecting their creative process can be fascinating in itself. But as a designer, I don’t necessarily see those rules and think “Aha! I must apply those rules directly to my own games and then they will be perfect!” That would be foolish. Those rules worked for Warren, Harvey, or Sid in the context of the games they were making at the time they were making them. Extending them beyond that can be problematic.

I think all game design rules are local – to a genre, to a project, to a particular designer. When hearing about interesting sounding design rules, always remember to analyze the context. What genres does this rule work in? What effect would this rule have within that genre? Is breaking this rule appropriate now that the audience and medium have matured? In what type of project teams and development environments will this rule even work?

On that last point, it’s often important to think about how game design rules will work within a team environment. When working with a team of designers, basic agreement on the design principles the project is operating under is crucial. Often this will be established by the project’s design leads, as we saw from the example from Harvey and Warren for Deus Ex. Making such a set of mutually agreed on rules can be a tremendous tool for keeping a game design team moving in a focused direction.

As a game designer working on a large project where another lead designer is calling the shots, one inevitably thinks the boss is sometimes wrong – they’re designing by their own rules, not yours. But at the same time, every designer is building their own rule book, whether they get to use it or not. What are the things that matter most to them? How would they do things differently than other designers? In this way, design rules can become very personal.

For many designers who have worked on large teams, independent development can hold that bewitching allure of finally getting to “design by my own rulebook.” I’ve been extremely fortunate in that I’ve gotten to play mostly by my own rules on some of my past projects (though certainly not all of them). Other times, I have worked primarily as a consultant and advisor, where I was helping teams identify and strengthen their own “rules” and guiding principles to make their games stronger. In the last half year I’ve started on a new independent project – right now I’m enjoying working within some of my own rules that will create a very different game. Other designers wouldn’t necessarily agree with my design choices, but isn’t that the point?

A Design Rulebook of One’s Own

Whether you’re an indie flying solo or a designer on a tight-knit team at a bigger company or one of many designers on a giant team at a giant company, the way you work with design rules will be different. As you read about the design rules in places like Gamasutra always use a filter. Consider the source – who is the person stating this rule? What have they worked on? How is that game similar to the game you are working on and the problems you face? Even if a designer is brilliant and you love their work, keep in mind that any rule they put forth will probably be a personal, aesthetic choice that governs that person as a creator. Those rules can be fascinating and informative, but they are far from absolute. Accept them or reject them for your own personal rulebook, remembering to add rules of your own creation that will define you as a game designer.(source:gamasutra)