作者：Tim Huntsman

我在之前文章中谈到“操作”过程，主要围绕设计师在初期设计阶段所能够进行的操作。着眼点在于提问问题，找出玩家期待的内容，确定项目的焦点，将其放入大家都能够运用的格式中。这里我们将主要讨论初期设计及落实阶段的构思。

思考内容：

“思考”版块主要涉及你作为设计师及项目整体目标维护人员要提高作品质量所应该思考的东西。进行思考就是要参与设计过程中。你应该和参与项目的人员保持联系。你应该清楚内容的具体放置位置及负责人员，能够回答大家就项目提出的任何问题。

1. 提出更多问题：

下述内容可以运用至开发过程中。你应在步入Alpha阶段时就开始思考这些问题，问题需在你步入Beta阶段前就得到解决（游戏邦注：Alpha阶段意味着，你的“主要”技术都已落实到位，但不是100%都顺利运作。这同样也适用于音效和美术内容。Beta阶段意味着，游戏的所有必要元素都已落实到位。这里主要围绕调整内容及追踪漏洞）。

前端内容/零件要素如何流动？

“保持简单性”原则适用于此。不要让玩家经过6-7个页面才最终接触到玩法，除非这对游戏来说非常必要。将内容放置于合理位置，不要害怕给予玩家帮助或在页面中告知各按键的用途。另一针对PC开发者的法则是：如果你让我给保存的游戏内容输入新名称，那么务必允许我通过点击“返回”进行保存，而不要让我返回到鼠标位置，点击“保存”按键。我甚至还没有谈到删除先前保存内容，释放更多空间。

这还包括思考你要让玩家如何设置他们的个人游戏体验。

很多公司的前端内容都非常糟糕。他们通常设置有限的选项，导致玩家难以设置自己偏好的内容。这点体现在多数PC游戏公司中，但掌机游戏公司除外。掌机游戏公司有自己的标准。让玩家能够轻松修改游戏允许范围内的内容。我要补充的是，最好让玩家知道他们需要点击什么按键，菜单页面才会有所反应。

应该融入什么选项及模式？

这个问题相当于：“我们如何赋予玩家权力？”越来越多玩家希望能够“修改”他们的游戏。《雷神之锤》粉丝自制关卡、皮肤和音效倍受欢迎就说明这点，游戏中我接触到WWF Warzone和WWF Attitude之类的内容。让玩家在游戏空间上享有一定的控制权能够有效提高游戏的重玩价值。它显著放大“出色”元素。Konami的《国际超级明星足球98》同样允许玩家创建真实或虚拟团队，在随后的长期比赛中运用这些团队。

向玩家提供出色功能、选项和游戏模式也能够换得回报：你将建立起忠实的粉丝基础，这些用户会购买你制作的游戏。

寻找能添加至游戏中的选项和模式的简单方式，就是转向测试部门或是通过小组讨论完成测试工作。所有人都有自己的看法，不妨听听他们的意见。

节奏如何？

很简单的问题。整款游戏是否过于冗长？通常你会发现，游戏太过简短。玩家支付20-70美元购买游戏，最好让他们觉得这物有所值。关于游戏应持续多久，我们没有明确规定（游戏邦注：除街机游戏外），但至少要让玩家觉得他们的投入非常值得。

第二项考虑是，以你评论书籍或电影的方式思考游戏的节奏。你的作品是否持续过久，令玩家心生厌烦，从当前情境跳至下个情境？游戏是否以极高速度进展，未给予玩家喘息或思考应采取什么举措而非一味求生的机会？记住要“平衡流动性”。变换速度是不错选择，但要认真看待这些变化。

什么程度算是困难？

在考虑难度问题时争取QA的反馈非常重要。玩家是否能够在几分钟、几小时或几天里轻松完成你的游戏内容？要将购买游戏的潜在玩家铭记在心，不要着眼于取悦过去6-9个月里一直都在玩此游戏的QA测试者。在测试者看来有难度的内容多半会挫败可能购买游戏的玩家，迫使他们退还游戏，因为他们无法通过首个关卡。如果可以，设置3个层次以上的难度通常是更明智的选择。遗憾的是，调整难度层次（调整AI，以实现相互匹配，平衡玩法，以适应玩家）是项艰难而耗时的任务，需由所有项目相关人员共同完成。

我们如何植入过场动画、全动态影像及运行阶段的影片？第一个问题非常简单：你是否真的需要这类内容，或者游戏没有这一内容是否可行？如果必不可少，尝试“内置游戏”的影片，而非预先渲染的过场动画。这不仅能够帮你维持玩家的沉浸性，你的过渡在玩家看来也会显得不那么冲突。《合金装备》、《半条命》和《魔剑邪神》都是这类内置游戏影片的经典例子。

我们如何从此获得重玩价值？

有些游戏结束了就结束了。惊喜消失，没有什么值得探索的内容。其他游戏则能够反复进行体验，或因为还有更多需要探索的内容，或是你试图争取个人目标（游戏邦注：例如赢得高分）。

加载/保存时间如何？

没有人会喜欢静静看着双色栏填满，等待游戏完成加载。索尼在此设有自己的标准，这对N64来说不是个问题。PC开发者只能够依靠自己。要督促程序员优化这一问题。这是整体游戏体验的组成要素。

允许玩家随时进行保存，除非你有正当理由限制他们的这一权限。PC游戏《Reflection’s Driver》要求玩家在保存内容前通过3-4个情境。你应该清楚这非常令人厌烦，此外，你不应该将此强加给玩家，除非这对维持游戏的基本设计特点来说非常必要。

2. 良好习惯，批判眼光及趣味性元素

整理设计文档、日常安排和预算

我们需要在前期制作设计阶段或这一阶段之后投入时间，整理项目的真实数据、时间和日期。这里经常会出现的问题是，上述各项内容会由不同小组负责。他们通常不会相互保持密切联系。很多公司都喜欢说，“我们要填补本季度的空白！你们要在8个月内完成这款游戏。！”你的回应是，“完全不行，但如果必须这么做，我们需要更多资金和资源。”当然，他们不想给你更多资金和资源。这就是为什么这能够让你聚集同这一开发过程相关的人员，讨论具体数据；这就是为什么这能够从一开始就让你把设计工作分解成需求、任务和功能。

检验资源和预算注意事项的最佳时机是构思设计细节的阶段，除非你无需安排计划表或进行预算规划。但如果你负责主导产品的设计目标，那么你最好参与工作安排和预算考量。将所有相关人员聚集到一起，商讨具体数据。这颇令人厌烦，但就长远看来一切物有所值。记住，当设计文档变更，或功能被重新制作时，你需要查看其中影响，判断这是否会在开发过程中产生障碍。

更新设计文档

这听起来很简单，但长时间开发的痛苦及来自各方的压力会促使细节内容遭到忽略。你也许会在半夜的临时会议上谈论一个功能，然后隔天再将调整落实到位。你应该将这一变更存档，尤其是当你打算在1年后推出作品的续集，这样你才能够首先记住自己的具体操作内容。

当团队成员决定植入、调整或变更某功能时，我们应该标注、存档这一功能，引起大家的注意。如果你制作出文章第1部分提到的在线风格设计文档，那么你就能够建立起有效机制，让团队成员了解情况，承担相应责任。

制作设计日志

这听起来非常直白；制作持续记录项目得失的对白。每周进行记录就可以，除非你处在关键时刻。这能够发挥众多用途。首先，这促使你进行回想，很多个月之后，你在项目初期学到或没学到的经验会在每天工作15小时的巨大压力中日益模糊。其次，它让你能够在事后分析中谈论成员在项目的正确或糟糕举措。最后，它让你能够在相关出版物中发表项目事后剖析文章，这样你的同伴设计师就能够从中吸取经验教训，是吧？

批判性评估

落实功能的最佳举措就是批判评估竞争性，我的意思是查看竞争情况。有这样一种说法：“你能够通过观察学到很多”。不要因为对手的作品比你先上架就高估竞争局势，而是要进行合理评估。每款游戏无论多么糟糕，都有值得借鉴的经验教训。这里的主要经验是，避免犯下对手曾犯过的错误。

这适用于整款游戏，查看前端之类的内容，获悉访问游戏的便捷程度，检验控制器装置，检验页面固定资产，同时测试游戏定时问题，进行控制器抽样。你定不希望自己徒劳无功。如果其他游戏在某些方面表现不错，借鉴他们的理念或构思。你只需确保自己不是完全照搬这一构思。这是个禁忌。记住：优秀设计不仅围绕构思，还涉及构思的执行。

当然，在某些情况下，你需要公证评判自己的作品。测试反馈能够发挥一定的作用，但这最终会冒犯他人。查看自己的作品时，你需要将自我意识暂搁一旁。许多游戏最终烟消云散是因为某人的自我意识同普遍观点及淘汰扼杀玩法功能的意见形成分歧。

“趣味性元素”

有些公司希望你着眼于“趣味性元素”。休闲玩家和普通玩家无法判断真正的趣味性。大家都在探究这个你在空洞设计方案及营销广告中经常会看到的晦涩概念。他们会告诉你某内容非常有趣，但他们无法告诉你，游戏具体发生什么，他们回应的是什么内容。趣味是个相对概念，主要围绕节奏、定时和刺激之类的具体元素。这些元素可以通过理论进行表达；告诉玩家“重击这一家伙非常有趣！”但你永远不知道这点，直到你在游戏中投入时间，最终发现这点。作为设计师，你需要批判评价竞争活动。查看他们如何处理特定问题，将此记录下来。

趣味性元素源自于能够确定具体操作内容和操作方式，你可以持续进行这一操作，而游戏又不会变乏味。这是执行设计方面最棘手的内容。多数开发者都握有具体细节内容的若干参数。在此，一个有效举措是筛选QA部门的适当信息和反馈意见。

3. “禁忌”列表

这里的“禁忌”列表有10条戒律。这些内容是我在体验游戏过程中逐步积累的。此外，我发现其中有些规则经常在游戏预览和评论中出现。

但和所有优秀规则一样，开发者经常没有遵循这些规则。

1. 尽量不要将游戏过度复杂化。简单来说就是，“保持简单、单一”。熟悉“经典”电子游戏时代的人士都记得，这个时代的游戏非常直截了当，能够让你持续盯住显示器几个小时。游戏由简单前提或控制器输入方式逐步进化而来。这些游戏不受技术限制或是不缺乏这些元素，相反它们是经过反复试验的稳固构思。简单性原则在今天依然适用。《吃豆人》只有一个操纵杆和一个迷宫。《俄罗斯方块》只融入若干从天而降的简单形状方块。就连《雷神之锤III：竞技场》也遵循不要将主要目标过度复杂化的简单性原则，这里主要就是尽可能多地轰炸对手，直到你的手脱落。具体情况会随玩家预期或技术而改变，但原则依然保持不变。

传统街机游戏设计师很清楚自己在做什么。他们遵循的哲学是，在30秒内将玩家吸引至游戏中，且持续保持兴致。玩家愿意在机箱中投入25美分查看具体操作内容。如果他们无法立即把握内容，他们就不会再次在机箱中投入25美分。你需要快速获取他们。你可以通过保持简单性做到这点。下次你参加E3之类的活动，花时间观察体验游戏的玩家而非游戏本身。查看什么内容吸引他们的眼球。找出令玩家爱不释手的游戏，然后以批判视角亲身进行尝试。

2. 不要犯下相同错误。批判评估竞争情况意味着你需要查看所完成的内容。这意味着如果你制作类似题材的游戏，你应该借鉴它们的优点，避免糟糕元素。不要重新创造整个体系，除非你有足够时间和金钱，能够想出更好的方案。

3. 尽量不要剥夺玩家的控制权。若玩家不愿意，不要规定他们看完某些动画、过场动画或音乐插曲。《合金装备》巧妙通过运行阶段的过渡留住玩家，让他们保持兴趣。Valve的《半条命》也让玩家享有过渡权限（但却丝毫没有这种感觉）。而Cinimatix的《Revenant》则是个反面例子，当玩家在沮丧中狂按ESC按键时，游戏依然通过脚本引擎让角色穿过屏幕。这一原则也适用于“游戏中”的事件。战斗、动作或其他游戏类型（游戏邦注：主要是玩家从身体上同对手进行斗争的游戏类型）的一个共同弊端体现在玩家“受困于”袭击反应循环的时候。动画也许在屏幕上看起来很酷，但当主角在攻击者的猛烈进攻下痛苦打滚时，此进攻者已完成自己的动画，开始发动下个攻击。这里我要说什么？最终，玩家被攻击3-4次，毫无防御机会。这是个非常令人沮丧的缺陷。

4. 不要忽略你将用于体验游戏的控制器或I/O设备。问题存在于当PC游戏被转换至掌机平台时。通过Playstation控制器进行16种不同的热键操作非常困难。你已清楚角色将在游戏中进行什么操作，同时知道玩家会在游戏世界中如何调遣角色。这同时也适用于导航目录页面和复杂选择方案。这里你应该遵循简单性原则，除非你无能为力。

5. 不要认为玩家知道你的想法。玩家通常都非常聪明，能够很快凭直觉发现预先存在的谜题或情境。因此设计师需想办法挑战玩家。有时我们会通过呈现这样的内容挑战玩家：在制作人员和测试人员看来行得通，但对没有参与游戏制作的玩家来说却难以理解的内容。

《魔剑邪神》就是个典型例子，既遵循这一原则，同时也破坏这一原则。游戏的指南版块精彩介绍游戏世界。但在某些节点，游戏会不加说明地要求你进行某些操作。例证：方向以指南针形式呈现（如向北），但游戏当中没有指南针，玩家如何知晓哪里是北？听起来很简单，但我花了4小时回去探究这一问题。

6. 不要打破既有规则，除非你有向玩家说明。有些游戏通过不让玩家操纵环境培养他们的某些习惯。这没有问题，但若随后你决定让玩家以不同以往的方式运用这些物件，要知会他们。《合金装备》在此表现突出。游戏提供完成目标所需的信息。这会消除悬念，但远要好过让他们摸索几个小时，试图忘掉之前在整款游戏中所进行的操作。向玩家隐藏的信息不应致使他们陷入迷惑状态。这里还有个类似观点，基于既有逻辑制作游戏。《决战大魔域》就是个典型例子，在此游戏的逻辑和谜题的破解毫无关系，玩家因此而丧失兴趣。

7. 不要认为技术能够补救糟糕设计。这是个重要原则，行业在过去几年一直都没有严格遵循。每年都有很多游戏标榜融入特定技术成就，通常体现在植入多边形或是融入“最逼真的AI”。对此，你的回应应该是，“那么，有趣吗？”实时灯光效果！如果游戏缺乏趣味，将没有人会进行体验。

在有些情况下，技术能够缓解糟糕设计。植入更多多边形，进而提高帧速率，让画面变得更平滑，这是件好事。但有些技术不会渗透至普通终端用户。他们通常不清楚或不关心技术标准，他们只是想要知道游戏是否有趣。

一个例子是Terminal Reality的PC产品《Nocturne》。游戏包含很棒的“实时灯光和阴影”FX，这带来若干令人毛骨悚然的游戏时刻，但每当有2个以上的生物出现在屏幕上时，帧速率就会陷入非常糟糕的状态，有时甚至会令战斗陷入无法进行的地步。非常令人沮丧。

9. 不要欺骗玩家。这里的基本原则是，如果玩家做不到，那么CPU也不应做到。程序员要将AI设置成完美状态非常简单，但要让AI像真人般运作则就非常困难。出色AI生物的典型代表要数《Unreal》（游戏邦注：因为游戏设置类似人类的元素阻碍玩家）。

10. 不要设计道德元素。若玩家通过保存功能跳过游戏的某个“功能”，就让他们这么做。你会在《博德之门》或《铁血联盟II》之类的RPG游戏中发现这一问题。我自己就曾错误地将玩家置于战斗中，只是为了让他们知道坏人来自何处，然后重新加载游戏，进行相应规划。不要因为玩家在房间或障碍中重新加载失败尝试而惩罚玩家。以此方式挫败玩家的典型例子是《博德之门：剑湾传奇》的扩展包。这一游戏融入这样的功能：如果你重新加载之前保存的游戏，游戏就会向你呈现更多的怪兽或让弹簧陷阱更严重地袭击你。这糟糕透了。这同时是解决问题的荒唐理由。如果玩家想要保存游戏，走到房间查看跳出什么东西，重新加载及重新配置角色，就让他这么做。所以？我们不设计道德元素。如果玩家想要进行“欺骗”，就让他这么做，但如果你能够找到不强迫玩家的解决方案，那就再好不过了。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

A Primer for the Design Process, Part 2: What to Think About

by Tim Huntsman

Previously, I talked about the “Do” process, about what you as a designer can do as you ramp-up in the early design process. The focus was on asking questions, finding out what people want, getting a focus for your project, and putting it into a format everyone could (and would) use. This next section should help in giving you some insight about the frame of mind you should be in during the early design and implementation phase.

What to Think About:

The “Think” section contains info that you, as the Designer and maintainer of the overall vision of the product, should be thinking about to improve the quality of your game. To be thinking is to be involved in the design process. You should be in constant contact with all the people working on your title. You should know what goes where, who’s supposed to put it there, and be able to answer just about any question anyone might have about the product.

1. Asking Even More Questions:

The following section can be employed through the development process. These are things you should be asking as you go Alpha, and they should be finalized before you go Beta. (Just so you know where I’m coming from, I’ve always understood the terms Alpha and Beta as they apply to game development in the following way: Alpha means that all of your “major” technology is in place, but not working 100%. This also applies to sound and art. Beta means that everything that’s supposed to be in the game IS in the game. It’s all down to tweaking and bug hunting from there to turnover.)

How is our front-end/fluff going to flow?

The “KISS” rule applies here (See “Never” rule #1.) Don’t force the player to filter through 6 or 7 screens to get to the game play unless it’s absolutely necessary to the game. Put things in their logical place, and don’t be afraid to give the player help or tell them what buttons do what within each screen. Another rule for you PC developers out there: If you’re going to make me type a new name for a game save, please allow me to hit the “return” key to save instead of forcing me to go back to the mouse and click on the “save” button. I won’t even talk about deleting an old save to free up some space.

This also includes thinking about what you’re going to let the player do to configure their individual gaming experience.

On a side-note-many companies have front ends that, to put it simply, suck. They have limited options, navigating these options is a task Uri Geller couldn’t fake, and it’s usually a chore to try to configure something for your own liking. This comment holds true for the vast majority of PC game companies and not consoles. The console companies have standards that they are held to. Make it easy for players to modify things that you’re going to allow them to modify. And, I might add, there’s absolutely nothing wrong with giving players instructions on what button(s) they need to press to make something happen on a menu screen.

What options or modes should be included?

This particular question could be restated as, “How can we empower the player?” More and more players want to “mod” their games. I’ve seen this with the popularity of Quake mods-special fan-made levels, skins, and sound FX-and in games I’ve worked on like WWF Warzone and WWF Attitude. Giving players some measure of control over their environment will do wonders to increase the replay value of your title. It pumps up the “cool” factor. Konami’s International Superstar Soccer ’98 had the same create a player idea allowing the player to make either real or fantasy teams and using them in long-term tournaments.

Empowering the player with cool features, options, and game modes also has a definite payback in the fact that you will build a loyal fan-base that will buy into the franchise you create. (Sequels, people, sequels.)

A simple way to find options and modes to add to your title is to ask your testing department (or your publishers) or get some focus group testing done. Everyone has an opinion, you might as well listen to them.

How’s the pacing?

Simple question. Is the overall game too long? Usually, you’ll find that the game’s too short. Players fork out anywhere from $20 to $70+ bucks for a game and it better be worth it. There are no rules on just how long the total gaming experience should be (with the exception of arcade titles) but players should feel like they got their money’s worth.

A secondary consideration is to consider in-game pacing in the same way you’d critique a book or a film. Does your product drag its heels for an ungodly long time, boring the player to tears from one scene to the next? Does it go crashing through it’s paces at breakneck speed, never giving the player time to catch a breath or reflect on what he’s supposed to actually be doing other than surviving? ‘Balance the flow’ are the words to remember. Changes in tempo are a good thing but remember to take care how you manage those changes.

How hard is hard?

Get QA’s feedback when considering the difficulty. Can players breeze through your game in minutes, in hours, or days? Remember the players who are buying your game, and don’t always look to please the QA testers who have been playing the game solid for the last 6 to 9 months. Whatever is going to be considered difficult for your testers will probably cream the average player who might purchase your game, and force them to return it because they can’t get past the first level. More than three levels of difficulty are usually better if you can swing it. Sad to say, tweaking levels of difficulty – adjusting AI to match and balancing game play to accommodate – is a tough and time-consuming thing that needs to be addressed by everyone involved on the project.

How can we integrate cut scenes, FMV or Run-time movies?

The first question is simple: Do you really need something like this, or can your game survive (quite nicely) without this? If absolutely necessary, try for the “in-game” movie rather than the pre-rendered cinematic escapade. It not only helps to keep the player immersed, but your transitions will be less jarring to the player. Metal Gear Solid, Half-Life, and Soul Reaver were good examples of the In-game movie.

How can we get replay value out of this?

Some games are over when they’re over. The surprise is done and there’s really nothing left to look for. Others can be played again and again, either because there’s more to discover, or you’re trying to do something personal like beating a high score. (Score? Games keep score? What’s that? I’m sorry, but I’m a throwback to halcyon arcade days of the early 80′s where score was EVERYTHING!)

How are our load/save times?

No one wants to sit around looking at 2-tone bar fill while waiting for the game to load. Sony has standards for it and it’s not really an issue for the N64. PC guys, you’re on your own. Push the programmers to optimize this. It’s ALL part of the total game experience.

On a related note here-allow the player to save where they want to unless it’s fundamentally necessary to not let them save. Reflection’s Driver for the PC is a glaring example of forcing the player to get through 3 or 4 scenarios before they can save. You should know just how annoying this is and furthermore, you shouldn’t be doing this to the gamer unless it’s absolutely necessary to maintain the fundamental design features of your game.

2. Good Habits, A Critical Eye, and the Fun Factor

Merging Design Documents, Schedules, and Budgets.

Time will need to be taken during, or immediately after, the pre-production design phase to come-up with real numbers, times, and dates for the project. The usual problem with those above-mentioned words is that, for each concept mentioned, you have a different group of people crunching the numbers. They also don’t tend to be in very close contact with each other. Many companies are fond of saying, “Hey, we need to fill a gap in the quarter here! You guys, do this game in 8 months!” Your response is, “Not on your life, but if we must, we’ll need more money and resource to do it.” Of course, they don’t want to give you more money and resources to do it. That’s why it helps to gather all relevant parties to this portion of the development process, bring them together, and hash out the numbers. That’s why it helps to have your design broken down into needs, tasks, and features at the start.

There is no better time to examine resource and budget considerations then while you’re hammering out design detail, unless of course you have nothing to do with making the schedule or planning the budget. If you’re leading the design vision of the product, however, you should very well have a hand in the schedule and budgetary considerations. Get all the relevant people into the room at one time and hammer out the numbers. It’s a big pain in the backside, but it’s definitely worth doing in the long run. Remember, when the design doc is changed, or features are re-worked, you’re going to have to take a look at the impact and figure out if this is going to push you back in the development process.

Updating the design document.

This sounds easy, but in the throes of development long hours and crushing stress from all sides can cause details to slip through the cracks. You might talk about a feature in a late-night impromptu gathering and then implement the change the next morning. You should document that change, especially if you end up doing a sequel a year or so later, so that you remember what you did in the first place.

When anybody on the team decides to round out a feature, change a feature, or add a feature this change should be noted, documented, and brought to everyone’s attention. If you’ve created an on-line style design document not entirely unlike the one mentioned part one of this article, you’ll have the mechanism in place to keep the team informed and responsible.

Keeping a Design Journal

This is as straightforward as it sounds; keep a running dialogue of what’s gone right and wrong during the project. Week to week will probably do unless you’re in the middle of one heck of a crunch time. This will serve a number of purposes. First, it lets you recall, months and months after the fact, lessons you may have learned or not learned early in the project before the press of 15 hour days began to blur one day into the next. Secondly, it allows you to bring up key issues of good or bad work done by people throughout the project during the post-mortem (your company has post-mortems, right?) And lastly, it will help you in publishing a post-mortem article for a relevant publication so your fellow designers out there can learn from your experience, right?

Critical Evaluation

One of the best things you can do for your game when you’re looking to implement features is to critically evaluate the competition and I mean look at them. There is a saying, “It’s amazing how much you can see if you just look.” Don’t knock on the competition simply because their title is out before yours hits the shelves, evaluate it. Every title, no matter how heinous, has some lesson to be learned tucked within its folds. The primary lesson here is to avoid making the same mistakes that killed a rival product.

This goes for the whole game, look at things like their front end to see how easy it is to get into the game, check the controller set-ups, examine screen real estate and test in-game timing issues and controller sampling. You don’t want to be reinventing the wheel if you don’t have to. If some other game is doing something well, borrow that idea or concept. You just have to make sure that you don’t outright steal the concept. That would be a no-no. Remember: Good design not only about ideas, but it’s also about the implementation of those ideas.

Of course, at some point you are going to need to turn that cruel, cold eye of unswerving criticism on your own title. Testing feedback will help here but ultimately someone’s toes are going to get stepped on. When looking at your own product, put your ego in your back pocket. Many a title has crashed-and-burned because someone’s ego fought against the tide of popular opinion and washed-out (or in) a feature (or features) that killed game play.

The ‘Fun Factor’

Some companies want you to work on the “fun factor.” Everyone’s looking for that elusive concept that you read so much about in fluffy design treatments and marketing blurbs. The causal gamer and average consumer can’t nail down what is really fun. They’ll tell you something’s fun, but they can’t tell you what’s happening inside the game and what they’re responding to. Fun tends to be a relative concept that revolves around things like pacing, timing, and excitement as specific to that particular title. These are things you can theorize about; tell people “punching this guy is fun!” but you’ll never really know until you spend time with the game and work it out. As a designer, you need the ability to critically evaluate the competitions efforts. Look at how they handle certain issues and make note of them.

The fun factor comes from being able to identify exactly what’s being done, how it’s being done, and you can continue to do it without the game getting boring. This is a touchy part of the implementation of the design. Lots of people are going to have arguments one-way or the other about the details. One thing that will help you with this is filtering proper information and feedback from your QA department, but I’ll go into that later.

3. The list of “Never”:

The list of “Never” has evolved into a kind of Ten Commandments for me. They’ve evolved over the years, usually noted and expanded upon while playing games. They are things I’ve noticed, come to realize, and things that are brought up in conversations with my peers. I’ve also noted that some of these rules get repeated in game previews and reviews.

Like all good rules, however, they are ALWAYS made to be broken. And, of course, you are allowed to break them. You just better make darn sure you know what you’re doing when you do break them.

1. Never overcomplicate a game if you can help it. Stated in the obvious way it reads, “Keep It Simple, Stupid.” Those of us old enough to look back on what is considered the “classic” era of video gaming remember it as being a time of very straight forward gaming that could keep you glued to a monitor for hours. Games evolved around a simple premise or method of controller input. Those games were not limited by technology or the lack thereof, but were instead solid concepts of experimentation. The KISS principle still holds true today. Pac-Man had one joystick and one maze. Tetris had a few simple shapes falling gently from the sky. Even Quake III Arena follows the KISS ideal of not over-complicating the main goal, which in this case happens to be blasting your opponent as many times as you can till your hands fall off.
The context may change with player expectation or technology, but the principle will always remain sound.

The arcade game designers from the good old days knew what they were doing. The philosophy there was that they had 30 seconds to introduce someone to a game and maintain that interest. People are willing to drop 25 cents into a cabinet to see what it does. If they don’t see it immediately, they won’t drop another 25 cents into the machine. You have to grab them quickly. You do that by keeping it simple. The next time you go to E3 or some such event, spend some time watching not the game, but the people playing the game. See what’s grabbing their attention. Find the games that people won’t put down then try them yourself with an eye towards critical evaluation.

2. Never make the same mistake twice. Critical evaluation of your competition means looking at what’s been done and what’s out there. It means if you’re doing a game in a similar genre, you should be borrowing from the things that they do well, and avoiding the things they don’t do well. Don’t re-invent the wheel unless you sincerely have the time and wherewithal to come up with a better way.

3. Never take control from the player if you can help it. Don’t make the player sit through some animation, cut-scene, or musical interlude if they don’t have to. Metal Gear Solid did a great job of using run-time transitions to keep you there and interested. Valve’s Half-Life was another excellent example of transitioning-taking control from the player-but it didn’t really feel like it. Revenant by Cinimatix, on the other hand, is a frustrating example of waiting for the developer’s scripting engine to putter characters around the screen while you mash the ESC key in frustration.
This rule also works for “in-game” events. A constant and common failing of many fighting, action, or other titles where the player is physically “fighting” an opponent happens when the player gets “stuck” in a hit reaction loop. The animation may have looked cool on the animator’s screen, but while the hero is writhing in pair from a vicious blow on the part of the attacker, this same attacker has finished his animation and has initiated another attack. (while the hero is still writhing) See where I’m going here? The player ends up getting hit 3 or 4 times with no chance to defend themselves. This is a very frustrating flaw.

4. Never forget the controller or I/O device you will be using to play the game. Obvious problems are when PC games are converted to consoles. It’s hard to type from 16 different hot-keyed actions with a Playstation controller. You’ve figured out what your character will be doing in the game, at the same time you should have figured out how the player is going to maneuver the character through your world. This applies to navigating inventory screens and complex selection schemes as well. You should always defer to the KISS philosophy here unless you absolutely can’t help it.

5. Never assume the player knows what you’re thinking. Players are usually bright people who can intuit a pre-existing puzzle or situation rather quickly. Because of this, designers must think of ways to challenge the player. Sometimes, we will challenge the player by presenting to them something that makes sense to us while we were working on it, and make sense to QA while they were testing it, but doesn’t translate for a player who hasn’t spent the last 9 months of their life working on the game.

Soul Reaver is a good example of maintaining this rule AND breaking it at the same time. The tutorial portion of the game was an excellent introduction to the game’s world. At several points, however, the game would tell you do something without any explanation. Case in point: Directions were given in the form of a compass point (go North, young man. . .) yet there is no compass in the game so, just how am I supposed to know which way is North? Sound’s easy, but I lost 4 hours backtracking to figure this one out.

6. Never break the established rules unless you TELL the player. There are a number of games out there that will teach the player certain habits by NOT letting them manipulate their environment. That’s OK, but if at a later date you decide to allow the player to use these objects in a way that’s different from previous lessons, TELL THEM! Metal Gear Solid was good about this. The game gives you the information you need to accomplish your goal. It begs a little suspension of belief when this happens, but it’s far better that fumbling around for several hours trying to unlearn something you’ve been doing the entire game to this point. Withholding information from the player should not be the extent of the puzzle. There’s also the parallel argument here about making your puzzles somewhat dependent on existing logic. Return to Zork was a prime example of logic having nothing to do with solving the puzzle and the players lost interest for that very reason.

7. Never assume technology can fix bad design. This is a BIG rule that this industry is guilty of breaking repeatedly in the last few years. We see a number of titles every year that claim to make certain technological feats, usually in terms of pushing poly’s or having “the most realistic AI ever encountered!” You’re answer to marketing ploy’s like this should be, “So, is it fun?” Real-Time Lighting! If the game’s not fun, no one is going to want to play it.

There are cases where technology can ease bad design. Pushing more poly’s, thus raising the frame rate and smoothing out your visuals, is a good thing. Some technologies, however, don’t or won’t filter through to the average end-user. They generally don’t know about or care about technical specs, they just want to know if the game is fun.

An example here is the PC product Nocturne by Terminal Reality. The game has great “real-time lighting and shadows” FX that lead to some truly creepy moments in the game, but anytime more than two creature jumped on screen, the frame rate would bog to amazingly bad rates, making combat near unplayable at certain points. Very frustrating.

8. Never assume the license is all you need. No association in the world will help you sell an inferior product. There are some exceptions to the rule but as above, players want to know if the game is fun.

9. Never cheat the player. The basic rule here is that if the player can’t do it, the CPU shouldn’t be able to do it. It’s AMAZINGLY easy for a programmer to set up the AI to be perfect but it’s a lot harder to get that AI to act like a human would. The hand’s-down winner of cool creature AI would be Unreal because they do human player-type things to get on you.

10. Never design morality. If players find a way to circumvent a “feature” of your game by utilizing the save feature, let them. You see this kind of problem in RPG’s like Baldur’s Gate or Jagged Alliance II. I myself was guilty about sending guys blindly into the fray just to see where the bad guys were coming from, then re-loading the game and planning accordingly. Don’t penalize the player for re-loading a failed attempt at a room or hurdle. A specific example of creaming the player in this manner would be the expansion pack to Baldur’s Gate-Tales of the Sword Coast. They had a feature that, if you re-loaded a previously saved game, they would throw MORE monsters at you or make some sprung trap hit you even harder. This, quite simply, sucks. It’s also a poor excuse for problem solving. If the player wants to save his game, walk into a room to see what jumps out, the re-load and re-configure his characters, let him. So what? We don’t design morality. If the player wants to “cheat” let them but if you can come up with a solution that DOESN’T screw the player, even better.

The last installment of this series (Need) will deal with some of the things that you, as a designer, should have available to you within your development environment. Did I happen to mention time . . ? There’s also a small section at the end called ‘Expect.’ This is more of a personal bit about how I see the intrinsic philosophy of game-making and how it relates (and rules) my life.（Source：gamasutra）