论架构 on 设计虚拟世界

总体架构

Mon, 01 Jan 0001 00:00:00 +0000

实际的架构因开发者而异，但它们几乎都可以看成同一种通用做法的变体，这种做法的着眼点是可靠性、可扩展性与可维护性。图 2.1 展示了这种总体架构。

图 2.1 总体架构

下面说说它是怎么运作的。

服务器架构

Mon, 01 Jan 0001 00:00:00 +0000

服务器集群承载着虚拟世界的各个实例。集群之间可能存在由程序设定的差异（例如，在某个集群里可以攻击其他玩家，在另一个集群里则不行），但这些差异在形式上通常很小，效果上则未必。一个集群里有多少台服务器，因实现而异，但通常也就六台上下。集群的数量同样不等：一款产品越受欢迎，增设的集群就越多（《无尽的任务》——EverQuest——在 2000 年达到 40 个服务器集群，高峰时段平均每个集群同时在线约 1,500 名玩家）。

负载均衡

Mon, 01 Jan 0001 00:00:00 +0000

幸运的是，负载均衡这门学问虽然玄奥，却并不是设计师需要直接操心的事。不过，技术专家最终采用什么方案、会带来什么后果，设计师还是得心里有数——尤其是因为碰上这件事，多半会有人来征询他们的意见。

别的事情也会发生

Mon, 01 Jan 0001 00:00:00 +0000

虽然支撑虚拟世界的硬件上，负载主要来自玩家，但玩家并不是唯一的来源。不管有没有玩家在场，都会有事情发生。这些事里有些是机械式的：虚拟世界的太阳照常升起、落下，天气照常来去，全都不管周围有没有玩家。对于一个细节极其丰富的世界来说，这些加起来可能意味着相当可观的工作量（一阵微风吹动树上的一片片叶子，其中一片飘落下来，掉进小溪，溪水懒洋洋地把它送进河流，再由河流送进大海）。不过，眼下要做出这么复杂的虚拟世界，还差得远呢。

客户端／服务器模型

Mon, 01 Jan 0001 00:00:00 +0000

服务器体现着虚拟世界，客户端则把它转换成玩家能够理解的形式。由于客户端是玩家瞭望虚拟世界的窗口，设计者对客户端的外观与感觉有很多话要说。不过，这些多半属于品味与惯例的问题，因此这里不予讨论。显然，如果你提出的施法系统复杂到无法用鼠标和键盘来实现，那确实会造成差别 ¹，可要是这种事还需要别人告诉你，那你根本就不该当设计者。

同步

Mon, 01 Jan 0001 00:00:00 +0000

信息在客户端和服务器之间传递需要时间。服务器执行命令也需要时间。在这段时间里，客户端得一直把虚拟世界显示下去。因此，屏幕上显示的东西未必是服务器所认定的当前世界状态的真实呈现：两者并没有同步。在真实世界里，太阳也许在 19 秒前就毫无缘由地爆炸了，而你还要再过八分钟才会知道。在虚拟世界里，你朝某人射出一箭，而对方可能四秒前就已经退出了。

安全

Mon, 01 Jan 0001 00:00:00 +0000

你的客户端软件一定会被人破解。对某些虚拟世界来说（比如那些完全没有游戏成分的），这未必有什么关系。对其余的虚拟世界，关系可就大了。

至少，这意味着客户端发给服务器的每一个数据包，都必须检查一遍，看它是否讲得通。硬件层与传输层的纠错机制本应保证，到达服务器的内容就是客户端发出去的内容——那又何必浪费时间，去检查根本不会出现的胡话？可事实是：正在跟服务器说话的，未必是一个货真价实的客户端。它可能只是在跟一段代码说话——那是某个玩家自己写的，用来冒充客户端，或者往客户端的数据包里插数据。要是服务器收到了讲不通的数据，却没有办法处理，那会怎么样？是不是已经有人学会了让服务器崩溃的本事？