Godot 骨骼数量预算：角色精细之前，先问同屏能站多少人

为什么要单独写成系统

单个角色骨骼越多，动画和蒙皮越贵；同屏角色数量一上来，成本会被放大。这个问题表面上通常很小：一个确认框、一个焦点切换、一个 LOD 开关、一个下载判断，或者一次性能采样。但它真正影响的是玩家对客户端稳定性的判断。Godot 项目如果把它散落在页面脚本、角色脚本和导出脚本里，后期会很难回答“当前状态是谁决定的”。

主角模型在预览器里很漂亮，手指、表情、衣摆、武器挂点都很完整。进入多人大厅后，同屏二十个角色，CPU 和 GPU 都上来了。模型本身没有错误，问题是资产预算只看单角色效果，没有看同屏上限。

所以本文把Godot 骨骼数量预算拆成可维护的客户端系统。目标不是把实现做复杂，而是让状态可解释、失败可恢复、QA 可复现、上线后有指标。只要这些条件成立，第一版实现可以很朴素；如果这些条件不成立，再漂亮的表现也会在版本迭代里变成维护负担。

模块边界

建议从这些模块开始：SkeletonBudgetTable, AvatarComplexityScorer, BoneLodPolicy, AttachmentBoneFilter, SkinningCostSampler, CharacterBudgetReport。每个模块只做一件事，采样归采样，策略归策略，表现归表现，调试归调试。不要让一个页面节点直接读取平台状态、修改资源、发起请求、改变渲染策略和写缓存。那样短期快，长期无法复盘。

先把规则写进设计说明，而不是藏在代码分支里：

• 主角、队友、路人、怪物使用不同骨骼预算。
• 远处角色关闭手指、表情和次要附件骨骼。
• 附件挂点要登记用途，不能为一次活动永久增加全局骨骼。
• 角色导入时生成预算报告，超限要有负责人确认。

架构图

下面这张图是实现和排查时的共同语言。图上的每个节点都应该能输出日志或调试字段，尤其是失败原因和 owner。

flowchart TD
    N0["Imported Model"] --> N1["Budget Table"]
    N1["Budget Table"] --> N2["Complexity Scorer"]
    N2["Complexity Scorer"] --> N3["Bone LOD Policy"]
    N3["Bone LOD Policy"] --> N4["Runtime Sampler"]
    N4["Runtime Sampler"] --> N5["Budget Report"]

如果代码里出现图外的隐式通路，例如某个回调直接改 UI，某个资源加载直接跳过策略层，就要重新评估。隐式通路越多，线上反馈越难定位。

数据模型

核心字段建议至少包括：skeleton_id, bone_count, weighted_bone_count, visible_actor_count, lod_level, attachment_bones, skinning_ms, budget_group。字段不是为了堆结构，而是为了把玩家看到的结果解释出来。比如同样是不可用，原因可能是平台限制、玩家设置、资源缺失、网络计费、性能压力、版本不兼容或旧请求返回。

字段命名不要偷懒。enabled、valid、ok 这类词只能说明当前分支想通过，不能说明为什么。更稳的做法是保留 source、reason、owner、revision、scope 和 timestamp。source 说明来源，reason 说明原因，owner 说明控制权，revision 用于丢弃旧回调，scope 限定影响范围，timestamp 帮助分析时序。

在 Godot 里，稳定配置适合放进 Resource，跨场景状态适合放在 autoload service，页面节点只订阅归一化后的信号。这样切场景、热更新、重建 UI 时，不会把业务状态跟节点生命周期绑死。

实现片段

下面的 GDScript 只展示关键习惯：统一入口，先归一化，再交给策略层，最后通知表现。

func score_avatar_budget(stats: SkeletonStats) -> int:
    return stats.bone_count + stats.weighted_vertices / 200 + stats.attachment_bones * 2

真实项目里还要补 request_id、trace_id、错误码和调试开关。request_id 防止旧回调覆盖新状态，trace_id 让一次玩家操作跨模块串起来，错误码让 UI、日志和客服口径统一。调试开关则保证开发包看得清，正式包不泄露内部细节。

落地步骤

可以按下面顺序落地：

• 导入模型时统计骨骼数、权重数量、蒙皮网格数和附件挂点。
• AvatarComplexityScorer 结合同屏数量估算总成本。
• BoneLodPolicy 根据距离和重要度切换简化 skeleton 或隐藏次要层。
• 调试面板显示同屏骨骼总量和最贵角色。

第一版只接一个最容易出问题的场景，把状态、日志和 QA 样本跑通。第二版接入相邻场景，确认模型没有被特例打穿。第三版再补编辑器检查、导出报告或自动化测试。很多系统失败不是因为第一版小，而是因为第一版没有观测能力。

配置权限也要写清楚。程序负责字段语义和保护线，内容同学可以改阈值和映射，美术可以改表现资源，但不能临时新增未登记字段。否则后续工具和校验都会失效。

常见事故

这类系统最常见的事故不是崩溃，而是“看起来还能用，但玩家不信任”。下载重复、输入误触、帧率抖动、资源不释放、深链跳空、座位错乱，这些问题都可能不报错，却会直接破坏体验。排查时不要只问哪个函数失败，要问哪条链路没有给出可解释状态。

复盘建议固定写三段：玩家看到什么，系统真实状态是什么，代码为什么没表达出来。只要第三段写不清楚，说明修复仍停留在现象层。下一次换设备、换内容、换网络条件，同类问题还会回来。

性能与资源预算

预算要在第一版就存在。每帧最多处理多少任务，缓存最多多大，日志采样率是多少，重试间隔怎么退避，降级冷却多长，资源何时释放，这些都要写出来。没有预算，功能上线后会被内容量和设备差异拖垮。

低端设备上优先保留玩家理解状态所需的信息，再削减装饰、动画、刷新频率和后台任务。不要为了省一点性能隐藏错误原因，也不要为了表现顺滑让主线程等待磁盘、网络或资源。Godot 项目尤其要小心同步加载、Control 树重建、AnimationTree 采样、材质 duplicate 和每帧轮询。

上线后建议观察这些指标：visible_bone_total, skinning_gpu_ms, bone_lod_switch_count, over_budget_avatar_count, attachment_bone_count。指标要能按设备、渠道、场景和内容版本拆分，否则总量正常也可能掩盖局部严重问题。

QA 清单

这些用例建议进入回归：

• 多人大厅、换装预览、Boss 战召唤物、低端机都要测。
• 角色远近切换时不能出现明显姿态跳变或附件错位。
• 活动皮肤新增挂点后，预算报告必须变化。

QA 用例要写清前置状态、操作步骤、预期结果和预期原因。比如“蜂窝网络下取消下载后不再自动重试”比“下载正常”更可执行。好的用例能倒逼系统输出清楚的 reason，也能帮助新同学理解为什么某个分支存在。

每次修复内测或线上事故，都要把最小复现路径加入样本库。后续改同一模块时先跑样本，再谈新功能。样本库比口头经验可靠，也比临时录屏更容易长期维护。

调试工具

开发包至少要有一个可截图的面板，显示当前策略、关键字段、最近状态变化、错误码、owner 和耗时。面板不需要漂亮，但必须准确。QA 截图后，程序应该能知道卡在采样、策略、资源、请求、表现还是恢复阶段。

如果系统涉及输入，保留最近输入和意图转换；涉及性能，保留时间线和 P95 样本；涉及资源，保留 owner 和引用路径；涉及移动端，保留平台原始状态和客户端归一化结果。调试工具的核心价值是减少猜测。

上线和回滚

上线前写清楚哪些配置能远程关闭，哪些资源能回滚，哪些状态需要玩家重进，哪些数据一旦写入不能撤。灰度不是把全量发布变慢，而是给团队发现问题和撤回问题的窗口。

回滚时要考虑玩家感知。不要让玩家因为技术回退丢下载进度、丢输入设置、重复领奖、误离队伍或看到矛盾提示。客户端不一定能解决所有外部问题，但至少不能展示错误承诺。

最小验收标准

我会用六条标准验收：状态能解释表现；失败原因能展示和记录；旧请求、切场景、切后台不会破坏状态；低端设备有预算；QA 有样本；发布后有指标。六条都满足，再继续扩玩法和美化体验。

最后要把状态图、字段表、错误码、配置入口、调试面板位置、QA 样本和回滚方式交接给团队。代码合进去只是开始，规则被团队理解，系统才算真正落地。

更具体的上线细节

骨骼预算要在资产提交时就生效。美术导入一个新角色后，工具自动生成报告：骨骼总数、影响顶点数、附件挂点数、是否超过目标平台预算、是否有可裁剪层。评审时不要只看截图，还要看这份报告。单个角色多 20 根骨骼不明显，十几个角色同屏就是另一回事。

还要给不同距离准备明确策略。近景主角保留完整骨骼，中景队友关闭手指或表情，远景 NPC 使用简化骨架，极远处可使用静态姿态或 impostor。LOD 不是画质缩水，而是把成本花在玩家能看见和能交互的地方。只要切换时机稳定，玩家不会注意到远处角色少了多少骨骼。

团队交接提醒

这类系统上线后不要只交代码，还要交接状态图、字段说明、错误码、调试入口、QA 样本和回滚方式。尤其是配置项，要写清谁能改、改完需要跑哪些样本、哪些阈值属于平台保护线。团队理解这些边界，后续新增内容才不会绕过系统重新写一套小逻辑。

验收样本和指标解释

验收样本可以做一张角色压力图：10 个主角级模型、20 个队友级模型、40 个路人级模型分别跑同一条镜头路线。记录骨骼总数、蒙皮耗时、动画采样耗时和内存。这样美术能直观看到预算边界，而不是只听程序说“太贵”。指标解释也要分层，主角超预算和路人超预算不是同等严重，前者可能需要优化，后者通常应该降级。

还要把样本固定到版本库或内部测试平台里，包含场景入口、设备条件、输入脚本、期望指标和失败时的截图说明。这样后续文章提到同类系统时，可以复用这些样本，而不是每次重新设计测试路线。长期看，样本和指标比单篇经验更有价值。

边界与反例

反例是只要求美术“少做点骨骼”。这句话没有工程边界，最后只能靠争论。更好的方式是给出平台预算、角色等级、同屏上限和超限审批流程。主角可以贵，Boss 可以贵，远处路人不能跟主角一样贵。预算表让取舍变成事实，而不是审美争论。

这段反例应该进入团队评审标准。只要新需求开始绕过统一入口、隐藏 owner、跳过校验或把失败原因吞掉，就说明它正在把系统重新拆散。及时拦住这些小例外，比上线后做大规模重构便宜得多。

最终检查点

最终检查点是让资产报告成为提交门禁，而不是性能测试后的口头建议。每个超预算角色都要写明原因、目标平台和豁免期限，否则预算会逐步失效。

补充一点：骨骼预算还要考虑动画压缩和附件策略。某些骨骼只是为了挂一次性活动道具，活动结束后仍保留在基础骨架里，会让所有皮肤长期付成本。更稳的做法是把临时挂点做成可选附件层，只有对应内容启用时才加载。这样主骨架保持稳定，活动内容也不会永久污染角色预算。

最终验收时，同屏角色数量达到设计上限，帧时间仍在预算内，且预算报告能指出最贵的角色和骨骼层。

预算必须让美术、程序和策划都能看懂。

这些数据也要进入后续角色资产复盘。

必须执行。