开发
开发
设计只是创建虚拟世界的一部分工作。设计者喜欢认为它是最重要的那部分，可它真的是吗？
设计者有天马行空的想象力。
程序员干的是构建虚拟世界的实打实的活。
美术才是给它赋予形式的魔术师。
音响工程师营造情绪与情感。
运维人员是维持它运转的工程师。
制作人提供资源。
任何人都能有天马行空的想象力。只有具备专业技能的人才能编程，才能作画，才能作曲，才能运维网络，才能管理项目。那设计者凭什么这么重要？
因为，设计者一旦搞砸，对虚拟世界造成的后果可能是毁灭性的。
一段跑不起来的代码也许很难定位，但一旦找出来，通常很容易改正。一张看着古怪却至关重要的贴图也许得费尽心思重画，但那终究只是一张位图。然而，设计者要是做出一个看似很小的误判，其影响可能极其广泛，甚至让一个世界瘫痪数周。
如果这话让你难以相信，那就设想这样一个虚拟世界：里面的非玩家店主按固定价格出售货物。这个虚拟经济要是发生通货膨胀，会怎样？用不了多久，你花仨瓜俩枣就能买到任何想要的东西。那要是出现通货紧缩呢？再琐碎的物品也贵到只有极有钱的人才买得起。哪些因素会影响通货膨胀／紧缩？噢，几乎所有的因素都会——它们以可怕的方式互相纠缠，全由设计者的操作决定。
崩坏的经济可不好看。曾有一段时间，《阿瑟龙的召唤》（Asheron’s Call，AC）的游戏货币变得一文不值，玩家之间想要交换货物只能以物易物。这种状况持续了好几个月才终于被控制住；这场灾难让 AC 付出了沉重代价。
所以，这就是为什么设计是创建虚拟世界时最重要的事情——它的失败代价最高。
团队
在制造虚拟世界这台机器上，设计也许就是最重要的那个齿轮，但这并不是说其他部件就不重要。有些部件绝对关键：比如服务器一旦崩溃，它每停摆一分钟，代价就是一批账号被注销。设计者必须了解这些事，才能在自己设计虚拟世界时把它们考虑进去。
设计者不仅应当对自己在这个系统中的位置有符合实际的认识，还应当扎实了解创建过程中其他参与者各自承担的角色。作曲家不必会演奏乐团里的每一件乐器，但必须知道所有乐器听起来是什么声音；不能指望设计者懂得程序员或美术是怎么做出成果的，但他们必须清楚存在哪些局限。如果你想让自己的虚拟宫殿每一面墙上都有一幅令人惊艳的原创壁画，那你还是趁早打消这个念头吧。
创建一个虚拟世界，就是在创造一款软件。当然，它不只是软件——它还是一个社区、一项服务、一个场所——但如果没有引擎来跑这个世界，这些都算不上什么。
一家典型的软件工程公司，是按职能分工组织起来的，涵盖以下几个方面：
公司领导层
销售与市场
财务与会计
软件开发、客户支持与质量保证（QA）
运维与信息技术（IT）
人力资源（HR）
其中有些职能可能会拆成独立的部门，比如销售部门可能和市场部门分开；不过总的来说，上面这份清单没什么争议。注意，通常并没有哪个专门的小组只负责产品规格；这项任务落在采购软件的那一方头上，而在很多情况下，那一方很可能就是客户。
一家典型的电脑游戏开发公司，组织方式大体相同，但有以下几点游戏行业特有的差异：
增设美术与动画部门。
增设音频部门（音乐、音效）——除非外包。
质量保证部门扩大，并与实际的软件开发正式分开。
增设一个设计组（通常很小）；其成员薪水比其他同事少，从粉丝那里得到的赞誉却比其他同事多。
大型多人在线图形化虚拟世界的开发者，沿用游戏开发模式，只是有以下不同：
设计组扩大。
运维组（负责维护并支持系统所运行的硬件）扩大。
客户支持组（处理虚拟世界内外与玩家相关的事务）大幅扩大，并与实际的软件开发正式分开。它通常还会把质量保证部门重新吸收进来。
公司领导层、人力资源、信息技术和财务／会计人员，只是偶尔才会来打扰设计者。设计者与销售／市场之间会进行一场对话，双方可能势均力敌，也可能一边倒（一边是“我们想让你设计的，是这种世界”，另一边是“我们想让你卖出去的，是这种世界” 1）。
设计者会告诉运维、美术和音频专家需要做什么，但一般之后就放手让他们去做。设计者打交道最多的是：
程序员（因为设计者从来都说不清自己想要什么——除非他们热情得过了头，试图教程序员该怎么编程 2）。
质量保证人员（因为测试人员发现的设计缺陷，比他们发现的编程 bug 和运维问题还多）。
客户支持人员（因为玩家发现的设计缺陷，比质量保证人员发现的还多）。
彼此（因为尽管本书一再提到虚拟世界的“设计者”，但通常存在的是一个设计团队，由一名主设计师带领）。
当一个新的虚拟世界开始动工时，就会组建一个核心团队。对小型世界来说，这个核心团队可能只有一个人，身兼数职；事实上，它可能永远就这么大。但对大型世界来说，它只是核心，围绕它才会形成一支完整的开发力量。核心团队包括：
制作人
主设计师
主程序员（服务端、客户端）
主美术（环境、居民／角色）
主程序员可能有两位，因为客户端编程最好由有电脑游戏开发背景的人来做，服务端编程最好由有软件工程背景的人来做。编程正日益成为一门分工越来越细的行当，在一个领域里很在行的程序员，换到另一个领域工作可能就需要培训。
主美术可能有两位，因为一个图形化虚拟世界涉及的美术工作量实在太大了（尽管开发刚起步时不会如此）。严格来说，“环境美术”（environment artist）负责概念美术（concept art）——也就是决定这个虚拟世界长什么样。“角色美术”（characters artist）负责技术层面——与程序员对接。由于所谓的技术层面通常最终落在动画问题上，角色美术到头来实际负责的就是角色。
运维和客户支持负责人正越来越多地被拉进核心团队，但由于他们的工作要等到开发进行了一段时间之后才能开始，所以初创公司里出现这种情况并不多见。
开发流程
虚拟世界的开发涉及许多步骤。对于玩家较少、功能也有所不同的较小世界，其中有些步骤可以跳过，也可以与其他步骤同时进行。不过，为了把流程的每一个方面都交代清楚，本章描述的是一个大型图形化世界。好在设计者并不需要知道其中每个细节——那是制作人的活——但他们确实需要大致了解这个流程是怎么分解的。因此，听到这里你可以松口气：下面只给一个概览，而不是一份操作指南。如果你想了解更多（并弄明白制作人的报酬为什么是设计者的两倍），可以参阅布里奇特·帕特罗夫斯基（Bridgette Patrovsky）与杰西卡·穆里根（Jessica Mulligan）的《在线游戏开发：内部人士指南》（Developing Online Games: An Insider’s Guide） 1（讲虚拟世界），或者安德鲁·罗林斯（Andrew Rollings）与戴夫·莫里斯（Dave Morris）的《游戏架构与设计》（Game Architecture and Design） 2（讲一般游戏）。
在线游戏的开发分为四个明显不同的阶段：
Pre-production（前期制作）
Production（制作）
Roll out（上线）
Operation（运营）
下面我们依次来看。
前期制作
前期制作最长可以持续六个月。它的目标是完成一切必要的概念评估与项目规划，以降低开发后续阶段的风险。这项工作由核心团队成员承担，成员之间密切磋商。从很多方面说，它是项目里最激动人心的部分，但它通常是在时间压力下、用不够用的资源做出来的，这就未免让那份兴奋打了折扣。具体说来，到这一步结束时，会有若干重要的交付物已经就绪，而它们几乎肯定都还需要继续加工，实际给到的工夫总是不够。
这些交付物是：
一份 visualization document（愿景文档）。它由主设计师最先产出。这份文档虽然只有寥寥几页，却为整个项目定下基调，申明项目的使命宣言、理念、目标、主要特性，以及这个世界的外观与感觉。
一份设计文档。因为它是设计师（们）写出来的，我用了本书第 3 章到第 5 章的大部分篇幅，去谈这份文档里该放些什么。不过眼下只需要说：它定义的内容包括世界的背景、架构、机制（含玩法）、控制机制（玩家如何与这个世界交互），以及这个世界不可或缺的社区支持系统 1。随着开发推进，具体内容会不断添加。
一份技术设计评审，评估硬件与软件需求。需要哪些技术？需要哪些工具（既有专门定制的工具，也有中间件）？技术设计评审常常会被并入设计文档。
一份美术圣经（art bible），描述要采用的风格约定，并配以示例，说明所需素材的范围。这样做是为了让美术师产出的作品能与统一的整体外观保持一致 2。
一份制作管理评估，用其他交付物来估量项目的需求。其中会包含一份进度表（带里程碑）、资源需求明细，以及一些风险评估。进度表会根据事情的实际推进情况不断更新，而不是根据事情本应如何推进。
若干原型，用来提供概念验证，表明潜在的技术困难是可以克服的。
前期制作主要是一个规划阶段，因此构建（有限的）原型似乎有些不合时宜。原型之所以必要，一部分是出于商业上的理由——它们向投资人证明团队拿得出东西——但它们对团队自身同样有好处。
它们确保设计、程序与美术方面的标准已经确立，确保源码控制能正常工作。它们表明基本原理行得通，并且（但愿如此）能够整合到一起。对于那种像流水线一样、为不同项目源源不断产出内容的公司来说，与各个制作中心沟通的基本通路也因此得到了检验。
技术设计评审处理的是基础性问题，例如服务器代码如何模块化、将采用哪些网络传输层协议（TCP/IP 还是 UDP）、背景内容如何一点一点地送给客户端，以及如何支持多种接入方式（PC／家用主机、网页浏览器、手机）。另外，技术设计评审还必须考虑与虚拟世界毫无直接关系的议题，主要是登录、计费之类的后端系统。必要的软件开发工具（包括用于系统测试与调试的工具）必须在现阶段就准备好，同时还要把合适的中间件尽量配齐。特别值得一提的是，尽管通常要付高得吓人的授权许可费，公司买一套现成的数据库、3D 引擎和计费系统，通常也比自己从基本原理出发去写要划算 3。
不过，能不能买到用于世界构建与 AI 脚本编写的合用中间件，要视项目而定，因为这一块需要极大的灵活性。开发者通常喜欢手边有自己能随意使唤的程序员，随时把必要的改动迅速做掉，而不是到了临时要改的时候，还得去指望别人的手下。
制作管理评估涵盖的职责范围比它的名字所暗示的要宽。这个术语来自电脑游戏行业，在那个行业里，典型的产品摆上货架之后并不需要多少支持。因此，电脑游戏的管理评估只需覆盖制作环节。而虚拟世界（无论是不是游戏）在上线之后却需要有人来管理——而且是极度繁重的管理！针对虚拟世界的制作管理评估，还必须覆盖上线发布，一直延伸到运营阶段。这意味着它要考虑质量保证、运营团队管理、社区维护、内容创作与打补丁之类的事情。也正是在这里，与市场部围绕产品上线该怎么操办的拉锯战拉开了序幕。
制作
制作阶段 1 对一个大型商业虚拟世界来说会持续两到三年 2，大部分编程与数据制作工作都发生在这个阶段。必须为客户端、服务器和各类工具编写代码。所有这些都得依照制作人制定的制作日程 3 依次完成。工具通常最先写，因为其他工作都依赖它们，也因为工具的部分代码往往可以复用到服务器或客户端上。需要用工具来做的事情包括世界生成、人工智能（AI）脚本编写和客户服务支持。另外，做几个分析工具也是个好主意：这样世界一旦运转起来，不必去问，就能弄清玩家、软件和硬件各自在做什么。
服务器端需要多少代码，取决于选定的架构。服务器端代码包括局域网（LAN）联网层面的驱动功能（把服务器连到它的对等机），以及通信模块（把服务器集群连到互联网）。它通常还包括一个 mudlib 层，用来支撑世界的物理规则与 AI 系统。是否包含世界模型层，取决于脚本编写工具产出的是什么。如果要在多个化身里运行，它就不会包含任何特定于某个实例化的细节（否则要想做全局更新就会难得多）。
客户端代码里包含一个大型 3D 引擎，外加对音乐与音效的支持。连接服务器所需的通信协议显然是必需的，客户端需要打补丁时的软件更新机制也一样（而打补丁是免不了的）。
程序员忙着编程的时候，美术则在忙着制作物件模型（静态的和动画的）和纹理贴图，以及其他各种杂项图片（例如给手册、片头动画和网站用的图）。所需美术素材的数量极大，因此通常会存放进它自己的数据库，好让美术能把全部素材都管起来。图形方面也同样会出现可扩展性与可维护性的问题 4。
世界本身，是用程序员做出的建造工具、按照设计文档的规格搭建起来的。这项工作涉及相当程度的创作自由 5，因此通常由专门的设计者而不是程序员来做；这和动画通常由美术来做是一个道理，尽管必要的工具是程序员造的。
上线
上线是开发中最关键的阶段：所有已经创造出来的技术与素材，都在这个阶段汇集到一起，形成虚拟世界的体验。它正式始于公测（open beta test），但根在开发流程中扎得比这早得多。
当然，测试贯穿整个开发过程。程序员会测试一段段代码，动画师会测试动画，就连设计者也会拿数据去跑模型，看看自己以为会发生的情况，在玩家被放进他们那件漂亮的作品、放手去玩之后，是不是多半真会发生。
当虚拟世界已经有足够多的部分可用、能构成一个完整的环境时，就可以架起一台测试服务器，开始阿尔法测试。这项测试由设计者、程序员和美术亲自动手：主要在自己负责的范围内找 bug，但也会把发现的任何其他东西报上来，只要那东西看起来“莫名其妙就是不对劲”。差不多就在这个时候，有些开发者比较开明，可能会请独立设计顾问来看一看；但大多数开发者并不开明，也就不会请。各位，团队外面那些懂行的人，并没有连续两年整天泡在这件事里；他们的意见值得一听，也值得花钱去听。当然，这还有一个前提：你会去听他们说了什么，而不是在制作排期表上把“聘请顾问”那一项打个勾，然后接着往下走。
阿尔法测试也是受过培训的客户支持人员开始学习的阶段：他们一边学，一边把虚拟世界往死里折腾——而真正的玩家将来也很可能会这么折腾它。
为了做平台测试——也就是看客户端能不能在多种具有代表性的家用电脑配置上跑起来——可能会请质量保证（QA）专家来（从公司外部请，或者从公司其他部门调）。但这些专家事后不会留下来，因为虚拟世界的规模通常比普通电脑游戏大得多，玩通一遍也要久得多。既然客户服务代表本来就需要深入了解虚拟世界，那么合理的做法就是给他们足够的 QA 培训，让他们来接手这项工作，同时还能把自己的游玩水平练上去。
在阿尔法测试期间，什么都可以改，什么都可能发生：发现 bug、修掉 bug，再把修好的结果并回整体。但到了最后（但愿这个时点是由制作人提前排定的），世界会稳定到足以让不直接参与开发的人也进来。换句话说，就是玩家。
最初，只有少数外来者被允许进入虚拟世界。第一批是开发者专门点名请来玩的人，挑他们的理由要么是朋友关系 1，要么是他们有影响力却又靠得住（或者只是在社区留言板上给人这种印象）。另外还有几个人，会通过面向大众的测试玩家招募报名进来，以此掩盖一个事实：他们这批人里大多数走的是后门。内测就这样开始了。
在这个阶段，这场内测还属于封闭测试（closed beta），因为这个世界只许受邀者进入。随着稳定性提高，开发者可以从公开招募里放进来更多眼巴巴想进来的人，把玩家数量逐步提上去，这种手法叫作渐进放量（ramping）。当准入门槛放宽到足够程度、测试者的表现开始像真正的玩家时，这个世界就进入了实战内测（live beta）；这个时点与它正式向所有人开放、接受压力测试的时点——也就是进入公测（open beta）的时点——可能重合，也可能不重合。因为测试的这个最后阶段标志着越过就无法回头的临界点，所以上线阶段到了这里才算真正开始。
通常，电脑游戏会尽量晚地进入内测。虚拟世界其实算不上电脑游戏（尽管许多虚拟世界的开发者似乎并不这么认为），所以会尽量早地进入内测。这样，bug 和 exploit（可被利用的漏洞）就能早在付费客户因为它们而流失之前被发现，同时还能在内测者之间结成牢固的社区纽带。这些人里甚至可能有人能提出像样的改进点子 2。
上线阶段在正式发布之后结束，此后它留下的一切就移交给市场部门（而这个部门在此之前已经深度参与其中了）。当然，后来的资料片可能各有各的上线过程，就像它们也要走过开发的其他阶段一样。
归纳一下：上线阶段的目标，是让虚拟世界在正式发布时具备以下几样东西：
一个已经播下种子的社区
一个预热好的市场
平衡性
没有 bug
除了最后一项，其余都是办得到的。
运营
运营阶段 1 从人们开始付费进入虚拟世界那一刻开始。它在两种情况下结束：人们不再付费，或者用来维持这些玩家所需的资源用在别处更划算（也就是说，能赚更多钱）。
在运营阶段，最初的设计与开发团队（dev team，开发团队）通常会把控制权移交给一批新的开发者（live team，运营团队）。道理在于，久经沙场的开发团队可以转去做别的项目（比如说，制作下一个资料片），而虚拟世界的维护与长期改进就交给经验较少的运营团队。但事情并非总是如此：例如《卡米洛特的黑暗时代》（Dark Age of Camelot）在运营阶段就保留了自己的开发团队，而不是恰恰把最了解这个项目的人调去别处工作。
那么，运营团队究竟做些什么呢？它的任务包括以下几项：
客户与社区支持。
网络与技术支持。
功能开发与增强。
应对玩家的狡黠，维持玩法的整体品质。
与技术保持同步（例如新平台、新显卡）。
偶尔做市场推广（推广虚拟世界及其知识产权）。
商业虚拟世界的开发团队规模各不相同；一般说来，项目推进得越深入，参与的人就越多。尽管有些公司可能宣称，只靠一名设计者、一名程序员和一套剪贴画素材包，就能做出一个能容纳 100,000 名玩家的世界，但实际情况与这多少有些出入。粗略说来，进入制作阶段一年左右，开发团队通常有 30 人上下，按设计者、程序员和美术／动画师 5:10:15 的比例分配。
为什么现在提这个？因为运营团队的规模将是开发团队的三到四倍！它的设计者与程序员人数大致相当（美术可能更少 2），但客户与社区支持方面要多出一百多人。
对虚拟世界来说，真正的工作要到运营阶段才算开始。开发者们一而再、再而三地没能领会这一点——尤其是那些长期浸染在普通电脑游戏行业“发射后不管”式做法中的人。虚拟世界虽然来历如此，却并不是普通的电脑游戏——也未必是任何一种游戏（至于它们究竟是什么，第 6 章“它不是游戏，而是一种……”里另有讨论）。