跳转至

为什么需要语涵编译器

本页将详细介绍语涵编译器的设计目的。我们先介绍在没有语涵编译器时，视觉小说的一般制作流程。

原制作流程

每个团队的具体流程存在差异，但大体上遵循如下阶段：

  • 准备期(pre-production)：剧本作者完成剧情大纲、企划，确定世界观、角色、场景等信息。
  • 制作(production)：制作团队组建完成后，如下事项开始并行推进：
    • 美术、音乐：立绘、背景、CG等资源的需求整理完成并开始制作；
    • 剧本：剧本作者完善剧本；
    • 程序、UI：团队选择视觉小说引擎，构建UI；
    • （等剧本和资源完成后）将剧本录入为视觉小说引擎所用的格式，添加演出效果。
  • 后期(post-production)：打磨、完善，准备发售。

用一张图来表示的话大概是这样（不考虑返工、迭代的话），每个结点代表需要完成的任务：

graph TB
  subgraph preproduction["准备期"]
    outline["剧本大纲、企划"]
    teamforming["组建团队"]
  end
  subgraph production["制作阶段"]
    requirements["需求整理：整理需要哪些素材，分别有什么要求"]
    enginesel["引擎选择"]
    assets["美术、音乐资源：
    立绘，背景，CG，音乐，音效，……"]
    scripts["完整剧本"]
    ui["程序、UI"]
    assetintegrate["资源集成：把资源整理、转换为引擎所用的格式"]
    scriptintegrate["剧本录入：把剧本改成引擎所用的格式（语法）"]
    voice["配音、后期处理"]
    perform["演出"]
  end
  subgraph postproduction["后期"]
    testing["测试迭代"]
    marketing["宣发"]
    release["发售"]
    patching["维护、Bug修复等"]
  end
  outline --> teamforming;
  outline --> requirements;
  outline --> scripts;

  requirements --> assets;
  teamforming --> assets;

  enginesel --> ui;
  enginesel --> assetintegrate;
  enginesel --> scriptintegrate;

  scripts --> scriptintegrate;
  assets  --> assetintegrate;

  scriptintegrate --> perform;
  assetintegrate  --> perform;

  scripts --> voice;
  ui --> testing;
  perform --> testing;
  voice --> testing;

  testing --> release;
  marketing --> release;
  release --> patching;

本可避免的问题

对于爱好者团体（而非经验丰富的商业化公司）来说，上述流程可能会出现以下问题：

  • （开坑主因）部分制作组没有足够的编程能力实现自动化录入，需要额外的人力将剧本录入到引擎所需的格式。
    • 即使是提供完全的图形界面、“免代码”的视觉小说引擎，同样没有自动化录入的功能；剧本必须按照引擎所用的格式书写。
  • 可运行的游戏实机演示(Demo)一般在开始演出之后才有，此时距离企划开始已经过去很久。
    • 在这之前，制作团队的积极性可能无法支撑制作组完成企划。碰上组员个人原因发生人员变动或是延期的话，变数更大。
    • 部分年轻的主催没有足够的耐心、急于完成实机演示，一开始就组建了规模超过自己能力范围的团队，导致之后需要同时与过多的人沟通对接，过度消耗自己的精力，欲速而不达。
  • “反射弧太长”，前期因为思考不足或是头铁导致的方向性问题往往得到项目中后期才发现（或者证实），然后船大难掉头。
  • 部分缺乏经验的主催在准备期立了超过自己能力的企划（包括经济能力和时间精力等），篇幅和体量过大，导致制作过程中“坐牢”。轻则预算超支、项目延期，重则项目夭折。
  • 部分（美术、音乐）资源使用不合理，比如一处给一两句话单独放了一张CG，另一处需要剧情CG的地方却因为诸如优先级安排不合理、预算不足，或只是因为单纯的疏忽而没有制作。
  • 引擎选择不恰当或是盲目选择自研引擎，导致游戏因为引擎的原因表现不佳。一般发现此类问题都是制作阶段的中后期，中途换引擎的工作量巨大。

解决方案

语涵编译器项目有以下两个主要目标：

  • 能在开发早期（演出之前）就能有可以运行的实机Demo。语涵编译器读取剧本和素材，导出用户指定的引擎所用的游戏工程文件（如 Ren'Py, WebGal 等）。
  • 集成分析工具和常用功能，提高游戏制作效率。

因此，使用语涵编译器的团队除了上述的传统工作流程外，还可以采用如下快速迭代流程：

graph TB
  subgraph preproduction["准备期"]
    outline["剧本大纲、企划"]
  end
  subgraph production["制作阶段"]
    decide["根据实机效果决定改进什么"]
    assets["美术、音乐资源"]
    scripts["完善剧本"]
    ui["程序UI"]
    voice["配音、后期处理"]
    perform["精细演出"]
  end
  postproduction["测试迭代、其余后期"]
  outline --> |"使用语涵编译器"| decide;
  decide <--> assets;
  decide <--> scripts;
  decide <--> ui;
  decide --> |"脱离语涵编译器"| perform;
  voice --> postproduction;
  perform --> postproduction;

对于之前提到的问题，语涵编译器项目希望能以如下方式提供解决方法：

  • 手动录入费时费力：可使用语涵编译器进行录入和基本的演出。
  • 反射弧太长：采用快速迭代的工作流程可以缩短反馈时间，及早发现问题。
  • 实机Demo遥远、积极性不足：通过使用程序生成实机演示，我们尽可能使每一点进度都能很快在实机中呈现，立即给予正反馈。
  • 同时开工方向过多、协调困难：两个方面：
    • 程序生成的实机演示是游戏成品质量的下限，我们保证哪怕某个方向什么也不做，成品游戏也能有一个合理的下限。主催可以根据情况去选择方向逐个击破，一点点迭代。
    • （未来有可能）提供工具来辅助生成需求文档，减少协调所需工作量
  • 企划过大、成本失控：我们可以通过分析工具在早期估算出成本，方便主催悬崖勒马。
  • 资源配置不合理：我们可以通过分析工具整理资源需求、了解资源使用情况，团队可以以此为基础去调整需求、优先完成更重要的部分。
  • 引擎选择不当：（目前还不完善，但）语涵编译器可以生成不止一种游戏引擎所用的游戏工程，制作团队可以先完成游戏内容，再根据效果决定所使用的引擎。语涵编译器也可以支持用户添加对自研引擎的支持。

某种程度上说，对于视觉小说制作过程中碰到的可以自动化处理的一切问题，如果没有被引擎和发行平台解决的话，以后都可以在语涵编译器中解决。如果成熟的制作团队内部有自己开发的辅助工具的话，语涵编译器就是要抢这些工具的饭碗。

语涵编译器对输入剧本的格式也有要求，不过我们在设计上尽可能接近创作者的自然写作习惯，由于演出需要所添加的命令也尽可能设计得好懂，含义一目了然。如果我们发现新的符合自然写作习惯的表述方式，我们会修改程序来添加支持。换句话说，如果其他引擎的语言是“创作者学习引擎的规则”，那么语涵编译器是去“主动学习创作者的规则”。

由于视觉小说引擎的设计千差万别，所支持的演出效果和特性等也大相径庭，所以我们不可能保证每个引擎的所有特性都能在语涵编译器内得到支持。因此，语涵编译器尽可能支持视觉小说引擎共通的一部分功能和特性，其余与引擎深度绑定的优化、演出等仍然需要用户脱离语涵编译器后手动完成。

总结

  • 自动录入、自动生成游戏工程。
  • 经验不够，程序来凑
  • 能用程序做的，别人没做的，我们做