前言

游戏服务端开发是一个非常神秘的软件开发工种，作为游戏开发的两大子类之一，其关注度远低于游戏客户端开发。常见的游戏开发书籍《游戏引擎架构》、《游戏编程精粹》等基本都是介绍客户端相关的渲染、物理、动画等内容。Bilibili上的知名游戏开发经验分享账号Games Webinar上传的五百多个视频里关于游戏服务端的一只手都数的过来，都集中在Games 104里。相对于汗牛充栋的游戏客户端开发书籍，关于游戏服务端开发的书籍可谓屈指可数，比较知名的只有《网络多人游戏架构与编程》。这些游戏服务端开发相关书籍大多在花一半以上篇幅来介绍网络相关的内容：如何使用基础socket来做网络通信，如何降低延迟，服务器与客户端之间的互联拓扑。由于这些内容与常规的互联网服务端开发重合度太高，同时又缺少类似于分布式一致性这类高端内容的介绍，给了读者一种游戏服务端开发没啥技术含量的错觉，以至于知乎上有这么几个提问:互联网服务端技术领先游戏服务端几十年？; 游戏服务端技术/人员整体水平是不是已经落后于互联网服务端?。

正所谓"指法无优劣，功力有高下"，游戏服务端与互联网服务端两者要处理的业务有着很大的差异，无法直接对比技术栈。在上面的知乎问题的回答里，很多人都提到了这两者最大的差别：互联网服务是短连接、无状态、高延迟的，而游戏服务是长连接、有状态、低延迟的。但是这种过于干练的概括对于理解游戏服务端并没有很大的帮助。刚好那段时期本人用Python做了太多的游戏节日活动，有点烦躁，想通过自己从零搭建一些游戏服务端通用的组件来更好的理解隐藏在脚本接口之下的游戏服务端的核心业务。在看到这个知乎问题之后，萌生出了一个大胆的想法：用cpp做一个Demo性质的游戏服务端引擎mosaic_game来复刻当前使用的自研闭源游戏服务端引擎的核心功能，同时将这个引擎的功能设计与实现归纳整理为一本完整的书籍，为那些对游戏服务端有兴趣的开发人员提供一份比较系统且充满细节的参考资料。希望通过本书的介绍，能够让大家对游戏服务端开发有一个更全面的认识，了解其功能集合与职责所在。

随着后续工作的变动，逐渐开始接触到其他的商用游戏服务端引擎，最知名的就是BigWorld和Unreal Engine。我所在的大世界服务端组的业务重心就是将BigWorld核心的无缝大世界功能移植到Unreal Engine上，以提升Unreal Engine的单场景玩家承载能力。在做这个无缝大世界功能移植的过程中需要反复的去查阅这两个引擎的源代码，再加上我自己闭门造车的mosaic_game，发现虽然这三个游戏服务端引擎面对的问题相似，但是对应的解法却各有不同。同一个问题三种解法，着实有趣。

兴致起来了之后，我便修改了原有的开发计划，给mosaic_game增加了无缝大世界的支持。同时本书的内容也进行了大量的扩充，同一个业务主题会多个章节来分别介绍这三个引擎的解决方案，大致覆盖了下述内容：

• 通信管理，包括客户端与服务器之间，服务器与服务器之间的通信
• 会话管理，包括账号创建、登录、顶号、下线、断线重连等
• 数据持久化，包括玩家数据、场景数据、社交数据等
• 客户端请求响应，包括移动、聊天、社交、战斗、场景切换等
• 玩法流程控制，包括副本流程、怪物AI等
• 实体状态同步，包括实体的位置同步、属性同步等，
• 分布式场景管理，包括分布式场景的动态扩缩容、无缝迁移等

在介绍这这些内容的时候，我都会附加这些内容的核心代码来方便读者去了解这些内容的实现细节。在章节膨胀和代码填充这两个因素的影响下，本书的篇幅也从原来的600页不到扩充到了现在的1500页。太多的代码贴在书中，会导致书籍的可读性下降。如果读者不想深究实现细节的话可以对这些代码进行跳过，对于不感兴趣的章节也可以跳过。

由于本人经验和精力有限，上述内容之外的一些游戏服务端的非常重要的业务并没有在本书中展开介绍，例如技能与战斗系统、脚本系统、日志收集系统、性能监控系统、运维部署系统、热更新系统、容灾系统等，欢迎对这些内容有深刻理解的游戏服务端开发人员来对本书进行补充。