游戏系统策划案的特点及特点和特点性分析

　　游戏系统策划案的特点及特点和特点性分析

　　一、系统规划概述

　　1.1 什么是系统方案？

　　游戏系统规划方案是关于游戏规则、UI界面以及考虑用户交互体验的规划方案。也是团队中提供给开发者的文档，方便开发者更好的理解游戏设计的内容。规划以“规划方案”的形式将想法传达给开发者，做出相应的功能。它是用于通信的文档。

　　1.2 合格系统方案的特点

　　可读性：《规划方案》需要以最简单直观的方式，以最少的时间消耗，将规划思路和思路等设计要求传达给开发者。因此，《规划方案》需要字数简洁、易读、排版。整洁、组织清晰的特点不应该是冗长的、空洞的内容和一些无用的例子。 “规划方案”不是一张纸，可以让规划者随意泼墨。

　　合理性：“规划方案”是基于游戏设计的开发文件，因此必须满足“规划方案”的合理性。包括合理的内容设计、合理的开发要求、合理的美术要求以及后期满足维护和扩展的需求。

　　完成：我们无法保证“规划方案”的初稿会完美，因此我们会在游戏更新过程中不断对设计进行调整，并继续跟进和完善“规划方案”以上各项规则和设计，检查遗漏，填补空缺，尽量减少“规划方案”设计中的漏洞。

　　1.3写计划前的准备

　　同类竞品研究：如果我们需要写系统方案，最好观察同类竞品在系统上是如何设计的，寻找设计灵感，然后产生设计思路。这样做，我们将确保我们的系统设计在竞争游戏中具有足够的竞争力，同时我们可以在系统设计上满足游戏框架的需求。

　　思维导图推理与练习：我们对竞品做了研究，有了一定的设计思路后，可以用“脑图”的形式对原型进行推理和练习，然后仔细思考删除选择不必要的设计让您的设计更合理。

　　UI原型设计：我们会在思维导图中为其UI原型生成设计思路，并在“规划方案”中优先设计思维导图中使用的UI原型。考虑用户体验的合理性和便利性，然后设计UI原型。

　　流程图设计：涉及游戏循环、UI结构等逻辑清晰部分的设计思路，以流程图的形式表达其变换关系，全部呈现在“规划方案”中，可优化服务器判断以满足合理完整的工艺要求。

　　二、计划的基本格式

　　既然是系统方案，就必须有标准的排版和字体。一是看起来专业，二是要有明确的规定和明确的要点，让程序员更容易理解计划的内容和重点，减少程序。人们阅读有困难，他们可以直接快速地找出他们想要找到的点。如果没有规范排版和字体的计划，别人看的时候，第一感觉就是不舒服，增加眼睛疲劳。主要内容都堆成一堆，读起来很吃力。

　　2.1 排版

　　计划主题置于页面顶部，居中对齐；

　　整个计划应该有一个清晰的文档结构。在编写不同的内容点时，正文应划分为不同的副标题。如果每个小标题都可以分为不同的点，则继续进行划分以确保计划的格式。整洁。

　　2.2font

　　各级标题字体为微软雅黑，粗体；

　　正文字体也是微软雅黑；字体大小为5；

　　每级标题字体大小依次减小，大致如下：主标题>副标题1>副标题2>...>正文。

　　2.3存档记录

　　一个标准的、标准化的系统方案，也会在其开头附上一个存档记录，记录每次修改的内容、日期和负责人。档案记录表格置于主题之下，其他内容之上。

　　三、规划案例写作

　　在写方案的时候，脑子里一定要有明确的设计目的和设计思路，注意实现方法上的各种规范和细节，再加上知识的积累和一些独到的创意，才能写出好的案例接下来，我将一一讲解方案的编写。

　　3.1 设计目的

　　每个设计目的的来源都是发现需求，分析需求，然后确定需求。

　　3.1.1 寻找需求

　　例如，几种常见的驾驶情况：玩家驱动、自我驱动和操作反馈。

　　玩家驱动：

　　比如游戏论坛里的一群玩家讨论“XX角色太丑了！”——外观要求

　　“每天都是地牢，有点无聊，和人打架很好玩！”——PVP竞技场需求

　　“50级就满级了，才玩了两个星期，真无聊！”——需要提高等级上限

　　自我驱动：比如你发现某款游戏的支付系统做得很好，很多玩家愿意付费，或者在体验你团队开发的游戏时发现社交系统出了问题.

　　运营反馈：通过运营部分发出的反馈，如某级别玩家活跃度低，支付率未达到预期状态等

　　3.1.2分析和确定需求

　　如果我们找到一个需求，我们就可以开始分析它。是什么导致了这个问题？例如，玩家的社交互动太少？付费空间不够？你想增加功能系统吗？增加了什么样的功能系统？分析需求后，我们确定了。

　　3.1.3Summary

　　所以在做一个系统之前，你要弄清楚这个系统在做完之后需要达到什么作用，以及为什么要拥有这个系统。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .游戏中的每一个系统都不是多余的，大部分都是为了提高游戏的可玩性和寿命，为玩家提供支付空间，培养玩家的支付心理。如果设计目的不明确，就很难设计出一个好的系统，甚至是一个没用的系统，增加了开发者的负担，浪费了研发资金和时间。

　　设计目的在写作时要简明扼要，让人们尽快理解整个系统的设计意义。同时，设计目的也规范了系统在设计时的方向和思路。比如《撕逼江湖》中帮派系统的设计目的：“增加玩家互动；提供道具、装备等输出；提供增益buff。”短短的几句话，直接说明了这个系统的设计目的，一目了然。我知道帮派系统是做什么的，为什么要设计帮派系统。

　　3.2 实现方法

　　有了设计目的之后，我们应该回溯设计目的，写出具体的实现方法，就是这个系统的功能描述。功能描述是本系统的手册，将使用界面UI、流程图和配置表来辅助完成系统。当涉及到一些逻辑规则时，最好用流程图来表达；在讲解一个系统的时候，最好附上一个基本的UI界面，这样就容易理解程序；配置表通常会是另一种EXCEL表格，在规划案例中只是粗略的说明。在编写函数描述时，要注意逻辑的正确性，对各种细节的考虑，各种操作的结果，防止漏洞。

　　3.2.1功能说明

　　例如《撕毁江湖》签到系统的规则说明：

　　1概览

　　2 系统规则

　　2.1 登录入口

　　2.2 登录七日奖励

　　2.2.1领取奖励

　　2.2.2 奖励提示和界面隐藏规则

　　2.3月签系统

　　2.3.1 登录检测

　　2.3.2 登录界面

　　2.3.3 登录界面逻辑

　　2.3.4 奖励提醒规则

　　规则概览：规则概览是对本系统基本玩法的介绍。例如，奖励机制分为7天和1个月。七日内每天签到一次。总共7天可以获得7天奖励，一个月可以获得月签。奖励、7天奖励和包月奖励只能获得一次。规则概览直接表达了本系统的内容框架，以下几点将在规则概览的内容框架下对其进行细化和完善。

　　规则说明：规则说明会详细说明系统的具体规则和各种操作的逻辑说明，以及*敏*感*词*和音效的播放。它涉及到这个功能的方方面面，如果涉及到配置表，还要读取配置表。比如设计主城的签到入口，进入签到系统的基本界面UI，播放每个操作触发的*敏*感*词*和音效等等。

　　总结：规划计划用作沟通文件。在写这部分时，你应该使用适当的图片和表格来表达你的想法。如果可以用图片来说明，可以添加图片，用表格来说明，只要列出网格就清晰明了，让开发者在做功能的时候能更快的了解规划者的意图。使用大量的纯文本来表达会让人头疼，而且容易让人理解偏差。 在编写系统规则时，一定要注意不要遗漏任何细节。例如，接收状态有三种类型，即应收、不可收和已收。有必要详细说明一下这三种接收状态以及是什么情况。下次开会就处于可以索赔的状态，什么情况下不能收到，什么情况下已经收到：

　　玩家累计登录天数≥奖励所需天数处于可领取状态，并显示按钮。点击后会发放奖励，播放音效，弹出界面；

　　玩家累计天数副标题1>副标题2>...>正文。

　　2.3存档记录

　　一个标准的、标准化的系统方案，也会在其开头附上一个存档记录，记录每次修改的内容、日期和负责人。档案记录表格置于主题之下，其他内容之上。

　　三、规划案例写作

　　在写方案的时候，脑子里一定要有明确的设计目的和设计思路，注意实现方法上的各种规范和细节，再加上知识的积累和一些独到的创意，才能写出好的案例接下来，我将一一讲解方案的编写。

　　3.1 设计目的

　　每个设计目的的来源都是发现需求，分析需求，然后确定需求。

　　3.1.1 寻找需求

　　例如，几种常见的驾驶情况：玩家驱动、自我驱动和操作反馈。

　　玩家驱动：

　　比如游戏论坛里的一群玩家讨论“XX角色太丑了！”——外观要求

　　“每天都是地牢，有点无聊，和人打架很好玩！”——PVP竞技场需求

　　“50级就满级了，才玩了两个星期，真无聊！”——需要提高等级上限

　　自我驱动：比如你发现某款游戏的支付系统做得很好，很多玩家愿意付费，或者在体验你团队开发的游戏时发现社交系统出了问题.

　　运营反馈：通过运营部分发出的反馈，如某级别玩家活跃度低，支付率未达到预期状态等

　　3.1.2分析和确定需求

　　如果我们找到一个需求，我们就可以开始分析它。是什么导致了这个问题？例如，玩家的社交互动太少？付费空间不够？你想增加功能系统吗？增加了什么样的功能系统？分析需求后，我们确定了。

　　3.1.3Summary

　　所以在做一个系统之前，你要弄清楚这个系统在做完之后需要达到什么作用，以及为什么要拥有这个系统。游戏中的每一个系统都不是多余的，大部分都是为了提高游戏的可玩性和寿命，为玩家提供支付空间，培养玩家的支付心理。如果设计目的不明确，就很难设计出一个好的系统，甚至是一个没用的系统，增加了开发者的负担，浪费了研发资金和时间。

　　设计目的在写作时要简明扼要，让人们尽快理解整个系统的设计意义。同时，设计目的也规范了系统在设计时的方向和思路。比如《撕逼江湖》中帮派系统的设计目的：“增加玩家互动；提供道具、装备等输出；提供增益buff。”短短的几句话，直接说明了这个系统的设计目的，一目了然。我知道帮派系统是做什么的，为什么要设计帮派系统。

　　3.2 实现方法

　　有了设计目的之后，我们应该回溯设计目的，写出具体的实现方法，就是这个系统的功能描述。功能描述是本系统的手册，将使用界面UI、流程图和配置表来辅助完成系统。当涉及到一些逻辑规则时，最好用流程图来表达；在讲解一个系统的时候，最好附上一个基本的UI界面，这样就容易理解程序；配置表通常会是另一种EXCEL表格，在规划案例中只是粗略的说明。在编写函数描述时，要注意逻辑的正确性，对各种细节的考虑，各种操作的结果，防止漏洞。

　　3.2.1功能说明

　　例如《撕毁江湖》签到系统的规则说明：

　　1概览

　　2 系统规则

　　2.1 登录入口

　　2.2 登录七日奖励

　　2.2.1领取奖励

　　2.2.2 奖励提示和界面隐藏规则

　　2.3月签系统

　　2.3.1 登录检测

　　2.3.2 登录界面

　　2.3.3 登录界面逻辑

　　2.3.4 奖励提醒规则

　　规则概览：规则概览是对本系统基本玩法的介绍。例如，奖励机制分为7天和1个月。七日内每天签到一次。总共7天可以获得7天奖励，一个月可以获得月签。奖励、7天奖励和包月奖励只能获得一次。规则概览直接表达了本系统的内容框架，以下几点将在规则概览的内容框架下对其进行细化和完善。

　　规则说明：规则说明会详细说明系统的具体规则和各种操作的逻辑说明，以及*敏*感*词*和音效的播放。它涉及到这个功能的方方面面，如果涉及到配置表，还要读取配置表。比如设计主城的签到入口，进入签到系统的基本界面UI，播放每个操作触发的*敏*感*词*和音效等等。

　　总结：规划计划用作沟通文件。在写这部分时，你应该使用适当的图片和表格来表达你的想法。如果可以用图片来说明，可以添加图片，用表格来说明，只要列出网格就清晰明了，让开发者在做功能的时候能更快的了解规划者的意图。使用大量的纯文本来表达会让人头疼，而且容易让人理解偏差。 在编写系统规则时，一定要注意不要遗漏任何细节。例如，接收状态有三种类型，即应收、不可收和已收。有必要详细说明一下这三种接收状态以及是什么情况。下次开会就处于可以索赔的状态，什么情况下不能收到，什么情况下已经收到：

　　玩家累计登录天数≥奖励所需天数处于可领取状态，并显示按钮。点击后会发放奖励，播放音效，弹出界面；

<p>玩家累计天数