世界美术方向

这一页讲一个世界的图片应该长什么样，以及交付之前要检查什么。它写给为世界配图的人：世界作者、画师，以及维护内置世界的人。不需要会编程。

它分三部分：怎样给自己的世界定方向，四个内置世界各自定下的方向，以及图片怎样出现在世界列表里（画廊）。具体怎样出图，见给角色配立绘和给世界配场景图。

先想清楚图片要做什么

世界的图片有两个任务：

• 选世界的时候，让玩家一眼看出这个世界是怎么玩的。
• 进入世界之后，让人物、地点和规则看起来可信，并且前后一致。

所以不同的世界应该有不同的画风。四个内置世界追求的是同样的完成度，而不是同一种画法。给自己的世界定方向时，回答这四个问题：

问题	例子
这个世界主要是怎么玩的？	对话和关系；调查和风险；修理和求生
用什么画法和哪几种颜色？	清透的动漫线稿，海蓝、薄荷绿、樱粉
图片主要以什么方式出现？	透明背景的立绘加场景图（舞台视图）；带环境的人物卡加一张封面（文字叙事）
哪些东西无论如何不能画错？	某个角色的伤在左臂；某栋楼是三层；某个人是成年人

最后一个问题的答案叫不变量：不管重画多少次、出多少个变体，都必须保持不变的东西。把它们写下来，每次出图后对照检查。

四个内置世界的方向

下表是按题材和现有图片定下的设计定位。它没有经过玩家访谈或数据验证，也不限定玩家的年龄、性别或文化背景。

世界	想传达的玩法，以及会喜欢它的玩家	画法和颜色	图片怎样出现
遥风学园	对话、慢热的关系、群像和学园祭。喜欢视觉小说和日常陪伴的人	清透的动漫线稿，柔和的赛璐珞上色。海蓝、薄荷绿、樱粉。夜晚是蓝紫的环境光配暖灯	透明背景的立绘，五组固定机位的昼夜场景
雾港	线索、阵营、风险和未知。喜欢悬疑调查、黑暗奇幻和探索的人	写实绘画感的海港 noir。冷灰、青灰、旧铜和铁锈。雾里近处清楚，远处消失	半身人物卡和一张遗迹港口封面，配文字叙事
Emberback	修复设施、协作求生和时间谜团。喜欢科幻探索和技术冒险的人	明亮的复古工业科幻插画。奶油白、陶土、钴蓝。低角度的亮侧光，冷色的暗侧边光	带职业环境的成人全身像和一张中继站封面，配文字叙事
提灯古冢	经典的跑团冒险和民间奇幻。喜欢桌面角色扮演的人	写实的皮肤和旧衣料。暖色的油灯主光，冷色的轮廓光。阴冷潮湿的深秋	透明背景的全身立绘，地标示意图和几张场景图

两点提醒：

• 雾港的人名和叙事语境不等于要把现有的面孔换掉，或者全部改成古装。
• Emberback 的温暖、实用和社区感是它的题材特征。不要因为是“科幻”就改成冰冷的舰桥、军装或霓虹。

已归档的 Cloudmere 和 Neonridge 不在当前可玩的世界里。它们重新上架时，要按各自的设定单独检查。

每个世界的视觉不变量

遥风学园

• 角色靠发型、表情和一件道具来区分：澪的稿纸，凛的采访本和相机，夏帆的木吉他，悠真的眼镜和文件夹，遥的日程本，千寻的粉笔和旧书，奏太的鼓棒，茜的书和干花。
• 沿用已定稿的藏蓝校服、白色滚边和每个人现有的轮廓。表情变体里不要随机换成水手服、西装，也不要随机换发饰或蝴蝶结。
• 千寻是二十多岁的成年教师，学生是高中生。内容要清爽、适合青少年，但这说的是尺度，不是把教师也画成学生：她要保留成人的身份、职业着装和温和引导的姿态。
• 日景是空间的母版。夜景只改光线、天空和原有灯具的开关，镜头、地平线、门窗、楼层、书架、路面和道具的位置都不变。不要因为入夜就自动下雨。
• 五个场景的固定特征：社团楼始终是三层、瓦顶、右侧有攀藤；教室的窗边课桌和前景的笔记本位置固定；图书馆的夹层和右侧的长桌固定；海堤坡道右侧的贩卖机固定；商店街是书店和花店在左，餐厅和乐器店在右。
• 背景是给人物表演用的。前景和对话框的区域要看得清。夜景保留中间亮度，不要把温柔的日常画成惊悚片。

雾港

• 地点的身份来自永远不散的雾、悬崖、三层的港城、涨退的潮水和被盐侵蚀的材质。场景里能看到的距离要短，远处只用模糊的轮廓暗示。
• 宣传封面上的城市全景是题材概览，不代表玩家在雾里能看清整座城，也不是遗迹的路线图。
• 先让人看到脸和一件标志性的道具。黑色的衣料要有层次。不要为了“黑暗”把所有的脸都压黑，也不要让华丽的法术抢走线索和人物的注意力。
• 铁姑的雾蚀在她自己的左臂肘部以下，右臂正常。不要把“画面的左边”当成她的左边。那是局部半透明的灰雾，不是冰甲、雷电或机械义肢。
• 灰隼下潮时带的是遮光的、低亮度的潮石冷光，不是明火。城里安全地点的暖色灯火和探险装备要分得开。
• 小霜开局时的雾蚀只在指尖偶尔透光。齐老的双手半透明得更重。不要把所有人都画成同一种发光的法师，具体程度以角色卡为准。
• 用服装区分身份：公会的严谨，议会的旧权威，盐牙的实用和磨损，雾使的朴素。保留年龄和经历的差别，不要统一画成美型。

Emberback

• 这是一颗一面永远朝向太阳的行星。亮侧、暮光带和暗侧是空间上的分区，不是时间。不要套用“白天和夜晚换一片天”的模板。以后需要场景变体时，优先表现风暴、电力和通信的状态。
• 人物的识别点：Tomas 的搪瓷杯和电台，June 的围巾和车钥匙，Mina 的频谱仪。保留各人的年龄、肤色、脸形和职业姿态。
• 最能表达这个世界的是：中继站的陶瓷隔热件、反复修过的设备、模拟仪表、六轮爬行车和玄武岩地貌。没有用途的齿轮、装甲和太空服不是。
• 人物身边的维修间、车站坪和观测台是人物卡的一部分。它们不是给舞台用的透明素材，不要为了整齐把环境都抠掉。
• 明亮不等于没有危险。警报、损坏的设备、风暴的边缘和长长的影子提供悬疑，人物仍然是容易亲近的社区居民。

提灯古冢

• 保留这几样：灰苇村，北方的古冢，山顶熄灭的古灯，洞开的青铜墓门。阴冷潮湿的深秋、旧铜和暖色的油灯，是它和雾港的潮石冷光的区别。
• 六个人物保留角色卡上的年龄、身份和性格差别。伊索德是七十多岁的女性，雷恩是十九岁的见习祭司，布兰诺克是五十岁的老兵。
• 全身透明立绘用同样的画幅、相近的人物大小和同一个方向的光。头像和舞台立绘用的是同一张图。
• 地标图只表达已知地点之间大致的关系，不规定原文没有写的街道、距离或墓里的布局。灯廊点灯是一个可能发生的探索画面，不代表开局时灯已经点了。

出图和交付

1. 先读设定，再看现有的图。 读 WORLD.md、角色卡和 data/dimensions.yaml。清单里的提示词和现有图片矛盾时，要把矛盾改掉。只改了文字，不能算图片已经合格。

2. 新人物、新地点可以按清单生成。 清单里共用的画风描述只能减少画风跑偏，保证不了同一个人长得一样、同一个地点布局一样。

3. 已有人物的变体、已有场景的另一个时段，要以定稿的图为参考来改。 逐条写明哪些不能变。仓库里的批量脚本是纯文字生成，不会读参考图。

4. 尺寸。 人物图是 1024x1536，场景图是 1536x1024。透明立绘必须有真正透明的像素：只带一个全不透明的透明通道不算，把棋盘格画进图里也不算。

5. 格式。 立绘和场景只以 WebP 入库（有损，画质 90，透明通道无损）。生成脚本直接写出 WebP。用别的工具做的 PNG，用下面的命令转换，然后删掉 PNG。这需要本机装有 cwebp。

   node scripts/encode-world-webp.mjs <file.png>...

6. 逐张检查。 看原尺寸，看缩略图，分别放在浅色和深色的底上，看手机宽度下怎么裁，对照昼夜两张。图里不要有说明文字、水印或没校对过的招牌。必须出现的文字尽量交给界面去显示。

7. 替换定稿的图之前，留好原件或 Git 历史。 选定的图放进世界包之后，重新生成对应清单，见下一节。

本轮定稿的图里，有一部分是用“以图改图”的方式做的：遥风学园五组场景的夜图，以及雾港四张人物图的修正。它们完整的提示词和所用的参考图版本，记录在提示词记录里。

图片变了之后要刷新什么

立绘或场景的文件只要变了（重画、替换、重新压缩），对应清单里记的校验码就过期了，即使画面看起来一样。要重新生成：

node scripts/emit-presence.mjs mistport
node scripts/emit-scenes.mjs haruka-academy
pnpm validate:world worlds/emberback worlds/mistport worlds/haruka-academy worlds/lantern-barrow

校验全部通过时，每个世界输出一行：

✓ worlds/emberback/world.yaml
✓ worlds/mistport/world.yaml
✓ worlds/haruka-academy/world.yaml
✓ worlds/lantern-barrow/world.yaml

改的是内置世界时，再运行一遍图片资源的测试。它检查每个世界的每种语言引用的都是当前的图：

pnpm --filter @covel/server exec vitest run tests/lib/world-art-assets.test.ts

画廊清单 gallery.json 里也记着每张图的校验码和大小，同样要更新。

关于文件的几条规定：

• 立绘和场景只留 WebP。这两个目录下的 PNG 被 Git 忽略，不入库。
• 已经有损压缩过的 WebP 不要再压一次。要改图时，从没压缩过的来源重新转：生成的原图，或者 Git 历史里的 PNG。
• 画廊图片是例外：它保留 PNG 原图，旁边附一张同名的 WebP 用于展示。桌面安装包和 Docker 镜像不带画廊的 PNG，所以 gallery.json 里每一张 PNG 都必须写 webFilename。

封面

世界的封面由 world.yaml 里的两个字段声明：

cover: media/gallery/world-cover.webp
accentColor: "oklch(72% 0.15 350)"

accentColor 的格式和亮度范围见世界数据参考。加载时，无效颜色会被丢弃，世界照常加载，界面按世界 ID 生成默认强调色。pnpm validate:world 仍会把它报为错误，供作者修正。界面遇到不可用的已存颜色时也使用默认强调色。

• cover 是一张图片的路径，必须在 media/ 下的某一个文件夹里。界面直接显示这张图。世界包里的人物图更新了，封面不会自动跟着换。
• 不写 cover 时，界面用默认的背景。
• 封面和玩法相符、质量合格，就可以一直用。

开局之前玩家就会看到图

世界包里的图片在玩家进入游戏之前就已经展示出来了：

• 世界详情页列出全部图片。
• 有的界面风格把场景图和剧照轮播成全屏的背景，把人物图排在简介下面，点开可以看原图和介绍。
• 有的界面风格在封面的左下角显示几个头像和图片总数，鼠标停在封面上时轮播场景图。

所以每一张图都要能单独拿出来看，不要把半成品放进世界包。

展示哪些图、叫什么名字、怎么介绍，由下面的画廊清单决定。

画廊资料与前端使用

画廊是世界列表和世界详情里展示的那一组图片。它由世界包里的 media/gallery.json 决定。译文放在旁边的 gallery.en-US.json 或 gallery.zh-CN.json 里。

没有这个文件也可以。 这时画廊列出世界包里公开的图片文件夹（立绘、场景）中的图，按宽高比区分是场景还是人物，没有名字和介绍。写了 gallery.json，你就能决定顺序、分类和每张图的说明。

画廊和游戏里的立绘、场景是两回事。游戏里用哪张立绘、哪张背景，仍然由立绘和场景各自的清单决定。画廊不改变游戏里的任何状态。

画廊怎样使用这份清单

• 按清单里的顺序展示图片，最多 60 张。
• 有 webFilename 时展示它，没有时展示 filename。
• 只展示 spoilerLevel 是 opening 或者没有写这一项的图。画廊是在开始游玩之前看的，所以不展示会剧透的图。
• filename 和 webFilename 必须写成“media/ 下的一层文件夹 / 文件名”，例如 gallery/harbor.webp。别的写法的图不展示。
• 清单文件本身写坏了的时候，画廊不会空着，而是退回到“没有这个文件”的做法。

kind 决定一张图怎么用：

kind	用法
scene	场景图。会铺满屏幕轮播，裁切时上下各少一条
still	剧照。同上
map	地图或地标示意图。只完整显示，不参与轮播
portrait	人物图
hero	世界自己的封面图。应用里没有内置封面的世界（例如玩家安装的世界）用它来开场

每条图片记录的字段

字段	含义
id、kind	固定不变的标识，以及上表里的分类
name、description	展示的名字和一句简短的画面介绍
background	背景资料，要能在世界正文或角色卡里查到出处
storyContext	这张图适用于故事的什么情境，以及不应该从图里推断出什么剧情结果
location、visualNotes	有依据的地点，以及逐张看图确认过的视觉要点。人物卡可以不写
relatedCharacters	相关角色的 ID。写了不代表这个角色一定出现在画面里
depiction、spoilerLevel	这是人物像、设定插画、地标示意还是一个可能发生的片刻，以及它透露到什么程度
sourceRefs	世界包里原始设定资料的路径
filename、webFilename	相对 media/ 的图片文件，以及可选的 WebP 展示版
width、height、sha256、bytes	filename 那个文件的尺寸、内容校验码和大小
generation	可选的生成记录：用的工具、完整提示词、参考图。它不是给玩家看的背景资料

界面实际读取的是 id、kind、filename、webFilename、name、description、background、location 和 spoilerLevel。其余字段是给维护的人看的编辑资料。

写介绍时的规矩

• 主文件只写世界默认语言的文字。语言文件只写译文，用 id 和主文件对应。图片路径、角色 ID 和校验信息只写在主文件里。
• 设定类的字段必须能在原文里找到出处。原文没有写的，留空。不要用“合理的推测”去补人物关系、经历、年龄或剧情结果。
• 提示词里为了画面而写的构图、服装和长相，不能反过来当成世界设定的依据。
• 表情、服装和昼夜的变体分别介绍。不要从一个人的神态推断出关系或事件。
• 剧照以原有的角色立绘作为身份参考。不要把画里的活动写成已经发生的事。
• 已有的图片查不到可靠的生成记录时，不写 generation。不要把清单里的创作意图冒充成实际的生成记录。

内置世界现在有什么

四个内置世界的画廊清单一共有 54 条：

世界	条数	内容
遥风学园	25	十二张人物像（其中四张是变体），十张昼夜场景，封面，以及新增的文艺部场景和澪校稿的剧照
提灯古冢	11	六张人物像，首页外景，已知地标的示意图，酒馆、墓门和灯廊
雾港	10	七张人物像，封面，以及新增的近水通路和苏窈鉴定的剧照
Emberback	8	三张原有的人物像，封面，以及新增的两张人物像、第十七里和托马斯监听的剧照

其中 35 条是逐张复核过的原有素材，19 条是新增的。

• 原有的立绘和场景直接引用原来的文件，没有复制。
• 遥风学园、雾港和 Emberback 原有的封面被原样复制到各自的 media/gallery/world-cover.webp，world.yaml 的 cover 指向它。以后换封面时，要同时更新画廊清单里的校验信息。
• 提灯古冢的 cover 指向 media/gallery/lantern-barrow-hero.webp，也就是它的 hero 图的 WebP 版。
• 新增的横幅图是 1536x1024 的 PNG，各附一张 WebP。
• 地图适合完整显示。场景和剧照也尽量完整显示，裁切时要保住人物和关键道具。
• Emberback 封面上发光的波形是一种视觉意象，不是设定里的实物。

接口的说明见 API 参考里的 GET /api/worlds/:id/gallery，世界数据一侧的说明见世界数据参考。

接下来值得投入的美术

下面是还没有验证的建议。它们不是已经做好或者已经接入的内容。

世界	优先增加什么	怎样判断有没有用
遥风学园	澪、悠真、茜的克制的情绪变体，以及学园祭前夜的布置变化	玩家不看标签，能不能认出同一个人、情绪和祭典的进度
雾港	主栈桥、公会鉴定台、退潮入口这类线索插画。用潮位而不是昼夜来区分状态	玩家能不能看出调查的对象、安全的边界和撤离的压力
Emberback	信号维修间、爬行车站坪、Nightglass。用正常、断电、风暴将至来区分状态	玩家能不能看懂设备的状态和下一步能去哪里

建议的顺序是：先看不同兴趣的玩家选这几个世界时各自的理由，再看他们进去之后觉得是否和预期相符、愿不愿意完成第一个目标。审美上的判断代替不了这些证据。也不要为了凑齐同一套视觉小说素材的数量，去改变一个世界本来的玩法。

交付之前的检查表

检查什么	合格的样子
和设定一致	年龄、身份、道具、地点特征都和角色卡、世界正文相符。不变量逐条对过
同一世界统一	画法、色调、光的方向一致。人物的大小和取景相近
尺寸和格式	人物 1024x1536，场景 1536x1024，WebP。要求透明的图真的透明
小图也认得出	缩成头像后，还能认出是谁
各种底色	透明立绘放在浅色和深色的底上都没有白边或黑边
没有多余的字	没有水印、说明文字、乱码的招牌
清单是新的	改图之后重新运行过 emit-presence / emit-scenes，校验通过
目录干净	media/portraits/ 和 media/scenes/ 里没有留下 PNG

接下来

• 动手出立绘。 见给角色配立绘。
• 动手出场景图。 见给世界配场景图。
• 图片怎样导入一局游戏、怎样存储。 见世界数据参考和媒体库参考。