游戏服务器设计之NPC系统

简介

NPC系统是游戏中非常重要的系统，设计的好坏很大程度上影响游戏的体验。NPC在游戏中有如下作用：

1. 引导玩家体验游戏内容，一般游戏内有很多主线、支线任务，而任务的介绍、接取、领取奖励等操作都是通过NPC的操作，一般会有几个核心NPC，再不停的任务引导中，玩家会对核心npc印象深刻，强化了游戏代入感。
2. 核心功能的展示和操作。游戏大部分功能都会放到游戏主界面，但是全部功能都放进去是不现实的，其他功能则以NPC的方式提供，比如进入某副本的入口等。
3. 一些运营活动，比如道具秒杀，打折促销等，过年过节也可以制作一些应景的NPC形象。

NPC的设计

NPC跟角色怪物等相似是一个实体，所谓实体指的是必须有唯一ID，可通过ID索引到且可以在地图动态添加，本文实现的NPC的ID由配置文件指定，其他基本属性如名字、地图坐标、外形、朝向等都可配置。

当与NPC对话时一般都是显示文字和一些引导操作的按钮。这些都是需要可配置。另外NPC的文字除了静态描述文字，还需要一些动态数据，比如显示玩家活动分数，排名次序等。如何定义服务器和客户端的协议才能满足上述要求呢？首先必须是文字协议并且可扩展，这样才对配置友好，Json是一种，但是json够紧凑但是对配置不是很友好尤其是对文字描述这种。xml相比更好一点，扩展性强，可读性也好，在文字长度不大的情况下效率也可以接受。本人推荐用xml的格式NPC的显示协议。NPC至少有两个元素文字和按钮，怎么用xml来表示呢？我首先想到了html。常规文字显示就参考html的格式，特殊的ui组件，扩展一下xml就可以了，这种情况甚至不需要重启服务器。为了客户端解析方便，我们只需要使用html的子集即可，比如：

过年好!<br/>
<font color="red">狗年大吉!</font> <a href="showPage">旺旺旺</a>
<br/>
<button type="button" onclick="showPage">OK</button>

使用html格式的配置有如下好处:

1. html大家都比较熟悉，无论是服务器客户端都对html有一定了解，甚至策划也不陌生，接受起来非常容易。
2. html编写虽说需要一定的程序能力，但是这种在线编辑器一抓一大把，所见即所得的配置方式非常方便配置人员。
   比如使用http://www.w3school.com.cn/tiy/t.asp?f=html_basic 这个在线html编辑工具可以所见即所得的编辑文字内容。结果示例如下：
   
   使用这种格式的好处是，策划事先可以在在线编辑器上编辑好npc相关的文字，颜色、排版等都处理好，一些显示错误可以一开始就发现。

关于超链接和按钮

上图显示了一个有超链和按钮的npc面板，那么点击了超链和按钮后程序如何处理呢？这时正时脚本排上用场的地方了。一个超链或按钮对应一个脚本的函数，而整个脚本正好是对应了脚本的全部功能。另外超链是可以传参数的，那么参数会被带到脚本函数中，如下例所示：
查看成绩

def showScore(player, npcid, param):
    sortCondition = param['sort']
    #do something
    return

第一次点击npc因为没有指定超链，那么默认调用脚本的main函数。时序图如下：

def main(player, npcid):
    msg = '''
过年好!<br/>
<font color="red">狗年大吉!</font> <a href="showPage">旺旺旺</a>
<br/>
<button type="button" onclick="showPage">OK</button>
'''
    return msg

关于安全性

思考下如果有外挂没有点击main直接发消息点击showScore会怎么样？正常情况下角色必须点击当前看到的页面包含的超链，否则会出现安全性问题，必须加以限制。npc系统每次发送npc面板内容给客户端时，都会记录下当前的npc面板内容，当玩家点击超链，首先验证一下是否是本次面板内的超链，否则拒绝，安全性大大提高。时序图如下：

总结

1. xml作为npc显示协议具有非常强的扩展性，比如显示文字，控制文字大小，显示图标等都可以通过扩展xml标记实现。
2. xml与脚本结合实现npc的功能，会大大利用脚本的已修改、热更新的优势，一些运营活动不停机上线这是最基本的要求了，如果有bug，可以下发正确的脚本覆盖后重新载入脚本即可。
3. 这种格式易理解，好配置，对于策划这种弱程序的也是可以接受，当然基于html做个配置工具也是非常的容易。
4. 实现显示协议后，npc的外放、删除，外形配置、文字配置等，都是策划可以搞定的，这也是团队都希望的。
5. 再考虑到扩展性前提下，保证了npc的安全性，有的时候写代码的人经常会写这样的代码，如判断一个人可以领奖，然后显示可以领按钮，点击了领取按钮的对应函数有可能忘了判断有效性，在这种npc的方式下，就不太会出现重复领奖的bug，因为每次领奖，都会npc提示领奖成功，然后把player上的当前npc文字冲掉，这样假如外挂再发领奖请求会被npc系统自动拦调，大大提高系统安全性。
6. npc的点击频率限制，npc距离限制，这写基本的安全性逻辑也要有，这个不在赘述，详情看github代码。
7. GitHub地址: https://github.com/fanchy/h2engine
8. 关于属性管理器：http://www.cnblogs.com/zhiranok/p/h2engine_propmgr.html
9. 关于游戏服务器引擎h2engine：http://www.cnblogs.com/zhiranok/p/ffengine.html

原文地址：https://www.cnblogs.com/zhiranok/p/npc.html