# 团队

LLMS 索引： [llms.txt](/dvw/llms.txt)

---

在制造虚拟世界这台机器上，设计也许就是最重要的那个齿轮，但这并不是说其他部件就不重要。有些部件绝对关键：比如服务器一旦崩溃，它每停摆一分钟，代价就是一批账号被注销。设计者必须了解这些事，才能在自己设计虚拟世界时把它们考虑进去。

设计者不仅应当对自己在这个系统中的位置有符合实际的认识，还应当扎实了解创建过程中其他参与者各自承担的角色。作曲家不必会演奏乐团里的每一件乐器，但必须知道所有乐器听起来是什么声音；不能指望设计者懂得程序员或美术是怎么做出成果的，但他们必须清楚存在哪些局限。如果你想让自己的虚拟宫殿每一面墙上都有一幅令人惊艳的原创壁画，那你还是趁早打消这个念头吧。

创建一个虚拟世界，就是在创造一款软件。当然，它不只是软件——它还是一个社区、一项服务、一个场所——但如果没有引擎来跑这个世界，这些都算不上什么。

一家典型的软件工程公司，是按职能分工组织起来的，涵盖以下几个方面：

- 公司领导层

- 销售与市场

- 财务与会计

- 软件开发、客户支持与质量保证（QA）

- 运维与信息技术（IT）

- 人力资源（HR）

其中有些职能可能会拆成独立的部门，比如销售部门可能和市场部门分开；不过总的来说，上面这份清单没什么争议。注意，通常并没有哪个专门的小组只负责产品规格；这项任务落在采购软件的那一方头上，而在很多情况下，那一方很可能就是客户。

一家典型的电脑游戏开发公司，组织方式大体相同，但有以下几点游戏行业特有的差异：

- 增设美术与动画部门。

- 增设音频部门（音乐、音效）——除非外包。

- 质量保证部门扩大，并与实际的软件开发正式分开。

- 增设一个设计组（通常很小）；其成员薪水比其他同事少，从粉丝那里得到的赞誉却比其他同事多。

大型多人在线图形化虚拟世界的开发者，沿用游戏开发模式，只是有以下不同：

- 设计组扩大。

- 运维组（负责维护并支持系统所运行的硬件）扩大。

- 客户支持组（处理虚拟世界内外与玩家相关的事务）大幅扩大，并与实际的软件开发正式分开。它通常还会把质量保证部门重新吸收进来。

公司领导层、人力资源、信息技术和财务／会计人员，只是偶尔才会来打扰设计者。设计者与销售／市场之间会进行一场对话，双方可能势均力敌，也可能一边倒（一边是“我们想让你设计的，是这种世界”，另一边是“我们想让你卖出去的，是这种世界” [^1]）。

设计者会告诉运维、美术和音频专家需要做什么，但一般之后就放手让他们去做。设计者打交道最多的是：

- 程序员（因为设计者从来都说不清自己想要什么——除非他们热情得过了头，试图教程序员该怎么编程 [^2]）。

- 质量保证人员（因为测试人员发现的设计缺陷，比他们发现的编程 bug 和运维问题还多）。

- 客户支持人员（因为玩家发现的设计缺陷，比质量保证人员发现的还多）。

- 彼此（因为尽管本书一再提到虚拟世界的“设计者”，但通常存在的是一个设计团队，由一名主设计师带领）。

当一个新的虚拟世界开始动工时，就会组建一个核心团队。对小型世界来说，这个核心团队可能只有一个人，身兼数职；事实上，它可能永远就这么大。但对大型世界来说，它只是核心，围绕它才会形成一支完整的开发力量。核心团队包括：

- 制作人

- 主设计师

- 主程序员（服务端、客户端）

- 主美术（环境、居民／角色）

主程序员可能有两位，因为客户端编程最好由有电脑游戏开发背景的人来做，服务端编程最好由有软件工程背景的人来做。编程正日益成为一门分工越来越细的行当，在一个领域里很在行的程序员，换到另一个领域工作可能就需要培训。

主美术可能有两位，因为一个图形化虚拟世界涉及的美术工作量实在太大了（尽管开发刚起步时不会如此）。严格来说，“环境美术”（environment artist）负责概念美术（concept art）——也就是决定这个虚拟世界长什么样。“角色美术”（characters artist）负责技术层面——与程序员对接。由于所谓的技术层面通常最终落在动画问题上，角色美术到头来实际负责的就是角色。

运维和客户支持负责人正越来越多地被拉进核心团队，但由于他们的工作要等到开发进行了一段时间之后才能开始，所以初创公司里出现这种情况并不多见。

[^1]: 市场人员自认为对玩家的好恶有专家级的了解。他们也许确实有这种了解。之所以起摩擦，是因为他们试图告诉设计者应当增删或改动哪些特性，以便开发利用这个虚拟世界。
[^2]: 尤其重要的是，程序员不能觉得自己可以即兴添加自己想要的功能。