作者：Soren Johnson

“好游戏是一系列有趣的选择。”大部分游戏开发者都知道Sid Meier的这条设计法则。

事实上，我的专栏合作者Damion Schubert在他最近写的关于玩家选择的文章中也引用了这句名言。

然而，在他的职业生涯中，Sid Meier还提出过其他几条游戏设计的法则。在他的工作室Firaxis Games工作的7年间（2000-2007），我多次听到他谈起。因为他的见解对设计师来说是相当实用的经验，所以我认为值得探讨。

sid-meier(from joergspielt.de)

加倍或减半

好游戏不是凭空做出来的，这就是为什么许多设计师都主张重复设计，也就是在这个过程中尽早制作游戏的简单原型，然后重复修改直到游戏变成可以发布的产品。

Sid把这个过程叫作“寻找乐趣”。开发团队在挖掘创意、测试然后根据反馈调整的循环中重制游戏的次数，通常直接关系到游戏能否成功。

在这个过程中，开发团队重制游戏的次数是有限的，开发者不应该浪费在小小的变动上。相反地，如果要调整玩法，那就变动得大一些，使之产生明显的影响。

例如，如果单位看起来太弱，不要降低它的费用5%，而是增强它的力量2倍。如果玩家受不了这么多升级，那就取消一半的升级数量。在初版《文明》中，游戏进展太慢，Sid通过缩小地图一半面积解决了问题。这么做并不是说调整后的新数值一般是对的——这么做的目标是使每一次重制都拓展出更广的设计领域。

把设计新游戏想像成探索未知的世界。设计师可能对存在于那个世界的东西会有模糊的概念，但没有实验和测试，这些假设都只能停留在纯粹的理论阶段。因此，对开发者而言，每一次重大改变都像开拓一片新大陆，在确定扎根筑营以前必须好好探索一番。

质量高于数量

Sid喜欢把这一条叫作“隐秘动作法则”，这与他在90年代早期设计的一款不太成功的侦察游戏有关：

我犯下的错误其实是，让一款游戏分裂成互相竞争的两款游戏。一款是动作游戏：玩家进入某座建筑做一些如寻找线索等事情；另一款游戏强调推理：在游戏情节中，玩家必须找出幕后操纵者是谁在哪里。

分开看，各个部分都能成为一款好游戏，但放在一起就会互相打架。玩家要解决迷题又要面对打斗，等到大战一场从建筑出来，玩家早就忘了自己要解决什么迷题了。隐秘动作不能把故事和动作良好地结合起来是因为动作其实太多了——玩家花了10分钟打斗，等到完成任务，早就不知道发生什么事了。

换句话说，即使游戏的这两个部分本身都很趣，但它们共存就会破坏体验，因为无论是哪个部分，玩家都不能专心玩。

这条原则指出一个大问题，也就是所有设计选择的选择产生于相互关系中，做任何一种选择在得到它的好处时也放弃了其他选择的优势。例如，选择制作策略游戏意味着选择不做战术游戏。因此，一个想法本身可能“有趣”但如果它干扰主体体验，那么它就不能使游戏更好。确实，这条原则显然就是《文明》系列为什么从来不篡改战斗的深度和战术。

然而，有时候多种游戏也是可能和谐共存的。Sid自己的《Pirates!》就是集战斗、航海和舞蹈小游戏于一体的成功案例。但是，这些体验总是很短的——大多只持续几分钟，不至于对扮演海盗这一主要体验构成干扰。各个小挑战都是通向更大目标——洗劫所有西班牙城市或拯救你失散已久的亲人的一个步骤。

Pirates(from cnet.com.au)

另一个案例是《X-Com》。它成功地将战术、回合制、组队的战斗游戏与策略、即时、资源管理游戏融为一体。与《Pirates!》一样，这种混合在《X-Com》中管用是因为游戏没有模糊焦点——与海军和入侵者的战斗。

高级的、策略性的主体游戏只是提供了一个松散的框架（游戏邦注：在这个框架中，这些战斗每场都可能持续长达半个小时）——这很重要。玩家不是为了之后的资源管理而与入侵者战斗，相反地，玩家是为了以后的战斗而管理资源。

多研究和利用现实题材

许多成功的游戏——《模拟城市》、《侠盗猎车手》、《文明》、《过山车大亨》、《模似人生》等，都采用真实世界的主题，通过围绕人们熟悉的概念构建玩法，从而扩大潜在受众范围。

然而，这种真实题材的游戏可能存在一个风险：使游戏充斥着大量生活琐事和炫耀设计师研究量很大的晦涩知识。这种倾向解释了为什么真实世界的主题这么有价值——玩家进入游戏时已经有现成的知识。

所有人都知道火药是强大的武器，警局能减少犯罪，劫车是违法的。正如Sid所说的：“不应该要求玩家阅读设计师读的书才能玩游戏。”

游戏仍然有很大潜力当作一种教学工具，只是并不是以许多教育专家所期望的方式。虽然设计师仍然应该注意不在要在游戏中犯明显的错误，交互体验的价值是简单的概念之间的互动，不是灌输大量事实和数字。

许多人都知道世界上最早的文明均发源于大河区，如尼罗河、底格里斯河/幼发拉底河、印度河。没有什么比《文明》中的若干简单规则更能有效地教授这个概念——在农业文明的早期控制能生产出最多食物地区。另外，一旦核心工作完成，研究可以充实游戏内容，比如用历史情境、背景叙述、或图像细节等。只要记住，学习新游戏是一个可怕的过程，所以不要因为以为玩家在开始游戏时已经知道所有知识，而浪费了熟悉的主题的优势。

乐趣是属于玩家的，而不是设计师或电脑的

文明4(from btz.cn)

对设计师来说，制作剧情导向型游戏是令人陶醉的，所以许多设计师加入太多专有词、生僻词和省略号，使故事变得臃肿。另外，复杂的、精细的模拟类游戏可能变得迟钝，如果太依赖算法模式的内部运作方式的话。如Sid常说的，在这类游戏中获得乐趣要么是玩家，要么是电脑，总之不是玩家。

例如，在开发《文明4》时，我们用政府类型做实验。我们的做法是，给政府显著的生产能力，但玩家不能选择研究什么技术、建造什么建筑、训练什么单位，而是依靠隐蔽的、内部的模式来模拟政府。

当然，在游戏之外，这个算法做起来说起来都很有趣。然而，玩家却不这么认为，因为享受所有乐趣的是电脑。所以我们把这个设定取消了。

进一步说，游戏需要的不只是有意义的选择，还有有意义的交流。如果玩家不理解自己的决定的后果，那么做选择就没那么有趣了。RPG在这方面通常做得很失败，例如，在玩家还没见识到任何真正的玩法以前就要求他选择职业或技能。

在了解各个职业的战斗方式和属性以前，玩家怎么决定自己要选择野蛮人、战士还是游侠？只有在知情且能产生可理解的结果的情况下，做选择才是有趣的。

因此，按Sid的话说，玩家必须“总是主角”。在开发游戏时，作为设计师的我们必须成为玩家的最有力支持者，总是认真考虑如何设计影响玩家角色以及玩家对潜层机制的理解的决定。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Analysis: Sid Meier’s Key Design Lessons

By Soren Johnson

Most game developers are familiar with Sid Meier’s dictum that “a good game is a series of interesting choices.”

In fact, my co-columnist Damion Schubert started his recent article on player choice (October 2008) by referencing this famous quote.

However, over the course of his career, Sid has developed a few other general rules of game design, which I heard him discuss many times during my seven years (2000-2007) at his studio, Firaxis Games. As these insights are quite practical lessons for designers, they are also worthy of discussion.

Double It Or Cut It By Half

Good games can rarely be created in a vacuum, which is why many designers advocate an iterative design process, during which a simple prototype of the game is built very early and then iterated on repeatedly until the game becomes a shippable product.

Sid called this process “finding the fun,” and the probability of success is often directly related to the number of times a team can turn the crank on the loop of developing an idea, play-testing the results, and then adjusting based on feedback.

As the number of times a team can go through this cycle is finite, developers should not waste time with small changes. Instead, when making gameplay adjustments, developers should aim for significant changes that will provoke a tangible response.

If a unit seems too weak, don’t lower its cost by 5%; instead, double its strength. If players feel overwhelmed by too many upgrades, try removing half of them. In the original Civilization, the gameplay kept slowing down to a painful crawl, which Sid solved by shrinking the map in half. The point is not that the new values are likely to be correct – the goal is to stake out more design territory with each successive iteration.

Imagine the design space of a new game to be an undiscovered world. The designers may have a vague notion of what exists beyond the horizon, but without experimentation and testing, these assumptions remain purely theoretically. Thus, each radical change opens up a new piece of land for the team to consider before settling down for the final product.

One Good Game Is Better Than Two Great Ones

Sid liked to call this one the “Covert Action Rule,” a reference to a not-altogether-successful spy game he made in the early ’90s:

The mistake I made was actually having two games competing with each other. There was an action game where you break into a building and do all sorts of picking up clues and things like that, and then there was the story which involved a plot where you had to figure out who the mastermind was and what cities they were in, and it was an involved mystery-type plot.

Individually, each part could have been a good game. Together, they fought with each other. You would have this mystery that you were trying to solve, then you would be facing this action sequence, and you’d do this cool action thing, and you’d get out of the building, and you’d say, “What was the mystery I was trying to solve?” Covert Action integrated a story and action poorly because the action was actually too intense – you’d spend ten minutes or so of real time in a mission, and by the time you got out, you had no idea of what was going on in the world.

In other words, even though both sections of the game were fun on their own, their co-existence ruined the experience because the player could not focus her attention on one or the other.

This rule points to a larger issue, which is that all design choices only have value in relation to one another, each coming with their own set of cost/benefit trade-offs. Choosing to make a strategic game also means choosing not to make a tactical one. Thus, an idea may be “fun” on its own but still not make the game better if it distracts the player from the target experience. Indeed, this rule is clearly the reason why the Civ franchise has never dabbled with in-depth, tactical battles every time combat occurs.

However, sometimes multiple games can co-exist in harmony with each other. Sid’s own Pirates! is an example of a successful game built out of a collection of fighting, sailing, and dancing mini-games. However, these experiences were always very short – a few minutes at the most – leaving the primary focus on the meta-game of role-playing a pirate. Each short challenge was a tiny step along a more important larger path, of plundering all Spanish cities or rescuing your long-lost relatives.

Another example of a successful mix of separate sub-games is X-Com, which combined a tactical, turn-based, squad-level combat game with a strategic, real-time, resource-management game. As with Pirates!, what makes X-Com work is that the game chose a focus – in this case, the compelling tactical battles between your marines and the invading aliens.

The high-level, strategic meta-game exists only to provide a loose framework in which these battles – which could take as long as a half hour each – actually matter. One doesn’t fight the aliens to get to manage resources later; instead, one manages resources to get to perform better – and have more fun – in future battles.

Do Your Research After The Game Is Done

Many of the most successful games of all time – SimCity, Grand Theft Auto, Civilization, Rollercoaster Tycoon, The Sims – have real-world themes, which broadens their potential audience by building the gameplay around concepts familiar to everyone.

However, creating a game about a real topic can lead to a natural but dangerous tendency to cram the product full of bits of trivia and obscure knowledge to show off the amount of research the designer has done. This tendency spoils the very reason why real-world themes are so valuable – that players come to the game with all the knowledge they already need.

Everybody knows that gunpowder is good for a strong military, that police stations reduce crime, and that carjacking is very illegal. As Sid puts it, “the player shouldn’t have to read the same books the designer has read in order to be able to play.”

Games still have great potential to educate, just not in the ways that many educators expect. While designers should still be careful not to include anything factually incorrect, the value of an interactive experience is the interplay of simple concepts, not the inclusion of numerous facts and figures.

Many remember that the world’s earliest civilizations sprang up along river valleys — the Nile, the Tigris/Euphrates, the Indus — but nothing gets that concept across as effectively as a few simple rules in Civilization governing which tiles produce the most food during the early stages of agriculture. Furthermore, once the core work is done, research can be a very valuable way to flesh out a game’s depth, perhaps with historical scenarios, flavor text, or graphical details. Just remember that learning a new game is an intimidating experience, so don’t throw away the advantages of an approachable topic by expecting the player to already know all the details when the game starts.

The Player Should Have The Fun, Not The Designer Or The Computer

Creating story-based games can be an intoxicating experience for designers, many of whom go overboard with turgid back stories full of proper nouns, rarely-used consonants, and apostrophes. Furthermore, games based on complex, detailed simulations can be especially opaque if the mysterious inner workings of the algorithmic model remain hidden from view. As Sid liked to say, with these games, either the designer or the computer was the one having the fun, not the player.

For example, during the development of Civilization 4, we experimented with government types that gave significant productivity bonuses but also took away the player’s ability to pick which technologies were researched, what buildings were constructed, and which units were trained, relying instead on a hidden, internal model to simulate what the county’s people would choose on their own.

The algorithms were, of course, very fun to construct and interesting to discuss outside of the game. The players, however, felt left behind — the computer was having all the fun — so we cut the feature.

Further, games require not just meaningful choices but also meaningful communication to feel right. Giving players decisions that have consequence but which they cannot understand is no fun. Role-playing games commonly fail at making this connection, such as when players are required to choose classes or skills when “rolling” a character before experiencing even a few seconds of genuine gameplay.

How are players supposed to decide between being a Barbarian, a Fighter, or a Paladin before understanding how combat actually works and how each attribute performs in practice? Choice is only interesting when it is both impactful and informed.

Thus, in Sid’s words, the player must “always be the star.” As designers, we need to be the player’s greatest advocate during a game’s development, always considering carefully how design decisions affect both the player’s agency in the world and his understanding of the underlying mechanics.(source:gamasutra)