游戏知识体系

脚本层定位与语言选择 ​

Category ​

system / 脚本与热更子树。节点定位：脚本层的边界——真正适合承担什么、什么不适合、语言选择看什么、边界治理与更稳妥的定位。

Definition ​

脚本层之所以会反复进入游戏项目，不是因为“脚本语言更高级”，而是因为项目总会遇到这样一种现实：有些逻辑变化得太快，改一次原生代码、走一遍完整发版链路的成本太高。脚本层的真正价值，就是把这部分高频变化从较重的编译和审核流程中拆出来。

但脚本层一旦引入，也意味着系统不再只有一种语言、一种运行时和一种调试路径。它解决的是修复速度问题，同时也把复杂度带进了运行时边界、性能治理和线上排障。

Problem ​

脚本化最大的误导是把「灵活」当目标：该脚本的没脚本（改个数值等热更），不该脚本的全脚本了（结算走脚本被人扒协议）。脚本层最难的不是写逻辑而是边界治理——语言选型之前，先回答哪些能力根本不该进脚本层。

脚本层真正适合承担什么 ​

比较适合脚本层承接的，通常是这些特征明显的逻辑：

  • 业务规则变化频繁
  • 活动和运营节奏快
  • UI 和交互流转复杂但性能不是最极限
  • 需要热修复或快速试错
  • 更偏配置解释和业务编排，而不是底层性能热点

例如活动逻辑、部分 UI 页流程、任务触发规则、对话和表现驱动，往往比渲染底层、物理热点或平台接入更适合放到脚本层。

哪些能力不适合为了“灵活”就脚本化 ​

下面这些能力如果轻率交给脚本层，通常会带来更大代价：

  • 强性能热点逻辑
  • 引擎底层或平台相关调用
  • 安全敏感和作弊敏感逻辑
  • 大量跨层互调的复杂运行时路径

脚本不是不能做这些事，而是如果长期让它承接高性能和高安全边界，后面维护、调试和治理成本会迅速放大。

语言选择真正要看什么 ​

很多团队谈语言选择时会被生态、语法和社区热度带走。更实际的判断通常包括：

  • 宿主环境集成成本高不高
  • 调试、分析和崩溃定位工具是否成熟
  • 跨平台支持是否稳定
  • 团队是否真正有长期维护经验
  • 热更新、裁剪、加密和发布链路是否顺畅

也就是说，语言选择不是单看“写起来爽不爽”，而是看它接进现有运行时以后，会不会成为新的系统性负担。

脚本层最难的不是写逻辑，而是边界治理 ​

脚本层一旦没有边界，很快就会出现这些问题：

  • 业务层什么都想放进去
  • 原生层 API 暴露面越来越大
  • 脚本互调和原生回调越来越深
  • 一次问题排查要跨多层调用栈

所以脚本层最需要被提前定义的，不是语言语法，而是职责范围：哪些模块默认可以脚本化，哪些模块必须经过评估，哪些底层能力绝不直接暴露。

更稳妥的定位方式 ​

比较稳妥的做法通常是：

  • 把脚本层定位为高变业务逻辑和部分表现编排层
  • 把原生层保留给性能敏感、平台相关和底层运行时能力
  • 让脚本层通过受控接口访问宿主，而不是无限制穿透
  • 把热修复和灰度能力建立在清楚的模块边界上

这样做的关键，不是限制灵活性，而是让灵活性不会变成失控。

常见误区 ​

最常见的错误，是把脚本层理解成“以后什么都能动态改”的万能逃生口。第二类错误，是只讨论语言特性，不讨论宿主集成、调试和运维成本。第三类错误，是脚本层边界没有先定，结果所有临时需求都往里塞，最后它反而变成最难治理的一层。

Used By ​

脚本层范围评审；语言选型会议；边界治理规范。

  • BigWorld（commit 088d3b84，路径相对 programming/bigworld/）：嵌入式脚本层的重型实例——嵌入式 Python 3.13（fork 自 2.7 迁移，README.md:21），脚本库 lib/pyscript/，实体定义由 lib/entitydef/ 承载，Witness 本身暴露为 Python 对象（server/cellapp/witness.hpp:28-56）

关系链：适合什么 → 不适合什么 → 语言选择 → 边界治理 → 稳妥定位 → 常见误区。上游：无（scripting 子树入口）。下游：scripting/02（宿主 VM 集成）、production/05（配置表驱动面）。

Reference ​

本页为工程经验归纳。

游戏知识体系

© 2025 cuihairu