游戏服务端自动化（游戏聊天系统的结构设计和功能逻辑）

游戏服务端自动化（游戏聊天系统的结构设计和功能逻辑）对于聊天系统而言，在面对关系型社交结构的时候，需要解决的问题是聊天系统的能力如何帮助玩家进行关系的建立与递进，而面对服务型社交结构的时候，需要解决的问题是在不同场景下如何高效交流。很多时候关系型社交也会对服务型社交有所需求，但是总的来说，两者适用于不同的场景。要构建一个系统的结构，需要明确该系统的解决的问题。聊天系统是社交结构的重要且基础的组成部分，其承载了解决社交痛点的重任，在开始解析聊天系统结构之前，我们先从社交结构出发简单聊一下。社交体系一般有两种方向，一种是关系型社交，目的是解决玩家之间连接的问题，一种是服务型社交，目的是解决玩家之间交流的问题。前者关注于玩家之间如何通过社交形成稳定的连接关系，而后者关注如何通过合适的沟通方式提升不同系统玩法的体验。那么问题来了，这种交易信息属于哪种社交需求呢？

文/八云茉莉

首发于公众号“蕾米莉亚喜欢玩游戏”，GameRes经授权发布

上一篇聊完了聊天系统的价值，本篇终于轮到结构设计和功能逻辑了。很庆幸决定分三部分来写，这才让我有了写完的可能（手动狗头）。

聊天系统结构

要构建一个系统的结构，需要明确该系统的解决的问题。聊天系统是社交结构的重要且基础的组成部分，其承载了解决社交痛点的重任，在开始解析聊天系统结构之前，我们先从社交结构出发简单聊一下。

社交体系一般有两种方向，一种是关系型社交，目的是解决玩家之间连接的问题，一种是服务型社交，目的是解决玩家之间交流的问题。前者关注于玩家之间如何通过社交形成稳定的连接关系，而后者关注如何通过合适的沟通方式提升不同系统玩法的体验。

那么问题来了，这种交易信息属于哪种社交需求呢？

很多时候关系型社交也会对服务型社交有所需求，但是总的来说，两者适用于不同的场景。

对于聊天系统而言，在面对关系型社交结构的时候，需要解决的问题是聊天系统的能力如何帮助玩家进行关系的建立与递进，而面对服务型社交结构的时候，需要解决的问题是在不同场景下如何高效交流。

此外，从前一章可以总结，聊天系统除了是社交结构中重要的组成部分，对各类系统玩法的反馈承载也是其重要的价值之一，比如潜移默化的引导、反馈和基于聊天能力的玩法。

最后，聊天系统可以集成多元化的内容，留存、活跃和付费设计或多或少可以在聊天系统中展现。

综上所述，一个聊天系统最基础的结构设计可以概括为下面的图示：

到了这一步，我们就可以对聊天系统做详细的结构设计了。

1.1社交关系的建立与递进

亚瑟阿伦的36个问题想必大家都有所耳闻，从这个著名的心理学实验中我们可以得知，人们之间的关系递进并不取决于“三观”相同，而是建立“共情”。自我暴露理论指出，人们通过打招呼—聊天—交换“秘密”（深入聊天）而获得更加深入的了解，进而建立起共情，并进一步发展为信任。

值得康康

互联网的匿名性更容易让人们深入交流而不被现实束缚，且互联网和现实的隔离能够让人们有可能重新塑造与众不同的个体，这些都有助于建立共情。

除了打招呼—聊天—深入交流以外，玩家之间的共同的行为的回忆也会作为一种可回顾的信息促进建立共情，增强信任。比如一些玩法中的合作对抗等等。

聊天系统的能力贯穿整个关系建立到递进过程，它从聚焦社交范围，到提供表达工具，再到承载共情话题，最终还会为关系递进提供支撑性内容。这一系列的能力组成了聊天系统在社交关系部分的基础结构。

下面拆开来讲这部分结构。

社交范围

社交范围影响个体建立联系的速度，一般来说，划分的社交范围越大，话题响应越不易集中，大部分参与用户获得社交奖励的频率极低，个体间的联系难建立（但是越大型的圈子单次获得的社交奖励价值越大，这是一种“圈子X奖励”的动态平衡）。

基于个体建立联系的需求，聊天系统需要建立适应不同社交范围的微型、小型、中型的社交圈子，便于玩家在社交中建立联系。常见的设计就是聊天分区，比如帮派聊天（中大型圈子）、队伍聊天（小型圈子）、私聊（微型圈子）、自建群聊天（小型/中型圈子）、划分频道的世界聊天（中大型圈子）。

欢迎来到大型聊天交友APP，请右上角切换房间

但是常见的分区并不一定满足所有游戏，明确圈子范围是聊天系统结构中第一个要处理好的事情。比如国战题材游戏中同国家帮派管理层社交分区、同类型玩家（比如新手玩家）社交分区等，这些分区设计都算是不太常见但是适合本身用户属性的设计。

规划聊天系统分区分为两部分，首先规划处较为基础的三类范围不同的圈子：私聊、队伍和世界聊天，第二部分是按照玩法和系统划分，将可以形成话题或本身就是关系引导的玩法系统划分出独立的分区，比如帮派、社区（一种基于家园系统的社交场景——剑网三中可以看到这种场景）、新手、交易、阵营等等。

这就是传说中的大型沙雕聊天软件，看到街坊了嘛

（这里插一句，其实有一个分区和游戏本身社交属性有挂钩，但是和游戏的系统玩法本身并无太大关联，那就是我们常说的匿名社交或者说树洞。这种形式可以参考梦幻西游端游的传闻频道，它非常有特色，对社交关系递进的影响是曲折的，我不对这种分区做详细说明，但是大家可以仔细考虑一下这种分区的价值。）

个体表达

现实中的个体表达是一个极为复杂的过程，有着非常多样的形式，一般来说可以简单划分为直接表达和间接表达。直接表达是直接通过语言传递个体要表达的内容，间接表达则是通过行为、动作，甚至眼神、语气等进行表达。

在这个层面上，聊天系统肯定无法达到现实中如此多样的表达方式，但是还是可以分为直接表达和间接表达的。

直接表达是通过文字、语言、图片等内容进行表达，构建的时候首先要明确表达信息的能力，比如文字和语音，第二是考虑构建提升表达的能力，比如图片，最后考虑是否需要衍生能力，比如语音转文字。

间接表达则是通过非文字语言的内容，但是不提供视频聊天的功能情况下（大多数游戏最多做到嵌入直播……），间接表达可以通过文本化来进行的。比如，微信拍一拍、心情图片，颜文字，有点类似早期的MUD游戏。

比起代码只需要写一行，背后的使用逻辑可是多样的

构建间接表达首先要考虑常用的表达，比如生气、开心、赞扬、吐槽，再根据需要的表达确定表达形式，比如表情、签名、点赞、提示等，最终设计对应的功能，集成入聊天系统。

间接表达是一个非常复杂的部分，构建的时候可以参考社交工具APP。

共情话题

我们说的共情话题来源一般分为两种，一种是玩家自己发起的社交话题，另一种是基于游戏内玩法或者系统产生的话题。

玩家自己发起的社交话题很难控制或引导，有时候这些内容会与三次元现实有关，有时候这些内容则与其他边缘系统息息相关，聊天系统本身发挥的作用更多还是话题载体。这部分内容如果要细致讨论恐怕又是一个数千字的篇幅了，我们暂且放下，还有一件相关的事情更为重要。

我们要规划聊天的限制，防止社交话题带来的恶性影响，无论是私聊的骚扰，还是世界聊天的一些不和谐论调，都对项目本身有着非常坏的影响，这部分要规划好相应的处理方式，比如聊天限制、屏蔽字、举报等。

接下来说基于游戏玩法或者系统产生的话题。

游戏内玩法产生话题不是聊天系统结构设计中要关注的点，这些话题需要各个系统的能力配合，聊天系统要关注的是如何能够便捷的传递这些话题，能够让玩家更容易开启社交。举个例子，部分多人副本成就弹窗在帮派聊天频道展示。

到底什么样的话题可以在什么范围的圈子中传递？一个简单的处理方式是按照话题出现难易程度，越难出现的话题投放到越大圈子中。

更为细致的处理则要考虑话题和受众的契合程度。比如战队赛的话题在战队比赛的小组中传递。（这个设计很主观！和人群属性也有关系，建议多方面考虑或者尝试）

除此之外，聊天系统应当具备展现各个玩法和系统相关话题的能力，比如再举一个成就的例子，聊天频道可以插入已完成的成就条目，供别人查看。聊天系统可以插入自身装备、宠物等信息，供大家讨论。

关系递进

上述三部分共同作用构建社交关系，而下面这个部分更独立，也是作用在上述三部分之上的聊天系统中重要的社交关系支持工具……

知乎经常会推送给我一个问题——为什么现在的男生追女生追到一半就不追了？

这个问题很像是钓鱼问题，不过我更想探讨的是，追一半是一种什么概念？

社交这个东西很奇怪，是人与人之间形成的一种非固化也非量化的交流形式，关系建立在社交之上，就是更难以衡量了。试想一下，如果追求新垣结衣有一个进度条的话，会有多少人锲而不舍呢？

错了错了，即便有了进度条，也会因为个体不同而落差极大。

关系不会有进度条，即便是在游戏中，也无法将两个背后都是现实玩家的角色关系用进度的形式展现，但是简化的进度表现还是要有的。

这里有两个思路，一个是通过系统提供的维度进行的进度表现，另一个是由玩家掌控的维度构建的进度表现。

系统提供的维度比如关系类型——师徒、夫妻、结拜，数值类型——好感度，这些维度和聊天系统的关系一般是特殊的共同标签。

玩家掌控的维度和系统本身就没有什么关系了，但是聊天系统最好有支持能力，比如下述几个例子：

模拟现实关系形式，比如姐姐、哥哥、弟弟、妹妹，这些类似现实中的家庭关系很难在游戏中提供系统级别的维度，但是很多玩家，尤其是年轻的玩家喜欢这种关系化的称呼，聊天系统可以提供备注功能帮助玩家进行设置。

特殊关系表达，比如情头、特殊聊天背景，这部分内容同样不是游戏系统级维度可以涉及到的，但是玩家在关系进度中可能对此有需求。聊天系统同样可以提供支持。

更多的例子不再列举了，其实不难发现，这部分内容也不全是聊天系统需要关注的，很多时候需要专门的系统承载，但是聊天系统需要关注其中一些细节。

小结

聊天系统有其独特的属性，玩家在这里可以基本没有限制的与其他玩家交流，这是一个非常适合社交关系萌芽和发展的场景。

但是，玩家之间的交流需要话题，聊天系统本身并不能产生话题，它可以承载话题，我们在规划聊天系统这部分结构的时候，首先要考虑话题如何能够更好的在玩家之间传播，围绕这个点来打造我们的聊天系统，就可以更好的服务于社交关系的建立与递进。

1.2特定场景下的交流

对于MMO或者SLG来说，关系构建是非常重要的部分，但是对于炉石传说、皇室战争这类竞技向游戏而言，服务向的聊天系统才是重点，这部分就是要说明如何构建这些场景的聊天系统。

场景划分

按照参与形式大类可以归纳为PVE、PVP、GVE、GVG四种场景，这四种场景中玩家的交流目的有较大区别。

• PVE场景

PVE场景由于缺少其他参与者，玩法场景中不必建立直观的沟通路径，但是可能需要和场景外的其他玩家建立联系。

• PVP场景

PVP场景拥有一位对抗者，从场景开始到结束，玩家在不同时期有着不同的表达诉求，比如开场的问候、过程中的语言对抗、最终结尾时候可能出现的嘲讽等等，这些丰富的情感表达需要一套看似复杂的系统。

• GVE场景

GVE场景没有玩家作为对抗者，但是有玩家作为合作者加入场景之中，这个时候的交流诉求更多的是交流效率的提升。

• GVG场景

GVG场景既拥有其他玩家作为合作者，也有其他玩家作为对抗者，既考验合作，也考验策略，这种情况下的交流既要考虑交流效率，又要考虑情感表达。

以上划分维度过于单一，有时候还不能指导我们的结构设计。实际上，我们可以从操作和策略上对上述场景进行拓展划分。

• 重操作轻策略的场景

这类场景玩家虽然无需进行太多思考，但是操作占用的情况下，交流很难通过文字进行，语音或许是一个更好的选择。

• 重策略轻操作的场景

这类场景玩家需要经过大量思考，如果是合作类玩法，交流是非常必要的，这种时候文字、语音都需要集成，以便最大化服务于策略交流。

• 重操作重策略的场景

这类场景玩家不仅需要大量思考，还需要将思考转化为操作，一般这类场景时间都很短，社交交流很难穿插其中，如果有需要，可以使用提前设计好的快捷用语。

• 轻操作轻策略的场景

这类场景玩家很惬意，类似于挂机一条龙，玩家会经历比较长的闲暇时间，交流形式完全可以全面allin，提供给玩家随心所欲的交流能力。当然，这个时候的聊天交流目的更趋近于关系递进而非场景服务。

通过以上的划分，可以组合出最多16种不同的场景，一般可以覆盖我们对玩法的设计，当我们完成对每个玩法的划分之后，接下来就要进行第二步，筛选每个玩法具体需要的系统能力。

筛选系统能力

这类交流中常见的可用能力在上面也略有提及，如果分类的话，大概是：

• 支持玩家输出的能力

玩家输出能力是指玩家实时输入的内容，比如文字、语音，玩家输入内容占用操作和时间较长，但是可以更为清晰的表述个体意思。适合于策略要求高，操作要求低的场景。

• 支持玩家预设的能力

玩家预设能力是指玩家在玩法外提前设置的内容，比如预设的文字、语音等，玩家预设内容不占用玩家玩法内的操作，但是可以表述的个体意思有限。适用于策略要求一般，操作要求也高的场景。

• 支持系统预设的能力

系统预设能力是指系统提供给玩家的交流内容，比如表情、文本等，系统预设能力不需要占用玩家的操作，表达个体意思也有限，但是一般形式多样，适用于策略要求高，操作要求也高的场景

不支持玩家自己预设的话，可是需要很多准备工作呢

以上能力划分也不绝对，按照玩法逻辑来选择即可，这里还有两类特殊情况要说一下。这两类特殊情况都是玩家输出能力上产生的问题。

• 嘲讽或者语言攻击

任何的嘲讽或者谩骂攻击对手都会对对方造成游戏体验的降低，这一点是毋庸置疑的，从这一点出发，有一些即便操作要求低的场景也不要完全放开自由说话，或者是对于GVG，仅开放己方队伍内聊天即可，做好范围限制。

• 交流作弊

　　对于PVP内容而言，如果提供给玩家足够多的细致交流能力，那么越能让玩家考虑作弊，玩家可以商量比赛的结果，这可能不是我们想要的！

　　Ps.从另一个角度而言，这种商量可能达成休闲竞技比赛中一种特殊的社交——“强者的微笑”，通过让一让对方，又不影响自身成绩，又让对方获取更多奖励，比如QQ飞车的冲线前停下

　　越是全面的提供交流能力，越容易产生作弊，这种时候就要考虑两者的影响了，大多数情况下，设计者不会特别看重这类作弊的影响，但是相信我，我已经经历过从全面开放聊天到只能发送固定用语的项目了，有时候这种影响非常大！

好了，当我们为每一个场景划分好具体需要的能力之后，就可以进行形式和操作上的构建了。

构建系统形式与操作

对于特殊的场景而言，常规的聊天系统形式是无法达成最优解的。

• 在皇室战争或者索尼克力量这类竖屏游戏的对局中，你很难找到一块区域展现聊天框

• 在QQ飞车的对局中，你甚至无法在右下角区域安放一个语音按钮。

紧张的对局中很难插入聊天操作

聊天系统的形式在这些游戏中简化为了一个符号，一个按钮，一个特殊的交互操作。比如：

• 对已经提前设置的快捷用语或者表情进行点选、拖动等。

• 对语音按钮进行长按、滑动等。

特定场景下的系统形式和操作是一个需要精细打磨的事情，没有所谓的最优解，需要在系统设计的时候与玩法设计者、UI/UE同学做好沟通，从用户体验的角度出发决定用哪种形式，放哪个位置展现最好。

小结

特定场景下的交流设计更考验设计能力，这些场景需要从底层结合聊天系统，才能更好的提升其本身的乐趣性。

这个过程比起为社交关系构建聊天系统更为漫长，需要来回调整，甚至为了一个表情的设计进行长时间的玩家观察。

所以这类设计上线才是开始，随着反馈持续优化。

1.3引导和反馈信息的承载

我们第一部分已经聊过，引导和反馈信息的承载也是聊天系统重要的价值之一，这部分我们将谈一下聊天系统结构上是如何设计承载这部分信息的。

设计这部分结构依然从三个步骤进行，首先挑选出承载的信息，第二个考虑对应的信息展现使用的形式，最后考虑信息展现的范围和频率等内容。

筛选承载信息

不同的系统有不同的目标，所需要进行的引导也不同，我们不单看某一个系统，而是从大类上进行区分。

• 引导信息

　　以公共维度作为引导吸引点：比如说玩法开启提示（全服竞赛将在10分钟后开始）、玩法状态提示（现在王城由XX联盟持续占领中）、奖励提示（XX迷宫刚刚出现了暗影大魔王，击败可以获得史诗级装备！）。

　　以玩家行为结果作为引导的吸引点：比如抽卡公示（某玩家在卡池中抽到SSR吃货童子）

以上两种引导的触发逻辑是有差异的，一个是系统按照固定规则触发（比如时间），一个是系统被动触发。这会影响后面要说的信息展现范围。

• 反馈信息

　　对玩家行为的反馈：点击未解锁的功能，弹出提示的同时，在聊天界面也会展现这个提示。

　　对玩家行为的记录：玩家获取任务奖励的同时，在聊天界面中也会展示这些奖励信息。

单一系统根据其设计目的不同，在引导和反馈中需要呈现的信息也不同，通过上述方式将重要系统的信息进行分类，然后进入下一步，挑选适合的表现方式。

（有一点要说明的是，无论是引导信息还是反馈信息，比起在聊天系统展示，应该有更好的方式告知玩家。聊天系统是一种特别的候补措施，用来提升信息的触达率和触达效果。）

构建展现信息的形式

通过上一步筛选了信息内容之后，再对信息展现形式进行构建。

常用的形式就是文字、图片，除此之外语音也是一种选择。

• 文字

文字展现信息是应用最为广泛的形式了，通过设定不同颜色的高亮突出要引导的重点内容，让玩家在一瞬间抓住信息关键点是该形式的重点。

这里也可以直接给予快捷跳转功能让玩家快速达到引导的目标位置（适用于功能玩法复杂多样的游戏中）。

这种形式的问题是引导信息过多的时候，玩家很难直观筛选，所以控制信息的分级展示是关键。

• 语音

语音引导或者反馈很少见，有一定成本（录制语音成本或者是接入AI语音成本等），但实际上效果还不错。

常见的语音引导比如一些端游的副本插件中的闪避BOSS技能的提示语音。语音形式是完全可以脱离于聊天系统的独立存在的，但是也可以通过聊天系统文字 语音的形式可以给予更全面的展现。

语音在一些较为特殊的场景使用很便捷（比如上述说的操作要求很大的场景），但是语音的问题也很明显，一次只能引导一条内容，使用场景有限制。

语音信息可以简化为音效形式，通过固定化某个行为的反馈音效让玩家建立意识从而简化引导，最终依然可以建立引导价值，当然，这一点不是聊天系统讨论的，我们就此打住。

• 图片

图片引导很少见，倒是携带图标的文本信息已经常见于很多游戏。图标化的部分文本可读性更强，更统一，玩家更容易快速阅读，快速理解信息。

其实这个经验图片挺特别的hiahiahia

图片形式的优势在于展现上容易抓住眼球，在很多文本信息中能够较快被人注意到，当然，这也是和图片引导较少有关系。

图片的形式有一定成本，同时有时候聊天框的图片无法使用太大尺寸，展现形式有限，如果点击放大，又会有操作成本。

综上，在游戏平台变化不大的情况下，文字依然是最基本的信息载体，语音在一些要求操作的场景可以使用，图片方案中，图标代替文字可以直接使用，但是完整的图片展现信息要根据信息量来确定（还有项目成本和人力）。

是否还有其他的载体形式？我认为是可以有的，但是是否能够在聊天系统中承载有待验证，毕竟聊天系统轻重随意，需要根据整体结构设计来考虑。

规划展现信息的位置、范围和频率

为每一个需要进行展现的引导和反馈规划形式之后，就要考虑展现的位置、范围和频率等内容了。

• 位置

一般分为内容区和非内容区。

内容区就是聊天系统的内容主框体，承载各类系统和玩家的发言信息。非内容区则是内容区以外的地方，比如主界面底部公告栏、聊天框顶部悬浮窗、主界面大喇叭区域等等。

内容区很标准，不用详细讨论，非内容区位置天马星空，从体验角度出发，不影响的情况下各个项目随意规划。但是非内容区的价值在于更加突出，而且一般非内容区不能同时展现多条信息，所以设计的时候要考虑展现位置和切换/消失规则。

非内容区的内容形式也需要提前规划好，比如支持文字 特效 表情的形式，还是纯粹一个图片形式。

QQ飞车的商城的广告位，虽然不是聊天系统，但是放到聊天框内也是一样的

• 范围

从信息面向的用户角度考虑信息应该投放的范围，比如公会战的提示信息应该在公会频道中出现，同时对于核心队伍（假设了一种公会战的元素），还需要通过私聊提示。

反馈信息一般是面向个人的，可以投放到系统频道中，但是在主界面的聊天框内，无论选择哪个聊天频道，反馈信息都应该即时插入到聊天信息流中。

对于面向大量用户的引导类信息，比如抽卡信息，从引导价值的角度是可以放到系统栏的，但是考虑到社交或者信息有效性的需求，是可以下放到更加垂直的渠道，比如公会、固定队、甚至特别关系的私聊。

对于信息展现范围，可以从综合价值（引导价值、社交价值、获取信息的有效性等）来考虑，没有固定解。

• 频率

频率影响触达率，在单一信息的情况下，肯定是频率越高触达效果越好。但是当有无数的消息开始同时触发，聊天窗体的信息复杂度上升了好几个量级。这时再高的频率可能也不会达到更好的效果。

一般范围越大的圈子，信息的频率越要控制，如果不加以控制，很容易变成一个“信息垃圾收容场”

一般越是有时间维度限制，且较为紧急的信息，频率越高，以便在时效前完成引导提示，同时由于时间短，也不会长久造成信息冗余。

对于触发型消息而言，正常是无法控制频率的，但是从系统目标来说，一定要做好展现控制，类似于抽卡展示的信息在新卡池上线的时候一定是大量产生的，无论是将其导入大范围的系统频道还是小范围的公会频道，都要控制展示。反之在长草期，可能长时间没有抽卡展示，这个时候要考虑降低展现要求。

小结

以上是引导反馈信息结构设计的部分内容，很多地方只说了设计原则，毕竟设计要根据具体的场景来讨论的，没有百搭的设计，基于上述方案对每个信息进行具体筛选、规划展现、设计范围频率等，最终形成一套完整的体系是我们的目标。

1.4 多元化内容结构设计

当我们完成前三部分的构建之后，其实聊天系统的基础构建就完成了。接下来则是一些多元化内容的结构设计。

多元化内容是指从多个不同维度出发，为聊天系统添加对应能力的设计，这里我会重点从活跃、付费两个维度进行结构说明。

留存

聊天系统本身并不适合做留存，留存应该交给更为专业的系统完成。但是聊天系统可以通过承载的信息来强化留存展示。比如：

在登陆的时候，在聊天框内展示：【已累计登陆（8/15）天，坚持登陆即将领取大奖】

这里发挥了聊天系统本身承载信息的作用，这部分前面已经聊过，不再赘述了。

活跃

聊天系统增强活跃的方式一般是两种，第一种是通过话题提升社交活跃，第二种是通过嵌入聊天系统的玩法提升玩家的参与活跃。

第一种方法一般不是由聊天系统主动发起的，而是作为信息承载平台参与其中，我们应该在其他系统玩法设计的时候考量，而第二种方式是当前较为常见的一些做法。

（嵌入聊天系统玩法的优势在于这类玩法使用聊天系统本身的交互，可以做到无需前端处理，仅需要一个后端技术非常短的时间即可完成一个包含多人互动的玩法）

拿到第一的怕不是双手没停过吧

规划这类活跃玩法的时候，还是要确定项目整体玩法节奏和需求，聊天系统本身的一些特点导致玩法设计的特殊性：

• 聊天系统交互形式比较独特（文字、语音、图片等不是固定内容的交互）
• 聊天系统有不同分区，对应玩法面向不同的用户群体。
• 聊天系统内容区域的信息流形式，导致出现的信息会较快消失。
• 聊天系统的公共流量池特性，无论是PVP、GVG内容玩法都可以承载的。

我们在这里不对玩法设计本身进行探讨，在聊天系统结构上讲，我们只需要明确玩法的目的和大致形式就可以了（PVP还是PVE还等其他等等），这样就可以筛选需要聊天系统支持的能力和分区等内容。

付费

聊天系统的付费也是由其公共流量池的属性决定的。一般分为服务内容付费和外观内容付费。

• 服务内容付费

服务内容付费包括世界频道说话次数、私聊人数、跨服说话、禁言、喇叭、气泡等等一系列内容使用权限相关的付费。

对于不在主要内容区的服务，在不影响体验的情况下，都可以作为付费点进行开发。

而对于主内容区的部分，比如世界频道说话次数，要考虑对世界频道的定位来规划具体的付费形式甚至是完全免费开放。

有一类服务内容付费比较特殊，比如聊天系统禁言，这类服务直接售卖体验较差，可以作为某些追求的奖励制造稀缺性进行投放。

（有时候我们做服务内容的付费可能仅仅是为了防范工作室，但是也会伤害到很多正常的玩家。一般的服务内容付费仅仅是满足一小部分人需求而创造的，他有自身存在的价值，但是更多时候会造成聊天系统的体验问题，如果项目整体付费能力较强，不必在这个地方设置太多的付费内容，以免引发一些问题。）

规划服务内容付费的时候，需要先拆分玩家的需求，全服公告、跨服聊天、特别提示性聊天都可以规划为不同的服务内容，然后再按照控制频次等需求设定具体付费形式。

• 外观内容付费

严格来讲，聊天系统内部承载的外观付费仅有两类，一类是和文字样式挂钩的，比如彩色字、艺术字、文本框的使用，另一种是和内容挂钩的付费表情。

文本框很可爱，头像也是！

像是头像框、特效称谓、“QQ秀”等内容，不仅可以在聊天系统内展示，还可以在场景、或者其他更多的UI界面内展示，这类内容多数有一个自身选择展示的界面，本身应该属于独立的功能，聊天系统仅仅是一个展现入口。

设计外观内容结构的时候，首先考虑承载的外部外观有哪些，常见的有头像、称谓等，展示位置、形式都是结构设计中要注意的细节。第二个就是考虑聊天内容是否需要外观化，这部分就是上面提到的文字样式、表情等。

在人力允许的情况下，开发较多的外观内容是可以获得更多的收益的，但是要注意内容的外观化可能会导致可读性变差。

• 付费形式

聊到付费就要说一下付费形式。

聊天系统的付费其实可以灵活使用多种形式，以便提升玩家的体验，较为多样的外观付费内容可以拆分为免费、试用、直接付费或者间接付费（考验战力或者时长的外观获取）等等。服务内容的付费可以采用试用、直接付费或者间接付费

付费形式不属于聊天系统结构设计部分，不重点说明了。

小结

聊天系统的多元化设计乍看起来似乎脱离了其核心价值，但是仔细考虑一下，以上说的几种活跃和付费形式最终都会对社交产生正向影响。

从本质来讲，聊天系统就是一个巨大的流量池，在这个基础上如何多元化运作，产生更大的收益，是我们设计者需要仔细考虑的事情。

聊天系统功能逻辑

仅供参考

上图是常见的一个聊天系统的功能，可能不全，但是大部分聊天系统内涉及的功能都标注了出来，仅供参考。

下面对部分功能做一下简单说明，因为大部分功能理解应该不难，所以不在赘述。

• 交互-文字输入

游戏毕竟不是纯粹的聊天工具，一些文字的设置需要仔细考虑，可能会带来其他影响，比如文字大小我们一般不提供设置，这样可以保证聊天系统内容整体可读性更好。

文字颜色设置也同上，但是颜色影响要小于体型影响，在进行一些限制之后（比如付费），可以提供玩家使用这种形式。

另外，如果是私聊，理论上无论是大小和颜色的设置都可以提供给玩家，但实际项目中，我们都会统一成一套规则，毕竟这部分玩家需求还是相对较少的。

有些游戏会将文字颜色、特殊字体、字号打包成一种设置来出售。

• 交互-语音输入

语音输入中有一个功能，就是语音转化为文字，这种功能一般需要接入第三方服务处理，也不算是常用功能，所以一般规划中不太常见。

• 交互-表情输入

表情输入有两种，需要明确区分，一种是小图表情，可以跟随在文字后面，另一种是大图表情，选择后直接就发送，不会在输入框出现。

此外，小图表情选择后有两种处理方式，一种是直接以图片的形式出现在聊天输入框内，另一种则是以标识的形式出现在聊天框内，这两种方式各有优劣，大家自行选择吧。

• 交互-输入限制

灵活使用付费作为限制工作室或者广告的手段，虽然有时候会伤害部分玩家的体验，但是找准玩家的需求，可以尽量减少这种伤害。

现在有第三方公司专门处理聊天区域广告识别问题，宣传的效果不错，但是实际上工作室也在利用各种规则可能制造新的麻烦，还需观望。

• 交互-附加功能

快捷文本选择和历史消息重复发送对服务型社交都非常有用，建议开发。

插入游戏内容模块是重要的话题开启器，可以将玩家较为独特的内容（培养内容、收集内容等）嵌入其中。

• 交互-其他位置交互

在聊天系统之外，如何能让玩家想起聊天系统，合理的提示是非常必要的。尤其是在没有重度操作和策略的局内，能够提示开启聊天系统可以提升整体活跃。

私聊是最为重要的社交模块，在部分MMO中，快速开启私聊可以有效提升社交链接，所以在规划这部分提示的时候，尽量在玩家常接触的界面，方便点击的位置规划。

• 交互-异形交互

在重度操作和策略的局内，如何更快的发送文本就成了需要处理的问题。

结尾

距离上一章探讨聊天系统的价值已经过去了快一个月，第二章才堪堪准备好，能够抽时间把一些过去的经验总结一下总算是在创造一点点价值。

本篇主要聊了聊天系统的结构设计和功能逻辑，内容或许并未覆盖全面，有些结构上也没有特别展开去聊，这已经是控制了字数的结果，但是鉴于过去的经验，或许没有多少人能看完吧~

就这样！