企业官网建设流程全解析

1. 为什么我放弃了游戏引擎，选择 Canvas 2D 手搓搜打撤玩法

1.1 从《逃离鸭科夫》说起：搜打撤玩法的核心魅力在哪

《逃离鸭科夫》这个游戏最近在圈子里讨论度很高，它本质上是一个“搜打撤”类型的玩法框架——你进入一张地图，搜集物资，跟敌人或其他玩家交火，然后在限定时间内找到撤离点安全离开。听起来简单，但真正让它上瘾的是那种“带出去的才是你的，死了就全没了”的紧张感。这种玩法最早可以追溯到一些硬核射击游戏，但《逃离鸭科夫》用更轻量的方式把它做成了一个独立体验，节奏更快，门槛更低，但核心的博弈感一点没少。

我之所以想用 Canvas 2D 来复现这个玩法，原因很直接：游戏引擎虽然强大，但对于一个 2D 俯视角的搜打撤小游戏来说，很多功能其实用不上。Unity 或 Godot 当然能做得更好，但它们的体积、学习曲线、以及“杀鸡用牛刀”的感觉让我不太舒服。Canvas 2D 加上原生 JavaScript，整个项目就是一个 HTML 文件加几个 JS 模块，打开浏览器就能跑，分享给朋友也只需要发一个链接或者一个文件夹。这种轻量化的开发体验，对于想快速验证玩法原型的人来说，效率高得不是一点半点。

更重要的是，用 Canvas 2D 手搓游戏能让你真正理解游戏循环、碰撞检测、状态管理这些底层逻辑。引擎帮你封装了太多东西，用久了容易产生依赖。我自己就是从引擎转回原生开发的，刚开始确实有点不适应，但一旦把渲染循环、输入处理、实体管理这些基础搭起来，后面加功能反而更自由。你不需要跟引擎的更新日志较劲，也不需要为了一个小功能去翻半天文档。

1.2 Canvas 2D 做搜打撤的可行性分析

有人可能会问：Canvas 2D 性能够吗？能做复杂的 AI 和碰撞吗？我的实测答案是：对于俯视角、像素风、同屏实体数量在 100 以内的搜打撤游戏，Canvas 2D 完全够用。关键在于你怎么组织渲染和更新逻辑。如果你每帧都重绘整个场景，那确实会卡；但如果你用脏矩形或者分层 Canvas，性能可以优化到很流畅的程度。

搜打撤玩法的核心要素其实不复杂：地图、玩家、敌人、物资、撤离点、计时器、背包系统。这些用 Canvas 2D 都能很自然地实现。地图可以用二维数组表示，每个格子对应一个地形类型；玩家和敌人就是带有位置、速度、碰撞半径的实体；物资就是地图上的可交互点；撤离点就是一个触发区域。整个游戏状态可以用一个对象来管理，每帧更新一次，然后渲染出来。

localStorage 在这里扮演的是存档和排行榜的角色。你可以把玩家的最高撤离收益、存活局数、击杀数存下来，下次打开页面还能看到。虽然 localStorage 有大小限制，但对于这种小游戏来说，存几个 JSON 对象绰绰有余。而且它不需要后端，纯前端就能跑，部署成本几乎为零。

1.3 技术选型背后的取舍：为什么不用框架和库

我见过很多人一上来就上 Phaser、PixiJS 这些 2D 渲染库，它们确实能省不少事。但我的选择是：只用原生 Canvas API，不引入任何渲染库。原因有三点。第一，我想保持项目的纯粹性，一个 HTML 文件加一个 JS 文件就能跑，不需要 npm install，不需要构建工具。第二，搜打撤玩法的渲染需求并不复杂，无非是矩形、圆形、文字和简单的图片，Canvas 原生 API 完全覆盖。第三，自己手写渲染循环能让我对每一帧的开销有更清晰的掌控，优化起来更有针对性。

当然，这并不意味着我反对用库。如果你要做的是更复杂的 2D 游戏，比如有大量粒子效果、骨骼动画、复杂光照，那 PixiJS 这类库确实更合适。但对于一个搜打撤原型来说，原生 Canvas 的简洁性反而是优势。你不需要理解库的抽象层，所有代码都是直白的“清空画布、画东西、再画下一帧”。

2. 核心系统拆解：一个搜打撤游戏到底需要哪些模块

2.1 游戏循环与状态机设计

任何游戏的核心都是一个循环：更新逻辑、渲染画面、重复。在 Canvas 2D 里，这个循环通常用requestAnimationFrame来驱动。我习惯把循环拆成三个部分：update(deltaTime)负责更新所有实体的位置和状态，render()负责把当前状态画到 Canvas 上，gameLoop()负责计算时间差并调用前两者。deltaTime是关键，它让游戏逻辑与帧率解耦，不管你是 60 帧还是 144 帧，游戏速度都是一致的。

状态机方面，搜打撤游戏至少需要这几个状态：主菜单、游戏中、暂停、结算。我用一个简单的gameState变量来管理，每个状态对应不同的更新和渲染逻辑。比如在主菜单状态下，我只渲染标题和开始按钮；在游戏中状态下，我更新玩家、敌人、物资和计时器；在结算状态下，我显示本局收益和撤离结果。状态之间的切换通过事件触发，比如玩家点击开始按钮就从主菜单切到游戏中，玩家死亡或成功撤离就切到结算。

这里有个容易踩的坑：状态切换时一定要清理上一状态的残留数据。比如从游戏中切到结算时，要停止计时器、清空敌人数组、重置玩家输入。我一开始没注意这点，结果从结算返回主菜单再开始新游戏时，上一局的敌人还在场上，直接把我围殴了。后来我养成了一个习惯：每个状态都有一个enter()和exit()方法，进入时初始化，退出时清理。

2.2 地图生成与碰撞检测

地图我用二维数组来表示，每个元素是一个数字，代表不同的地形：0 是空地，1 是墙，2 是物资点，3 是撤离点。地图大小我设定为 40x30 个格子，每个格子 32x32 像素，这样整个地图就是 1280x960 像素。Canvas 大小设为 960x640，所以地图比视口大，需要摄像机跟随玩家移动。摄像机逻辑很简单：每帧计算玩家的位置，然后调整渲染偏移量，让玩家始终在屏幕中央。

碰撞检测我用的是 AABB（轴对齐包围盒）加上圆形碰撞的混合方案。玩家和敌人都是圆形碰撞体，墙是矩形。检测圆形和矩形是否相交，我用的是“最近点”方法：找到矩形上离圆心最近的点，然后判断这个点到圆心的距离是否小于半径。这个方法比单纯的 AABB 更准确，而且计算量也不大。物资点和撤离点则是圆形触发区域，玩家进入范围就触发交互。

地图生成我用了简单的随机算法：先全部填成空地，然后随机放置一些墙壁，确保不会把地图堵死。物资点随机分布在空地上，撤离点放在地图的边缘区域。为了让每局游戏都有变化，我用了Math.random()来生成不同的地图布局。但纯随机有时候会生成很糟糕的地图，比如物资点全挤在一个角落，或者撤离点被墙围死。后来我加了一个简单的验证：生成后检查从玩家出生点到每个撤离点是否连通，如果不连通就重新生成。这个检查用 BFS（广度优先搜索）实现，虽然增加了生成时间，但保证了地图的可用性。

2.3 玩家控制与输入处理

玩家控制我用了 WASD 移动加鼠标瞄准的方案。WASD 控制移动方向，鼠标控制朝向，左键射击。输入处理的核心是维护一个keys对象，记录每个按键的按下状态。keydown事件把对应按键设为true，keyup设为false。在update()里，我根据keys的状态计算玩家的移动向量，然后归一化，乘以速度和时间差，得到位移量。

鼠标瞄准需要把屏幕坐标转换成世界坐标。因为摄像机有偏移，所以世界坐标 = 屏幕坐标 + 摄像机偏移。射击时，我从玩家位置向鼠标世界坐标发射一颗子弹，子弹的方向就是两点之间的单位向量。子弹有速度、伤害、存活时间三个属性，每帧更新位置，检测与敌人和墙的碰撞。

这里有个细节：输入处理一定要考虑按键冲突和焦点问题。比如玩家按住 W 和 D 时，移动向量应该是右上方向，而不是先右后上。我用向量加法来处理：moveX = (D ? 1 : 0) - (A ? 1 : 0)，moveY = (S ? 1 : 0) - (W ? 1 : 0)，然后归一化。另外，当浏览器窗口失去焦点时，要清空所有按键状态，否则玩家切出去再切回来，角色会一直往一个方向跑。这个 bug 我调试了半小时才找到原因。

2.4 敌人 AI 与战斗逻辑

敌人 AI 我做了三个层次：巡逻、追击、攻击。巡逻状态下，敌人沿着预设的路径点移动，或者随机在附近游荡。追击状态下，敌人朝玩家当前位置移动。攻击状态下，敌人停止移动，朝玩家射击。状态切换的条件是距离：玩家进入视野范围（比如 300 像素）就切到追击，进入攻击范围（比如 200 像素）就切到攻击，超出视野就回到巡逻。

视野检测我用的是简单的距离判断加上射线检测。距离判断很快，但不够精确，因为敌人可能隔着墙看到玩家。射线检测用 Bresenham 算法，从敌人位置向玩家位置画一条线，检查中间是否有墙。如果有墙，就认为看不到。这个算法在网格地图上效率很高，不需要复杂的光线投射。

战斗逻辑方面，敌人和玩家一样有生命值、子弹、射击冷却。敌人射击时，我加了一点随机偏移，让子弹不会百发百中，否则玩家根本没法玩。伤害计算很简单：子弹命中就扣血，血量归零就死亡。玩家死亡后进入结算状态，敌人死亡后从数组中移除，并掉落一些物资。

2.5 物资搜集与背包系统

物资点在地图上用圆形标记，玩家靠近后按 E 键搜集。搜集时，我从物资点的掉落表中随机抽取物品，放进玩家的背包。背包我用一个数组来表示，每个物品有名称、价值、重量三个属性。重量影响玩家的移动速度，价值决定撤离时的收益。这个设计是为了让玩家做取舍：是拿高价值但重的物品，还是拿低价值但轻的物品。

背包界面我用 Canvas 直接绘制，按 Tab 键打开。打开时游戏暂停，显示当前背包物品列表和总重量、总价值。玩家可以丢弃物品来减轻重量。丢弃的物品会掉在地上，可以重新捡起。这个交互逻辑不复杂，但状态管理要小心：打开背包时要记录游戏状态，关闭时恢复。

localStorage 在这里用来保存玩家的历史最高收益和总撤离次数。每次结算时，我读取 localStorage 里的数据，比较并更新最高收益，然后写回去。数据格式就是一个 JSON 对象：{ maxProfit: 1000, totalExtracts: 5, totalDeaths: 3 }。读取时用JSON.parse，写入时用JSON.stringify。注意 localStorage 只能存字符串，所以一定要序列化。

3. 从零搭建：完整实操流程与关键代码解析

3.1 项目结构搭建与 Canvas 初始化

项目结构我保持极简：一个index.html，一个style.css，一个game.js。HTML 里只需要一个 Canvas 元素和一个用于显示 UI 的覆盖层。CSS 负责让 Canvas 居中、去除滚动条、设置背景色。JS 里所有逻辑都写在一个文件里，用立即执行函数包裹，避免污染全局作用域。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>逃离鸭科夫风格搜打撤</title> <link rel="stylesheet" href="style.css"> </head> <body> <canvas id="gameCanvas" width="960" height="640"></canvas> <div id="uiOverlay"></div> <script src="game.js"></script> </body> </html>

Canvas 初始化时，我获取 2D 上下文，设置imageSmoothingEnabled = false，这样像素风渲染不会模糊。然后初始化游戏状态、地图、玩家、敌人数组、子弹数组、物资数组。所有初始化逻辑放在init()函数里，页面加载完成后调用。

const canvas = document.getElementById('gameCanvas'); const ctx = canvas.getContext('2d'); ctx.imageSmoothingEnabled = false; const TILE_SIZE = 32; const MAP_COLS = 40; const MAP_ROWS = 30; const VIEW_WIDTH = canvas.width; const VIEW_HEIGHT = canvas.height;

3.2 地图数据生成与渲染

地图生成我用了一个generateMap()函数，返回一个二维数组。先生成全部空地，然后随机放置墙壁，再放置物资点和撤离点。墙壁的生成我用了“随机游走”算法：从地图中间开始，随机选择一个方向走几步，把经过的格子设为墙。这样生成的墙壁比较自然，不会像纯随机那样杂乱无章。

function generateMap() { const map = []; for (let y = 0; y < MAP_ROWS; y++) { map[y] = []; for (let x = 0; x < MAP_COLS; x++) { map[y][x] = 0; } } // 随机游走生成墙壁 let wx = Math.floor(MAP_COLS / 2); let wy = Math.floor(MAP_ROWS / 2); for (let i = 0; i < 200; i++) { const dir = Math.floor(Math.random() * 4); if (dir === 0) wx++; else if (dir === 1) wx--; else if (dir === 2) wy++; else wy--; wx = Math.max(1, Math.min(MAP_COLS - 2, wx)); wy = Math.max(1, Math.min(MAP_ROWS - 2, wy)); map[wy][wx] = 1; } // 放置物资点 for (let i = 0; i < 15; i++) { const x = Math.floor(Math.random() * MAP_COLS); const y = Math.floor(Math.random() * MAP_ROWS); if (map[y][x] === 0) map[y][x] = 2; } // 放置撤离点 map[1][1] = 3; map[MAP_ROWS - 2][MAP_COLS - 2] = 3; return map; }

渲染地图时，我只渲染视口内的格子，避免不必要的绘制。摄像机偏移量用camera.x和camera.y表示，每帧根据玩家位置更新。渲染循环里，我先计算视口对应的格子范围，然后遍历这个范围，根据格子类型画不同的颜色。墙是深灰色，空地是浅灰色，物资点是黄色圆形，撤离点是绿色圆形。

function renderMap() { const startCol = Math.floor(camera.x / TILE_SIZE); const endCol = Math.ceil((camera.x + VIEW_WIDTH) / TILE_SIZE); const startRow = Math.floor(camera.y / TILE_SIZE); const endRow = Math.ceil((camera.y + VIEW_HEIGHT) / TILE_SIZE); for (let y = startRow; y <= endRow; y++) { for (let x = startCol; x <= endCol; x++) { if (y < 0 || y >= MAP_ROWS || x < 0 || x >= MAP_COLS) continue; const tile = map[y][x]; const screenX = x * TILE_SIZE - camera.x; const screenY = y * TILE_SIZE - camera.y; if (tile === 1) { ctx.fillStyle = '#3a3a3a'; ctx.fillRect(screenX, screenY, TILE_SIZE, TILE_SIZE); } else { ctx.fillStyle = '#2a2a2a'; ctx.fillRect(screenX, screenY, TILE_SIZE, TILE_SIZE); } if (tile === 2) { ctx.beginPath(); ctx.arc(screenX + TILE_SIZE/2, screenY + TILE_SIZE/2, 8, 0, Math.PI*2); ctx.fillStyle = '#ffcc00'; ctx.fill(); } if (tile === 3) { ctx.beginPath(); ctx.arc(screenX + TILE_SIZE/2, screenY + TILE_SIZE/2, 12, 0, Math.PI*2); ctx.fillStyle = '#00ff88'; ctx.fill(); } } } }

3.3 玩家移动、射击与碰撞实现

玩家对象我定义为一个包含位置、速度、半径、生命值、背包等属性的对象。移动逻辑在updatePlayer()里，根据按键状态计算移动向量，归一化后乘以速度和时间差。碰撞检测在移动之后进行，如果新位置与墙相交，就回退到旧位置。这个“先移动再检测”的方式比“先检测再移动”简单，但需要保存旧位置。

function updatePlayer(dt) { let moveX = 0, moveY = 0; if (keys['w'] || keys['arrowup']) moveY -= 1; if (keys['s'] || keys['arrowdown']) moveY += 1; if (keys['a'] || keys['arrowleft']) moveX -= 1; if (keys['d'] || keys['arrowright']) moveX += 1; if (moveX !== 0 || moveY !== 0) { const len = Math.sqrt(moveX * moveX + moveY * moveY); moveX /= len; moveY /= len; } const speed = player.baseSpeed * (1 - player.backpackWeight / player.maxWeight * 0.5); const oldX = player.x; const oldY = player.y; player.x += moveX * speed * dt; player.y += moveY * speed * dt; if (checkWallCollision(player.x, player.y, player.radius)) { player.x = oldX; player.y = oldY; } // 鼠标瞄准 const worldMouseX = mouse.x + camera.x; const worldMouseY = mouse.y + camera.y; player.angle = Math.atan2(worldMouseY - player.y, worldMouseX - player.x); }

射击逻辑在鼠标按下时触发，检查冷却时间，然后创建一颗子弹。子弹从玩家位置出发，方向是玩家朝向，速度比玩家移动速度快很多。子弹每帧更新位置，检测与墙和敌人的碰撞。与墙碰撞就销毁，与敌人碰撞就扣血并销毁。

function shoot() { const now = performance.now(); if (now - player.lastShot < player.shootCooldown) return; player.lastShot = now; const spread = (Math.random() - 0.5) * 0.1; const angle = player.angle + spread; bullets.push({ x: player.x, y: player.y, vx: Math.cos(angle) * 800, vy: Math.sin(angle) * 800, damage: 25, life: 1.0, owner: 'player' }); }

3.4 敌人 AI 状态切换与行为树简化版

敌人 AI 我用了一个简化的状态机，每个敌人有一个state属性，取值patrol、chase、attack。每帧根据与玩家的距离切换状态。巡逻时，敌人朝一个随机方向移动，碰到墙就换方向。追击时，敌人朝玩家位置移动，但会避开墙壁。攻击时，敌人停止移动，朝玩家射击。

function updateEnemy(enemy, dt) { const dx = player.x - enemy.x; const dy = player.y - enemy.y; const dist = Math.sqrt(dx * dx + dy * dy); if (dist < 200) { enemy.state = 'attack'; } else if (dist < 400) { enemy.state = 'chase'; } else { enemy.state = 'patrol'; } if (enemy.state === 'patrol') { enemy.x += Math.cos(enemy.patrolAngle) * enemy.speed * dt; enemy.y += Math.sin(enemy.patrolAngle) * enemy.speed * dt; if (checkWallCollision(enemy.x, enemy.y, enemy.radius)) { enemy.x -= Math.cos(enemy.patrolAngle) * enemy.speed * dt; enemy.y -= Math.sin(enemy.patrolAngle) * enemy.speed * dt; enemy.patrolAngle = Math.random() * Math.PI * 2; } } else if (enemy.state === 'chase') { const angle = Math.atan2(dy, dx); const oldX = enemy.x; const oldY = enemy.y; enemy.x += Math.cos(angle) * enemy.speed * dt; enemy.y += Math.sin(angle) * enemy.speed * dt; if (checkWallCollision(enemy.x, enemy.y, enemy.radius)) { enemy.x = oldX; enemy.y = oldY; } } else if (enemy.state === 'attack') { enemy.angle = Math.atan2(dy, dx); const now = performance.now(); if (now - enemy.lastShot > enemy.shootCooldown) { enemy.lastShot = now; const spread = (Math.random() - 0.5) * 0.2; const angle = enemy.angle + spread; bullets.push({ x: enemy.x, y: enemy.y, vx: Math.cos(angle) * 600, vy: Math.sin(angle) * 600, damage: 15, life: 1.0, owner: 'enemy' }); } } }

3.5 撤离点判定与 localStorage 存档

撤离点判定很简单：每帧检查玩家与每个撤离点的距离，如果小于触发半径，就启动撤离倒计时。倒计时结束后，如果玩家还在范围内，就判定撤离成功，进入结算状态。倒计时期间，玩家移动会中断撤离，需要重新等待。

function checkExtraction(dt) { let inExtraction = false; for (const point of extractionPoints) { const dx = player.x - point.x; const dy = player.y - point.y; if (Math.sqrt(dx * dx + dy * dy) < 40) { inExtraction = true; break; } } if (inExtraction) { extractionTimer += dt; if (extractionTimer >= 3.0) { endGame(true); } } else { extractionTimer = 0; } }

localStorage 存档在endGame()里处理。读取历史数据，更新最高收益和总撤离次数，然后写回。注意要处理 localStorage 不可用的情况，比如隐私模式，用 try-catch 包裹。

function saveStats(profit, extracted) { try { const stats = JSON.parse(localStorage.getItem('gameStats') || '{}'); stats.maxProfit = Math.max(stats.maxProfit || 0, profit); stats.totalExtracts = (stats.totalExtracts || 0) + (extracted ? 1 : 0); stats.totalDeaths = (stats.totalDeaths || 0) + (extracted ? 0 : 1); localStorage.setItem('gameStats', JSON.stringify(stats)); } catch (e) { console.warn('localStorage 不可用，存档失败'); } }

4. 踩坑实录：那些让我熬夜调试的典型问题

4.1 性能问题排查：从 20 帧到 60 帧的优化过程

刚开始做的时候，我没注意渲染优化，每帧都遍历整个地图的所有格子，结果地图一大，帧率直接掉到 20。后来我改成只渲染视口内的格子，帧率立刻回到 60。这个优化很简单，但效果立竿见影。计算视口范围只需要四个除法，然后遍历这个范围，而不是整个地图。

另一个性能问题是子弹和敌人的碰撞检测。我一开始用双重循环，每颗子弹跟每个敌人检测，敌人多了之后 O(n*m) 的复杂度就扛不住了。后来我加了一个简单的空间划分：把地图分成几个区域，只检测同一区域内的子弹和敌人。虽然实现起来麻烦一点，但性能提升很明显。

还有一个容易被忽略的点：ctx.save()和ctx.restore()的调用次数。我一开始在每个绘制函数里都调用，结果一帧下来几百次，开销不小。后来我改成只在需要变换的时候调用，比如旋转敌人朝向时，其他时候直接设置fillStyle和fillRect，性能好了不少。

4.2 碰撞检测的边界情况与解决方案

碰撞检测最头疼的是“卡墙”问题。玩家贴着墙走的时候，如果移动方向稍微偏向墙内，就会被判定为碰撞，然后回退，导致玩家在墙边抖动。我试过几种方案：一种是分离 X 轴和 Y 轴的移动，先移动 X 再检测，再移动 Y 再检测，这样即使一个方向被挡住，另一个方向还能走。另一种是加一个“滑动”逻辑，碰撞后沿着墙的切线方向移动。我最后用了分离轴方案，实现简单，效果也不错。

另一个边界情况是高速子弹穿墙。子弹速度是 800 像素/秒，如果帧率是 60，每帧移动 13 像素，而墙的厚度是 32 像素，一般不会穿。但如果帧率掉到 30，每帧移动 26 像素，还是不会穿。但如果子弹速度再快，或者墙很薄，就可能穿过去。解决方案是用射线检测代替点检测：从子弹当前位置到下一帧位置画一条线，检测这条线是否与墙相交。我用的是 Bresenham 算法，在网格地图上效率很高。

4.3 localStorage 数据丢失与兼容性处理

localStorage 在隐私模式下会抛异常，这个我一开始没处理，结果用户反馈说游戏打不开。后来我加了 try-catch，如果 localStorage 不可用，就降级到内存存储，虽然刷新就没了，但至少不会报错。另外，localStorage 存的是字符串，如果直接存对象，读出来是[object Object]，必须用JSON.stringify和JSON.parse。

还有一个坑是数据版本兼容。我后来加了新字段，但老用户存的数据里没有这个字段，读取时就是undefined。解决方案是给每个字段设默认值，比如stats.maxProfit = stats.maxProfit || 0。这样即使数据格式变了，也不会崩溃。

4.4 常见问题速查表

4.5 独家避坑技巧与实操心得

第一个心得：游戏循环里不要做任何 DOM 操作。我一开始在update()里更新 UI 文字，结果每帧都触发重排，性能很差。后来我改成只在状态变化时更新 UI，比如血量变化、背包变化时才更新 DOM，帧率稳定了很多。

第二个心得：用requestAnimationFrame的时间戳计算 deltaTime，不要用Date.now()。requestAnimationFrame传入的时间戳精度更高，而且与浏览器刷新率同步。计算 deltaTime 时要设一个上限，比如 0.1 秒，防止切标签页回来后 deltaTime 过大导致实体瞬移。

第三个心得：敌人 AI 的随机性要控制。我一开始让敌人完全随机移动，结果它们像无头苍蝇一样乱撞，玩家很容易就能躲开。后来我加了“巡逻路径点”的概念，敌人在几个固定点之间移动，发现玩家后才切换状态。这样敌人的行为更有规律，也更有挑战性。

第四个心得：背包重量影响速度的公式要调参。我一开始用线性公式，结果背包一重，玩家就慢得像蜗牛。后来改成speed = baseSpeed * (1 - weight / maxWeight * 0.5)，这样即使背包满了，速度也只降到一半，游戏体验好很多。参数调优没有捷径，就是多试几组值，找手感最好的。

第五个心得：撤离点的位置要合理。我一开始把撤离点放在地图角落，结果玩家要穿越整个地图才能撤离，风险太高。后来我改成放在地图边缘的中间位置，并且每局随机选择两个撤离点中的一个激活。这样玩家有选择，但也要承担相应的风险。

5. 后续扩展方向与个人体会

这个项目做完之后，我最大的感受是：Canvas 2D 做搜打撤游戏完全可行，而且开发效率比想象中高。整个项目从零到能玩，我花了大概三个晚上，代码量不到 1500 行。当然，这只是一个原型，还有很多可以扩展的地方。

比如可以加一个简单的音效系统，用 Web Audio API 播放射击声、脚步声、撤离成功提示音。音效对游戏氛围的提升很大，而且实现起来不难。还可以加一个“任务系统”，每局随机生成几个任务，比如“搜集三个医疗包”或“击杀两个敌人”，完成任务有额外奖励。这样玩家每局都有目标，不会漫无目的地乱逛。

另一个方向是多人联机，但这个复杂度就高很多了，需要后端服务器和网络同步。如果只是本地双人，可以用分屏或者共享键盘的方式实现，但体验肯定不如单人。我个人觉得，对于这种轻量级搜打撤游戏，单人体验已经足够有趣，联机反而是锦上添花。

最后分享一个小技巧：如果你也想用 Canvas 2D 做游戏，建议先从最小的可玩原型开始。不要一上来就设计复杂的系统，先让一个方块能动，再让它能射击，再加敌人，再加地图。每加一个功能就测试一次，确保没有引入新的 bug。这种迭代式的开发方式，比一次性写完再调试要高效得多。我在这个项目里踩的坑，大部分都是因为想一次性把功能做全，结果调试的时候找不到问题出在哪。后来我改成小步快跑，每次只加一个功能，问题就好定位多了。