游戏开发系统功能（9）
一个游戏的系统可以按照以下列举的顺序进行：
l 登录创角色
l 主UI
l 游戏地图
l 副本
l 玩家角色
l 升级成长
l 交互NPC
l 怪物
l 战斗规则
l 职业技能
l 装备
l 宠物
l 道具
l 任务
l 聊天
l 邮件
l 交易、摆摊、拍卖、NPC商店
l 商城
l 组队
l 社交（好有、仇人、师徒）
l 成就
l 公会
l PVP
l 排行榜
l 活动
l 教学引导
考虑游戏系统好坏着眼于易用性、灵活性、可玩性和耐玩性这四点（功能性系统就不用考虑后两点了）。
当我们对一个游戏系统有了想法后，就需要通过MCV的理念来抽象、拆分和解析我们的想法，让他成为一个真正的游戏系统。
第一步，找到这个系统里需要建立的模型数据。以排行榜系统为例，我们可以通过分析我们需要哪些排行榜，找到需要哪些玩家数据，等级榜对应玩家等级，等级榜中需要玩家名称，所在公会，职业等等信息，如果有转生，等级榜需要优先排列出以转生的玩家；战力榜需要玩家名称、最高战力（这里就提出了一个需求，要求数据库记录玩家角色达到的最高战力值）、所在公会、职业等信息，这些榜需要记录他们上次的排名，这样在刷新排名的时候，可以标示出谁的排名上升了，谁的排名下降了……就这样将所有需要记录，关注的数据条目整理出来，阐述每个数据的具体含义，就可以得到游戏系统的第一部分：Model。这些数据将成为游戏系统操作应用的对象。
第二步，找到这个系统里的所有控制功能。玩家有哪些操作，系统自动的功能有哪些？一般可以按照时间顺序推想，进行列举。再说排行榜系统。一个服务器一开始排行榜是怎样的？显然应该是空的；下一步就需要确定什么时间点刷新排行榜；刷新后第一次的排名上下标示默认应该是什么？之后刷新排行榜时需要哪些操作，如何改变排名上下标示？玩家可以通过排行榜上的名单做什么操作（私聊？加好友？组队？）？在榜首异主时如何增加全服公告？通过这样的思考，将游戏系统的所有控制功能逻辑一条条的列举并描述清楚，这就是第二部分：Control。这些功能描述将成为游戏系统核心设计。
第三步，找到这个系统有关的全部显示与反馈功能。可以通过参照Control中的一个个控制功能，进行延伸找到所有的显示与反馈功能。在这一步，我们只关心玩家能看到，听到什么。控制核心相同，但界面表现方式是可以独立出来做出很多不同种的。还是排行榜系统为例。这时候要考虑排行榜按钮是什么样子，放在什么位置。排行榜界面打开是什么样子，显示哪些内容，自己的排名显示在哪里，总共显示前多少名的排名信息，如何选择不同排行榜分页。这就是第三部分：View，在这一步，将游戏系统完全的视觉化，呈现出来。
这三步并非一定顺序执行，通常会在对某一功能进行思考的时候并行执行。最终将所有功能全部完成。
通过MCV的思考模式，我们就能够没有遗漏，足够清晰的建立自己对游戏系统的理解。这将非常有助于下一步对游戏系统进行执行的设计。
系统设计的漫长步骤可以整理如下：
l 系统概念设计
简要描述这个系统的运作。提出这个系统的核心理念，主题或主要目的以及需要特别注意的设计点。一般这个步骤由主策划起草，系统策划辅助完善。
l 初步可行性沟通
以概念设计文档为基础，进行一次团队讨论，程序美术测试策划对这个系统的可行性进行评估。可以得出一些修改或制作意见，以及重点问题。一般由主策划、主程序、主美术、主测试和负责执行的系统策划共同参与讨论。
l 撰写系统功能设计文档
利用MCV的理念将系统设计制作成标准设计文档，阐述这个系统的所有设计细节。
l 撰写系统玩法规划文档
玩法性系统需要不仅需要功能，还需要有玩法设计，规划出玩家的玩法，从而得出系统的实际应用方式，反过来可以审视系统功能是否全面。
l 引导教学设计
每个系统都应该有自己的引导教学，让玩家在初次接触系统的时候自主学会使用该系统。有时候我们还会因为教学有难度而放弃或修改游戏系统。这一步同时可以补充一些功能和资源数据需求。
l 拆分出执行文档（需求文档最好有固定格式以方便需求的整理和避免需求项目的不完整）：
n 撰写程序功能需求文档
该文档面向程序，重点阐述系统功能点。
n 撰写美术资源需求文档
该文档面向美术，最好以有固定格式的表格文件进行沟通。
n 撰写数值设计需求文档
该文档描述玩法规划需要的数值感受。由于游戏数值是一个整体，需要数值策划进行具体的设计安排。系统策划自己独立定下的数值可能不合适。
n 撰写策划数据需求文档
该文档将系统中需要的策划数据的需求提出，交由数据执行策划进行数据的实际制作。由于一个系统可能涉及很多很多不同的数据，因此该文档可能还会进一步细分为物品需求、NPC需求、怪物需求、掉落策略需求等。
n 撰写关卡设计需求文档
当系统设计需要新的关卡或对原有关卡进行修改时，就需要提交这个需求文档，用以向关卡策划说明如何配合制作关卡。
n 撰写测试需求文档
这个文档经常被忽略，如果测试不提前知道系统需要如何的测试环境，如何的测试方法。当系统各项功能数据做完后，会尴尬的发现要等很久才能得到测试反馈。一个实际的例子就是跨服战场系统设计完后，测试人员才接到测试需求，于是耽误了两天时间找机器建立多个服务器才能进行跨服测试。如果他们早就知道本次版本有这样的测试需求，他们可以提前做好准备，事半功倍。
l 再次确认所有设计细节的可行性
执行文档提交后需要向相关负责人再次确认这些需求是可以满足的，并得到预计用时，如有问题还需要进一步修改设计或调整需求。这一步以及后面的几个步骤都考验系统设计者的责任心和耐心。
l 跟踪需求执行情况
需求提出后不是再也不管了。设计者需要时刻最终这些需求的当前进度如何，进度产生问题，只有发现了才能及时处理。很多具体的执行人员并没有足够的自主性，在遇到问题时，往往是搁置等待，只有设计者查询进度情况时才会反应问题。也就是说，设计者没有跟踪这些执行情况，很可能导致执行过程失控。
l 协调团队设计约定
需求执行者之间非常有可能需要相互的设计约定。例如程序为新功能指定了功能ID，这个功能ID需要NPC数据执行策划进行实际数据的填写，在其中牵线搭桥的还是设计者自己，不能指望程序指定了功能ID，会主动找到谁是做NPC功能的策划，再去通知这个策划，也不能指望做NPC功能的策划老是跑去订着程序有没有指定好新功能的ID。系统设计之下的一切沟通都要经过设计者自己的手，也只有这样系统设计者才能够控制住整个设计。
l 组织联合测试
确认所有需求都已经完成后，组织好所有资源，进行联合测试，验证系统功能和玩法是否都满足需求。
l 维护修订各类设计与需求文档
对测试结果进行处理，分派修改bug。对不足的地方进行重新设计，进过几个循环逐步完善系统至最终定版效果。
要制作一个游戏系统，系统设计者不可能独自完成所有工作，也不可能让其他配合人员各自独立完成工作。系统设计者常常需要扮演总指挥的角色，将系统拆分成一个个小的工作点，交给各类专门负责人解决，再将这些工作集合在一起，通过系统设计者在这个过程中主要进行的推动力的作用，才能将一个系统最终制作成型。因此，系统设计者对于实际执行过程的知识越多越丰富，那么他在推动一个系统执行的时候，就会越拿手。新系统策划就是因为不熟悉各个环节需要提供的信息，而导致设计执行过程中困难重重，难免造成失误和漏洞。所以设计者面临的最终挑战不是思考系统设计，而是进行设计的执行能力。
设计和需求文档在系统设计中扮演重要角色。只是口头临时沟通，缺少文档而导致的误解和遗漏在工作中也是屡见不鲜的。不少公司对于系统设计文档有非常明确的格式与内容要求，这样做非常有益，至少能引起设计者的重视。
在做系统设计文档是可以注意以下几点经验：
l 首先明确设计这个系统的意义（要解决的问题或带来的效果）
l 重点先行，给出可类比的例子
l 按时间或空间顺序进行功能拆分，逐个阐述
l 按点描述说明，不使用大段文字
l 使用简易图标，不做复杂的图标
做玩法规划文档的时候需要包含以下内容：
l 系统的数据如何布置在游戏中
l 玩家如何介入该系统
l 玩家玩这个系统的目标列举
l 玩家玩这个系统的过程列举
l 玩家玩这个系统会产生哪些变化
l 其他系统如何与这个系统
l 系统的玩点在哪里
提需求文档时，需求文档应注意以下几点：
l 明确需求的东西，清晰的列举
l 需求全面，不要遗漏什么让执行者无法顺利完成
l 明确负责人
l 明确需求文档存放的位置唯一，千万不要一个文档好几份
l 明确需求反馈或完成的时间结点
l 需求有修改要立刻维护更新文档，更新后要邮件通知相关人员
文档做到设计的一切有据可查，就是最好了。
有关文档，还需要注意一点——不能迷信于文档。文档虽然重要，但那毕竟还是辅助设计的工具，设计本身是个过程，过程比文档要重要。设计实际上是观察、想象、推理、预测、沟通、写代码、绘图、做数据、测试、完善的过程。由于我们的系统相当庞大，才需要有很多文档，这些文字的东西来帮助我们记录与沟通。并不是一切都是在写，或者只要写了就完事了。更重要的是执行这个过程的意识与行动。没有哪个设计是写完文档就完事了，还需要更多更多的沟通和维护。
流程图、UI设计图和程序脚本是系统设计者常用的三种工具。系统设计者应该熟练使用这三样工具。
流程图负责传达系统的程序功能，若要深入理解可以参考UML相关书籍。流程图看似简单，好像谁都会做，但实际上是有严格规范的程序语言。工作中不乏随便滥用，难看又难懂的流程图。策划们还是应该先做做功课，不能把事情想简单了。
UI设计是系统策划的一项基本功。这个涉及到人机交互领域的相关知识，在其他地方都有很多设计参考。使用PS或其他专业UI设计工具快速老练的设计出画面好、功能佳的UI，这是需要多年的经验和锻炼的。
程序脚本分为很多种，不同的项目可能采用不同的脚本。常用的脚本语言有：Python，Lua。掌握一定的程序基础，学习这些脚本并不难，用好却不简单。若要提高可以参考一些算法、数据结构和设计模式的书籍。脚本和UI设计一样，需要在实战中才能掌握。
