站务联系
游戏服务端所完成的事情（一）从定义问题开始，简单直接地说，一套游戏服务端开发框架应当具备下边两种能力：?定义了 client 到 server、server 到 client、server 到 server 的消息 pipeline。?描述了游戏世界状态的维护模式。1 消息 pipeline1.1 经典消息 pipeline1.1.1 场景同步当讨论至游戏服务端的时侯，我们首先想起的会是何种？要回答这个问题，我们还要从游戏服务 端的需求起源说起。定义问题游戏对服务端的需求起源应当有两个：?第一种是单机游戏联网版，实现为主飞机方式的话，主机部份可以看做服务端。?第二种是所有 mmo 的雏型 mud，跟 webserver 比较类似，一个 host 服务多 clients，表 现为 cs 架构。第一种需求长盛不衰，一方面是 console 游戏非常适宜这一套，另一方面是近期几年手游上去 了，碎片化的 PVE 玩法+开房间式同步 PVP 玩法也得到验证，毕竟 MMO 手游再怎样火也不或许改 变手游时间碎片化的事实的，最近的皇家冲突也证明，手游不会再重走端游老路了。第二种需求就不用说了，网上大把实例可以参考。
最典型的是假定有这么一块野地，上面这些 玩家跟怪，逻辑都在服务端驱动，好了，这类需求没其他额外的描述了。但是，解决方案其实是不断发展的，即使速率太慢。说不断发展是特指针对第一种需求的解决方案，发展成因就是国情，外挂很多。像 war3 这种都 还是正宗的主飞机，但是之后对战平台出现、发展，逐渐过渡成了 cs 架构。真正的主机 其实是建在 服务器的，这样虽然服务器那边也维护了书房状态。后来的一系列 ARPG 端游也都是这个趋势，服 务端越来越重，逐渐显得与第二种方式没哪些差别。 同理如现今的各类 ARPG 手游。说发展速率太慢特指针对第二种需求的解决方案，慢的成因也比较有意思，那就是 wow 成了不 可僭越的鸿沟。bigworld 在 wow 用之前名不见经传，wow 用了后来国外厂家也跟进。发展了如此 多年，现在的无缝世界服务端和曾经的无缝世界服务端并无二致。发展慢的诱因就观察来说或许需求 本身就不是非常明晰，MMO 核心用户是重社交的，无缝世界核心用户是重感受的。前者跑去玩了天 龙八部跟倩女不干了，说这俩既轻松又女孩多；后者玩了 console 游戏也不干了，搞了半天 MMO 无 缝世界是使我更好地刷刷刷的。
所以仔细想想，这么多年了，能数得上的无缝世界游戏不仅天下就是 剑网，收入和重社交的那几款完全不在一个量级。两种需求起源，最终虽然导向了同一种业务需求。传统 MMO 架构（就是之前说的天龙、倩女类 架构），一个进程维护多个场景，每个场景里多个玩家，额外的中心进程负责帮玩家从一个场景/进 程切至另一个场景/进程。bigworld 架构，如果剥离开其紧扣切进程所做的一些外围设施，核心工作 流程基本能够用这一段话描述。抽象一下问题，那我们提到游戏服务端首先想起的就应当是多玩家对同一场景的 view 同步，也 就是场景服务。本节不会讨论帧同步或是状态同步这些比较下层的问题，我们将重点置于数据流上。如何实现场景同步？首先，我们看手边工具，socket。之所以不提 TCP 或 UDP 是因为要不要用 UDP 自己实现一套 TCP 是另一个待撕话题， 这篇文章 不做讨论。因此，我们假定，后续的实现是构建在对底层合同一无所知的前提之上的，这样设计的时 候只要适配各类合同，到时候能够按需切换。socket 大家都太熟悉，优点就是各操作系统上具象统一。因此，之前的问题可以规约为：如何用 socket 实现场景同步？拓扑结构是那样的 （之后的所有图片连结箭头的意思表示箭头对准的对于箭头起源的来说是静态 的）：场景同步有两个需求：?low latency?rich interaction要做到后者，最理想的状况就是由游戏程序员把控消息流的整套 pipeline，换句话说，就是不借 助第三方的消息库/连接库。
