企业官网建设流程全解析

很多人看到“Apollo-11”这个名字，第一反应是那场伟大的登月壮举。但在开发者圈子里，它还有个更朴素的身份——一个网页版月球着陆模拟器项目的名字。这类项目用纯前端技术实现，打开浏览器就能玩，玩家通过键盘控制着陆器的引擎推力，在燃料耗尽前完成软着陆。别看它体量小，一个游戏开发闭环该有的东西它全都有：物理模拟、帧循环、碰撞检测、状态管理、交互反馈，样样不缺。特别适合刚学完JavaScript基础、想往游戏方向迈第一步的人，也适合在业务开发里待久了、想补一补动画和物理模拟基础的同行。这篇文章我就从项目拆解、物理模型、实操落地、参数调优到问题排查，把这个经典小项目彻底讲透。

1. 项目到底做了什么：从标题反推需求

1.1 核心玩法拆解

模拟器给玩家的任务很简单：在月面指定着陆区完成降落。但展开来看，它需要处理的不只是画面渲染，而是几个互相制约的变量。

首先是物理规则。真实世界里的着陆器受月球引力作用持续加速下落，引擎点火后产生与重力方向相反的推力，让下降速度降下来。燃料是有限资源，烧完就没有了。这些规则放进模拟器里，会变成四个核心数据：高度、速度、燃料余量、引擎推力状态。玩家需要做的判断是“什么时候点火、点火多久、还剩多少油”。整个游戏的可玩性，集中在“推力和燃料哪一个先耗尽”的矛盾上。

其次是输入反馈的及时性。按下点火键，画面和数字立刻要有变化，玩家才能建立操作直觉。如果反馈滞后，或者速度数字跳来跳去，操作体感就会变得非常难受。这一点是很多初版模拟器做得最差的地方。

第三是胜负判定。怎么算安全着陆？下降速度在什么范围内算合格？燃料耗尽后硬着陆怎么表现？这些逻辑写在程序里就是几个条件判断，但边界情况处理得好不好，直接决定项目是“能玩”还是“好玩”。

1.2 技术选型为什么是纯前端

把这类游戏做成Web项目，优势很明显。

零依赖，打开即跑。不需要安装运行时、不需要编译环境、不需要后端服务，只要一个现代浏览器就能跑起来。这对传播和教学都极其友好。我见过不少用重型游戏引擎做同类效果的尝试，效果确实华丽，但也把学习门槛抬高了——光是工程化配置就够新手喝一壶。反而是这种轻量实现，把核心思路暴露得清清楚楚，读者可以直接面对最本质的游戏循环，不需要处理一大堆外围工具链。

另一个重要考虑是跨平台。桌面浏览器、触屏设备、甚至嵌入到技术文档里，一套代码都能跑。对一个以技术演示为定位的项目来说，这种普适性非常值钱。而且用Canvas绘图，整个过程不依赖任何图片素材，所有视觉元素都是代码画出来的，这本身就是一种很好的教学方式。

1.3 这个项目适合谁看

三类人我觉得最值得花时间拆它。

第一类是刚学完JavaScript基础、想做第一个小游戏项目的人。这类项目的代码量不大，读懂不费劲，又能通过改参数获得完全不同的游戏体验，天然就是一块试验田。

第二类是做前端业务开发、平时主要写页面逻辑，但想补一下动画和物理模拟基础的同行。你会发现很多游戏编程的思路，比如固定时间步、数据与渲染分离、状态机管理，反过来也能提升业务代码的质量。

第三类是想给学生讲游戏编程原理的老师或技术讲师。一个多小时就能讲完代码，学生还能亲手调参数体验“改一行代码手感全变”的乐趣，比纯讲PPT有用得多。

2. 物理模拟的核心：把牛顿定律搬到浏览器

2.1 简化的月球重力模型

真实月球表面重力加速度约为地球表面的六分之一，也就是大约1.62米每二次方秒。模拟器为了突出核心玩法，把整个场景简化成垂直方向的运动——很多初版模拟器连水平移动都砍掉，只保留高度、速度、加速度三个量。

向下为正方向时，重力始终提供一个1.62米每二次方秒的加速度。引擎点火后，提供一个向上的加速度，取值由游戏设计决定。这里就出现了关键矛盾：如果推力加速度小于重力，点火只能延缓坠落，不能上升；如果推力远大于重力，燃料又会迅速见底。所以设计者通常把推力设定在重力值的两到四倍之间，让操作具备“可挽救”的空间，又不至于毫无压力。

燃料的消耗速率要和推力联动。常见做法是让燃料消耗与点火时长成正比，设置一个每秒消耗多少单位的数值。燃料上限、消耗速率、重力大小、推力大小这四个数字，共同决定了一局游戏的难度曲线。我实测下来，初始高度250米、初始下降速度8米每秒、燃料上限100、重力1.62、推力3.2、燃料消耗率5.5单位每秒的组合，新手会手忙脚乱，但有经验的人能在二十秒左右完成一次着陆，时长和难度控制都很舒服。

2.2 帧循环与积分计算

Web端的动画驱动现在基本都用requestAnimationFrame。它会在浏览器每次刷新屏幕之前执行回调，给予稳定的刷新时机。但注意，不同显示器的刷新率可能是60Hz、90Hz甚至120Hz。如果每一帧更新固定数值，而不管真实流逝的时间，那高刷屏上的游戏就会比低刷屏更快，物理效果完全错乱。

正确做法是用时间差做积分。取当前帧的时间戳，减去上一帧的时间戳，得到真实流逝的毫秒数，换算成秒后作为Δt。这样无论屏幕刷新率是多少，物理模拟都按真实时间来推进。核心逻辑不算长，大致是这样：

let lastTime = 0; let height = INITIAL_HEIGHT; let speed = INITIAL_SPEED; let fuel = INITIAL_FUEL; function update(dt) { const throttle = engineOn && fuel > 0; if (throttle) { speed += (THRUST_ACCEL - GRAVITY) * dt; fuel -= FUEL_BURN_RATE * dt; if (fuel < 0) fuel = 0; } else { speed += GRAVITY * dt; } height -= speed * dt; if (height <= 0) { landingCheck(); } } function loop(timestamp) { const dt = (timestamp - lastTime) / 1000; lastTime = timestamp; update(dt); render(); requestAnimationFrame(loop); }

这种把物理更新和画面渲染分开的写法，是游戏开发的基本功。update里只改数据，render里只画画面。数据与表现分离之后，定位问题会轻松很多。哪怕你以后不写游戏，写复杂的前端交互，这个思路依然适用。

2.3 安全着陆的判定逻辑

评判着陆是否成功，要同时看位置和速度。最简单的单维模型里，位置条件是着陆器高度归零，也就是触到月面；速度条件则设定一个阈值，比如下降速度不超过2.5米每秒算软着陆，超过但在某个范围内算损坏着陆，再往上直接判定坠毁。

如果做二维版本，逻辑会更复杂一点：要区分“落在着陆平台上”和“落在月面斜坡上”，还要检查水平速度。落地时如果还在横移，即便垂直速度很小也会因为侧向力倾覆。我在自己的实验版本里加过二维判定，三个条件缺一不可：x坐标落在平台范围内、垂直速度低于阈值、水平速度低于1米每秒。这不算复杂，但对“看起来是否真实”的提升非常明显。

2.4 为什么这类物理不需要“精确”

有人会质疑，这种简化模型和真实轨道力学差得太远。它差得确实很多，但一个网页小游戏用不上开普勒方程，也用不上六自由度刚体动力学。模拟的目标是“手感可信”，不是“轨道精确”。这和工程仿真是两码事。

先理解质点在重力场中的运动，再去理解更复杂的系统，学习路径反而是清晰的。你不需要从广义相对论开始学游戏物理，也不需要先学完流体力学再做火焰效果。抓住几个关键量，用最简单的公式推起来，效果就足够好了。

3. 实操拆解：从空文件到一个可以玩的着陆器

3.1 场景搭建与Canvas渲染

我习惯把整个界面拆成几个层次：星空背景、月面地平线、着陆平台、着陆器、粒子火焰、HUD信息。前五层用Canvas直接绘制，HUD用DOM元素覆盖，数字更新更方便。

星空背景用随机点生成，每颗星亮度略有差异，营造纵深。月面是一条有起伏的折线，着陆平台画成一个带标记的矩形区域。绘制时需要注意Canvas的坐标系原点在左上角，垂直方向向下为正，这和物理模型的坐标系最好保持一致，省得换算出错。

着陆器的绘制可以用简单几何图形拼出来：一个倒梯形主体、四个支撑腿、一个引擎喷嘴。点火时在喷嘴下方动态生成一个火焰三角形，长度随推力大小变化。所有形状都用fillRect或beginPath画多边形，不需要任何图片资源。这也是纯代码绘图的优点：文件体积小，素材依赖为零，部署极其省心。

3.2 键盘控制与事件防抖

最常见的控制方案是按住空格键或方向键点火，松开即关。注意，在浏览器里空格键默认会滚动页面，方向键也会引起页面滚动，必须用preventDefault阻止默认行为。这一点在开发调试时最容易遇到，玩着玩着页面突然滚走了，多半就是忘了这茬。

还有一个容易踩的坑：keydown事件在长按时会重复触发。如果不做处理，玩家的按键可能被记录为多次“按下”，导致状态混乱。通常的做法是维护一个布尔变量记录键是否被按住，keydown时置true，keyup时置false，物理循环里只检查这个变量，而不是依赖事件触发的次数。这个技巧在几乎所有小游戏项目里都适用，非常稳定。

let engineOn = false; document.addEventListener('keydown', (e) => { if (e.code === 'Space' || e.code === 'ArrowUp') { e.preventDefault(); engineOn = true; } }); document.addEventListener('keyup', (e) => { if (e.code === 'Space' || e.code === 'ArrowUp') { e.preventDefault(); engineOn = false; } });

如果还想支持触屏，可以给画布加touchstart和touchend事件，逻辑完全一样，只是把“按压屏幕”映射到发动机开关上。

3.3 HUD信息设计

HUD至少要有四项信息：高度、速度、燃料、当前推力状态。高度用距离月面的垂直距离表示，速度用垂直速度表示，燃料用剩余百分比。数字显示我建议保留一位小数，因为实时变化时整数跳变不明显，小数跳变能更清晰地反映趋势。

为了增强操作反馈，可以在HUD里加一个速度颜色指示。具体做法是显示当前速度与安全着陆阈值的对比：速度在安全范围偏低时，数字显示为绿色；接近危险区时变黄；超过危险值变成红色。这个设计成本极低，却能极大改善操作感知。很多商业模拟器靠复杂仪表盘实现的效果，用数字颜色变化就能达到八九成体验。

3.4 游戏状态机

整个游戏的运行过程可以用状态机来管理：初始状态、进行中、着陆成功、坠毁、重置。状态不同，界面响应不同。比如坠毁时播出一小段爆炸动画并显示失败原因，成功时显示最终燃料余量和精确着陆速度，这些反馈直接影响玩家的成就感。

状态机的实现不需要引入复杂框架，一个枚举加一个switch就够。重点是确保任何状态都能通过一个重置按钮回到初始状态，重置时所有物理变量都要恢复初始值，包括燃料和速度，一个不能漏。我见过不少项目里，数值重置不完全导致第二次游戏手感不对，排查半天发现是燃料初始化写错了地方。

4. 参数调试与体验优化：把“手感”调到正确的轨道

4.1 难度平衡的核心参数

做这类模拟器，最核心的工作就是调参。下面是我整理的一组参考值，不是唯一标准，但经过多轮试玩验证，开局体验和进阶空间都比较平衡：

调参的逻辑从来不是“数值越大难度越高”这么简单。一组好的参数应该让玩家在第一次尝试时感到紧张但不到绝望，在熟练掌握后能形成操作节奏。我常用的调法是：先把重力定死，再决定想要的单局时长，反推燃料总量，最后微调推力，让“刚好能救回来”的场景频繁出现。这个临界点附近其实是游戏最有意思的地方，一组差的参数会让临界点要么过于频繁出现导致玩家麻木，要么几乎不出现导致玩家挫败。

举一个具体的调参场景。某次我把初始下降速度从8调到了12，结果一局游戏从二十秒缩短到十秒，新手玩家根本来不及反应，几乎局局坠毁。后来我把初始高度同步提高到300米，给玩家多留出反应时间，同时把燃料上限提高到110，体验立刻从“不可玩”变成了“紧张但有机会”。这就是参数之间的联动关系，单独改一个数往往不能解决问题。

4.2 视觉反馈如何辅助操作

模拟器的操作反馈不能只看数字。尾焰长度、引擎震动、画面抖动、着陆瞬间的渐变，这些视觉细节合起来构成了驾驶舱的“体感”。我测试了不少版本后得出一个结论：火焰长度比任何数字都更能教会新手“什么时候该收油”。

具体实现上，火焰长度可以和当前推力状态直接挂钩，在渲染时根据推力百分比动态改变火焰三角形的尺寸和颜色。推力越足，火焰越长，颜色从橙黄慢慢偏蓝。着陆成功时，让画面短暂地出现一个轻量白闪和平台高亮；坠毁时则让着陆器做一次快速缩小加明暗变化。这些效果用Canvas做起来并不难，但能让整个项目从“能跑”变成“好玩”，玩家的口碑完全不一样。

4.3 音效的取舍

如果项目定位是纯教学，音效可以后置。但若想让演示有完整感，最廉价的方案是用Web Audio API生成一个低频引擎轰鸣音，点火时启动振荡器，松开时关闭。它不需要任何外部音频文件，代码十分钟就能写完。唯一要注意的是音量控制，压低一点，低频为主，否则玩两局耳朵就累了。

着陆成功和坠毁也各需要一个短提示音。成功时可以做一个音量渐降的上行和弦，坠毁则做一个快速下降的噪音。Web Audio API完全能搞定，网上类似的示例代码很多，稍加改造就能用。

5. 常见问题排查与避坑实录

5.1 速度显示不稳定，一卡一卡的

最常见原因不是逻辑错，而是循环里没有使用真实时间差。如果你按固定帧数更新，而在渲染密集的页面上出现丢帧，物理就会像慢放一样，速度一时快一时慢。解决办法就是像前面代码那样，用timestamp差值得到Δt。

另外有一个细节：浏览器标签页在后台运行时，requestAnimationFrame会暂停，切回来时第一个Δt可能异常巨大，导致速度瞬间跳变，画面像“瞬移”了一样。处理方式是如果Δt超过0.1秒就放弃本次物理更新，只更新时间戳不执行计算。这个防御性判断成本很低，但能省掉不少诡异问题。

5.2 着陆判定穿模与“飘在地面上”

下降速度太快时，一帧内高度可能从正数直接越过0变成负数，速度却还没被判定，视觉上就出现了“陷进地里”之后再弹出来的效果。解决方式分两层：一是落地前做一个速度检查，如果当前下降速度过大，直接判定坠毁，不再等高度完全归零；二是允许极端情况下做“细分时间步”，比如把一帧拆成十个子步逐次检测。前者对小型模拟器足够，后者更接近商业物理引擎的做法。

另一个看似相关但完全不同的问题是“飘在地面上”：高度降到0以下又恢复成0，但速度没有归零，下一帧又往下落，看起来像悬浮。根本原因是碰撞响应没有把速度清零。正确做法是进入落地分支时，直接把速度设置成0或一个固定的倒地速度，再进行成功或失败的判定，就不会出现那种诡异的悬浮感。

5.3 页面滚动与按键冲突

空格键默认会滚动页面，方向键在部分浏览器里默认也会滚动视口。如果开发调试时发现“玩着玩着画面跳走了”，八成就是忘记调用preventDefault。这个前面已经强调过，建议在事件监听器里第一时间写死，不要留到后期再补。

还有一个容易忽略的细节：如果把游戏嵌入到带滚动条的文档里，焦点必须落在页面主体上，按键事件才会生效。在模拟器初始状态下主动调用一下focus方法，可以避免用户需要先点击一下画面才能开始操作的尴尬。移动端访问时，这个“点击才能激活”的问题会更明显，别忘了做兼容提示。

5.4 燃料数值显示不同步

燃料每秒消耗额定数值，但画面上的显示可能因为帧率和舍入误差出现“还剩一点却显示0”或者“显示100但一碰就没”的错觉。排查思路其实很简单：先把消耗量改成基于时间的精确累计，再统一在渲染时通过一个燃料剩余百分比函数做显示，不要在多处直接修改燃料值。否则很容易出现你同时更新了三个变量，彼此之间差了零点几，视觉上就一直在跳。

燃料耗尽后，要确保推进器在物理层也彻底关闭，否则会出现“燃料为0还在喷火”的表演性bug。这属于状态机管理不严格的典型后果，逻辑分支里遗漏了“燃料等于0时强制熄火”的条件。

5.5 高刷新率显示器带来的难度差异

同样是这个游戏，在60Hz和144Hz屏幕上玩起来难度居然不同。原因就是前面说的帧与时间的换算问题。如果物理更新不当，高刷新率下操作响应更频繁，玩家会觉得“推力更给力”。解决办法永远是统一用真实时间驱动物理，并固定物理步长，比如每六十分之一秒执行一次固定步长逻辑，剩余时间累计到下一个步长。这个方法在商业游戏引擎里叫“固定时间步”，小型项目可以借助一个累计器实现：

let accumulator = 0; const PHYSICS_STEP = 1 / 60; function loop(timestamp) { const dt = Math.min((timestamp - lastTime) / 1000, 0.1); lastTime = timestamp; accumulator += dt; while (accumulator >= PHYSICS_STEP) { update(PHYSICS_STEP); accumulator -= PHYSICS_STEP; } render(); requestAnimationFrame(loop); }

这样做的好处是物理行为完全与帧率无关，无论屏幕是60Hz还是144Hz，手感保持一致。代价是代码多了一层循环，但对这种小项目来说完全值得。这也是我在踩过几次高刷屏的坑之后才彻底理解的，早期版本一直用“每帧固定更新量”，结果换了台显示器手感全变，排查了大半天。

6. 后续玩法与扩展方向

原版项目已经能完整游玩，但如果你愿意多花点力气，可以往几个方向扩展，每一个方向都能加深你对游戏开发的理解。

第一，粒子系统。火焰可以用简单的粒子对象数组实现，每个粒子有自己的位置、速度和生命周期。引擎点火时不断生成新粒子，粒子向上运动并逐渐缩小消失。这个改动既能提升视觉质感，也能让绘制代码更接近商业引擎的套路，值得认真做一次。

第二，二维化。增加水平速度、水平位置和左右平移按键，让着陆器可以斜向移动，同时引入平台坐标判定和着陆倾斜角检查。难度会往上跳一个台阶，但可玩性提升是压倒性的，很多经典街机着陆模拟器玩的就是这个模式。

第三，数据记录与本地排行。记录每次着陆的综合评分，比如燃料余量、着陆速度、用时，存到localStorage里，做一个本地榜单。这类社交反馈会让学习项目里的“炫耀一下”的冲动变成继续优化的动力。配合上简单的速度回放功能，还能顺带学会时间序列数据怎么存储与绘制。

第四，关卡与任务化。给模拟器加几个关卡，比如“燃料只有50单位”“初始下降速度15米每秒”“必须落在最右侧的小平台上”。关卡系统会逼着你把参数配置从写死的常量改成一个数据驱动的配置表，这本身就是一次很好的代码重构练习。

每个扩展点都能独立成篇，但原版的核心逻辑始终不变：极小的数据模型，加上清晰的状态更新，承载完整的交互闭环。把这三个点吃透，换任何题材都能快速做出可玩的Demo。

我个人做这个项目最大的收获反而是“减法”：如何用最简物理规则做出可信手感，如何在限制条件下做出清晰反馈，如何用状态机管理复杂交互。游戏开发的门槛不在炫技，而在逻辑与细节的取舍。把Apollo-11拆一遍，比照着教程抄十个页面更能理解这种取舍的实质。建议你拿到代码后，先不要急着加功能，试着把重力改成3、把燃料改成50、把推力改成2，玩几局再想想为什么手感差那么多，这个思考过程本身就是最好的学习。