前阵子我看到一个项目标题没有配图也没有很长的介绍但一眼就让人停住了Alpaca Push – Rebuilding 2004 ICQ Slide-a-Lama in HTML5。不是每个人都知道 ICQ也有很多人不记得 2004 年的浏览器长什么样。这两件事放在一起恰恰是问题所在。把一个旧聊天客户端里的小游戏搬到 HTML5技术上是重写产品上是再设计文化上则是一场小型考古。2004 年的小游戏运行环境往往绑定在某个特定客户端、某个系统版本甚至某个私有组件上。玩家要玩游戏通常不是“打开一个网页”这么简单而是要先装软件、进入入口、等待加载最后才能在聊天窗口边上见缝插针地玩两把。而 HTML5 给出的承诺是只要有浏览器打开 URL 就能玩。它不需要额外安装不需要插件不需要关心用户的电脑是 Windows、macOS、iOS 还是 Android。但真正动手之后你会发现把“2004 年的小游戏搬到 HTML5”这句话说清楚容易做起来并不轻松。难的不是用 Canvas 画出一个会移动的角色而是你面对的可能只有一个可执行文件、一些截图、几段录像甚至只是记忆里一段模糊的操作手感。你没法直接把旧的二进制文件塞进浏览器复制粘贴式的“转换”根本不存在。你能做的是理解原版玩法之后用今天的 Web 技术把它重新实现出来。这篇文章不打算假装我完整熟悉 Slide-a-Lama 的每一关。因为这类旧资料的完整度通常很差如果有人说他能一字不差还原 2004 年的全部关卡那你更可能要警惕。我更在意的是当你想把一个旧时代的小游戏重建到 HTML5 时真正应该先想清楚的问题是什么搭建顺序是什么容易在哪里翻车以及最后能得到什么。1. 先想清楚Alpaca Push 这类项目到底在重建什么1.1 2004 年的客户端小游戏和今天 Web 游戏的差距不在“画质”先说一个很多人容易误解的地方。重建一个老游戏难点往往不是画面不够精致而是运行环境的断层。2004 年前后的客户端小游戏多半不是“一个 HTML 文件打开就能跑”的东西。它们可能依赖聊天客户端的内置功能可能依赖操作系统的图形库可能依赖某个已停止维护的运行环境。一旦上游停止维护终端用户手里的游戏就成了一个历史遗留品。哪怕文件还在想在新系统里打开也可能撞上兼容问题。HTML5 的优势不是让画面更漂亮而是把运行环境统一到了浏览器里。浏览器是当前几乎所有设备都会有的东西而且它下面垫着的是一组仍在演进但相对稳定的标准化能力Canvas 负责绘制游戏画面requestAnimationFrame 负责驱动动画和刷新Event 体系处理键盘、鼠标、触摸localStorage 负责保存进度AudioContext / audio 负责音效和音乐网络请求负责加载关卡数据。Alpaca Push 这类项目真正在做的不是“把一个 2004 年的文件打开”而是“让 2004 年的玩法规则在 2024 年后的浏览器坐标体系里重新成立”。用一张表格来对照会更清楚维度2004 年客户端小游戏的常见形态HTML5 Web 游戏的形态运行环境特定操作系统 / 特定客户端 / 私有组件现代浏览器安装成本下载、安装、入口寻找打开 URL输入方式鼠标键盘为主鼠标、键盘、触摸、手柄存档方式本地文件或服务器会话localStorage、IndexedDB、云端账号分发方式捆绑软件、下载站CDN、静态网页、iframe 分享更新方式重新发包发版之后刷新即生效生命周期随平台关停而消失取决于标准兼容性通常更长这张表格的每一行都会在项目中期变成真实的代码问题。比如你打算支持手机触摸那原来“方向键”就不能只绑定 keydown如果你希望老玩家记住自己玩到哪一关localStorage 就要在游戏启动时先读取如果你今天想给朋友发一个试玩链接那最后就得把静态资源托管到任意一台 HTTPS 服务器上。这些都不是画质问题它们共同构成了“一个游戏能不能被今天的人继续使用”的基础条件。1.2 老游戏搬到 HTML5本质是“重新发明一次交互规则”网上有很多人会把“旧游戏重制”理解成资源迁移把旧图片找出来把旧代码反编译一下再把素材贴到新引擎里。实际情况往往不是这样。旧版可执行文件里封装的逻辑、图片编码、音频格式甚至坐标系统都与今天的浏览器环境不兼容。除非你手里保留了原始工程而且这个工程当年就是用通用技术写的否则绝大部分情况下你能做的是“重写”不是“迁移”。这更像重新编曲而不是把磁带转录成 MP3。磁带转录虽然会有噪声但至少旋律结构还在而面对一个旧二进制程序你连“这首曲子的谱面是什么”都不一定知道只能通过观察、试玩、对照录像反推节拍、配器和结构。反推的过程才是这个项目最值得做的地方。它逼迫你去拆解一个问题原版游戏的核心规则到底是什么一个简单的滑块谜题玩家到底是在控制角色移动还是直接滑动格子箱子被推动后是一次移动一格还是一次滑到撞墙角色能不能绕到箱子后面继续推关卡什么时候算通关这些规则比“用什么颜色画背景”重要得多。只要规则描述不清楚后面的动画、音效、关卡设计全都是空中楼阁。Alpaca Push 这类重建项目价值也在这里。它把一个旧游戏推到开发者面前逼你完成“从规则到描述、从描述到状态机、从状态机到代码”的完整转化。你越是认真做越会发现HTML5 在这里不只是技术栈它改变的是交互的定义方式。旧版客户端里的“移动”可能是鼠标单击某个区域完成的而在浏览器里同一个动作可能需要同时兼容键盘、点击、触摸和手柄输入。所以我可以给这个项目下一个更明确的判断它最难的地方不在于怎样用 canvas 画一只像样的羊驼而在于怎样把整个时代的交互逻辑转换成一段可以长期维护、可以随时分享、可以被搜索引擎索引的 HTML5 游戏状态机。2. 一个最小可跑的 HTML5 滑块推箱子原型是怎么搭起来的如果不想一开始就背着“完整还原”的包袱可以先把一个最简单的推箱子原型跑起来。下面这个思路不只适用于 Slide-a-Lama也适用于绝大多数类似的格子类滑块游戏。2.1 先选 Canvas 还是 DOM 元素很多人第一次写 HTML5 游戏会纠结到底用 Canvas 还是 DOM。我的个人观点是如果目标是一个“以后还可能扩展玩法”的格子推箱子直接用 Canvas 起步会更省心。用 DOM CSS Grid 不是不行。简单关卡、没有复杂动画的时候DOM 方案反而容易调试。但一旦涉及多状态叠加比如“箱子上有没有目标点”“玩家能不能踩目标格”DOM 方案通常需要在元素类名和样式之间来回切换状态一多就容易乱。Canvas 的思路更直接整个游戏画面都是一张画布每一帧里根据当前游戏状态重新绘制所有内容。碰撞、判定、动画插值和逻辑刷新都可以放在同一个循环里不会被浏览器布局和 CSS 过渡的时序干扰。我建议的初始技术栈是HTML 结构只放一个canvasJavaScript 负责所有游戏状态包括地图、玩家位置、箱子位置requestAnimationFrame 负责刷新画面事件监听负责把用户输入转成状态变更。2.2 游戏主循环与动画帧游戏和普通网页最大的区别在于它有一个持续运行的主循环。普通网页是“用户操作一下页面响应一下”游戏则希望“即使你不按任何键画面也能持续刷新动画也能继续播放”。在 HTML5 里最接近主循环的是requestAnimationFrame。它会让浏览器在每次刷新屏幕之前调用你的函数通常是每秒钟 60 次也可能达到 120 次取决于显示器的刷新率。一个最小主循环长这样let lastTime 0; function gameLoop(time) { // 限制 dt 上限避免切后台回来后出现跳帧 const dt Math.min(time - lastTime, 50); lastTime time; update(dt); // 根据 dt 更新状态 draw(); // 重新绘制画面 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里有一个新手经常忽略的点不要假设每帧的时间都相同。在 60Hz 屏幕上每帧间隔大约是 16.7 毫秒但在 120Hz 屏幕上可能只有 8.3 毫秒。如果你把移动速度写死成“每帧移动 2 像素”那高刷新率设备上的角色会比普通设备快很多。正确做法是让速度与帧间隔相乘// 假如角色要每秒移动 60 像素 player.x speed * dt;dt的单位是毫秒所以speed代表的是“每毫秒移动多少像素”。很多老游戏原本运行在固定帧率上搬到 HTML5 后如果忽略了帧率差异玩家会被快慢不一的操作手感折腾得很难受。2.3 推动和滑动的碰撞逻辑一个最小实现推箱子类游戏的核心是一个很小的碰撞逻辑玩家尝试走向某个格子如果那个格子是空的就直接走如果那个格子是箱子就检查箱子后面有没有空间如果箱子后面也是空的就把箱子推过去否则整个移动失败。下面是一个最简化版本的核心移动函数省略了画布初始化代码const TILE_EMPTY 0; const TILE_WALL 1; const TILE_CRATE 2; const TILE_GOAL 3; let grid [ [1, 1, 1, 1, 1], [1, 0, 2, 0, 1], [1, 0, 2, 0, 1], [1, 3, 0, 0, 1], [1, 1, 1, 1, 1], ]; // player 只记录角色所在的行列 let player { row: 1, col: 1 }; const MOVES { ArrowUp: { dr: -1, dc: 0 }, ArrowDown: { dr: 1, dc: 0 }, ArrowLeft: { dr: 0, dc: -1 }, ArrowRight: { dr: 0, dc: 1 }, }; function tryMove(direction) { const { dr, dc } direction; const nextRow player.row dr; const nextCol player.col dc; const tile grid[nextRow]?.[nextCol]; if (tile undefined || tile TILE_WALL) return false; if (tile TILE_CRATE) { const boxNextRow nextRow dr; const boxNextCol nextCol dc; const boxNextTile grid[boxNextRow]?.[boxNextCol]; if ( boxNextTile undefined || boxNextTile TILE_WALL || boxNextTile TILE_CRATE ) { return false; } grid[boxNextRow][boxNextCol] TILE_CRATE; grid[nextRow][nextCol] TILE_EMPTY; } player { row: nextRow, col: nextCol }; return true; } document.addEventListener(keydown, (event) { const direction MOVES[event.key]; if (!direction) return; event.preventDefault(); tryMove(direction); });这个最小实现里目标格和箱子用的还是同一个静态数组真实项目里出现“箱子压住目标点”时会丢失目标信息。所以实际开发时我更建议把地图拆成两层一层是不可变的静态地图记录墙、地面和目标点另一层是动态状态记录玩家和箱子当前位置。这样判断胜利时遍历所有箱子看它们是否都位于某个目标点上就可以了。代码看起来不复杂但它已经覆盖了一个推箱子游戏最重要的骨架地图网格作为数据结构玩家坐标作为可变状态移动函数作为规则绘制循环作为输出。先把这一步跑通后面所有“复古感”“羊驼皮肤”“音效增强”才有着手点。3. 从“能玩”到“像那么回事”还原一个老游戏的细节维度最小原型跑通之后离“像那么回事”还有很长一段路。这个阶段最需要做的不是拼命加关而是把老游戏里那些你记住了、但说不清楚为什么重要的细节一个一个还原回来。3.1 手感调优速度、停顿和误触推箱子类游戏对“手感”的要求比很多人想象中更苛刻。哪怕名字里带 Slide也需要先判断原版究竟是一个格子一个格子离散移动还是一次滑动到撞墙。这是决定整个重写方向的分叉口。我在做这类游戏时会有一个习惯在还没有完整旧文件可参考时先不猜而是把移动模式做成一个配置项用两三种不同手感分别跑几关再对比老游戏录像或记忆里的操作感受。在 HTML5 里决定手感的主要因素有三个移动单位玩家是按整个格子移动还是按像素移动还是先按下方向键再等待一小段延迟后连续移动。动画插值逻辑上的格子和画面上的位置可以分离。逻辑层立刻改变坐标视觉层用几百毫秒的补间动画把角色“滑”过去。这能让游戏感觉流畅又不影响碰撞正确性。失败反馈当玩家试图把箱子推向墙时游戏不应该只是“什么都不发生”。一个很短的角色抖动或者轻微的音效都能让玩家立刻明白操作无效。老游戏里的很多“顿挫感”来自当时的硬件和动画同步机制而这些感觉恰恰是最难用代码复现的部分。一个常见的陷阱是一开始就去调视觉动画忽略了底层离散逻辑结果画面已经滑到一半碰撞却提前触发玩家会觉得角色像在打滑。我更建议先让底层逻辑在无动画、无插值的状态下跑通确定每一步移动都符合规则。等到逻辑稳定后再给“角色从格子 A 移到格子 B”这个过程加上 easing 动画而不是反过来。顺序反了你大概率会被动画和碰撞串扰的问题耗掉大量时间。3.2 关卡数据、目标点和存档一个复古解谜游戏能不能长久玩下去取决于关卡内容质量而不是引擎多炫。所以在早期阶段就应该把关卡数据从游戏逻辑代码里拆出来。关卡数据不需要很高级用 JSON 数组就够。每个关卡至少包含地图网格、玩家初始位置、箱子初始位置、目标点位置。把数据独立存放之后你甚至可以给自己写一个地图编辑器直接复制粘贴关卡。这里我提供一个非常基础的关卡结构const LEVELS [ { name: Tutorial, grid: [ [1, 1, 1, 1, 1], [1, 0, 2, 0, 1], [1, 0, 2, 0, 1], [1, 3, 0, 0, 1], [1, 1, 1, 1, 1], ], player: { row: 1, col: 1 }, goals: [{ row: 3, col: 1 }], }, ];关卡数据独立后保存进度就是一件小事。浏览器里的标准方案是 localStorage但有一个很容易踩的坑某些浏览器的隐私模式会禁用 localStorage直接写入可能会抛异常。所以保存代码不能裸写要用 try/catch 包一层function saveProgress(currentLevel) { try { localStorage.setItem(alpaca-push.level, String(currentLevel)); } catch (error) { // 隐私模式下写入失败是正常现象至少不要让游戏崩溃 console.warn(进度保存失败可能处于隐私浏览模式); } }更完整的做法是把玩家每一步产生的关卡状态序列保存下来方便后续做“撤销”功能。如果是在做教学项目这同样是一个很好的练习点。3.3 声音、视觉风格与浏览器兼容性老游戏让人记住的视觉只是一部分声音同样重要。不过 HTML5 里的声音处理比想象中更容易遇到环境差异。如果你只是给游戏加几个短音效Web Audio API 比audio元素更可控。你可以用 oscillator 直接合成“哔哔”声也可以加载一段很小的音效文件。另一个关键点是浏览器普遍不希望网页一打开就自动播放声音通常要求用户先与页面产生一次交互。所以在初始化 AudioContext 时我会放在用户第一次点击或第一次按键之后let audioCtx null; function initAudio() { if (audioCtx) return; try { audioCtx new AudioContext(); } catch (error) { console.warn(当前环境不支持 Web Audio API); } } document.addEventListener(click, initAudio, { once: true }); document.addEventListener(keydown, initAudio, { once: true });不要小看这个顺序。不同浏览器对音频自动播放策略并不完全一致尤其是 Safari 这类对资源加载和后台播放限制更严格的环境。喜欢用audio元素做背景音乐的朋友也会在项目里感受一轮“不同浏览器对 HTML5 播放器的支持差异”。解决办法通常是把音频能力限制在用户主动触发后的范围内并提供音量开关。视觉风格的兼容性也要提前考虑。如果项目要用像素风素材Canvas 绘制时可能会在高 DPI 屏幕上显得发虚。一个通用做法是设置 Canvas 的实际分辨率高于 CSS 显示尺寸用devicePixelRatio做缩放。另一个直接有用的 CSS 属性是image-rendering: pixelated可以让放大后的位图保持边缘清晰而不是被浏览器自动模糊。这些细节单个看都不复杂但它们决定了游戏会不会在“我的浏览器里可以换台设备就出问题”。4. 容易踩的坑以及一套相对靠谱的排查顺序做这类重建项目最折磨人的往往不是核心逻辑而是“明明在本地好好的换个环境就出毛病”。这里我总结几个高频问题并给出一个排查思路。4.1 为什么单机跑通换台电脑或手机就出问题第一个最常见的坑是事件绑定错了对象。在桌面浏览器里方向键事件可以监听在document上但如果游戏页面嵌在 iframe 里且 iframe 没有被点击聚焦键盘事件根本不会送达。所以游戏启动后最好先让用户点一下画布区域再把键盘监听挂到window或document上。否则玩家会觉得方向键“时而灵时而不灵”。第二个高频问题是Canvas 尺寸为 0。如果你在 CSS 里给 Canvas 设置了百分比宽度但初始化 Canvas 时没有正确读取父容器高度可能导致宽度正常、高度为 0 的画面。这个问题在移动端特别常见。排查方式很简单在绘制第一帧时输出canvas.width和canvas.height确认它们不是 0。第三个问题是设备像素比不一致。同一张 480x480 的 Canvas在普通屏和 Retina 屏上的显示效果不同。如果不处理 devicePixelRatio 用HTML5复活2004年ICQ小游戏：Slide-a-Lama的重建思路
前阵子我看到一个项目标题没有配图也没有很长的介绍但一眼就让人停住了Alpaca Push – Rebuilding 2004 ICQ Slide-a-Lama in HTML5。不是每个人都知道 ICQ也有很多人不记得 2004 年的浏览器长什么样。这两件事放在一起恰恰是问题所在。把一个旧聊天客户端里的小游戏搬到 HTML5技术上是重写产品上是再设计文化上则是一场小型考古。2004 年的小游戏运行环境往往绑定在某个特定客户端、某个系统版本甚至某个私有组件上。玩家要玩游戏通常不是“打开一个网页”这么简单而是要先装软件、进入入口、等待加载最后才能在聊天窗口边上见缝插针地玩两把。而 HTML5 给出的承诺是只要有浏览器打开 URL 就能玩。它不需要额外安装不需要插件不需要关心用户的电脑是 Windows、macOS、iOS 还是 Android。但真正动手之后你会发现把“2004 年的小游戏搬到 HTML5”这句话说清楚容易做起来并不轻松。难的不是用 Canvas 画出一个会移动的角色而是你面对的可能只有一个可执行文件、一些截图、几段录像甚至只是记忆里一段模糊的操作手感。你没法直接把旧的二进制文件塞进浏览器复制粘贴式的“转换”根本不存在。你能做的是理解原版玩法之后用今天的 Web 技术把它重新实现出来。这篇文章不打算假装我完整熟悉 Slide-a-Lama 的每一关。因为这类旧资料的完整度通常很差如果有人说他能一字不差还原 2004 年的全部关卡那你更可能要警惕。我更在意的是当你想把一个旧时代的小游戏重建到 HTML5 时真正应该先想清楚的问题是什么搭建顺序是什么容易在哪里翻车以及最后能得到什么。1. 先想清楚Alpaca Push 这类项目到底在重建什么1.1 2004 年的客户端小游戏和今天 Web 游戏的差距不在“画质”先说一个很多人容易误解的地方。重建一个老游戏难点往往不是画面不够精致而是运行环境的断层。2004 年前后的客户端小游戏多半不是“一个 HTML 文件打开就能跑”的东西。它们可能依赖聊天客户端的内置功能可能依赖操作系统的图形库可能依赖某个已停止维护的运行环境。一旦上游停止维护终端用户手里的游戏就成了一个历史遗留品。哪怕文件还在想在新系统里打开也可能撞上兼容问题。HTML5 的优势不是让画面更漂亮而是把运行环境统一到了浏览器里。浏览器是当前几乎所有设备都会有的东西而且它下面垫着的是一组仍在演进但相对稳定的标准化能力Canvas 负责绘制游戏画面requestAnimationFrame 负责驱动动画和刷新Event 体系处理键盘、鼠标、触摸localStorage 负责保存进度AudioContext / audio 负责音效和音乐网络请求负责加载关卡数据。Alpaca Push 这类项目真正在做的不是“把一个 2004 年的文件打开”而是“让 2004 年的玩法规则在 2024 年后的浏览器坐标体系里重新成立”。用一张表格来对照会更清楚维度2004 年客户端小游戏的常见形态HTML5 Web 游戏的形态运行环境特定操作系统 / 特定客户端 / 私有组件现代浏览器安装成本下载、安装、入口寻找打开 URL输入方式鼠标键盘为主鼠标、键盘、触摸、手柄存档方式本地文件或服务器会话localStorage、IndexedDB、云端账号分发方式捆绑软件、下载站CDN、静态网页、iframe 分享更新方式重新发包发版之后刷新即生效生命周期随平台关停而消失取决于标准兼容性通常更长这张表格的每一行都会在项目中期变成真实的代码问题。比如你打算支持手机触摸那原来“方向键”就不能只绑定 keydown如果你希望老玩家记住自己玩到哪一关localStorage 就要在游戏启动时先读取如果你今天想给朋友发一个试玩链接那最后就得把静态资源托管到任意一台 HTTPS 服务器上。这些都不是画质问题它们共同构成了“一个游戏能不能被今天的人继续使用”的基础条件。1.2 老游戏搬到 HTML5本质是“重新发明一次交互规则”网上有很多人会把“旧游戏重制”理解成资源迁移把旧图片找出来把旧代码反编译一下再把素材贴到新引擎里。实际情况往往不是这样。旧版可执行文件里封装的逻辑、图片编码、音频格式甚至坐标系统都与今天的浏览器环境不兼容。除非你手里保留了原始工程而且这个工程当年就是用通用技术写的否则绝大部分情况下你能做的是“重写”不是“迁移”。这更像重新编曲而不是把磁带转录成 MP3。磁带转录虽然会有噪声但至少旋律结构还在而面对一个旧二进制程序你连“这首曲子的谱面是什么”都不一定知道只能通过观察、试玩、对照录像反推节拍、配器和结构。反推的过程才是这个项目最值得做的地方。它逼迫你去拆解一个问题原版游戏的核心规则到底是什么一个简单的滑块谜题玩家到底是在控制角色移动还是直接滑动格子箱子被推动后是一次移动一格还是一次滑到撞墙角色能不能绕到箱子后面继续推关卡什么时候算通关这些规则比“用什么颜色画背景”重要得多。只要规则描述不清楚后面的动画、音效、关卡设计全都是空中楼阁。Alpaca Push 这类重建项目价值也在这里。它把一个旧游戏推到开发者面前逼你完成“从规则到描述、从描述到状态机、从状态机到代码”的完整转化。你越是认真做越会发现HTML5 在这里不只是技术栈它改变的是交互的定义方式。旧版客户端里的“移动”可能是鼠标单击某个区域完成的而在浏览器里同一个动作可能需要同时兼容键盘、点击、触摸和手柄输入。所以我可以给这个项目下一个更明确的判断它最难的地方不在于怎样用 canvas 画一只像样的羊驼而在于怎样把整个时代的交互逻辑转换成一段可以长期维护、可以随时分享、可以被搜索引擎索引的 HTML5 游戏状态机。2. 一个最小可跑的 HTML5 滑块推箱子原型是怎么搭起来的如果不想一开始就背着“完整还原”的包袱可以先把一个最简单的推箱子原型跑起来。下面这个思路不只适用于 Slide-a-Lama也适用于绝大多数类似的格子类滑块游戏。2.1 先选 Canvas 还是 DOM 元素很多人第一次写 HTML5 游戏会纠结到底用 Canvas 还是 DOM。我的个人观点是如果目标是一个“以后还可能扩展玩法”的格子推箱子直接用 Canvas 起步会更省心。用 DOM CSS Grid 不是不行。简单关卡、没有复杂动画的时候DOM 方案反而容易调试。但一旦涉及多状态叠加比如“箱子上有没有目标点”“玩家能不能踩目标格”DOM 方案通常需要在元素类名和样式之间来回切换状态一多就容易乱。Canvas 的思路更直接整个游戏画面都是一张画布每一帧里根据当前游戏状态重新绘制所有内容。碰撞、判定、动画插值和逻辑刷新都可以放在同一个循环里不会被浏览器布局和 CSS 过渡的时序干扰。我建议的初始技术栈是HTML 结构只放一个canvasJavaScript 负责所有游戏状态包括地图、玩家位置、箱子位置requestAnimationFrame 负责刷新画面事件监听负责把用户输入转成状态变更。2.2 游戏主循环与动画帧游戏和普通网页最大的区别在于它有一个持续运行的主循环。普通网页是“用户操作一下页面响应一下”游戏则希望“即使你不按任何键画面也能持续刷新动画也能继续播放”。在 HTML5 里最接近主循环的是requestAnimationFrame。它会让浏览器在每次刷新屏幕之前调用你的函数通常是每秒钟 60 次也可能达到 120 次取决于显示器的刷新率。一个最小主循环长这样let lastTime 0; function gameLoop(time) { // 限制 dt 上限避免切后台回来后出现跳帧 const dt Math.min(time - lastTime, 50); lastTime time; update(dt); // 根据 dt 更新状态 draw(); // 重新绘制画面 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里有一个新手经常忽略的点不要假设每帧的时间都相同。在 60Hz 屏幕上每帧间隔大约是 16.7 毫秒但在 120Hz 屏幕上可能只有 8.3 毫秒。如果你把移动速度写死成“每帧移动 2 像素”那高刷新率设备上的角色会比普通设备快很多。正确做法是让速度与帧间隔相乘// 假如角色要每秒移动 60 像素 player.x speed * dt;dt的单位是毫秒所以speed代表的是“每毫秒移动多少像素”。很多老游戏原本运行在固定帧率上搬到 HTML5 后如果忽略了帧率差异玩家会被快慢不一的操作手感折腾得很难受。2.3 推动和滑动的碰撞逻辑一个最小实现推箱子类游戏的核心是一个很小的碰撞逻辑玩家尝试走向某个格子如果那个格子是空的就直接走如果那个格子是箱子就检查箱子后面有没有空间如果箱子后面也是空的就把箱子推过去否则整个移动失败。下面是一个最简化版本的核心移动函数省略了画布初始化代码const TILE_EMPTY 0; const TILE_WALL 1; const TILE_CRATE 2; const TILE_GOAL 3; let grid [ [1, 1, 1, 1, 1], [1, 0, 2, 0, 1], [1, 0, 2, 0, 1], [1, 3, 0, 0, 1], [1, 1, 1, 1, 1], ]; // player 只记录角色所在的行列 let player { row: 1, col: 1 }; const MOVES { ArrowUp: { dr: -1, dc: 0 }, ArrowDown: { dr: 1, dc: 0 }, ArrowLeft: { dr: 0, dc: -1 }, ArrowRight: { dr: 0, dc: 1 }, }; function tryMove(direction) { const { dr, dc } direction; const nextRow player.row dr; const nextCol player.col dc; const tile grid[nextRow]?.[nextCol]; if (tile undefined || tile TILE_WALL) return false; if (tile TILE_CRATE) { const boxNextRow nextRow dr; const boxNextCol nextCol dc; const boxNextTile grid[boxNextRow]?.[boxNextCol]; if ( boxNextTile undefined || boxNextTile TILE_WALL || boxNextTile TILE_CRATE ) { return false; } grid[boxNextRow][boxNextCol] TILE_CRATE; grid[nextRow][nextCol] TILE_EMPTY; } player { row: nextRow, col: nextCol }; return true; } document.addEventListener(keydown, (event) { const direction MOVES[event.key]; if (!direction) return; event.preventDefault(); tryMove(direction); });这个最小实现里目标格和箱子用的还是同一个静态数组真实项目里出现“箱子压住目标点”时会丢失目标信息。所以实际开发时我更建议把地图拆成两层一层是不可变的静态地图记录墙、地面和目标点另一层是动态状态记录玩家和箱子当前位置。这样判断胜利时遍历所有箱子看它们是否都位于某个目标点上就可以了。代码看起来不复杂但它已经覆盖了一个推箱子游戏最重要的骨架地图网格作为数据结构玩家坐标作为可变状态移动函数作为规则绘制循环作为输出。先把这一步跑通后面所有“复古感”“羊驼皮肤”“音效增强”才有着手点。3. 从“能玩”到“像那么回事”还原一个老游戏的细节维度最小原型跑通之后离“像那么回事”还有很长一段路。这个阶段最需要做的不是拼命加关而是把老游戏里那些你记住了、但说不清楚为什么重要的细节一个一个还原回来。3.1 手感调优速度、停顿和误触推箱子类游戏对“手感”的要求比很多人想象中更苛刻。哪怕名字里带 Slide也需要先判断原版究竟是一个格子一个格子离散移动还是一次滑动到撞墙。这是决定整个重写方向的分叉口。我在做这类游戏时会有一个习惯在还没有完整旧文件可参考时先不猜而是把移动模式做成一个配置项用两三种不同手感分别跑几关再对比老游戏录像或记忆里的操作感受。在 HTML5 里决定手感的主要因素有三个移动单位玩家是按整个格子移动还是按像素移动还是先按下方向键再等待一小段延迟后连续移动。动画插值逻辑上的格子和画面上的位置可以分离。逻辑层立刻改变坐标视觉层用几百毫秒的补间动画把角色“滑”过去。这能让游戏感觉流畅又不影响碰撞正确性。失败反馈当玩家试图把箱子推向墙时游戏不应该只是“什么都不发生”。一个很短的角色抖动或者轻微的音效都能让玩家立刻明白操作无效。老游戏里的很多“顿挫感”来自当时的硬件和动画同步机制而这些感觉恰恰是最难用代码复现的部分。一个常见的陷阱是一开始就去调视觉动画忽略了底层离散逻辑结果画面已经滑到一半碰撞却提前触发玩家会觉得角色像在打滑。我更建议先让底层逻辑在无动画、无插值的状态下跑通确定每一步移动都符合规则。等到逻辑稳定后再给“角色从格子 A 移到格子 B”这个过程加上 easing 动画而不是反过来。顺序反了你大概率会被动画和碰撞串扰的问题耗掉大量时间。3.2 关卡数据、目标点和存档一个复古解谜游戏能不能长久玩下去取决于关卡内容质量而不是引擎多炫。所以在早期阶段就应该把关卡数据从游戏逻辑代码里拆出来。关卡数据不需要很高级用 JSON 数组就够。每个关卡至少包含地图网格、玩家初始位置、箱子初始位置、目标点位置。把数据独立存放之后你甚至可以给自己写一个地图编辑器直接复制粘贴关卡。这里我提供一个非常基础的关卡结构const LEVELS [ { name: Tutorial, grid: [ [1, 1, 1, 1, 1], [1, 0, 2, 0, 1], [1, 0, 2, 0, 1], [1, 3, 0, 0, 1], [1, 1, 1, 1, 1], ], player: { row: 1, col: 1 }, goals: [{ row: 3, col: 1 }], }, ];关卡数据独立后保存进度就是一件小事。浏览器里的标准方案是 localStorage但有一个很容易踩的坑某些浏览器的隐私模式会禁用 localStorage直接写入可能会抛异常。所以保存代码不能裸写要用 try/catch 包一层function saveProgress(currentLevel) { try { localStorage.setItem(alpaca-push.level, String(currentLevel)); } catch (error) { // 隐私模式下写入失败是正常现象至少不要让游戏崩溃 console.warn(进度保存失败可能处于隐私浏览模式); } }更完整的做法是把玩家每一步产生的关卡状态序列保存下来方便后续做“撤销”功能。如果是在做教学项目这同样是一个很好的练习点。3.3 声音、视觉风格与浏览器兼容性老游戏让人记住的视觉只是一部分声音同样重要。不过 HTML5 里的声音处理比想象中更容易遇到环境差异。如果你只是给游戏加几个短音效Web Audio API 比audio元素更可控。你可以用 oscillator 直接合成“哔哔”声也可以加载一段很小的音效文件。另一个关键点是浏览器普遍不希望网页一打开就自动播放声音通常要求用户先与页面产生一次交互。所以在初始化 AudioContext 时我会放在用户第一次点击或第一次按键之后let audioCtx null; function initAudio() { if (audioCtx) return; try { audioCtx new AudioContext(); } catch (error) { console.warn(当前环境不支持 Web Audio API); } } document.addEventListener(click, initAudio, { once: true }); document.addEventListener(keydown, initAudio, { once: true });不要小看这个顺序。不同浏览器对音频自动播放策略并不完全一致尤其是 Safari 这类对资源加载和后台播放限制更严格的环境。喜欢用audio元素做背景音乐的朋友也会在项目里感受一轮“不同浏览器对 HTML5 播放器的支持差异”。解决办法通常是把音频能力限制在用户主动触发后的范围内并提供音量开关。视觉风格的兼容性也要提前考虑。如果项目要用像素风素材Canvas 绘制时可能会在高 DPI 屏幕上显得发虚。一个通用做法是设置 Canvas 的实际分辨率高于 CSS 显示尺寸用devicePixelRatio做缩放。另一个直接有用的 CSS 属性是image-rendering: pixelated可以让放大后的位图保持边缘清晰而不是被浏览器自动模糊。这些细节单个看都不复杂但它们决定了游戏会不会在“我的浏览器里可以换台设备就出问题”。4. 容易踩的坑以及一套相对靠谱的排查顺序做这类重建项目最折磨人的往往不是核心逻辑而是“明明在本地好好的换个环境就出毛病”。这里我总结几个高频问题并给出一个排查思路。4.1 为什么单机跑通换台电脑或手机就出问题第一个最常见的坑是事件绑定错了对象。在桌面浏览器里方向键事件可以监听在document上但如果游戏页面嵌在 iframe 里且 iframe 没有被点击聚焦键盘事件根本不会送达。所以游戏启动后最好先让用户点一下画布区域再把键盘监听挂到window或document上。否则玩家会觉得方向键“时而灵时而不灵”。第二个高频问题是Canvas 尺寸为 0。如果你在 CSS 里给 Canvas 设置了百分比宽度但初始化 Canvas 时没有正确读取父容器高度可能导致宽度正常、高度为 0 的画面。这个问题在移动端特别常见。排查方式很简单在绘制第一帧时输出canvas.width和canvas.height确认它们不是 0。第三个问题是设备像素比不一致。同一张 480x480 的 Canvas在普通屏和 Retina 屏上的显示效果不同。如果不处理 devicePixelRatio