了不起的灵感和它的诅咒
那么，这个庞大的宣传反差，是为何诞生的呢?为什么无人深空会如此笃定他们能做出一个超级庞大，而且支持多人联机的宇宙来(虽然他们最后并没有做出来)?要知道，他们可只有那么小的一支团队(2016年的现在是15个人)，按照游戏开发的常理来说，这简直是睁着眼睛乱吹牛皮了!15个人?做个单机手游还差不多，你们要做3A太空沙盒?是来骗经费的吧?!
要解答这个问题，我要从无人深空所使用的程序算法开始解释。从某种意义上来说，无人深空这个项目，是整个游戏行业中极为罕见的“程序员和算法主导”的游戏项目。绝大多数的游戏，要不是游戏设计师主导，要不是美术总监主导，甚至很多时候是市场总监、财务总监甚至融资总监主导，但极少有被程序技术算法主导的例子——偏偏无人深空就是那极为罕见的一个。这也是他们敢以15个人的超袖珍团队，向所有玩家和发行商索尼描述游戏愿景的底气;而最终，这也导致他们没能完成这个架空的愿景，是游戏上市后玩家舆论给他们致命一击的根本原因。
18,446,744,073,709,551,616这个数字是什么呢?对于学计算机的各位肯定非常熟悉——它是2的64次方，和256、65,536、4,294,697,296一样都是计算机系的大家应当很熟悉的数字，代表着一个64位的2进制数。看到这个数字，你就能猜出来，他们用了一个“长整形变量”作为生成随机星球的种子。
这意味着，在无人深空中，他们使用了程序化生成算法(Procedural Content Generation，一般简称PCG)来构成这个随机宇宙。你能够在很多地方见到对PCG原理的简述，甚至还有人专门写了一篇介绍无人深空中随机宇宙生成算法的文章，所以我在这里不再赘述这些程序化生成是怎么实现的。
当然，实际上的生成算法会非常复杂，经过很多很多步的生成，绝非我或者科普文章说的“使用一个随机生成的长整形数来随机生成星球上的数据”这么简单。你可以想象，相对于一般游戏使用的复杂的数值表，无人深空有一张复杂的生成规则表：星球的名字如何生成、生物如何生成、地形如何生成、资源如何摆放、宇宙太空站如何生成、NPC种族如何生成、飞船如何生成、蓝图和语言如何生成……
而在这里面，有些问题会比其他问题更加复杂。如何生成合理的地貌?如何生成看起来合法的生态环境?每个星球上都需要生成资源和值得玩家去探索的特殊地点，这些又怎么通过一个64位的随机数种子去进一步生成?在这些内容上，团队必须要投入比简简单单地说“程序化生成”这三个单词多得多的工作量。在最终的游戏零售版本中，他们实现了完整的基本游戏逻辑——但也只有基本的游戏逻辑而已。对于4年的开发时间来说，这个答卷完全无法令玩家满意。
我想，那可能是因为他们浪费了很多时间，用来追寻另外一个最终失败的目标。很多关于无人深空的文章都说了程序化生成，但这个游戏并不仅仅是程序化生成。在这个游戏里面，还容纳了一个极为罕见的灵感，也正是这个灵感，将它原本的愿景和野心暴露在了我们的面前。
因为在这里还有另外一个非常重要的设计要点：虽然这个宇宙里，有2的64次方个不同的星球，但所有人看到的宇宙都是一样的。虽然游戏没有联机功能，但玩家们确实能够看到别人上传和命名的星球，在庞大的宇宙中找到其他玩家的踪影，看到别人所命名的生物——这证明大家所看到的宇宙，并不纯粹是用那个随机数生成的本地数据，而确确实实存在于所有人的电脑之中。
但从传统网络游戏的实现方法来说，这个“所有人都能看到的宇宙”原本是不可能存在的!只要做一个简单的算术，大家就能明白这一点了：假定一个星球的随机生成，真的只需要一个长整型变量，也就是一个64位的2进制数(64bit)。存储这个星球的随机生成种子，就需要64位2进制数，也就是8个字节(一个字节是8bit)。我们平时说的1MB有多大呢?有1,048,576字节，能存储131,072个这样的星球(约13万个)。1GB有多大呢?有1024MB，也就是说，能存储134,217,728个这样的星球(约1.3亿个)。1TB有多大呢?这个已经是大家一整块硬盘的单位，有1024GB，也只能存储137,438,953,472(约1374亿个)这样的星球。我们再用上服务器等级的硬盘，1PB=1024TB!这样的硬盘能储存多少个星球呢?140,737,488,355,328个，也就是140万亿个星球的数据。没错，即便我们动用了1PB这样惊人的服务器级别硬盘，也还没能存下这个宇宙每个星球的生成种子——遑论玩家们给这些星球和星球上的地点、生物们起的名字了。
那么，无人深空这个多层宇宙宇宙里，到底有多少个这样的星球需要储存呢?答案是1800亿亿个。我们换算成PB的话，是131,072PB——13.1万PB的服务器，当然远远超过一个游戏公司所能负担的上限。
所以，他们不可能使用这么愚蠢的“传统网络游戏”的做法。他们需要另外一种办法来存储这个“所有玩家共存的单一宇宙”。
这就是无人深空这个游戏大愿景的另外一半：用“伪随机数”的算法来同步所有人的宇宙。这是之前所有程序化生成游戏，从矮人要塞到孢子，都没有想到的事情。那些使用种子生成地图对战的游戏们想到了，但是他们从未想过要把这个算法扩大到一个真正的“大服务器游戏”上——这确确实实是一个非常疯狂，但也相当天才的想法。
我先来解释一下伪随机数的算法。对于学过计算机的人，计算机不能生成真正的随机数，只能生成伪随机数。通过一个算法，生成一个看起来没什么规律的大数字，然后再通过算法在这个大数字里面截取一段，之后再进行近似操作，对我们人类来说，看起来就好像是随机数了。
比如说最常用的伪随机数生成算法，叫做“线性同余法”：Xi = (Xi-1 * A + C ) mod M，通过取大数字的余数来快速生成伪随机数。懂数学或者算法的读者应该一看就懂，而各位不懂算法的大家不必深究，知道这是一个用于递归生成特定随机数的算法就可以了。
但是，伪随机数不是真正的随机数。如果你玩过那些廉价计算器，就会知道这一点：在这些计算器的伪随机数生成模块中，有极其明显的规律存在。比如你使用线性同余法，只要给定了计算的次数和函数的初始值，这个随机数序列的每一项都是固定的;当这个同余数字特别小的时候，甚至还会产生有规律的循环和特定数字。所以会有一些安全指南，告诉程序员的大家一定不要允许其他心怀恶意的用户在你的系统里连续取随机数，或者干脆就不要用语言提供的默认随机数算法(很多主流语言默认都使用线性同余法);在已知使用线性同余法的情况下，他们甚至能够通过连续取到一定数量的随机数反推到种子。所以，通常来说，我们看到这种默认通过一个函数来生成的算法都会觉得算法的随机性很差;一些从众所周知的函数(比如pi的通项公式)里面取值的算法就更糟糕，只要知道算法，种子瞬间就可以被破解。
实际上，我们在现实生活中，也大量使用和这个“伪随机数”原理类似的验证算法——最著名的验证算法就是被我们用于加密和验证的“大质数因数分解”(著名的RSA算法)。我们大量使用的“CRC校验算法”其实也是个类似的应用：只要给定输入和算法，任何一台计算机，一定都能算出相同的结果;反过来说，只要算出了相同的结果，我们就能够知道他们使用了相同的固定算法。
但是，在游戏领域，之前几乎没有人思考过如何反向使用“伪随机数”这类算法。随机性越高就越好的思维定势很难避开，所以几乎没有人考虑过能不能反过来利用大随机数序列的“伪”性来构造复杂的设计用途。
反向是什么样的呢?让我们想想看“给定一个算法和种子值，任意一台计算机都能生成特定的随机数”的反面……
没错，这个反向思维是“如果我想要一个所有人都能获得的特定值，那么给他们一个算法和种子值就可以了”!
我们不再需要这个至少13.1万PB的服务器用来存储宇宙了：只要在每台机器上存储这个“通过特定种子数值生成宇宙、行星及星球上一切的算法”，再给几个玩家一个相同的种子值，他们就会处在一个同样的行星系和同样的星球上。理论上来说，只要把玩家的数据再单独拆开，我们就能造出一个庞大的随机宇宙，让无数的玩家在里面同时游戏，还不用准备庞大的服务器和进行预先设计!
如果这个反向思维成真，只需要给每个玩家在服务器端储存一套用户数据，理论上我们就不需要去做单独的场景地图了。我相信，这个“可以同步的算法”本身，才是无人深空这个项目最开始的野心和愿景。不需要给大家预先准备副本和区域设计，只要所有人和服务器都使用同样的伪随机生成函数和算法，就能按需生成一个庞大的可以同时容纳很多玩家的宇宙。
从这点来看，在最初的设计方案中，这个宇宙一定、一定、一定是有多人游戏的。只有非常想做多人游戏的程序员和设计师，才会想出这种充满炫技色彩的实现方法，来解决这个大宇宙沙盘中的对战问题。而这个项目的总监、程序员、设计师……所有人，甚至包括索尼方面了解这个项目的宣传负责人，他们也应当是知道这个愿景的，所以才会印出那些包含多人游戏的包装盒来。所以，他们的项目制作人才会在各种场合，口无遮拦地畅想着以后“多人模式”实现后的景象。
然而，最后他们没做出来，索尼只能临时把包装盒上的“多人游戏”用贴纸给贴上。
要具体将这个野心变成具体的游戏设计，非常非常困难，一路上有非常非常多的细节问题要处理。某种意义上来说，他们所遇到的问题，有点像旗舰曾经讨论过的VR游戏设计：我们有一个听起来非常非常棒的点子，但是执行起来却发现这个点子的各个角落，都充满着我们之前完全没有想到的问题，每个问题都足够毁掉你之前的所有努力。
这些问题里，有些看起来可能是无法解决的;还有一些则是因为开发团队的无力和设计选择被迫放弃了;甚至还有一些是因为开发团队的不重视和漠视。所以，我们最终没能看到视频和宣传里说的那个游戏;就算用最宽松的标准评估，最后实现的这个游戏，也只达到了宣传和视频里那个游戏的30%。
微信扫描，关注游侠网
阿凡达潘多拉边境
博德之门3
心灵杀手2
星空
