六年谈-7.系统设计中的设计

jiyi713

相关链接：

六年谈-1.游戏工作室与游戏开发过程简介
六年谈-2.了解程序、美术与测试
六年谈-3.策划的工作内容与工作管理简述
六年谈-4.沟通、会议
六年谈-5.创造游戏的世界
六年谈-6.系统设计中的系统  
六年谈-7.系统设计中的设计  
六年谈-8.数值设计过程
六年谈-9.游戏数值原理与技巧
六年谈-10.游戏关卡的杂谈
六年谈-11.挑战中心规划
六年谈-12.工程管理
六年谈-13.人文管理




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

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

    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设计一样，需要在实战中才能掌握。

duuuubar

新手学习了

l285440467

这一堆废话

aiiaib

没法删除，只能编辑了