POLYSEA 七海征途·加勒比风云

游戏介绍

实机画面。这场混战由脚本布置并控制开火时机，舰船、炮弹、爆炸和炮台开火都是游戏本身的效果。

《POLYSEA 七海征途·加勒比风云》是一款以 1650 年加勒比海为舞台的航海策略游戏。英格兰与西班牙交战正酣，海盗四处劫掠，骷髅舰队在夜色中游荡。你可以为一国海军效力，也可以扯起黑旗当海盗：指挥舰队舷炮对轰、钩索跳帮夺取敌船，招募军官、安排舱室岗位，建设港口、开辟商路，探索群岛与沉船宝藏。

游戏特色

海战

每门炮各自装填、各自开火。六种火炮、四种炮弹，风向、射界、天气和视野都会影响战局。可以在俯视的海图视角指挥整支舰队，也可以切到船长视角亲自掌舵。

跳帮

钩索拉近、搭上跳板，战斗转到甲板上实时进行。29 种接舷战术，真刀真枪的白刃战，每个水手都是场上的一个人。

船员

船长与军官各有能力和技能，安排到合适的舱室，配上武器和宝物。军官靠岗位上的工作和立下的功劳积累经验。

港口与商路

六座港口建筑，城镇从帐篷长成宫殿和要塞。商船队沿航线运货赚钱，在港务厅任命总督和守军。

世界

四方势力、战争迷雾、天气昼夜、探岛寻宝、撒网捕鱼。未探索的海域是一张手绘羊皮纸海图，每座岛都按它真实的样子画出来。

联机

通过 Steam 和朋友在同一片海上并肩作战。

---

开发复盘

下面是这款游戏的开发记录，着重技术方案和解决问题的过程。

项目从 2026 年 9 月 23 日凌晨开始。第一次提交在 04:05，到 04:58 已经有了能开船、舷炮对射、接舷和进港的原型。之后一个月，C# 代码和 shader 由 Claude Code 编写，人负责定方向、试玩验收、挑选美术素材，并为声音把关。

本文的日期标注的是项目启动日，内容写到 2026 年 10 月 24 日的 v0.8.50。

先说结论

• 每次改动都要有基线。 海面在不到 23 小时里改了 36 个提交，最后整体回退。后来的规矩是一次只改一层，每一步都给出前后对比。
• 智能体看不见也听不见，验证手段决定质量。 画面靠截图和逐帧对比，声音靠响度测量，战斗靠自动演练。测不到的问题就修不好。
• 能量化的就量化，但要看样本量。 接舷战平衡跑了上百场模拟，其中一个 16 场得出的结论，换个随机种子就反过来了。
• 编辑器里通过不算通过。 有几类渲染问题只在打包后出现，后来专门加了打包版自检。
• 昂贵的效果放在需要它的地方。 真实波浪在俯视镜头下失败了两次，只放进低机位的船长视角后才成立。

用了什么

界面全部用代码搭建（uGUI），UI 目录有 19,076 行，是仅次于世界逻辑 World（23,328 行）的第二大模块。智能体改代码比在编辑器里拖控件可靠，改动也能在 git 里逐行看到。

时间线

海面：做了四遍，回到起点再往前走

水是这个项目返工最多的部分。游戏默认镜头在海面上方约 340 米，这个前提决定了后面几乎所有取舍，但我们是试错之后才真正理解它的。

第一版：扔掉 LOD 网格，海是一张大面片

9 月 25 日接入 Stylized Water 3 时，先用了插件自带的海洋 LOD 网格。它的每一圈 LOD 按各自的格距吸附，相邻两圈在接缝处重叠。海面是半透明的，重叠处的水画了两遍，于是浅水上多出一条横向色带，还会随镜头缩放移动。另一方面，我们的海是 unlit 卡通着色，网格带来的起伏几乎看不出来。

所以海改成一张大四边形，表现力放到上面一层自写的 SeaStrokes shader 里，之后逐步加进了这些内容：

• 波纹：两张法线贴图多尺度采样，朝不同方向漂移，按太阳方向算出卡通明暗带和细亮线；
• 遮罩：大尺度噪声让一片海比另一片粗糙，盖住平铺感；
• 闪光：朝向太阳的波面上一闪而过的小亮点，阴天、船影下和镜头太高时消失；
• 阴影：海本身不受光，船、帆和岛屿的影子由这一层画到水面上；
• 深度淡出：从深度图读水深，浅水处整层淡出，留出沙底和岸边泡沫。

第二遍：真实波浪，提交 13 分钟后回退

10 月 1 日试了真实波浪：800 米见方的水面网格跟着摄像机走，CPU 上算同一组 Gerstner 波，让船随之起伏。近看效果不错，但有三个问题：

• 短波在 3 到 4 米的网格上产生混叠，拉远后变成规则花纹；
• 波浪本身不明显，船的摇晃却又急又碎；
• 水面下降时，岸边的泡沫环偶尔露出礁石。

制作人的判断是这类问题会比想象中多，在有真正好的方案之前先不做。代码回退，只留在 git 历史里。

第三遍：换写实水体，23 小时后全部回退

10 月 12 日导入 KWS Water System 试用，同时试了 TENKOKU Dynamic Sky。后者只支持内置管线，在 URP 下什么都画不出来，还会抛空引用，当场淘汰。KWS 的数据很好看：在编辑器里以 2560×1440、RTX 4070 Ti 测量，GPU 只比我们的海多 0.3 到 1.7 ms，显存多 155 MB，CPU 没有变化。当晚就合入主线，设置里加了写实和卡通的切换。

上排是游戏默认的 340 米镜头，下排是低机位近景。左列是当时的卡通海，中列是 KWS 默认预设，右列是调成加勒比配色的 KWS。KWS 在近景明显更好，在游戏实际使用的高度上，优势就消失了。

接下来是一连串修补：

• KWS 的波浪是真实几何，波峰会盖住海面上的射程圈。所有海面标记改用一个 shader，让顶点沿视线抬高，抬高量跟随当前最大波高；
• 夜晚又平又暗。月亮在南边，镜头朝北，反光永远出不来，只能压暗水色、提亮泡沫；
• 动态波尾迹在 260 米范围、每米 4 像素的设置下像池塘涟漪，比例明显不对；
• 从 KWS2 切回 KWS1 后，编辑器一进 Play 就崩溃，报 d3d11: out of range sampler binding point。原因是着色器缓存坏了，挪走 Library/ShaderCache 后恢复。

同时还在卡通海上做风暴：白浪、碎浪、船头浪花、喷雾。试玩之后，制作人的结论有两条：KWS 从游戏高度看不如原来的卡通海；卡通海这边也已经被改坏了。

第一次回退只退到 KWS 之前，同一天加的白浪和泡沫都还在。制作人要的是 KWS 之前、所有海面工作之前的那片海。第二次回退到 v0.8.8 才算结束。从 KWS 合入到全部回退，不到 23 小时，36 次提交。代码保存在 tag 里，只留下三样东西：任何缩放下都细密的雨、缓慢的天气过渡、变慢的云隙光。

留下来的还有一组规则，每一条都是被否决过的方案换来的：

最后一条最值钱。智能体的眼睛是摄像机，摄像机放错了，再多截图也没用。这之后的海面问题都用跟船镜头录短片，抽 1/3 秒一帧的帧条来看。

第四遍：一次只改一层

从 v0.8.8 的海重新开始，规矩是一次只改一层，给出前后对比，别的都不动。

第一步处理制作人说的「海底的沙粒感」。逐层关闭后才定位到它：隐藏海底、把海底压低 25 米再压暗，画面都没有变化，所以不是海底；关掉 SeaStrokes 后纹路还在，说明它来自水体自己的法线贴图。这张图每 5 米重复一次，第二层的比例正好是一半，节奏非常规整。改成 12.5 米，第二层比例 0.37。

第二步是六边形平铺。改了 Stylized Water 3 的 Normals.hlsl 里的 SampleNormals：平面分成六边形，每格里的贴图各自平移和旋转，取最近的三格混合，于是看不到重复，也没有接缝。商店资产不进 git，所以改过的文件和原文件一起放在仓库的 ThirdPartyPatches/ 里，并写明重新导入插件后要把它覆盖回去。

船长视角：波浪终于有了位置

10 月 22 日加入了类似 World of Sea Battle 的船长视角：镜头贴到船后，WASD 直接掌舵。低机位下平的海立刻露馅，而标题画面的涌浪制作人一直很喜欢，于是只在这个视角里启用真实波浪：

• 摄像机周围一张 760 米、顶点间距 2 米的 WaterGrid，跟着摄像机走；
• 远处仍是平海，那张大四边形在此时变成中间开了方孔的环；
• 波高在距离摄像机 140 到 300 米之间淡出到零，所以网格边缘和平海严丝合缝；
• 船在 CPU 上用插件同一份 Gerstner 波形、同一个时钟和同一条淡出曲线算高度，缓动后跟着起伏。游戏规则仍然按平面海计算。

俯视镜头的海完全没动，10 月 1 日的三个问题也各有了答案：这个视角是低机位，不会拉到高处看到混叠；船的起伏经过缓动，不再抽搐；在主岛附近检查岸边，没有露出礁石。

但第一次打开船长视角时，波浪像开了快进一样狂奔。原因藏在两个系统之间：SeaMood 每帧修改海面材质的 _Direction，让花纹随风走；而插件计算波浪相位时，用的是这个方向乘以世界坐标。离原点几公里时，方向上极小的变化也会让波形滑动，在 2.5 公里外的船那里额外多出约 4.5 m/s 的速度，方向分量还把波形压扁了 1.8 倍。解决办法是这条规则：开了波浪的材质，_Direction 必须恒定。CPU 算高度时还要读全局的 _CustomTime，不能读 WaterObject.CustomTime，后者的 getter 一直是 -1。

雾也有类似的隐蔽问题。海面完全不吃雾，地平线像刀切的一样。查下来是插件 shader 的导入设置里，雾的集成方式被设成了项目并没有安装的 SC Post Effects，改成 Unity 雾后才对。这个文件夹同样不进 git，所以记进了笔记，重新导入后要再设一次。

海面上的标记

还有一个小而典型的问题。射界扇形要在多门炮重叠时不变深，用模板缓冲保证每个像素只染一次。最早用 bit 64，结果扇形在海面上完全不显示：SW3 的水会向每个像素写入模板值 65，占了 bit 1 和 bit 64。改成 128 后正常。后来又发现己方和敌方射界重叠时只显示先画的一方，于是每方一位：己方 128，敌方 32。

音乐音效：从代码合成到一条测量流水线

第一版：用代码合成

项目开始不到一天，SfxSynth 就能用代码合成炮声、爆炸、水花、雷声和雨声循环，不依赖任何素材。问题也很明显：智能体听不见，它能算频谱，判断不了好不好听。9 月 26 日换成素材包里的音效，按炮的重量分档。10 月 2 日玩家反馈海浪和大雨太吵，加了环境、战斗、界面、音乐四个声道和总音量。

把声音当成一个有需求文档的工种

10 月 5 日写了音效需求文档：185 个音效和 13 首音乐，每条都有编号、触发时机、时长、播放方式、变体数量、优先级（P0 到 P2）、当前状态和声音要求。交付规格也写死：WAV，44.1 或 48 kHz，音效单声道，环境声和音乐立体声，文件名 <id>_<n>.wav，不含听得懂的人声，为以后的多语言留路。

声音在这个项目之外按文档制作，第一批交付了 424 个 WAV，再由人逐条试听评审，结果存成 JSON。这里的智能体不判断音质，只接入通过评审的文件，再把文档里对应行改成「已接入」。

之后的音乐更新又加了一首，现在是 410 个文件。这些声音由 519 个 CC BY、CC0 和公有领域来源改编而成，经过剪辑、叠层、滤波、变速变调等处理。署名清单由脚本从素材表生成，随游戏发布，有 3,000 多行。人工维护这份清单不现实，而 CC BY 的署名是硬性要求。

响度：用 BS.1770 代替耳朵

智能体听不见，但可以测量。这是这一节里最有用的决定。Tools/Audio/audio_loudness.py 按 ITU-R BS.1770 测量每个文件，也就是广播行业用的 K 加权响度：

然后用一张表写下每个编号在游戏里应有的相对响度，例如舰炮 -18、重炮 -17、回旋炮 -21、按钮点击 -32、鼠标悬停 -40、海浪 -34、航海音乐 -32。脚本由此算出每个槽位的音量和同编号各变体的增益，生成 RecordedSoundTable.cs。

整张表锚定在炮声上：让录音版的炮声落在旧版炮声的位置，整体偏移 -4.8 dB，这样还没替换的旧声音在混音里的位置不变。测量结果按文件的 sha 缓存，下一轮只测新文件。之后每轮的流程固定成五步：复制文件、测量并生成响度表、导入、给新编号加触发点、更新文档。

音乐和环境声

Music.cs 有九种情绪：标题、白天航行、夜间航行、风暴、海战、接舷、港口、探岛、幽灵船。两个 AudioSource 交叉淡入，平时 2.5 秒，进入战斗 1 秒。

让音乐不烦人的是几条小规则：平静的曲目放完一遍后静默 25 到 70 秒再换下一首，紧张的曲目才循环；战斗音乐在最后一炮后再持续 12 秒；路过港口这种短暂变化要等 2 秒才切，避免来回跳；海战结束时放一段短乐句，同时压低背景。

Ambience.cs 负责环境声，由一组循环层组成：随天气变化的风、夜海、港口人声、岸浪、岛上的虫鸟、帆上的风声。每层按镜头所见的情况淡入淡出，海鸥、雾中钟声、阵风偶尔出现。提示音也要节制，比如发现敌舰帆影的提示音，25 秒内最多响一次，开局 5 秒内不响。

工程上的小坑

• forceToMono 每隔一次导入就翻转一次。导入代码根据声道数决定设置，而混成单声道的片段报告的就是 1 声道，下一次判断自然反了；
• 方法名叫 Start 并带参数，Unity 会把它当成生命周期函数，报 Start() can not take parameters。这类名字不能用；
• 宣传片要固定帧率录制，游戏的实时声音对不上。ClipRecorder 除了存帧，还把每个 AudioSource 的开始、音量变化和停止逐帧写进 sound.csv，再由脚本按日志重建音轨，做到帧级同步。

联机：一天改完架构

10 月 2 日的代码审计列出了 8 个障碍，比如：GameManager.player 和静态的 PlayerFaction 被引用 200 多处；isPlayer 约 150 处，同时表示「人类控制」和「本机控制」两个意思；暂停靠 Time.timeScale；接舷和登陆是单例；330 多处没有设种子的 UnityEngine.Random，船的运动依赖 PhysX 接触。最后两点直接排除了 lockstep，只能走房主权威加状态快照。

选型上用 Netcode for GameObjects 2.x，监听服务器模式，传输层自己基于 SteamNetworkingSockets 写。10 月 3 日先派 6 个只读智能体分头审计，把发现汇总成六个阶段的改造计划，然后逐个做完，当天 53 次提交。

做完的代价在后面。有代表性的问题有这些：

• 编辑器崩溃。 调试回调的函数指针交给了 Steam，脚本重载后 Steam 的线程调用了已释放的内存。现在只在打包版带特定参数时注册，并在重载前清除；
• Play 中重编译，NGO 消息表被清空。 现象是客户端连接被拒，日志里有 Allowed Count: 0。根因绕了一大圈：Steamworks.NET 每次域重载都自动添加 STEAMWORKS_NET 宏，而我们每次测试后用 git checkout ProjectSettings 清理设置，把宏删了，于是下次进 Play 又加回来并触发重编译。把宏提交进仓库后解决；
• 共用账户的竞争。 同一国家的两名玩家共用钱包和仓库。客户端的格子命令只带坐标，队友刚动过仓库时，就可能卖错东西。现在命令带上「我看到的是什么」，房主核对，不一致就拒绝并告知玩家。每种拒绝也都有明确提示，不再静默失败。

测试方式是编辑器当房主，打包版当客户端，走本机回环。客户端有一组命令行参数（如 -polysea-net-test），通过真实的游戏函数执行买卖、任命、接舷等操作。Tools/NetTest 下有近二十个场景脚本，每次网络格式变化都升协议版本，握手时还比较数值表指纹，两边数值不一致就连不上。

接舷战：用自动演练代替手感

10 月 15 日，接舷战改成单兵控制的实时战术。动画、寻路、士气、29 种战术道具全都要在甲板上真实生效，靠人手测不完，所以写了 BoardingRehearsal：在编辑器里连续跑随机战斗，记录死因、卡住的单位（附截图）、道具是否真的起效。原地跑步、滑步、人物重叠都做成计数指标，72 场以上的结果是：原地跑步 0，滑步 0，重叠 0 到 2 对，错误 0。

平衡也从这里开始。同样的双桅船、同样的人数，我方胜率是：对英格兰 75%，西班牙 94%，海盗 44%，骷髅 0%。而界面显示的战力四边全都约 430，说明战力公式没算进各阵营的武器和骷髅不会溃逃。修正后，用实测胜率校准战力系数，让自动结算和手动战斗的胜率一致：

这条曲线很陡。骷髅的生命系数从 0.7 改到 0.68 再到 0.65，我方胜率从 25% 变成 31% 再到 56%；人数少 4 个（24 对 28），32 场全败。

样本量的教训也来自这里。有一轮 16 场的结果是进攻 34%、防守 63%，看起来防守方优势巨大；换一个随机种子，变成进攻 56%、防守 38%。16 场不足以判断这种差异。

规模上，制作人定了一条规则：一个人就是一个小人，绝不合并。每方场上最多 64 名水手和 10 名士兵，其余作为预备队，减员到一定程度后每批 8 人上场，每帧最多生成 2 个，避免卡顿。优化后每个活人约占 0.1 ms，尸体不进逐帧循环，场上最多留 80 具。

羊皮纸海图：给随机地图手绘

未探索的海域是一张手绘羊皮纸海图。难点在于地图由种子随机生成，海岸线和建筑都不能预先画，每张图只能运行时生成：

• 地形。 顶视渲染一次陆地层，所有网格换成遮罩 shader，在水面下 1.2 米处裁切，再在 -8 米渲染一次得到浅滩。结果存成线性 RG16 贴图：R 是到海岸的距离（±48 米），G 是岩石高度或浅滩；
• 笔触。 shader 用这张场画岩石阴影线、沙岸点画和浅滩细点；
• 图案。 80 张小图（30 种建筑、14 种地形、36 个岛名母题）由一支小型 SDF 画笔在后台线程画进图集，约 1.7 秒；
• 摆放。 场景里的网格按名称分类，用并查集聚成一栋栋建筑，再换成对应的图案。

标签最初在主线程上花了约 6 秒，全部挪到 Task 里才解决。还有一个隐蔽的坑：数据贴图必须是线性的，早期用 R8_SRGB 时岛被画小了一圈。

只在打包后出现的问题

这些问题在编辑器里全部看不到。后来加了打包版自检：POLYSEA.exe -batchmode -polysea-autotest <dir> 跑一局，登陆战自检再渲染战斗画面，判断画面中央是暖色的地面还是蓝色的海。这项自检必须带图形启动，用 -nographics 读不到像素，会误报失败。

和智能体协作的习惯

• 测试和玩家共用存档。 测试至少四次覆盖过制作人的存档。现在进 Play 后先把 SaveSystem.OverrideFolder 指到测试目录，读回确认后才开局；
• 不在 Play 模式改脚本。 重编译会重置静态变量，包括刚才那个存档重定向。这条规矩写下来之后，我们仍然违反过；
• 测试后恢复项目设置。 Unity 会把测试时改的时间缩放和后台运行写回 ProjectSettings，测试结束后要还原，打包前要检查；
• 代码默认值不等于资产里的值。 改了 C# 里的默认数值，GameTuning.asset 里保存的旧值仍然生效；
• 决策写进文档。 大系统先出设计文档，未定项做成下拉选项，由制作人选择，文档就是规格；
• 踩过的坑写成笔记。 上下文会被压缩，笔记不会。到现在有 90 条左右，每条一个事实，包含原因和做法。

用量

会话从 2026-09-23 04:01（日本时间）开始，这里统计到 2026-11-01 写这篇文章时，包含主会话和 440 份子智能体日志。

按本站之前的算法折算（缓存读 ×0.1、缓存写 ×2、输出 ×5），总量约 21.3 亿 token。其中 Claude Opus 5.5 调用 34,992 次，Claude Sonnet 5.5 调用 4,491 次，Claude Haiku 5.5 调用 4 次。

做对了什么

• 保留回退能力。 每次大实验都留 tag，推翻一个方向的成本很低；
• 给每个系统做专用的验证工具。 接舷演练、联机脚本、打包自检、港口脱困测试，这些工具比任何一个功能都值；
• 用测量代替猜测。 响度、帧时间、胜率，都有数字可看；
• 把效果限制在需要的地方。 涌浪只在船长视角，俯视的海保持简单。

做错了什么

• 没有基线就连续改海面，改到回不去才停；
• 用固定镜头测运动问题，一个现象被报告多次才找到；
• 用 16 场的胜率下结论；
• 测试覆盖了制作人的存档，而且不止一次；
• 第一次回退时没确认「之前」具体指哪个版本，多回退了一轮。

接下来

• 逐个船级打磨数值和模型；
• 按纸面经济模型调整金钱曲线；
• 多语言：现在界面只有中文，新界面已经用语言中立的标记；
• 低配机型的战斗规模设置；
• 悬赏任务和酒馆情报的联机实测，以及差网络环境下的测试。这两项目前还没有做。

---

这篇文章由 Claude Opus 5.5 根据项目的 git 历史、代码和开发笔记写成，用量数字来自会话日志的直接统计。