参考书籍：《Basics of Game Design》——Michael E. Moore
资深的游戏设计师将会帮助团队确立游戏中将会构建的东西，并成为团队热情的火焰的守护者以确保最终成品不会偏离方向并且成为一个有趣的游戏。游戏设计师常被误解为负责构思游戏故事的职位，但这只是他们的工作之一。许多游戏类型（冒险游戏，第一/三人称射击游戏特别是角色扮演游戏）确实需要一个核心故事将游戏的各个部分串联起来，但是设计一个完整的包含有趣的角色、设定、敌人和道具的故事不仅充满挑战，还会花费大量的构思时间去补完故事中的细节。
然而，在这之中也有很多游戏类型是没有核心故事的，比如大部分的运动游戏，模拟游戏，解谜游戏（PS:译者不这么认为），或街机游戏。假使这些游戏真的出现了故事元素，他们也只与最核心的游戏体验相关联。即便如此，游戏设计师也需要花费大量功夫在寻找游戏中各个元素的平衡点上面，实际上为一个没有故事的游戏设计游戏玩法所花费的时间也不会比给一个大型角色扮演游戏设计核心剧情的时间要少。
构思想法和提出想法
对设计师最重要也是最有趣的任务之一就是构思出一个游戏并对其进行扩展以决定玩家会感觉有趣的内容。尽管部分设计师喜欢独自一人构思，绝大多数的设计师还是会和其他人一起思考。在众人各抒己见的自由讨论中设计师则掌控全局在白板上整理观点，在这之后设计师会写下关于这些想法的笔记并发放给团队的伙伴获得意见。多种多样的不同意见可以催生许多有趣富有创造力的想法。然后，设计师必须参考所有的想法，赋予游戏一个具体的中心概念。许多公司采用了一套让任何人都可以提出想法的流程——整理出一份意向书交给管理层和协商人员，说明游戏的精髓，并解释其中新颖和有趣的地方。 意向书中的创新部分应该给人留下不可磨灭的印象，应该包含游戏的类型，游戏的设定（如有必要），并谈论游戏玩法中最令人兴奋的一两个方面，这是为了作为一种销售工具让管理部门（特别是市场部）提起兴趣来发展这个企划。写意向书最为明智的方法是将游戏的中心概念浓缩至20字以内的一段话，这段话是对游戏的高度概括，也可以成为市场营销部门推广游戏概念的有力工具。
如果管理层认为一个想法是可行的，他们就会让一名设计师将游戏的意向书进一步完善细节作为游戏提案（Game Proposal）。好的游戏创意是很廉价的，每天都会有无数创意被送到管理层，但大部分都会被扔到一边。可能每十个提案中只有仅仅一两个会被认为有价值投入更多资源。
游戏提案
尽管游戏提案书阐述了项目的概念并描述了主要的游戏功能，但它仍然是一份相对较短的文件，不应对其中任何一个功能有太多的细节描述。为了让管理层对游戏的玩法和游戏世界的样子感到兴奋，游戏提案书应该表明这个概念值得进一步发展。设计师应当与设计草图的画师一同设计角色、场景和物体，但实际上在这个阶段不应该包含更加深层次的设计。同样的，游戏提案书也可以作为一种市场营销工具来推销概念，最重要的特征之一是市场分析，设计师与市场营销部门一起展现这款新游戏将不仅填补市场上现有的空白，还能够成功地与类似产品竞争。总的来说，游戏提案书最好控制在6到10页。如果太长了，管理层可能不会去认真研究这个游戏提案，而太短的游戏提案书则无法覆盖到所有包含丰富细节描述的有趣元素。设计师将会独自一人（除了有时要借助画师的帮助）花费约一到两个月的时间完成向管理层展示游戏提案书，偶尔借助一系列的故事板可以让管理层和市场部对游戏动作和世界观轻松产生具体的想象画面。同时强烈推荐设计师向公司中的技术总监咨询以了解该概念的可能性。
和上一章我们提到的一样，如果管理层认为这个想法是可行的，他们会要求设计师将游戏提案书中的概念扩展为一个完整的游戏设计文档。然而，每五到六个游戏提案中，可能只有一个提案能被允许进行后续的开发。
游戏设计文档
设计流程的最后一步是游戏设计文档。这可能是一份内容非常充实的文档，因为设计师在这个文档中会试图非常详细地解释游戏中的各个元素是如何与玩家互动的，以及游戏世界和角色是长什么样子的。一开始，游戏设计文档可能会让人感觉非常模糊和主观，因为在创建游戏原型之前，设计师无法知道设计出的游戏内容在游戏中的实际表现。因此，游戏设计文档是一个会随着时间的推移而扩充和进化的灵活的存在。每个公司都有自己独特的方法来构建游戏设计文档。 这里展示的文档构建结构是作者多年来反复使用的结构。我们的想法是把文档分成相当大的几个部分，这样团队的其他成员就不必一下子掌握整个文档。他们可以重点关注自己特长的领域，如果他们愿意，也可以阅读设计文档中的其他部分。
前言
这是为管理层特别撰写的部分，这一部分会从解释游戏的核心概念开始（通常都是引用游戏提案书的内容），并给出具体的示例来让阅读者明白游戏中将会发生的事情。前言中通常会包含关于游戏类型、世界观（如果需要特别说明）、目标平台和主要受众的基本信息，并说明游戏开发需要的大致预算和工期。这一部分应当简短，最多包含4到6页。
游戏机制
这一部分是专门针对编程团队的，每个游戏玩法中的元素都应该在这个部分进行详细说明并务必附上合适的图表。除了对游戏元素——如移动、战斗、资源管理、魔法以进行详细说明以外，在这部分中还应包含设计师对于每种显示器的用户界面(User Interface)的建议并对于游戏中每个操作应该如何控制的描述。在看完这一部分后，程序员应该已经完全了解该在游戏引擎中实现什么功能以及应该测试哪些部分，以便设计师能够按照他所想象的那样继续他的设计工作
游戏画面
这一部分是专门针对美术团队的，设计师会尽可能的在其中包括所有预定制作的美术素材——如角色、环境和道具。每个角色都应该有关于角色可以执行的行动（参考游戏机制部分的更多细节），以及任何需要的特殊视觉效果的客观描述。环境和物品也应该进行详细的描述，但请注意，在游戏开发的过程中设计师虽然对这些设计的构想会发生变化，但重要的这为美术设计师提供了一个着手设计的出发点。随着时间的推移，这一部分应当根据设计方案的变化和最终的成品的进行更新。在看完这一部分后，美术团队应该已经清楚他们要创作哪些内容了。
附录
在这个部分，一切之前没有提到的内容都可以放在这里
游戏设计文档在前期准备阶段和制作阶段中要经历两个阶段。第一阶段是游戏设计档的概述版本，如上所述，在经历很多次修改直到管理层满意后，游戏玩法和游戏画面的元素在这一阶段被确定。第二阶段是详细版本（被称为 "圣经"，因为它是团队中每个人的参考工具），用于跟踪整个制作阶段对原始设计的修改。这个版本既包括在原始设计文档之上的频繁更新，也包括在制作阶段创建的一些素材--例如，最终版本的关卡地图、对话、用脚本语言创建的脚本、错误报告更新日志，甚至包括游戏中所有资源的目录列表。在游戏完成时，游戏设计文件的详细版本可能有数百页之多。它可以在未来被证明是有用的，因为它是团队（或来自团队之外的开发者）制作附加内容或续作的必要资源。
游戏原型
对于复杂的游戏，设计师往往需要在确定要使用的游戏元素之前对其进行实验，其中的一个方法是创建简单的原型，纸上原型和数字化的原型都可以。原型是对游戏系统的抽象化，能向设计师展示系统运行的实际情况。例如，角色扮演游戏的设计师可能会有一个关于不寻常的战斗系统的想法，在这种情况下，创建一个简单的纸面原型可以用来测试系统，并在团队中的其他成员参与之前修改系统。纸质原型可以用来测试战斗系统、资源管理、升级技能树和有解谜元素的系统，有效的充实了关卡的结构以及确定物体东西在游戏场景中的摆放位置。设计师不需要让其他来自其他项目的员工参与进来，除了让他们参与测试并获得关于系统运行情况的反馈。尽管纸面原型可能很有用，但任何最终的设计都需要在游戏引擎启动和运行之后才能得出。一旦有了游戏资源，并且引擎按预期工作，在纸面原型中原本看起来不错的东西就会产生根本性的差异。可以的话，设计师最好向技术人员要求提供一个电子形式的可互动原型（一般称为软件原型）作为技术审查的一部分。这个原型可以做的很简陋，使用现有的引擎和美术资源。
一旦原型以游戏形式展现在屏幕上，即使是最简单的形式也可以让设计师辨别游戏原型与他自己的设计的区别，比如有些物体的大小需要调整，或是要重新平衡玩家每个行动的数值。假如这是个多人游戏，有个电子形式的早期测试版本也会是如有神助，在一些程序员和美术设计师的帮助下，设计师可以把游戏的测试成本降到最小限度。
设计原型的整体思路是为了在团队的其他成员开始为游戏制作最终版本的素材之前，确定游戏将如何运作。对于美术设计师来说最糟糕的事莫过于将自己的大量时间花费在美术素材后，发现这些素材并不适合放在游戏中，同样的，程序员也很讨厌因为设计师频繁改变他们的想法而不得不重写已完成的代码。简单的游戏原型可以帮助设计师决定和平衡分配在游戏物体中的数值，并且保证游戏机制按照设计文档中的描述运作。
创作素材
一旦整个团队做好了准备大干一场，设计团队不仅会加入创作素材，也会监督团队其他成员的工作。根据正在开发的游戏类型，用于制作游戏资源的工具可能简单到能让设计师使用，也可能复杂到只有熟练的团队成员才能轻而易举地使用它们。有时，公司会开发像地图编辑器和脚本语言这样的开发工具供设计人员使用，这样设计人员就可以直接创作游戏资源，并在测试人员发送他们的建议和错误报告时测试和平衡它们。但有时公司不愿意花费时间开发面向设计师的工具并直接依靠现有的商业产品，比如大部分设计师都不怎么会用的复杂3D建模软件像是Autodesk的3ds Max或Maya，然后这会造成使用这些软件的设计师搭建游戏场景变得十分困难。作为替代，美术设计师会接手搭建游戏场景的任务并与设计师一起确定关卡的布局，关卡的纸面原型可以帮助美术设计师将设计师脑中的设计展现出来，因而使关卡的创建更加迅速。
设计师还与编程和美术团队合作，确保各种游戏系统按计划运作，人物按设想的方式移动和行动。设计师们在必要时会对图表中的数据进行修改，调整数值并修改分配给对象的属性，直到游戏系统达到平衡和完整。同时，他们与美术设计师和程序员合作设计图形用户界面，使玩家能够一目了然地了解屏幕上显示的所有信息，他们还帮助确定控制方法，直到玩家感到自然且明显。
测试与调试
设计师最重要的工作之一就是不断地测试游戏，以确保数值平衡，以及逻辑和故事方面没有漏洞。当关卡完成后，它们将会被交付给测试人员，以检查游戏数值和游戏元素方面的问题。设计团队必须不断地调整游戏对象的数值，直到它们达到新手和老手都能享受的程度。随着开发工作的结束，设计师必须注意的是，在开发的后期阶段所做的任何改变不能使先前已经完成的游戏资源失去平衡。从Alpha测试阶段和之后的阶段开始，让新的人群来审阅总是一个好主意，否则会产生一种别样的诱惑使开发人员把关卡做的越来越难，因为过度熟悉这些关卡的测试人员会抱怨它们不够难。在这个阶段给对游戏感兴趣的新玩家开放测试的渠道尤为重要，因为可以让他们来评估当前游戏的整体编排是否合理。
当游戏开发进行到了Beta测试阶段，有的设计师可能已经被拉去做下一个项目了。这最后一轮的调试主要是为了修复代码和美术资源的漏洞，并且设计师已经不再需要参与调试的工作了（除非是数据库有问题或者松散的故事线需要被联系到一起）。一个游戏项目的结束通常意味着设计师们有一个正大光明的假期，这样他们就可以恢复自己的创造力为下一个项目做准备。然后，他们又开始了新一轮的工作--提出想法，向管理层推荐，并记录游戏的玩法。