# 前期制作

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

---

前期制作最长可以持续六个月。它的目标是完成一切必要的概念评估与项目规划，以降低开发后续阶段的风险。这项工作由核心团队成员承担，成员之间密切磋商。从很多方面说，它是项目里最激动人心的部分，但它通常是在时间压力下、用不够用的资源做出来的，这就未免让那份兴奋打了折扣。具体说来，到这一步结束时，会有若干重要的交付物已经就绪，而它们几乎肯定都还需要继续加工，实际给到的工夫总是不够。

这些交付物是：

- 一份 visualization document（愿景文档）。它由主设计师最先产出。这份文档虽然只有寥寥几页，却为整个项目定下基调，申明项目的使命宣言、理念、目标、主要特性，以及这个世界的外观与感觉。

- 一份设计文档。因为它是设计师（们）写出来的，我用了本书第 3 章到第 5 章的大部分篇幅，去谈这份文档里该放些什么。不过眼下只需要说：它定义的内容包括世界的背景、架构、机制（含玩法）、控制机制（玩家如何与这个世界交互），以及这个世界不可或缺的社区支持系统 [^5]。随着开发推进，具体内容会不断添加。

- 一份技术设计评审，评估硬件与软件需求。需要哪些技术？需要哪些工具（既有专门定制的工具，也有中间件）？技术设计评审常常会被并入设计文档。

- 一份美术圣经（art bible），描述要采用的风格约定，并配以示例，说明所需素材的范围。这样做是为了让美术师产出的作品能与统一的整体外观保持一致 [^6]。

- 一份制作管理评估，用其他交付物来估量项目的需求。其中会包含一份进度表（带里程碑）、资源需求明细，以及一些风险评估。进度表会根据事情的实际推进情况不断更新，而不是根据事情本应如何推进。

- 若干原型，用来提供概念验证，表明潜在的技术困难是可以克服的。

前期制作主要是一个规划阶段，因此构建（有限的）原型似乎有些不合时宜。原型之所以必要，一部分是出于商业上的理由——它们向投资人证明团队拿得出东西——但它们对团队自身同样有好处。

它们确保设计、程序与美术方面的标准已经确立，确保源码控制能正常工作。它们表明基本原理行得通，并且（但愿如此）能够整合到一起。对于那种像流水线一样、为不同项目源源不断产出内容的公司来说，与各个制作中心沟通的基本通路也因此得到了检验。

技术设计评审处理的是基础性问题，例如服务器代码如何模块化、将采用哪些网络传输层协议（TCP/IP 还是 UDP）、背景内容如何一点一点地送给客户端，以及如何支持多种接入方式（PC／家用主机、网页浏览器、手机）。另外，技术设计评审还必须考虑与虚拟世界毫无直接关系的议题，主要是登录、计费之类的后端系统。必要的软件开发工具（包括用于系统测试与调试的工具）必须在现阶段就准备好，同时还要把合适的中间件尽量配齐。特别值得一提的是，尽管通常要付高得吓人的授权许可费，公司买一套现成的数据库、3D 引擎和计费系统，通常也比自己从基本原理出发去写要划算 [^7]。

不过，能不能买到用于世界构建与 AI 脚本编写的合用中间件，要视项目而定，因为这一块需要极大的灵活性。开发者通常喜欢手边有自己能随意使唤的程序员，随时把必要的改动迅速做掉，而不是到了临时要改的时候，还得去指望别人的手下。

制作管理评估涵盖的职责范围比它的名字所暗示的要宽。这个术语来自电脑游戏行业，在那个行业里，典型的产品摆上货架之后并不需要多少支持。因此，电脑游戏的管理评估只需覆盖制作环节。而虚拟世界（无论是不是游戏）在上线之后却需要有人来管理——而且是极度繁重的管理！针对虚拟世界的制作管理评估，还必须覆盖上线发布，一直延伸到运营阶段。这意味着它要考虑质量保证、运营团队管理、社区维护、内容创作与打补丁之类的事情。也正是在这里，与市场部围绕产品上线该怎么操办的拉锯战拉开了序幕。

[^5]: 换句话说，设计文档很像产品发售时卖的那本攻略书，只不过把最无聊的部分拿掉了。

[^6]: 美术圣经往往是在制作阶段逐步（甚至非正式地）积累起来的，因为它并不总是这么早就用得上。不过，这种状况大概维持不了多久了。

[^7]: 程序员可能会抗拒使用第三方图形引擎，因为凡是在这个领域干过的人，都觉得自己能做得比现成的东西更好。奇怪的是，这份自信很少延伸到数据库和计费系统这类没那么好玩的领域。