游戏系统设计经验分享：系统的了解认知与实现

小提示：您能找到这篇{游戏系统设计经验分享：系统的了解认知与实现}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的游戏系统设计经验分享：系统的了解认知与实现内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

讨论游戏系统设计前，首先需要对系统和游戏系统有一定的认知。能够较为独立的完成特定功能或玩法的一整套逻辑、数据与表现就是一个游戏系统。这样，游戏系统可分为功能性系统和玩法性系统。功能性系统是游戏中方便玩家使用，纯粹提供功能的系统，例如聊天、邮件、查看地图、角色移动操作、合成等系统，他们本身并没有实际的可玩性，以功能性为核心，这些功能的易用性，实用性，适用性，可扩展性是考虑的重点。另一类玩法性系统是以可玩性为核心设计的系统。这类系统不仅仅要有好的功能，还需要有玩法规划，能够让玩家沿着规划的方向进行游玩，例如战斗系统、装备系统（掉落产出、制造、强化、镶嵌这些都是装备系统中的子系统，不仅要设计功能，还要做出足够的好玩的玩法规划才行）、技能书合成系统（在纯粹的功能性的合成系统上做的玩法规划，添加了可玩性而成的系统）、副本系统、任务系统等。在制作这些系统的时候，显然不能单纯的只考虑功能，功能完全OK，可是没有规划任何玩法，或者无法做出玩法可就糟了。如果做出了战斗的规则，技能缺只能有2种——攻击和加血——那这个系统依然是失败，无论这战斗规则多么的简单易懂，操作多么舒服上手也都没用。

一个游戏的系统可以按照以下列举的顺序进行：

登录创角色

主UI

游戏地图

副本

玩家角色

升级成长

交互NPC

怪物

战斗规则

职业技能

装备

宠物

道具

任务

聊天

邮件

交易、摆摊、拍卖、NPC商店

商城

组队

社交（好有、仇人、师徒）

成就

公会

PVP

排行榜

活动

教学引导

如果要设计一个游戏，上述列表已经包含了其中大部分的系统。这些系统，每个都需要独自的系统设计文档。你可以将他们先列出来，逐步补充来完成自己的游戏设计。如果一个系统太大，应该将其切割成较小的系统，方便设计、制作和验证，最后再将这些已经OK的小系统组合起来再调整较为简单。

系统设计有好有坏。同一个系统，不同的人看，评价也不一样。什么是设计的好的游戏系统，我这里只能给出自己的见解。

考虑游戏系统好坏着眼于易用性、灵活性、可玩性和耐玩性这四点（功能性系统就不用考虑后两点了）。

易用性是指用户使用系统时，容易上手，理解清晰，操作简单、方便、安全，系统功能全面，满足玩家需求。好的易用性来自于对玩家需求的不断挖掘，对系统不断的大量测试与改进；研究玩家的操作习惯和视听认知习惯，研究界面与特效的表现手法，研究如何处理各种细节和意外情况。我们的周围有很多值得借鉴的东西，我们正在使用着大量的系统：用ATM机、驾驶汽车、使用电梯、注册网站会员、使用微博、使用打印机传真机等等。这些系统和游戏系统在易用性上是有共性的。总的来说，你可以通过以下几种方法提高系统的易用性：

完成功能所需的操作尽量的少（相关量化比较计算可参考《人本界面》的第四章内容，通过GOMS模型非常精确的计算各种操作的优劣）

使用操作成本更低的操作（移动鼠标<左键点击<右键点击<点击按键<鼠标拖拽）

提供界面自动的检索功能

例如要让一个宠物学习技能，点击宠物学习技能后，自动列举出了背包中可以学习的技能书，玩家只需要选择一本点击即可，这样不再打开背包去找。

使用渐入渐出，位置固定的界面

界面层级越少越好

单个界面上的内容不易太多，需要有顺序和焦点

使用统一的操作按钮的布局

使用初次教学引导

界面有自解释的能力

一种功能只限定一种操作方式对应，多种操作完成同一功能会误导玩家

研究大众的习惯，设计符合大众习惯，并有所改进的操作方式

旁观者方式观察玩家使用游戏系统，了解那里有问题，并作出网站开发 深圳改正

灵活性是指游戏系统能够适应需求的变化，较为简单方便的修改就能完成新的需求。由于现代游戏设计，需求的变化实在是太快了，这一点就显得更加尤为的重要了。灵活性实际上要求的是程序的功能实现具有很好的可扩展性。在为程序提供功能需求的时候，策划能做的一是尽可能的列举出该系统将来可能的扩展功能，二是和程序共同分析游戏系统，抽象出最基本的概念。有程序基础的策划知道，系统中的数据抽象的越基础，其扩展性就越好。另外，灵活性上，脚本高于数据高于写死的代码。因此，你的系统如果确实需要灵活性，就可选用脚本来实现。

可玩性可以说是游戏设计的终极话题。没有任何理论步骤告诉如何如何做就可以制造出可玩性来，同时可玩性也很依赖个人感受。因此我将可玩性理解为一种实验属性。你作为一个普通玩家，在玩过一个游戏后是能够产生是否具备可玩性的评价的。当某一种游戏系统在很多游戏中出现并被玩家喜爱，那么这个系统是具备可玩性的。这样，我们在设计时，为做出可玩性来，需要参考游戏历史上的其他大量的游戏，同时培养出自己对于可玩性的独特感知雷达。

以愤怒的小鸟为例，横向2D抛物线的游戏在PC上早已有很多种，说明了这类游戏的核心系统的可玩性是存在的。将这种可玩性通过其类似的系统应用到手机平台时，经过很有功底的调整就得到了愤怒的小鸟的游戏系统。递进式关卡、积分、成就和战利品收集系统也是在很多游戏中验证了其可玩性，那么愤怒的小鸟也成功糅合了类似的游戏系统，使他又增加了可玩性。

从系统相似的角度设计和分析游戏系统可玩性是一方面。另一方面，创造全新可玩性的游戏系统就只能靠不断尝试，这也是宫本茂和小岛秀夫那么伟大的原因，他们创造了全新的可玩性系统——跳跃过关和秘密潜入。这也就是说，要么你玩过很多游戏，培养出了非常好的游戏品味，能够很好的选择适合的游戏系统组合出你的游戏来保证可玩性；要么经过大量的尝试，制作并测验新的游戏系统，最终筛选出前无古人的游戏系统。否则，只能靠上帝的眷顾让你偶然开发出了从未有过的具备可玩性的游戏系统。

耐玩性是对现代游戏越来越强烈的要求。耐玩性要求游戏系统不仅可玩，而且可以支持玩家玩很久。有些游戏系统可以非常好玩，但玩家只要玩一会儿就玩完了，不会再玩这个系统了，这就是缺乏耐玩性。一个系统如何能让玩家一直玩下去，或者一遍又一遍的玩呢？

第一种方法是增加内容。例如增加后续的关卡数量，增加新的成就目标等。这就需要制作团队具备足够的人力和能力，实际上玩家玩游戏的速度永远快过制作者制作的速度。画数个月制作的新内容，玩家也就花几天时间玩完了。但这种方法的好处是效果明显。新内容可玩就能够确定的支持一段时间。

第二种方法是拉长追求时间。这其中最厉害的是转生系统，用再来一次的时间代价来获得额外属性，这些属性实际的性价比已经边际效应的递减到很低的水平了。但是，当玩家满级而无其他突进获得增强的时候，还是会选择转生的。这个方法实施起来简单，就是想办法将已有的内容进行拉长，但损失的是因挑战难度提高，获得奖励刺激减弱带来的可玩性的下降。

第三种方法是利用随机。利用合理的随机机制，让游戏自动创造出不同的内容，带来总是不一样的感受的效果。这实际上是第一种方法的改良。俄罗斯方块的方块随机和暗黑破坏神2的地图迷宫随机就属于这一方法。这种方法是有难度的，如果随机处理不当，可能会产生不良游戏效果的游戏内容。因此需要很多的时间和国内公关公司十大天才的算法来完成，并需要大量的测试与反复的改进。

最后一种方法，也是最有效的方法就是玩家自创内容。这种方法也分三种不同：

1、一题多解

设计可以支持多种方法达成统一目标的游戏系统，玩家就可以反复尝试不同的方法完成目标，创造了属于每个玩家自己的游戏体验内容。

2、玩家自建关卡

将建设关卡的基础素材开放给玩家，玩家可以自创新游戏内容，利用玩家的设计资源创造无尽的游戏内容。

3、PVP对抗

这是目前来看最有效的方法。游戏系统设置基础简单的规则，让玩家相互之间互动对抗，通过不同玩家的思想行为不同，创造出了无尽的游戏内容。围棋、象棋、Dota类游戏就是这样，因此他们也长盛不衰。

对游戏系统的认知，很重要的一点是建立MCV理念。由于游戏系统最终是程序代码实现，从设计之初就以贴近程序的视角进行设计，能够让我们更顺利和准确的进行工作。MCV理念本来就是程序设计中的概念。MCV代表Model、Control和View，也就是模型、控制和显示。

当我们对一个游戏系统有了想法后，就需要通过MCV的理念来抽象、拆分和解析我们的想法，让他成为一个真正的游戏系统。

第一步，找到这个系统里需要建立的模型数据。以排行榜系统为例，我们可以通过分析我们需要哪些排行榜，找到需要哪些玩家数据，等级榜对应玩家等级，等级榜中需要玩家名称，所在公会，职业等等信息，如果有转生，等级榜需要优先排列出以转生的玩家；战力榜需要玩家名称、最高战力（这里就提出了一个需求，要求数据库记录玩家角色达到的最高战力值）、所在公会、职业等信息，这些榜需要记录他们上次的排名，这样在刷新排名的时候，可以标示出谁的排名上升了，谁的排名下降了……就这样将所有需要记录，关注的数据条目整理出来，阐述每个数据的具体含义，就可以得到游戏系统的第一部分：Model。这些数据将成为游戏系统操作应用的对象。

第二步，找到这个系统里的所有控制功能。玩家有哪些操作，系统自动的功能有哪些？一般可以按照时间顺序推想，进行列举。再说排行榜系统。一个服务器一开始排行榜是怎样的？显然应该是空的；下一步就需要确定什么时间点刷新排行榜；刷新后第一次的排名上下标示默认应该是什么？之后刷新排行榜时需要哪些操作，如何改变排名上下标示？玩家可以通过排行榜上的名单做什么操作（私聊？加好友？组队？）？在榜首异主时如何增加全服公告？通过这样的思考，将游戏系统的所有控制功能逻辑一条条的列举并描述清楚，这就是第二部分：Control。这些功能描述将成为游戏系统核心设计。

第三步，找到这个系统有关的全部显示与反馈功能。可以通过参照Control中的一个个控制功能，进行延伸找到所有的显示与反馈功能。在这一步，我们只关心玩家能看到，听到什么。控制核心相同，但界面表现方式是可以独立出来做出很多不同种的。还是排行榜系统为例。这时候要考虑排行榜按钮是什么样子，放在什么位置。排行榜界面打开是什么样子，显示哪些内容，自己的排名显示在哪里，总共显示前多少名的排名信息，如何选择不同排行榜分页。这就是第三部分：View，在这一步，将游戏系统完全的视觉化，呈现出来。

这三步并非一定顺序执行，通常会在对某一功能进行思考的时候并行执行。最终将所有功能全部完成。

通过MCV的思考模式，我们就能够没有遗漏，足够清晰的建立自己对游戏系统的理解。这将非常有助于下一步对游戏系统进行执行的设计。

对于游戏来说（不单单是游戏系统），设计是一个过程，而不是简单的一个步骤。脑子里构想了一个游戏系统，或者写了出了一个游戏系统的构想，这都不算是游戏设计。可以说，不到游戏系统上线被玩家玩过，设计就没有完成。在系统设计的众多步骤，不断调整中，设计师需要非常综合的能力，还需要细致与耐心的品质。

系统设计的漫长步骤可以整理如下：

系统概念设计

简要描述这个系统的运作。提出这个系统的核心理念，主题或主要目的以及需要特别注意的设计点。一般这个步骤由主策划起草，系统策划辅助完善。

初步可行性沟通

以概念设计文档为基础，进行一次团队讨论，程序美术测试策划对这个系统的可行性进行评估。可以得出一些修改或制作意见，以及重点问题。一般由主策划、主程序、主美术、主测试和负责执行的系统策划共同参与讨论。

撰写系统功能设计文档

利用MCV的理念将系统设计制作成标准设计文档，阐述这个系统的所有设计细节。

撰写系统玩法规划文档

玩法性系统需要不仅需要功能，还需要有玩法设计，规划出玩家的玩法，从而得出系统的实际应用方式，反过来可以审视系统功能是否全面。

引导教学设计

每个系统都应该有自己的引导教学，让玩家在初次接触系统的时候自主学会使用该系统。有时候我们还会因为教学有难度而放弃或修改游戏系统。这一步同时可以补充一些功能和资源数据需求。

拆分出执行文档（需求文档最好有固定格式以方便需求的整理和避免需求项目的不完整）：

撰写程序功能需求文档

该文档面向程序，重点阐述系统功能点。

撰写美术资源需求文档

该文档面向美术，最好以有固定格式的表格文件进行沟通。

撰写数值设计需求文档

该文档描述玩法规划需要的数值感受。由于游戏数值是一个整体，需要数值策划进行具体的设计安排。系统策划自己独立定下的数值可能不合适。

撰写策划数据需求文档

该文档将系统中需要的策划数据的需求提出，交由数据执行策划进行数据的实际制作。由于一个系统可能涉及很多很多不同的数据，因此该文档可能还会进一步细分为物品需求、NPC需求、怪物需求、掉落策略需求等。

撰写关卡设计需求文档

当系统设计需要新的关卡或对原有关卡进行修改时，就需要提交这个需求文档，用以向关卡策划说明如何配合制作关卡。

撰写测试需求文档

这个文档经常被忽略，如果测试不提前知道系统需要如何的测试环境，如何的测试方法。当系统各项功能数据做完后，会尴尬的发现要等很久才能得到测试反馈。一个实际的例子就是跨服战场系统设计完后，测试人员才接到测试需求，于是耽误了两天时间找机器建立多个服务器才能进行跨服测试。如果他们早就知道本次版本有这样的测试需求，他们可以提前做好准备，事半功倍。

再次确认所有设计细节的可行性

执行文档提交后需要向相关负责人再次确认这些需求是可以满足的，并得到预计用时，如有问题还需要进一步修改设计或调整需求。这一步以及后面的几个步骤都考验系统设计者的责任心和耐心。

跟踪需求执行情况

需求提出后不是再也不管了。设计者需要时刻最终这些需求的当前进度如何，进度产生问题，只有发现了才能及时处理。很多具体的执行人员并没有足够的自主性，在遇到问题时，往往是搁置等待，只有设计者查询进度情况时才会反应问题。也就是说，设计者没有跟踪这些执行情况，很可能导致执行过程失控。

协调团队设计约定

需求执行者之间非常有可能需要相互的设计约定。例如程序为新功能指定了功能ID，这个功能ID需要NPC数据执行策划进行实际数据的填写，在其中牵线搭桥的还是设计者自己，不能指望程序指定了功能ID，会主动找到谁是做NPC功能的策划，再去通知这个策划，也不能指望做NPC功能的策划老是跑去订着程序有没有指定好新功能的ID。系统设计之下的一切沟通都要经过设计者自己的手，也只有这样系统设计者才能够控制住整个设计。

组织联合测试

确认所有需求都已经完成后，组织好所有资源，进行联合测试，验证系统功能和玩法是否都满足需求。

维护修订各类设计与需求文档

对测试结果进行处理，分派修改bug。对不足的地方进行重新设计，进过几个循环逐步完善系统至最终定版效果。

要制作一个游戏系统，系统设计者不可能独自完成所有工作，也不可能让其他配合人员各自独立完成工作。系统设计者常常需要扮演总指挥的角色，将系统拆分成一个个小的工作点，交给各类专门负责人解决，再将这些工作集合在一起，通过系统设计者在这个过程中主要进行的推动力的作用，才能将一个系统最终制作成型。因此，系统设计者对于实际执行过程的知识越多越丰富，那么他在推动一个系统执行的时候，就会越拿手。新系统策划就是因为不熟悉各个环节需要提供的信息，而导致设计执行过程中困难重重，难免造成失误和漏洞。所以设计者面临的最终挑战不是思考系统设计，而是进行设计的执行能力。

设计和需求文档在系统设计中扮演重要角色。只是口头临时沟通，缺少文档而导致的误解和遗漏在工作中也是屡见不鲜的。不少公司对于系统设计文档有非常明确的格式与内容要求，这样做非常有益，至少能引起设计者的重视。

在做系统设计文档是可以注意以下几点经验：

首先明确设计这个系统的意义（要解决的问题或带来的效果）

重点先行，给出可类比的例子

按时间或空间顺序进行功能拆分，逐个阐述

按点描述说明，不使用大段文字

使用简易图标，不做复杂的图标

做玩法规划文档的时候需要包含以下内容：

系统的数据如何布置在游戏中

玩家如何介入该系统

玩家玩这个系统的目标列举

玩家玩这个系统的过程列举

玩家玩这个系统会产生哪些变化

其他系统如何与这个系统

系统的玩点在哪里

提需求文档时，需求文档应注意以下几点：

明确需求的东西，清晰的列举

需求全面，不要遗漏什么让执行者无法顺利完成

明确负责人

明确需电视媒体宣传求文档存放的位置唯一，千万不要一个文档好几份

明确需求反馈或完成的时间结点

需求有修改要立刻维护更新文档，更新后要邮件通知相关人员

文档做到设计的一切有据可查，就是最好了。

有关文档，还需要注意一点——不能迷信于文档。文档虽然重要，但那毕竟还是辅助设计的工具，设计本身是个过程，过程比文档要重要。设计实际上是观察、想象、推理、预测、沟通、写代码、绘图、做数据、测试、完善的过程。由于我们的系统相当庞大，才需要有很多文档，这些文字的东西来帮助我们记录与沟通。并不是一切都是在写，或者只要写了就完事了。更重要的是执行这个过程的意识与行动。没有哪个设计是写完文档就完事了，还需要更多更多的沟通和维护。

流程图、UI设计图和程序脚本是系统设计者常用的三种工具。系统设计者应该熟练使用这三样工具。

流程图负责传达系统的程序功能，若要深入理解可以参考UML相关书籍。流程图看似简单，好像谁都会做，但实际上是有严格规范的程序语言。工作中不乏随便滥用，难看又难懂的流程图。策划们还是应该先做做功课，不能把事情想简单了。

UI设计是系统策划的一项基本功。这个涉及到人机交互领域的相关知识，在其他地方都有很多设计参考。使用PS或其他专业UI设计工具快速老练的设计出画面好、功能佳的UI，这是需要多年的经验和锻炼的。

程序脚本分为很多种，不同的项目可能采用不同的脚本。常用的脚本语言有：Python，Lua。掌握一定的程序基础，学习这些脚本并不难，用好却不简单。若要提高可以参考一些算法、数据结构和设计模式的书籍。脚本和UI设计一样，需要在实战中才能掌握。