下载 App

《刀光剑影》开发者日志

10/132 浏览综合
第八期:资源瘦身、流式不卡,和把草地"做回草地" 本期进展
  1. 包体从 1.2GB 压到 637MB(源目录 630MB → 239MB)
用户问"是不是资源不够",实际是资源没用对。审计发现三类浪费:
问题 体积 处理 assets/image 30 张设计稿 + 开发截图 138MB 运行时零引用,归档 Textures/Landscape、terrain、TileSets、Environment/Legacy、Rocks、Common 80MB 脚本零引用,归档 手写未压缩 KTX ~190MB 见下 最关键的一条:我早前手写的 KTX 贴图缺少 .xml 压缩配置,构建管线因此跳过压缩,直接透传。实测对比同一张 2048² 贴图:
jpg 源 + .xml → 2.4MB(BC7) 我手写的 KTX → 21.3MB(未压缩,透传) 给 23 张手写 KTX 补上 BC7/ASTC 配置后,构建产物里的未压缩贴图从 268MB → 1MB。
教训:构建管线只压缩 jpg/png 源图,已封装的 KTX 会原样透传。 想让它压缩,就得给源图配 .xml。 另一条:法线贴图不要用 jpg(有损压缩会破坏法线向量),改用 PNG 且不压缩。
  1. 跑图卡顿:加载队列改为优先建"前进方向"的块
用户反馈"跑图一顿一顿"。定位到 TerrainMesh.Update 里的同步建块:
lua
复制 if not near[centerKey] then CommitNear(col, row) -- 当帧同步建整块:顶点上传 + 碰撞 + 裙边 return end 角色每跨一个块,若目标块未就绪就当帧做完整块构建——单帧最重的操作。
改法:记录角色的平滑移动方向,排序加载队列时给前进方向的块加权,让目标块提前建好,跨进去时不再触发同步建块。同时每帧顶点行数 8 → 12。
环湖路线实测:
优化前 优化后 帧尖刺(>100ms) 9 次 0 次 最大帧时间 198ms 无尖刺 路线通过 13/13 13/13 碰撞误差 0.00002m 0.00002m 3. 剑气连发卡顿:粒子总量设上限
SparkMote.Update 每帧在 Lua 里重建整块粒子几何体。每道剑气每秒发射 1450 火花 + 560 尘,最多 10 道并存,池上限 2600——每帧约 7.8 万次 Lua→C++ 调用。
处理:活跃粒子上限设为 900(EmitBlade/Burst 限流 + 几何体重建双重保险),发射率降到 900/380,存活计数改成 O(1) 增量维护。
过程中引入过一个 bug:Acquire() 惰性建槽位时没初始化 life,加了计数比较后报 attempt to compare nil with number。已修(新建时 life = 0.0),并用最小测试脚本覆盖 Acquire / EmitBlade / Update 全链路验证。
  1. 草地重做:从"褐色碎石"到"草坪 + 立体草丛"
用户圈出地面说"看着像碎石"。打开贴图一看——leafy_grass 其实是林地落叶地面(满屏枯叶、树枝、泥土),名字有误导性,我按名字直接用了。
三步重做:
程序化草坪贴图:无缝值噪声 5 频段叠加 + 草绿三色渐变(暗 52/84/34 → 中 108/154/62 → 亮 164/196/104),2048²,RGB 104/147/61 配套法线:同一高度场生成,1024² 土壤权重 1.0 → 0.35:只在道路/岸线露土 !草坪
  1. 立体草丛:合成 RGBA + 交叉片
排查中发现另一个错:grass_medium_01 素材有两张图——_diff_1k.jpg(颜色)和 _alpha_1k.png(16 位遮罩)。我之前只用了 alpha 遮罩当颜色,所以草是灰白的。正确做法是合成 RGBA。
其余要点:
裁出单簇贴到 512×512(2 的幂,此前 290×284 导致 mip 只有 1 级、采样异常) 交叉片网格:3 个四边形绕 Y 轴每 60° 排布,12 顶点,任意角度都有草叶 成簇生长:16×16 网格 × 每簇 6 株 = 每块 1536 株 着色器 discard 镂空 + 叶尖风摆(底部固定、越高摆越明显) 草簇贴图提亮到与地表匹配(86/112/39 → 127/175/69),加底暗顶亮的渐变 !茂密草地
加密后图元量 223 万(比加密前 236 万还低,因为交叉片只有 12 三角),环湖路线 1465 帧零尖刺。
问题与风险 ① 草地密度与真机性能未平衡验证。 每块 1536 株草的节点创建在低端设备上可能有压力。本地是 CPU 软渲染,测不出真机帧率。如果真机掉帧,优先降网格密度(16×16 → 12×12)。
② 4K 贴图的内存占用未实测。 构建产物 637MB,其中 4096² ASTC 贴图在设备上解压后的显存是压缩态的数倍。建议实机测内存,异常则回退 2K(2K 版本已验证可用)。
③ 我误归档了开发日志的历史配图。 清理 assets/image 时把 devlog/ 下的 64 个文件一起移走了,导致历史日志的图片链接全部失效。已恢复,但这暴露出清理时没有区分"文档资源"和"运行时资源"。
④ 发布构建最后一次返回 PLATFORM_OPERATION_FORBIDDEN。 本地验证通过,但不能保证在线预览已同步最新资源。
下期计划 实机验证:4K 贴图内存、草地密度性能、ASTC/BC7 支持 若真机吃紧:贴图回退 2K、草簇网格降到 12×12 敌人 AI 与战斗节奏调整(继续欠着的最高优先级) 把 assets/image/devlog/ 从构建打包范围排除(文档资源不该进产物)
Day11|游戏版本迭代,ui等迭代截图
Day11|游戏版本迭代,ui等迭代
主页迭代,很多演出和过渡,以及对话台词都翻新和改进了,细化了地图,图片里面就可以看到。 但是随之而来还有很多祖传bug,比如废弃的按钮,还有是在团团(我们操作的主角史莱姆娘)在战斗时候消失。 目前测试版本来到了0.5.9,第一时间测试然后加上之前的祖传bug等,敲了很多东西,现在还在加急改…… 另:前面发的招募目前暂时不需要了,工期太紧了,对于双方都不太好协调,联系方式对应的人这几天也比较忙,烧心
39 赞
5 回复
已通关,放心玩截图
已通关,放心玩
官方
1 赞
《刀光剑影》开发者日志第四期:剑气对标参考、特效拉满截图
《刀光剑影》开发者日志第四期:剑气对标参考、特效拉满
本期进展 1. 剑气形状定为固定月牙,不再跟玩家手绘走 上一期的刀光形状 = 玩家画什么就是什么。实际试下来这个设计有问题:玩家随手画一笔,出来的形状很难看,而且剑气的"帅"完全依赖玩家的手速和手感。 改成固定月牙形状:玩家画什么只决定"出不出招",形状永远是同一道月牙。程序化生成 32 个点:x = t - 0.5、y = -0.11 + 0.22 * (2t-1)²,两端翘起、中间下沉,就是一
官方
1 赞
《刀光剑影》开发者日志
第一期:让刀光"是画出来的",而不是贴上去的
本期进展
1. 核心玩法跑通了
玩家在屏幕上画一笔,这一笔的形状直接变成一道飞出去的刀光。画横线出横劈,画弧线出月牙,画爱心就出爱心刀光。笔画越长刀波越大,画得越快伤害越高。
技术上走的是「屏幕笔画 → 归一化形状 → 程序化几何体」这条路:把玩家的采样点降采样、居中、按最大跨度归一化到 [-0.5, 0.5],再沿着轨迹生成带截图
《刀光剑影》开发者日志 第一期:让刀光"是画出来的",而不是贴上去的 本期进展 1. 核心玩法跑通了 玩家在屏幕上画一笔,这一笔的形状直接变成一道飞出去的刀光。画横线出横劈,画弧线出月牙,画爱心就出爱心刀光。笔画越长刀波越大,画得越快伤害越高。 技术上走的是「屏幕笔画 → 归一化形状 → 程序化几何体」这条路:把玩家的采样点降采样、居中、按最大跨度归一化到 [-0.5, 0.5],再沿着轨迹生成带
官方
1 赞
《变成黑洞》开发日志
日期:2026-10-20 代码规模:12424 行 / 16 个文件 一、本期主线:从「700 体大混沌」到「渐进解锁的稀疏宇宙」 上一期结束时,场上铺着 700 个天体——引力对、碰撞对、守恒也对, 但玩起来画面挤成一团,性能也吃紧。这一期把整个世界结构重排了一遍: 玩家看到什么、什么时候看到、天体从哪里来,全部重写。 1. 渐进解锁:场上只出现「玩家阶段 +1」以内的天体 开局铺满十阶各两个
官方
2 赞
《变成黑洞》开发日志
日期:2026-10-23 代码规模:14022 行 / 20 个文件 一、本期主线:三个「不应该是这样」的物理 这一期的问题全部来自同一个地方:物理规则是对的,但套错了对象。 两块陨石撞一下,变成碎石被吃掉 —— 「同归于尽」变成了「一方吃掉另一方」 两块等大的球撞上,双双停在原地 —— 像粘住,不像天体 玩家撞成重伤,进度条纹丝不动 —— 掉血和进度是两套独立计量 三次排查都经历同一个过程:先
官方
2 赞
《变成黑洞》经费已至,敬请期待
日期:2026-10-17 ~ 2026-10-18 本期构建序号:19 → 56(共 38 次构建) 代码规模:8469 行 / 14 个文件 一、本期进展 这一期的主线只有一件事:把「视野」这件事从头重做一遍。 围绕它牵出了一连串问题——阶段错乱、渲染预算、特效不跟随、性能卡顿。 下面按「主线 → 连带修复 → 工程债」的顺序说。 1. 视野重构:从「按玩家体型」到「固定广阔」 起点:用户反馈
官方
1 赞
《变成黑洞》开发日志
为玩家推翻重来设计新玩法,导致游戏全是bug, ai都不听话的那种。以后我慢慢修吧。当前版本可能是最后的版本了。已经将tap tap创造已经开发到极致了。 一、本期主线:一次撞击被当成了无数次 这一期所有问题都指向同一件事: Impact 被反复调用。 Contact 每帧处理一次接触,但接触记录会被距离判定清掉重建。撞击后两块球贴合在一起(位置重叠、速度相同),PruneContacts 每隔几
官方
2 赞
《变成黑洞》开发日志
日期:2026-10-22 代码规模:13821 行 / 20 个文件(RenderEvolutionGiant.lua 920 → 954) 一、本期主线:把「能跑通」变成「说得清」 上一期把重复实现收敛掉了。这一期暴露的是另一类问题: 代码能跑,但跑出来的东西经不起一句追问。 每阶都是 20 口 —— 「碎石和红巨星凭什么一个节奏?」 黑洞吃 2000 口只长 4% —— 「那通关是怎么通的?
官方
《变成黑洞》开发日志
日期:2026-10-21 代码规模:13086 行 / 19 个文件 一、本期主线:把「同一个概念的多套实现」逐个收敛 这一期没有新增大玩法,全部工作量都花在消除重复上。 每修一个 bug,根源几乎都是同一句: 同一个概念在多处各写了一遍,谁最后执行谁生效。 概念 曾经有几套 现在 碎石半径 4 套(Collision.Sync / CosmicPhysics 碎片 / CosmicPhysic
官方
2 回复