Que fait 游戏画面视觉层级 ?
核心思想
玩家每一瞬间能分给画面的注意力有限。任何"显眼"——更亮、更暗、更艳、更密、更大、在动——都从同一份预算里支取。层级就是分这份预算：信息在玩法上越关键、越要立刻反应，就拿到越多、越独占的显眼手段；其余元素主动让出来。
关键动作是约束下层，不是拔高上层。只把重要的东西做亮，别的资产也会跟着变亮，最后人人都在喊。有效的做法是给最底层的画布划一个窄的范围，在上层要用的方向留白。
方法提炼自 Riot 2014 年的博客《Defining the Rift's Visual Style》。哪些是原文主张、哪些是本技能的推论，以及实测数据，见 references/rift-case-study.md；其他出处见 references/sources.md。
0. 先找项目自己的规范
先在项目里找这些东西：
- 美术方向和配色规范、调色板文件、QA 截图记录、评审页里已经写明的问题；
- 设备和导出工具的限制，比如点阵屏的帧数上限、亮度怎么驱动；
- 决策记录：做过什么、否决过什么。
找到就沿用它的术语和色彩空间，拿它的数字当验收标准。代码注释里的假设和已验证的事实要分开说。规范和这里的原则冲突时指出来，不要擅自改写。
1. 从玩家要做的判断出发
先问：这个时刻玩家必须读出什么？我在哪；能去哪；谁是敌、谁是友；什么马上要打到我；现在能做什么；刚才的结果是什么。读出来的还得是真的：看起来能走、会伤人、有范围的东西，玩法上必须真是这样。
- 排序看两点。紧急度：看漏的代价有多大、要多快反应；玩家能据此躲开、打断、换位时代价才大，不能应对的效果不要做成预警的样子。持续性：常驻还是瞬时。排最前的通常是"瞬时且致命"的信号。
- 注视点：标出玩家此刻在看哪里（角色、准星、光标）。注视点附近的信号可以靠颜色和形状；离得远的紧急信号要靠运动、面积或屏幕边缘的整体变化。
- 阶段：探索与战斗、浏览/选目标/结算，各排一次；进入某个阶段时主动压低与它无关的层。
- 按功能分层，不按资产分：悬崖边、可拾取物是玩法信息，放在环境层上缘；装饰粒子属于环境层，哪怕技术上是"特效"。
- 绘制顺序不等于显眼优先级：塔防的弹道画在敌人之上，但数量多、单个信息少，必须小而短。
各类型的分层起点见 references/layer-stacks.md。
2. 显眼的通道
| 通道 | 特点 |
|---|---|
| 明暗对比 | 最强最快，灰度下依然成立，是分层的首选。 |
| 饱和度 | 次强。小面积的高饱和色块也会抢眼。 |
| 色相与冷暖 | 和画面主色族拉开时很强，比如熔岩场景里的冷色；同一色族内、红对绿不可靠。也用来表达语义。 |
| 细节密度 | 高频纹理就是噪声，会把注意力摊薄。 |
| 形状、面积、剪影 | 形状语言区分信号的种类；剪影决定远看认不认得出。 |
| 运动与出现方式 | 对周边视野极有效，突然出现胜过渐变。最高优先的信号靠运动时，其他循环动画要停下或降级。 |
| 位置与框定 | 屏幕边缘、底板、描边、底圈。常驻 UI 主要靠它。 |
| 整屏色调与总亮度 | 远看、一瞥时最先读到，适合表达全局状态。 |
明度的口径：灰度下分不分得开，看感知明度（L*）。HSB 的 V 把"亮"和"艳"混在一起：纯蓝的 V 是 100，L* 只有 32。带数字的明度要写明是哪一种。
3. 分配规则
- 画布最窄，并在上层要用的方向留白。 默认两端都留。暗色游戏和 LED 的画布可以贴着暗端，这时上层只能向亮处和艳处外扩，再靠描边、剪影、运动补足。
- 上层包含下层，再向外扩。 上层可以用画布的中间调，靠多出来的部分被看见：更亮的高光、更深的剪影、更艳的点缀。层内也分主次：越界的部分花在承载玩法信息的小部位（朝向、武器、弱点、前摇肢体），其余做成低细节的休息区。
- 最强的通道留给第 1 节排最前的信号，做成专属档。 专属档从其他所有层里挖掉，只归它的主人。一档只对应一种含义，玩家才能学会；别的东西闯进来就是误报。它不一定是"最亮"，可以是一种色相、形状或运动，也可以按阶段分配。
- 显眼程度 × 面积 × 时长 × 数量 = 一份预算。 预算约束的是和主信号竞争的东西；主信号本身要先保证在观看距离上看得见。
- 要短的是命中闪光和结果反馈。预警相反：早于判定出现，留足反应时间，随临近逐级加强。
- 数量会压垮画面：同屏几百个弹道或飘字，要按数量限流。大范围指示压低填充、只让边缘显眼，重叠时取并集。
- 常驻 UI 首先不能遮挡玩法（角色周围、前进方向、下一步要操作的位置），其次才是窄、小、贴边。血条、伤害数字这类世界空间 UI，计入它所标注那一层的预算。
- 闪光安全优先于层级："短"不降低光敏风险。大面积闪烁每秒不超过 3 次，避免饱和红的闪烁。
- 比较的是局部。 看元素和它实际接触的、最不利的那块背景。会经过明暗两种背景的元素，用一深一浅的双层描边。
- 修问题的顺序：先降，再换通道，最后才升。 先把越界的下层收回去；再考虑给信号换一个下层没占用的通道（色相、形状、出现方式、位置）；最后才加强上层。压完下层要复测：原来靠"比背景暗"分开的元素，可能反而贴上去了。
- 提防升级通胀。 满级、高稀有度靠剪影、零件、动画来表达，留在原来的范围里。
4. 环境：退后，并引路
- 退后靠简化，不靠柔化：用大块的形状和明暗代替细碎的高对比纹理。把图模糊一遍也能压低指标，但材质会认不出来。常见的改动是降饱和、压低地面纹理反差、减少环境光源，往往不必先动角色。
- 引路：可走的地方更平、更安静，和边界保持稳定的明度差；边界更暗、更密。它是轻声的提示，不是箭头。
- 环境内部也分层：和玩法相关的地形放在范围的上缘，纯装饰放中间。环境光源会和专属档抢位置，要缩小、压暗，或让它有玩法含义。
5. 统一与技术痕迹
- 所有资产回到同一个愿景，尺度和角色相称。角色风格跨度越大，环境越要居中；评估新资产时，把它放到阵容两端的角色旁边看。
- 风格辨识度可以来自一组刻意的造型对比（柔软对尖锐），再控制现实参考与幻想元素的比例。
- 硬多边形边、接缝、平铺重复、闪烁、过度写实的粗粝纹理，吸引注意力却不传达信息，要藏起来或改成刻意的风格。网格、像素块、描边这些刻意保留的结构不算。
6. 按项目调整
- 暗色 / 恐怖："亮"是稀缺通道。多个信号都会变成黑里的亮点，要靠形状、高度、动态区分；关键信息不要只放在最暗一档。
- 明亮的卡通风格：两端被风格占用时，画布退回中段，或改用深色描边分离角色。
- 3D / 写实 / 动态光照：最终明度由材质、光照和镜头共同决定。先估算光照再定范围，在后处理之后的画面上测。见 references/3d-lighting.md。
- 像素图、有限调色板、LED 点阵、小屏：见 references/limited-palette.md。
- 色觉差异：分层主要靠明暗，语义色配合形状和图标。用到色相专属档时，看红、绿色盲的模拟图。
7. 检查方法
先推理，再测量。先用上面的规则和这个类型的常识得出判断：光照怎么衰减，设备有什么限制，玩家什么时候做判断。测量只用来回答具体的问题，不要让拼图和量数字挤掉推理。
-
先核对证据：截图是否早于现行版本，有没有调试叠加层，拍摄时灯光和后处理开没开。做法见 references/evidence-and-measurement.md。
-
取最坏情况：最拥挤的时刻、玩家做关键判断的那一刻。瞬时信号看起手帧，不看完全亮起的峰值帧。状态变化用同机位的两帧比较。
-
三个快速测试：灰度下层级还在吗；模糊后眼睛先落在哪里；把某一层涂成纯色，姿势和朝向还认得出吗。
-
关键信号逐通道核对：把最高优先的信号和实际挨着它的竞争者，按第 2 节的通道逐个比。
-
测量：本技能目录下的
scripts/sv_profile.py按层报告面积、饱和度和明度的范围、感知明度、细节密度、专属档归属和局部对比，支持项目的色彩空间、两帧对比和多帧 GIF。scripts/palette_check.py在动笔前检查分层调色板。参数见-h，读数方法见上面那份参考文件。输出写到临时目录，不要写进项目。python <技能目录>/scripts/sv_profile.py shot.png -o <临时目录> -r "!environment:0,0,1,1" -r "player:0.42,0.40,0.50,0.55" -r "hud:0,0.88,1,1" -
示意帧只做对照实验：没有截图时可以用色块拼帧，但一次只改一个变量，光照要大致符合实际。在自己拼的图上量出的数字不能当作"现状"，也不能用来证明自己的方案合规。
-
数字只是证据：结论最终回到"玩家能不能读出该读的东西"。需要验收时，写上玩家复测的指标。
8. 输出
审查默认只读：不改素材、代码和项目文档，改动只写成建议。先直接回答用户问的问题，同一个判断只说一次。
-
审查截图：先给一句话结论。发现按对玩法的影响排序：先是"我在哪、敌人在哪、什么要打到我"和 UI 遮挡，再是环境与角色抢注意力，最后是风格和技术痕迹。每条写位置、现象、违反的原则、最小改动。
-
前后对比：逐项回答"玩家要读的东西"变好还是变差；把对这组截图的判断，和对现行版本该做什么，分开写。
-
只有文字描述的诊断：给出最可能的原因和排查顺序，交给用户能自己跑的检查和引擎里的具体做法，并列出画面以外的可能原因（时长、判定范围、镜头、音效）。
-
制定规范：先完成第 1 节的排序，再写每层的范围、专属档归属、面积时长数量的约束，附合规与违规的对照。规范要能直接照做：
- 覆盖用户点名的每一类元素；
- 数值用执行者的单位给出起步值（格、像素、秒、引擎里的字段），并标"待实测"，不要因为没有截图就不给数；
- 写上渲染顺序和调度规则：谁压谁、叠加上限、何时清场；
- 最后列几条红线和落地顺序。
已有美术但没给截图时，同时请用户提供截图来校准。
共同的规则：
- 证据不足时删减结论，不要只在末尾提一句；截图里没有的东西不外推数字。
- 说不清用途的元素先在项目里查；查不到再按两种可能分别下结论，并问用户。
- 原因有多种可能时，先给一步能很快验证的诊断，再分情况给改法。
- 给改法前，查项目里已经做过什么、否决过什么。对照基准只用项目规范或项目自己的合规帧，不拿参考案例的数字当标准。
- 不擅自改变项目既定的画风，建议写明收益和代价。