用Godot开发登月着陆模拟游戏：物理模型、着陆判定与调试全记录

直接进入主题——我最近放下的“Apollo-11”项目，是一个登月着陆模拟小游戏。

大概说一下它是干什么的：玩家不需要操控真实火箭的复杂过程，只需要控制一架登月舱，在月面找一个合适的位置，在有限的燃料里完成减速、调整姿态，最后以足够慢的速度触地。项目代号叫 Apollo-11，纯粹是因为“降落月球”这个点子天然有仪式感。它不是正经航天工程，也不打算拿来做航天科普，就是一个轻量的、偏手感向的着陆模拟，目标用户是想在三五分钟内体验一把“驾驶舱里心跳加速”的人。

这个项目本身不难，但真正做完一轮之后，我发现坑全藏在那些不会被浆糊涂表情覆盖的细节里。从物理模型怎么搭，到着陆判定怎么设计，再到调试时被各种“伪着陆”骗到怀疑人生，每一步都值得展开聊。这篇文章我按实际开发顺序来写，希望能让想复刻同类游戏或者正在做体感模拟的人都少走点弯路。

1. 这个项目是怎么定义的：一个“致敬登月”的轻量着陆模拟

1.1 从标题到需求：Apollo-11 到底做什么

先别急着想代码。我拿到“Apollo-11”这个标题的时候，第一反应不是“我要做一个大工程”，而是先想清楚这个标题在玩家心里的第一印象是什么。

登月舱着陆，人们最期待的部分其实不是“精准的物理仿真”，而是那种“一脚踩空就没了”的紧张感。所以需求层我就只留了三个核心体验指标：

• 玩家必须能直观感觉到“速度太快”“倾斜太多”“燃料不够”三种危险。
• 一次完整游戏控制在3到5分钟，失败不心疼，成功有记忆点。
• 操作要简单到只用键盘上的两个键都能玩，但难度上限要足够高。

基于这三点，我把项目剪裁成了一个“推进器管理 + 姿态判断 + 燃料资源管理”的小型模拟器。不追求真实遥测，不引入轨道力学，只保留竖直方向的重力、横向漂移、推力矢量，以及最关键的触地判定。这样做的原因很现实：在有限周期里，与其做一堆表面炫酷但不产生玩法深度的系统，不如把一条最核心的体验链做扎实。

1.2 演示形态与目标玩家

Apollo-11 最终做出来的形态是竖屏网页小游戏，左侧是登月舱，下方是月面，右上角有一个燃料表，右下角是速度/高度读数。玩家按空格键或上箭头推进，左/右方向键负责微调横向推力。目标平台是桌面浏览器，所以我没有接入复杂的手势系统。

这个形态对当时的开发节奏是合适的。网页分享方便，不需要安装，而且 Godot 3D 导出到 Web 的质量足够支撑这种低面数月球场景。目标玩法受众我自己心里是这么分的：轻度玩家负责“按空格按得开心”，硬核玩家负责挑战“最低燃料成功着陆”。这两种需求在同一套物理参数里是可以共存的——前提是你别把燃料值设得太慷慨。

我非常推荐其他做这类项目的开发者，在动工前先用一段话把“玩家体验目标”写下来。哪怕这段话后来不执行也行，因为后续所有取舍都会回到这句话。没有它，你会非常容易在“要不要加云层”“要不要加陨石坑碰撞”这种问题上反复纠结。

2. 最核心的物理模型：推力、重力与燃料都怎么算

2.1 轨道矢量和受力模型

Apollo-11 的物理其实只写了一小段自定义加速度计算，没有引入现成的空间物理引擎。很多人觉得做飞行动力必须上物理引擎，实际上绝大多数着陆模拟的控制核心，就是下面这个公式：

[ a_{net} = a_{thrust} - g_{moon} ]

因为我做的是 2.5D 视角，登月舱只在竖直平面内运动，所以我直接操作CharacterBody3D的velocity就够用了。月球重力选 (1.62m/s^2)，推力最大加速度按引擎能力设为 (3.0m/s^2)，这样玩家满油门时净加速度约 (1.38m/s^2)，既能让飞船上升，又不会出现一碰按钮就窜出屏幕的失控感。

GDScript 核心逻辑大致是这样：

extends CharacterBody3D const MOON_GRAVITY := 1.62 const MAX_ENGINE_ACCEL := 3.0 const FUEL_BURN_RATE := 4.2 # 每秒消耗量 var fuel := 100.0 var engine_power := 0.0 # 0.0 到 1.0 之间 func _physics_process(delta: float) -> void: if fuel > 0.0 and engine_power > 0.0: var thrust_accel := MAX_ENGINE_ACCEL * engine_power velocity.y += (thrust_accel - MOON_GRAVITY) * delta velocity.x += horizontal_thrust() * delta fuel -= FUEL_BURN_RATE * engine_power * delta else: velocity.y -= MOON_GRAVITY * delta move_and_slide()

要特别提醒的是：这里用_physics_process而不是_process。体感模拟和判定类代码如果跑在主进程里，帧率波动会直接改变每次迭代手感，60帧和120帧玩起来完全两回事。用物理进程后，delta 固定，逻辑稳定，后续调试难度会低很多。

2.2 推力输入为什么设计成“油门+方向”两段式

我当时先写过一个原型版本，推力是“按一下就是满油门，松手就是零油门”。手感极其糟糕——玩家只能在“完全开火”和“完全关火”之间来回抽动，任何微调都是不可能完成的。这个在真实现场里其实有个对应场景：登月舱发动机并非只有开关两态，而是可以通过油门做连续调节。

所以我把输入改成了两段式：

• 油门响应：按住主推力键后，发动机功率不是瞬间拉满，而是每秒向目标功率逼近，压迫感就有了。
• 横向微调：左右方向键控制一个较小的侧向分量，侧向最大推力只有竖向推力的四成。

这样一来，玩家的操作开始有“姿态”概念。早期版本里横向推力和竖向推力一样猛，结果玩家稍微偏一下方向键，舱体就会横着飞出屏幕，非常出戏。缩小侧向推力后，横向漂移变成了可控的惩罚机制。

代码里我用一个lerp做油门缓冲，避免数值突变：

engine_power = move_toward( engine_power, target_power, ENGINE_RESPONSE_SPEED * delta )

ENGINE_RESPONSE_SPEED我反复试过，取2.2左右手感最稳。你如果之后做类似项目，强烈建议把这个值暴露成可调试参数，因为它直接影响“操作反馈是否跟手”。

2.3 参数表：一版直接能跑通的落地配置

为了节省读者反复调参的时间，我把项目第一次跑通用的核心参数列在这里。这个表不是最佳值，而是“能玩、难度适中、适合新手起步”的基线。真正上线前需要根据目标受众再校准。

从这个表可以反推一下玩家体验流程：开局看到 180 米高度和 -18 m/s 速度时，第一反应肯定是按住油门。此时燃料以每秒 4.2 的速度消耗，如果不控制油门，撑不过 24 秒。减速到接近悬停需要大约 5 秒，这就构成了“有资源压力但不至于一上来就劝退”的节奏。

3. 着陆判定与“失败体验”：从碰撞瞬间到状态机

3.1 着陆结果是怎么分级的

着陆模拟的核心是“判定成功或失败”。这个判定并不像很多人想的那样是无条件的“脚碰到地面就算成功”，而是先判断触地瞬间的系统状态，再决定玩家看到的是哪种结果。

我最终做了三档结果：

• 完美着陆：竖直速度 ≤ 2.0 m/s，水平速度 ≤ 0.6 m/s，机翼倾角 ≤ 5°。
• 勉强着陆：竖直速度 ≤ 4.0 m/s，但不在完美范围内，播放一声硬着陆音效，不判定失败但会有警报。
• 坠毁：竖直速度 > 4.0 m/s，或水平速度 > 1.5 m/s，或倾角 > 20°。

这里多说一句：为什么要分三档而不是“成功/失败”两档？因为两档判定太硬，玩家会很快摸出容错边界，然后不断在边界上试探，玩起来像考试。三档判定能制造“我好像还可以”的模糊感，玩家会因为“差一点就完美了”而重开，第二局就会开始思考正确的减速策略。

判定的核心逻辑放在_on_body_entered里，配合一个landing_state枚举：

enum LandingState { FLYING, PERFECT, HARD, CRASHED } func _on_body_entered(body: Node) -> void: if landing_state != LandingState.FLYING: return var vertical_speed := absf(velocity.y) var horizontal_speed := absf(velocity.x) var tilt_angle := absf(rotation.z) if vertical_speed <= 2.0 and horizontal_speed <= 0.6 and tilt_angle <= 0.09: landing_state = LandingState.PERFECT elif vertical_speed <= 4.0 and horizontal_speed <= 1.5 and tilt_angle <= 0.35: landing_state = LandingState.HARD else: landing_state = LandingState.CRASHED

倾斜角这里用了弧度值，写的时候要小心不要和度数混着用。0.09 弧度大约是 5.16°，0.35 弧度约等于 20°。我早期版本写错过一次，把角度当成弧度传进去，结果怎么落都判定成功，调试时人都懵了。

3.2 碰撞判定后，状态机做什么

着陆判定只是“状态机的触发条件”，真正决定游戏接下来往哪走的是状态机。整个游戏只有四个状态：航行中、完美着陆、硬着陆、坠毁。

状态触发以后，最重要的事情是立刻冻结控制权。很多人做失败反馈时只弹了一个“Game Over”文字，登月舱还在原地抖动、喷火星，这会让玩家产生“我是不是还能救一下”的错觉。Apollo-11 的做法是：无论命中哪个终态，马上把engine_power置零，停止所有推力输入响应，同时让登月舱的碰撞体进入待机状态。

我还做了一个小细节：终态判定的瞬间，舱体颜色会变化。完美着陆时舱外灯是冷白色，硬着陆是黄色，坠毁是红色。颜色反馈比文字弹窗更直觉，玩家在远处扫一眼就知道上一把是什么结果。

状态切换的顺序也值得注意。_on_body_entered信号触发时，物理系统还在处理本次碰撞，所以不能在回调里直接调用queue_free()把节点删掉，否则下一条判定逻辑就断了。我的做法是设置一个outcome_processed标志，在之后一帧的_physics_process里再做场景切换或定格处理。

3.3 撞击后的镜头表现：让失败也有“手感”

坠毁动画我没有做大爆炸特效，只做了两件事：舱体轻微上弹、然后单轴旋转。原因很简单——Apollo-11 是仰视角模拟，如果舱体真的四分五裂，反而遮挡视线，玩家根本看不清是怎么坠毁的。轻微回弹既保留了触感反馈，又不会干扰玩家复盘。

硬着陆时我会额外触发一次 HUD 闪烁，并在屏幕边缘加短暂的红色暗角。这个暗角持续 0.8 秒，之后消失。它不构成惩罚，只负责给玩家一次“刚才很危险”的生理反馈。

对于想复刻这套判定的读者，我建议从这样朴实的状态机开始，不要一上来就加爆炸粒子和镜头震动。先确保“触地瞬间判定”这件事绝对可靠，再讨论表现层。否则你调了半天效果，发现判定本身就有问题，等于白做。

4. 踏上月球之前：调试过程中最离谱的四个坑

4.1 “永远判定成功”的倾斜角单位问题

前面提到过一次，但我还想单独拎出来说，因为这个 bug 太隐蔽了。在 Godot 里，节点的rotation属性默认单位是弧度，而我早期在判定代码里直接写tilt_angle <= 5.0，心想这是“5度”。结果这个条件永远成立，因为实际机体的倾斜角只有 0.1 左右。

看起来小事，但亲测后果很严重：任何角度下着陆都会判定为完美，玩家辛辛苦苦斜着怼到地面也能拿到“完美着陆”。这类 bug 不是看代码能察觉的，只能靠测试时故意制造错误操作来暴露。

我把排查这类问题的方法固化成了一条自查列表：所有角度相关参数入判定前，统一换算成弧度；所有速度相关参数入判定前，确认是m/s而不是km/h。这类单位问题在模拟类项目里几乎必然出现，提前定好换算规则能省大量时间。

4.2 燃料表倒数的“视觉误差”

燃料表一开始是直接绑定一个ProgressBar，数值等于fuel。我后来发现玩家在紧张操作时根本看不清具体的条状剩余量，只会盯着数字疯狂跳动。而且因为每秒 4.2 的消耗速度，数字每秒跳 4 个小格，视觉上显得“特别脆弱”，玩家压力值拉满。

后来我把燃料显示改成“三段式”：绿色区、黄色区、红色区。当燃料低于 40 时数字跳动会让位给颜色切换；低于 15 时则出现一次持续低频报警音。这样既保留了精确数字，又用颜色信息承担了大部分感知任务。

再往后我还做了一个更隐蔽的设计：燃料表的读数每帧只刷新一次，避免小数位疯狂跳动。你可以理解为“尽力让人看清”。这个细节对新手友好度提升非常明显。

4.3 物理缩放：单位世界里一米到底有多长

Godot 自带的一套物理单位浮点精度在某些尺度下会出问题。Apollo-11 场景里的物体最小的是螺母级别，最大的是月面整片网格，尺度跨度其实不大。问题出在“速度数值”和“视觉效果”的对应关系上：我一开始把高度设为 800，结果玩家开局看到的就是一片深空黑，根本分不清自己离地面还有多远。

经过多轮调整，我把场景尺度锚定在“一单位约等于一米”，初始高度 180 米。同时我在月面上铺了一层非常大的网格参考线，网格大小为 10 米一格，速度感一下子就出来了。调试时不要信概念数字，要开一个摄像机视口从玩家角度去看这些值是否合理。

另一个细节是灯光。模拟月面时，我原以为环境光需要调得很暗才显得真实，结果测试发现玩家连地面都看不清。后来我把主光方向调成从舱体后上方照过来，既还原了登月那种“背后光源”的氛围，又保证了舱体轮廓清晰可辨。好的视觉不是“更暗更真实”，而是“信息完整且氛围到位”。

4.4 “差一点就成功”的悖论

这个坑和代码无关，纯粹是玩法设计问题。我做过一个版本，完美着陆的阈值非常宽，只要速度在 5m/s 以下都算成功。结果玩家反馈出现了一个奇怪现象：大家不追求平稳落地，而是在离地三四米时直接关掉引擎，让舱体砸下去，利用“只要没超过 5 就是成功”的判定暴力通关。

这让我意识到，宽松的着陆阈值并不会带来舒适体验，反而会让玩家的行为模式偏离设计意图。玩家会很快找到并利用规则的边界。最终我把完美阈值收紧到 2m/s，这才让“慢下来、摸清推力响应”成了最优策略。

这事给我的长期经验是：着陆模拟的判定阈值不是一个“技术参数”，它是一个玩法规训工具。阈值设在哪，玩家就会把操作风格训练成什么样。想清楚这一点再改参数，比盲目追求手感更稳妥。

5. 还是这些边角料：配置、界面与后续扩展

5.1 用配置文件把难度和手感分离开

Apollo-11 的参数越调越多以后，我发现直接在脚本里改const已经非常痛苦：每次调完重力、燃料、阈值，都得重新导出测试，而且容易记不清上次组合是什么手感。

于是我抽了一个独立的landing_config.tres资源配置，把所有可调参数放进同一个文件。难度切换、手感调整都可以直接改资源，甚至可以在同一局里动态读取。实际开发里这是性价比极高的一步，因为你早晚要在“测试参数A”和“测试参数B”之间来回横跳。

配置建议至少包含这些分组：

• 环境参数：重力加速度、参考面尺寸、初始高度。
• 飞船参数：最大推力、响应速度、侧向比例、燃料上限、消耗率。
• 判定参数：完美阈值、勉强阈值、倾角限制。
• 展示参数：燃料表分段阈值、警示音触发阈值。

5.2 界面上最重要的三个信息：速度、高度、燃料

很多同类模拟游戏会把遥测数据显示得非常复杂，参差不齐的专业指数玩家根本不看。我的取舍是：只保留速度、高度、燃料三组数字，用不同字号强化主次关系。速度最大，因为它是玩家实时判断的核心；高度其次；燃料最小，但旁边有进度条辅助。

界面排布我做了三版才定下来。第一版是全部堆在底部，但是屏幕下缘信息太多；第二版把燃料放在右上角，独立显示；第三版才确立了现在的布局：右上角燃料，左下角高度速度。左下角之所以顺眼，是因为玩家视线会自然从登月舱延伸到地面，速度数字落在视觉动线末端，不需要额外移动眼球。

字体的选择也有讲究。模拟感强的等宽字体比较合适，但如果是普通玩家偏多的场景，建议还是回归无衬线字体，方便快速辨认。速度数字如果刷新太快，人眼会被干扰，所以我对速度小数位做了四舍五入到一位，保留紧张感又不至于糊成一团。

5.3 后续可以拓展的方向

这个项目做完核心闭环之后，我其实还留了几个扩展方向，暂时没全部落地。如果你之后想以 Apollo-11 为底做进阶，可以考虑以下路径：

• 增加时间刻度：开局可以选“快速降落”或“慢速巡航”，改变燃料消耗和判定手感，让同一套核心玩法覆盖更多玩家。
• 引入风向扰动：在较低高度随机加入横向力脉冲，让“完美着陆”更稀有，适合竞速玩法。
• 对接排行榜：用燃料余量作为得分主轴，鼓励玩家追求“极限省油着陆”，这样每次重开都有明确驱动。
• 增加任务模式：在月面不同坐标布置观测点，玩家需要按照顺序完成多次着陆，比单次挑战更有故事性。

我个人其实最推荐第一个方向。它不增加任何新系统，只是把现有参数按难度档位重排一遍，但很容易把游戏时长拉到一个更耐玩的高度。资源消耗小，价值转化直接。

最后留个自己的体会

这几轮开发下来，我对“Apollo-11”这个项目的最大感触其实是：它看起来像一个物理仿真项目，真正难的地方却在天平的另外两端——一端是设计判定规则，另一端是把规则变成玩家能直觉感受到的反馈。代码里的每一处常量背后，都连着一次“我按了方向键但舱体没反应”“我以为稳了但判定坠毁”的实测经验。

如果你手头也在做类似的模拟或游戏项目，建议先别急着堆特效，把你判定的“触发条件”和“结果反馈”用表格列出来，对着玩一遍再改参数。这比任何优化技巧都来得直接。

另外有个小技巧值得提：每次调完一组参数，随手截一张 HUD 数值的截图，标注一下当时的判定表现。后面如果手感漂移，你有据可查，不会再凭记忆调回去。这个习惯支撑了 Apollo-11 后半程几乎所有参数收敛的工作，希望对你有用。