SuperAPI AI 工具集

auditing-game-screen-readability

测试与质量

查看项目

更新于 10-15 10:16

技能介绍

用途

该技能用于发现游戏状态测试无法看到的显示缺陷。例如:分数弹窗数值正确却被画在 HUD 面板下方;两条各自正确的通知落在同一行;警告线存在但比背景点更暗;计数器准确却没人能说清它统计什么。这些缺陷只在特定时刻出现,因此审计围绕“时刻”组织,而不是围绕“屏幕”组织。

何时使用

  • HUD 元素、通知、警告、指示器或分数弹窗被新增或移动。
  • 评审者询问某个数字或符号的含义,或指出某物被隐藏、太淡、太小。
  • 两个各自显示消息的事件可能在同一帧发生。
  • 发布前,对整个显示做一次全面检查。

何时不使用

  • 问题是“新玩家能否看出该瞄准什么”:应使用 gating-intent-legibility。
  • 尚无视觉方向:应使用 directing-game-visuals。
  • 构建无法在选定状态下捕获:应报告此情况,并退回到阅读绘制代码,执行第 3 步中不需要像素的检查。

操作步骤

1. 列出时刻

从代码而非记忆中枚举。阅读 moments.md 获取目录。至少包括:

  • 每个瞬时文本来源:分数弹窗、通知、横幅、倒计时;
  • 每个警告或预测指示器,在其最淡时以及最繁忙背景上;
  • 每个 HUD 计数器在它变化的瞬间;
  • 游戏能产生的最繁忙效果堆叠;
  • 每个仪式屏幕,包括每个终端屏幕;
  • 巧合:每一对可能共享一帧的通知,强制它们同时出现;
  • 极端:每个世界锚定元素在每个屏幕边缘以及每个 HUD 面板下方。

2. 捕获

通过状态注入或脚本化运行安排每个时刻,并以游戏原生分辨率及其支持的最小显示比例捕获。对于瞬时元素,捕获第一帧、中间帧和最后一帧。记录每帧是如何产生的,以便可重新捕获。

3. 运行机械检查

让游戏按捕获帧报告每个文本绘制、指示器和 HUD 面板的矩形与绘制顺序——来自渲染器使用的同一数据,绝不来自手工维护的列表。将它们写入清单并运行:

node <skill-dir>/scripts/check-screen-frames.mjs <manifest.json>

清单格式和阈值见 frame-manifest.md。脚本报告:

  • overlap — 两个可读元素相交;
  • occluded — 一个可读元素在覆盖它的不透明面板之前绘制。这需要两者有明确的绘制顺序;当顺序缺失或并列时(包括面板自身的子元素),脚本将相交列为 REVIEW 行,供在帧中检查,而不是直接失败;
  • offscreen — 可读元素的任何部分在视口之外;
  • small — 最小显示比例下的字形高度低于下限;
  • faint — 元素与其背后内容之间的对比度低于下限;
  • brief — 瞬时元素可见时间短于其长度所需。

通过的运行会打印它读取的清单和检查的计数。如果什么都没打印,说明它没有运行。每个环境运行一次 --self-test;它必须在其内置的错误清单上报告每个缺陷类别。

当项目无法输出矩形时,通过检查帧来应用同样的六项检查,并将结果标记为 inspected,而非 checked。

两项检查需要像素,直接在帧上进行:

  • 陈旧元素。前一次运行、阶段或模式中的任何内容都不应仍在绘制:吸引演示中遗留的指示器、重启后仍存在的通知、结束屏幕上闪烁的无敌玩家。
  • 范围一致。危险物的绘制范围在其可造成伤害的整个时间内至少等于其活动命中范围,且警告覆盖命中将覆盖的区域。

4. 询问隔离读者 HUD 的含义

给一个既未见过设计也未见过源码的智能体两到三张普通游玩帧,每个 HUD 元素编号。对每个元素询问:它统计什么、什么使它变化、更多是好还是坏?与设计比较。

读者无法命名的元素即使数值正确也是一项发现。如果无法生成隔离读者,自己回答这些问题并标记结果为 self-audit;这是较弱的证据,因为你已经知道答案。

5. 询问每个元素是否必要

对每个标签、数字和符号,说出依赖它的决策。如果没有,它就是移除候选:一个从不改变的模式名、一个重复动画已显示内容的标记、一个玩家无法据此行动的计数。

6. 按此顺序修复

  1. 移除该元素。
  2. 移到玩家正在看的地方,或从覆盖它的东西下方移出。向 HUD 面板漂移的世界锚定文本应朝相反方向漂移。
  3. 强化它:大小、对比度、持续时间,或跟随游玩方向的运动。
  4. 连接到其原因:从世界内事件到它所改变的计数器的动画,比说明文字更能解释计数器。
  5. 最后才加标签。

给重合的通知分配不同行,并将快速连续弹窗合并为一个累计总数。

7. 重新捕获

仅对改变的时刻重新运行第 2 步和第 3 步,仅对含义是发现项的元素重复第 4 步。

验证

  • 第 1 步列出的每个时刻都有帧,或有无法发生的说明理由。
  • 每个巧合都是有意产生的;不假设任何巧合不会发生。
  • 脚本的 self-test 在此环境通过,真实运行打印了其计数。
  • 每条 REVIEW 行都通过查看帧解决;没有未查看就报告为通过。
  • 每项发现都指明元素、帧和失败的检查。不指明元素的发现不是发现。
  • 来自隔离读者的发现单独标记,与 self-audit 结果分开。

输出

发现表(元素、时刻、检查、修复、状态)、其背后的清单或帧,以及无法捕获的时刻列表。

限制

此审计说明元素可以被看到和命名。它不说明游戏被理解、布局有吸引力,或显示在捕获未使用的硬件上阅读良好。色觉缺陷和非常小的物理屏幕需要人或专门的模拟。