交出来的东西 GameJam 结束时，《绿洲涌现》的规模：数量 游戏逻辑代码 约 6,300 行 Lua 模块数 20 个（含 4 个联网后台模块） 测试文件 24 个 断言调用点 867 处（运行时按数据展开为上万条检查） 已开放章节 2 章（锁住流沙 / 以水定绿） 功能上，玩家可以做这些事：铺草方格固定流沙，种梭梭、柽柳等乡土灌木 让植被连成上风向防护带（2 格链 = 强防护，1 格 =
《绿洲涌现》开发日志 · 第 4 篇一个反直觉的决定：不做教程游戏有固沙、种植、防护链、水预算、天气、洪水、养殖、章节验收……一套下来十来个系统。常规做法是做一个教程关，一条条教。我们没做。原因是：治沙本身就是"慢慢发现规律"的过程。 如果开局就把所有规则糊在玩家脸上，那种探索感就没了。替代方案是章节引导 + 逐层揭示。引导系统：只推下一步界面上永远只显示"现在该做什么"，而不是"全部
《绿洲涌现》开发日志 · 第 3 篇让"有限"真的有限"以水定绿"是治沙领域的一句行话：绿化的规模，要适应当地水资源的承载力。种得多不等于种得好——水供不上，苗全得死。设计上最难的一点是：怎么让玩家真的感到水是有限的？如果水只是一个缓慢增长的进度条，玩家很快就会忽略它。我们试过几种方案：方案 问题水无限，只限制种植速度 失去了"定绿"的核心张力水会枯竭，用完就 Game Over 太
警报：Simulation.lua 到 1000 行了第 1 篇结尾提到，D6 结束时核心模拟文件已经超过一千行。当时的 Simulation.lua 什么都管：地块状态、水资源预算、天气推进、洪水、养殖试点、章节验收、存档校验——全塞在一个文件里。这不是"能跑就行"的问题。真正的问题是：改任何一处都可能踩到别处。举个当时真实发生过的 bug：我调整了水预算的计算顺序，结果章节验收的"全年非
治沙功在当代利在千秋，我认为值得做一个游戏让更多的人知道。它慢。一块草方格铺下去，要等风沙停下来，等灌木扎下根，等一个季节过去，才能看到一点点变化。它也不爽——没有一击必杀的快感，没有数值暴涨的反馈，甚至连"赢"都很难定义：把沙漠变绿不是目标，守住绿洲的边缘才是。但正因为这样，它才值得做。GameJam 开始时我们定的第一条设计原则就是：不做"征服沙漠"的爽游，做"守住一条线"的经营模拟。这
