下载 App
开发者日志 05 · 六天之后 《绿洲涌现》
交出来的东西 GameJam 结束时，《绿洲涌现》的规模：
数量 游戏逻辑代码 约 6,300 行 Lua 模块数 20 个（含 4 个联网后台模块） 测试文件 24 个 断言调用点 867 处（运行时按数据展开为上万条检查） 已开放章节 2 章（锁住流沙 / 以水定绿） 功能上，玩家可以做这些事：
铺草方格固定流沙，种梭梭、柽柳等乡土灌木 让植被连成上风向防护带（2 格链 = 强防护，1 格 = 半防护） 管理有限生态水：供需缺口、养护储备、承载上限 应对沙尘暴（预报→准备→发生→恢复）与上游来水 建光伏治沙园、节水滴灌站、乡土育苗圃、固沙施工队 第一章验收后解锁封闭循环养殖试点 两章章节验收，云存档 + 排行榜 + 平台能力接入 做对了什么
- 先定原则，再写代码。 "不做征服沙漠的爽游"这条原则，帮我们砍掉了至少五个看似更"好玩"的方案。没有它，项目会滑向一个平庸的资源点击游戏。
- 测试当作重构的许可证。 24 个测试文件让我们敢动 1000 行的核心文件。多次重构（拆模块、改字号、改布局）都是靠回归测试兜住的——最近一次改动跑了 6,512 条地图几何断言全绿。
- 数据驱动配置。 Config.lua 集中了所有数值（季节长度、水耗、天气间隔、章节门槛）。调整平衡不用改逻辑代码，这也是第二章能快速做出来的原因。
做错了什么
- 字号一刀切。
中期玩家反馈"文字太小"，我们做了一个粗暴的决定：把全界面字号下限统一提到 14。结果引发一连串布局问题——文字撑破容器、卡片重叠、地图被挤小。
最后不得不回退：允许部分文本降到 12，并对密集区做分级（主信息 14 / 标签 12）。教训是：可读性不是单一数字，是"信息层级"。 所有文字一样大，等于没有层级。
- 一个渲染 bug 藏了很久。
底部通知条塌缩成一条绿色空框（面板自动宽度 + 子级 width="100%" 循环塌缩）。这个 bug 其实一直都在，只是不常触发。玩家截图报上来才被发现。
教训：“看起来正常"不等于"渲染正确”。 后来我们给这类浮层补了尺寸断言。
- 对"平台能力"的定位一开始是模糊的。
项目开启了服务端后台（云存档、排行榜、GM），一度让人误以为这是联网游戏。实际上玩法是纯单机的，服务端只负责身份、云档和授权。如果早点把这条边界写清楚，沟通成本会低很多。
如果重来 第一天就建立视觉规范（字号层级、间距、圆角、颜色），而不是最后统一改。 浮层类组件一开始就加尺寸断言，别等玩家截图。 把"这是单机游戏 + 云能力"写进 README 第一行。 想说的话 做这个游戏的过程中，我们反复回到同一个问题：怎么把一个很慢、很安静的过程，做成能让人愿意花时间的事。
真实的治沙没有一键变绿。先铺草方格让流沙停下来，再种下乡土灌木靠时间扎根。水是有限的——"以水定绿"说的不是能种多少，而是这片土地能承载多少。
游戏里引用的那条绿色防护带，在 2024 年 11 月实现了锁边合龙，全长 3046 公里。它不是把整个沙漠变绿，而是给绿洲守住了一条边界。
这也是我们想借这个小游戏说的话：守住一条线，比征服一片沙漠更值得。
愿你在沙盘上，种出属于自己的一抹绿。
