Canvas 2D手搓搜打撤游戏：从零实现核心玩法与性能优化

1. 为什么我放弃了游戏引擎选择 Canvas 2D 手搓搜打撤玩法去年年底《逃离鸭科夫》这类搜打撤玩法火起来的时候我正好在做一个小的独立项目练手。当时第一反应是打开 Unity毕竟现成的物理系统、寻路、动画状态机搭个原型一两天就能跑起来。但真正动手之后我发现一个问题这个玩法的核心乐趣根本不在画面表现上而在于信息博弈——你什么时候进图、带什么装备、听到枪声往哪走、什么时候撤。这些全是逻辑层面的东西跟引擎提供的渲染能力关系不大。于是我做了个决定用原生 Canvas 2D 加 JavaScript 从零写。原因有三个。第一搜打撤的核心循环是进入地图→搜集物资→与 AI 或其他玩家交战→到达撤离点这套逻辑用纯 JS 写反而更清晰没有引擎那层抽象挡在中间。第二Canvas 2D 的渲染开销极低一个俯视角的 2D 地图几百个实体同屏也不会掉帧省去了引擎的启动开销和包体体积。第三也是最重要的一点——我想彻底搞清楚游戏循环、碰撞检测、状态管理这些东西的底层是怎么跑的而不是调几个引擎 API 就完事。这篇文章就是我把这个项目从零跑通之后的完整记录。我会讲清楚为什么这么设计、每一步具体怎么做、踩了哪些坑以及哪些地方看起来能省事但其实会埋雷。适合有 HTML、CSS、JavaScript 基础想理解游戏底层逻辑但不想被引擎绑架的开发者。读完你至少能自己搭出一个可玩的搜打撤原型而不是停留在看过教程的阶段。先说清楚这个项目的技术边界纯前端不依赖任何游戏引擎或物理库用 Canvas 2D 做渲染用 requestAnimationFrame 驱动主循环用原生 DOM 做 UI 层。地图数据、物资分布、AI 行为全部用 JS 对象描述。整个项目跑在浏览器里打开 HTML 就能玩。2. 搜打撤玩法的核心循环拆解与 Canvas 2D 的适配逻辑2.1 搜打撤到底在玩什么三层决策模型很多人第一次接触搜打撤会觉得这不就是射击捡东西跑路吗。但真正玩进去之后你会发现这个玩法的张力来自三层决策的叠加。第一层是入场决策。你带什么装备进图带得越多死了损失越大但活下来的收益也越高。这是一个典型的风险收益权衡。第二层是路线决策。地图上物资点、交战热点、撤离点分布在不同的位置你选择先去哪、走哪条路直接决定了你遇到敌人的概率和能搜到的东西。第三层是撤离决策。什么时候撤听到远处枪声是绕过去还是摸过去背包满了是继续搜还是直接跑这三层决策全部是逻辑层面的跟渲染没关系。Canvas 2D 在这里的优势就体现出来了它足够轻轻到你可以把全部精力放在逻辑设计上而不用去跟引擎的组件系统、预制体、场景管理打交道。我用一个GameState对象来管理全局状态用Map结构存地图数据用简单的数组存实体列表整个数据层不到 500 行就描述清楚了。2.2 为什么不用引擎一次真实的对比测试为了说服自己这个选择是对的我做了个对比。用 Unity 搭一个同样规模的俯视角 2D 场景包含地图渲染、角色移动、碰撞检测、简单的 AI 追踪从新建项目到跑通大概花了 4 个小时其中大部分时间花在配置 Sprite、设置碰撞体、写 Animator 上。用 Canvas 2D 从零写同样的功能花了 6 个小时但其中 5 个小时是在写逻辑只有 1 个小时在处理渲染。关键差异在于调试成本。Canvas 2D 的项目里任何一个 bug 我都能直接在控制台打日志、打断点数据流是透明的。引擎项目里很多问题出在引擎的更新顺序、生命周期回调上你得去猜引擎内部发生了什么。对于搜打撤这种逻辑密集型的玩法透明性比开发速度更重要。当然Canvas 2D 不是万能的。如果你要做 3D 搜打撤、要做复杂的动画混合、要做联网同步那还是老老实实上引擎。但对于一个 2D 俯视角的单机原型Canvas 2D 是性价比最高的选择。2.3 技术选型的边界什么该用 Canvas什么该用 DOM这里有个很多人会踩的坑把所有东西都画在 Canvas 上。我一开始也是这么想的连血条、背包格子都画在 Canvas 里结果发现改一个 UI 样式要重新计算坐标、重新写绘制逻辑效率极低。正确的做法是分层。Canvas 只负责游戏世界里的东西地图、角色、子弹、物资箱、撤离点标记。UI 层全部用 DOM 做血条、背包、小地图、提示文字。DOM 层用绝对定位覆盖在 Canvas 上面通过 CSS 控制样式通过 JS 更新内容。这样改 UI 就是改 CSS改游戏逻辑就是改 Canvas 绘制两边互不干扰。我实测下来这个分层方案让 UI 相关的改动效率提升了至少三倍。比如我想把血条从红色改成渐变绿直接改 CSS 的background就行不用碰任何绘制代码。3. 从零搭建项目骨架HTML 结构、Canvas 初始化与主循环设计3.1 HTML 骨架一个 Canvas 加一个 UI 容器就够了整个项目的 HTML 结构极其简单核心就两个元素一个 Canvas 用来画游戏世界一个 div 容器用来放 UI。其他所有东西都是 JS 动态生成的。!DOCTYPE html html langzh-cn head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleCanvas 2D 搜打撤原型/title link relstylesheet hrefstyle.css /head body div idgame-container canvas idgame-canvas/canvas div idui-layer div idhealth-bar/div div idinventory/div div idminimap/div div idmessage-log/div /div /div script srcmain.js/script /body /html这里有个细节要注意#game-container要设置position: relative#ui-layer设置position: absolute并且铺满容器这样 UI 才能正确覆盖在 Canvas 上。Canvas 的宽高不要用 CSS 控制要用 JS 设置canvas.width和canvas.height否则会出现模糊和坐标偏移的问题。3.2 Canvas 初始化的三个关键参数初始化 Canvas 的时候有三个参数必须搞清楚否则后面一定会出问题。第一个是逻辑分辨率。我设定游戏世界的逻辑尺寸是 1280x720所有游戏内的坐标都基于这个尺寸计算。第二个是实际渲染分辨率。为了适配不同屏幕我会根据窗口大小计算一个缩放比例然后设置canvas.width 1280 * scalecanvas.height 720 * scale。第三个是设备像素比。在高分屏上如果不处理 DPR画面会模糊。处理方式是canvas.width 1280 * scale * dpr然后通过ctx.scale(scale * dpr, scale * dpr)把绘制坐标系缩回逻辑尺寸。const canvas document.getElementById(game-canvas); const ctx canvas.getContext(2d); const LOGICAL_WIDTH 1280; const LOGICAL_HEIGHT 720; function resizeCanvas() { const dpr window.devicePixelRatio || 1; const scale Math.min( window.innerWidth / LOGICAL_WIDTH, window.innerHeight / LOGICAL_HEIGHT ); canvas.width LOGICAL_WIDTH * scale * dpr; canvas.height LOGICAL_HEIGHT * scale * dpr; canvas.style.width LOGICAL_WIDTH * scale px; canvas.style.height LOGICAL_HEIGHT * scale px; ctx.setTransform(scale * dpr, 0, 0, scale * dpr, 0, 0); }这段代码我调了大概两个小时才稳定下来。最容易出错的地方是setTransform的调用时机——每次 resize 都要重新调用否则缩放会叠加。另外canvas.style.width和canvas.width是两个不同的东西前者是 CSS 显示尺寸后者是实际像素缓冲区尺寸搞混了就会出现画面拉伸或者模糊。3.3 主循环固定时间步长与可变渲染帧率的分离游戏主循环是整个项目的心脏。我见过很多教程直接用requestAnimationFrame的 deltaTime 去更新物理这在简单场景下没问题但搜打撤里有子弹飞行、AI 移动、碰撞检测如果帧率波动大物理表现会不稳定。我的做法是固定时间步长更新逻辑可变帧率渲染。逻辑更新固定为每秒 60 次每次步长 1/60 秒。渲染则跟着requestAnimationFrame走能跑多快跑多快。中间用一个累加器来衔接。const FIXED_DT 1 / 60; let accumulator 0; let lastTime performance.now(); function gameLoop(currentTime) { const deltaTime (currentTime - lastTime) / 1000; lastTime currentTime; accumulator deltaTime; while (accumulator FIXED_DT) { updateGame(FIXED_DT); accumulator - FIXED_DT; } renderGame(ctx); requestAnimationFrame(gameLoop); }这个模式的好处是无论你的显示器是 60Hz 还是 144Hz游戏逻辑的更新频率始终是 60 次每秒物理表现完全一致。渲染帧率则跟着显示器走画面更流畅。我实测在 144Hz 屏幕上角色移动的顺滑度明显比直接用 deltaTime 更新要好。注意累加器要设置一个上限比如accumulator Math.min(accumulator, 0.25)防止页面切到后台再切回来时累积了大量时间导致逻辑一次性跑几百步直接卡死。4. 地图、实体与碰撞搜打撤世界的底层数据结构4.1 地图数据怎么存二维数组还是对象列表地图数据的存储方式直接决定了后续碰撞检测和寻路的效率。我试过两种方案。第一种是二维数组每个格子存一个数字表示地形类型0 是空地1 是墙2 是物资点。这种方案的好处是碰撞检测极快直接查数组就行。坏处是地图尺寸受限于数组大小而且物资点这种需要额外属性的东西不好存。第二种是对象列表每个实体是一个对象包含位置、尺寸、类型、属性。这种方案灵活但碰撞检测需要遍历列表实体多了会慢。我最终采用的是混合方案地形用二维数组存因为地形是静态的、格子化的动态实体角色、子弹、物资箱用对象列表存。碰撞检测分两步先查地形数组判断是否撞墙再遍历实体列表判断是否撞到其他实体。这样既保证了地形碰撞的效率又保留了实体的灵活性。const TILE_SIZE 32; const MAP_WIDTH 40; const MAP_HEIGHT 22; // 0空地 1墙 2物资点 3撤离点 const terrainMap [ [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1], // ... 更多行 ];地图尺寸我选了 40x22配合 32 像素的格子正好是 1280x704接近逻辑分辨率。这个尺寸下一局游戏大概有 8 到 10 个物资点3 个撤离点玩起来节奏刚好。4.2 实体系统的设计用组合代替继承实体系统我一开始想用继承Entity基类Player和Enemy继承它。但很快发现一个问题子弹和物资箱也是实体但它们不需要移动逻辑和 AI继承体系会变得很别扭。后来我改成了组合模式。每个实体就是一个普通对象包含position、velocity、size、type这些基础属性然后通过components数组来挂载能力。比如玩家有movable、collidable、hasInventory三个组件子弹只有movable和collidable物资箱只有collidable和lootable。function createPlayer(x, y) { return { type: player, position: { x, y }, velocity: { x: 0, y: 0 }, size: { w: 24, h: 24 }, health: 100, maxHealth: 100, speed: 200, inventory: [], maxInventorySize: 12, components: [movable, collidable, hasInventory, controllable] }; }这种设计的好处是新增一种实体类型只需要组合已有的组件不用改继承树。比如后来我想加一个可拾取的医疗包直接复用collidable和lootable组件就行十分钟搞定。4.3 碰撞检测AABB 足够用但要注意穿透问题搜打撤是俯视角 2D所有实体都是矩形用 AABB轴对齐包围盒碰撞检测完全够用。核心逻辑就是判断两个矩形是否重叠。function checkAABB(a, b) { return a.position.x b.position.x b.size.w a.position.x a.size.w b.position.x a.position.y b.position.y b.size.h a.position.y a.size.h b.position.y; }但这里有个坑高速移动的物体会穿透。子弹速度设成 800 像素每秒在 60 帧下每帧移动 13 像素如果墙的厚度只有 32 像素理论上不会穿透。但如果帧率掉到 30每帧移动 26 像素还是不会穿透。真正会出问题的是当子弹速度超过 1920 像素每秒时每帧移动超过 32 像素就可能直接穿过薄墙。我的解决方案是射线检测。对于子弹这种高速物体不检测当前位置是否碰撞而是检测从上一帧位置到当前位置的线段是否与墙相交。这样无论速度多快都不会穿透。function checkRayCollision(start, end, terrainMap) { const steps Math.ceil( Math.hypot(end.x - start.x, end.y - start.y) / (TILE_SIZE / 2) ); for (let i 0; i steps; i) { const t i / steps; const x start.x (end.x - start.x) * t; const y start.y (end.y - start.y) * t; const tileX Math.floor(x / TILE_SIZE); const tileY Math.floor(y / TILE_SIZE); if (terrainMap[tileY] terrainMap[tileY][tileX] 1) { return { x, y }; } } return null; }这个射线检测我是在测试时发现子弹偶尔穿墙后才加上去的。当时排查了很久一开始以为是碰撞检测的边界条件写错了后来才意识到是速度太快导致的穿透。这个坑很典型凡是涉及高速移动的 2D 游戏都会遇到。5. 搜打撤核心机制的代码实现物资、AI 与撤离判定5.1 物资生成与拾取随机分布加权重控制物资点的生成不能纯随机否则可能出现所有好东西都挤在一个角落的情况。我用的是分区加权随机。把地图分成四个象限每个象限至少生成两个物资点然后根据物资点的等级普通、稀有、传说分配不同的权重。const LOOT_TABLE [ { type: ammo, weight: 40, rarity: common }, { type: medkit, weight: 25, rarity: common }, { type: armor, weight: 15, rarity: rare }, { type: scope, weight: 10, rarity: rare }, { type: golden_gun, weight: 5, rarity: legendary }, { type: keycard, weight: 5, rarity: legendary } ]; function rollLoot() { const totalWeight LOOT_TABLE.reduce((sum, item) sum item.weight, 0); let roll Math.random() * totalWeight; for (const item of LOOT_TABLE) { roll - item.weight; if (roll 0) return { ...item }; } return { ...LOOT_TABLE[0] }; }拾取逻辑很简单玩家走到物资箱附近按 E 键把物资加入背包。但这里有个体验细节——拾取要有反馈。我加了一个短暂的动画物资箱缩小消失同时屏幕右上角弹出提示获得 5.56 弹药 x30。这个反馈看起来不起眼但没有它玩家会不确定自己有没有捡到东西。背包容量我设了 12 格每格可以叠放同类型物资。这个数字是调过的太小了玩家搜两下就满太大了撤离的压力就没了。12 格刚好让玩家需要在继续搜和赶紧撤之间做选择。5.2 AI 行为设计状态机比行为树更适合小项目AI 这块我纠结过用行为树还是状态机。行为树更灵活但实现成本高调试也麻烦。状态机简单直接对于搜打撤这种 AI 行为不算复杂的场景完全够用。我给 AI 设计了四个状态巡逻、警觉、追击、撤退。巡逻时沿着预设路径点移动听到枪声或看到玩家进入视野切换到警觉朝声源方向移动确认玩家位置后进入追击直接朝玩家移动并射击血量低于 30% 时进入撤退朝最近的撤离点移动。function updateAI(enemy, player, dt) { switch (enemy.state) { case patrol: moveAlongPath(enemy, dt); if (canSeePlayer(enemy, player)) { enemy.state alert; enemy.alertTimer 1.5; } break; case alert: enemy.alertTimer - dt; moveToward(enemy, enemy.lastKnownPlayerPos, dt); if (enemy.alertTimer 0) { enemy.state canSeePlayer(enemy, player) ? chase : patrol; } break; case chase: moveToward(enemy, player.position, dt); if (enemy.health enemy.maxHealth * 0.3) { enemy.state retreat; } break; case retreat: moveToward(enemy, getNearestExtraction(enemy.position), dt); break; } }视野检测我用的是距离加角度。AI 有一个 120 度的视野锥距离 300 像素。在视野锥内且没有墙体遮挡就算看到玩家。墙体遮挡用射线检测判断跟子弹的射线检测复用同一套逻辑。实测下来这套 AI 的表现比预期好。玩家在 AI 背后开枪AI 会先转向声源方向然后才开始追击这个延迟给了玩家逃跑的窗口。如果 AI 直接瞬间锁定玩家游戏会变得非常挫败。5.3 撤离判定与结算让撤这个动作有重量撤离是搜打撤的灵魂。如果撤离太容易玩家就不会有紧张感如果太难玩家会挫败。我的设计是地图上有三个撤离点但每局游戏只随机激活其中两个。玩家到达激活的撤离点后需要站立不动 5 秒才能撤离。这 5 秒是精心设计的。它足够长让玩家在撤离过程中可能被 AI 发现又足够短不至于让玩家等得不耐烦。而且站立不动意味着玩家不能边打边撤必须确保周围安全才能撤。function updateExtraction(player, extractionPoints, dt) { for (const point of extractionPoints) { if (!point.active) continue; const dist Math.hypot( player.position.x - point.x, player.position.y - point.y ); if (dist point.radius) { player.extractionProgress dt; if (player.extractionProgress 5) { endGame(extracted, player.inventory); return; } } else { player.extractionProgress 0; } } }结算界面会显示这局带出来的物资总价值以及存活时间、击杀数这些数据。物资价值我按稀有度给了不同的系数传说物品价值是普通物品的 20 倍。这样玩家会有动力去冒险搜传说物资而不是只捡安全的普通物资。6. 渲染与性能Canvas 2D 绘制搜打撤画面的实战技巧6.1 分层渲染静态层缓存与动态层实时绘制Canvas 2D 的性能瓶颈主要在绘制调用次数。如果每帧都重绘整个地图40x22 的格子就是 880 次绘制调用再加上实体、UI很容易掉帧。我的优化方案是分层渲染加离屏缓存。地图是静态的我把它预先绘制到一个离屏 Canvas 上每帧只需要一次drawImage调用把整个地图贴上来。动态实体角色、子弹、物资箱才需要每帧实时绘制。const mapCanvas document.createElement(canvas); mapCanvas.width LOGICAL_WIDTH; mapCanvas.height LOGICAL_HEIGHT; const mapCtx mapCanvas.getContext(2d); function preRenderMap() { for (let y 0; y MAP_HEIGHT; y) { for (let x 0; x MAP_WIDTH; x) { const tile terrainMap[y][x]; if (tile 1) { mapCtx.fillStyle #2a2a2a; mapCtx.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE); } else if (tile 2) { mapCtx.fillStyle #3a3a2a; mapCtx.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE); } } } } function renderGame(ctx) { ctx.clearRect(0, 0, LOGICAL_WIDTH, LOGICAL_HEIGHT); ctx.drawImage(mapCanvas, 0, 0); renderEntities(ctx); renderEffects(ctx); }这个优化效果非常明显。优化前在低端笔记本上只有 40 帧左右优化后稳定 60 帧。绘制调用从每帧上千次降到了几十次。6.2 视野遮挡与战争迷雾用 Canvas 合成模式实现搜打撤的紧张感很大一部分来自你看不到墙后面有什么。我用 Canvas 的合成模式实现了简单的视野遮挡。思路是这样的先正常绘制游戏世界然后用一个半透明的黑色矩形覆盖全屏再用globalCompositeOperation destination-out在黑色矩形上挖出玩家视野范围内的区域。这样玩家视野外就是暗的视野内是亮的。function renderFogOfWar(ctx, player) { ctx.save(); ctx.fillStyle rgba(0, 0, 0, 0.85); ctx.fillRect(0, 0, LOGICAL_WIDTH, LOGICAL_HEIGHT); ctx.globalCompositeOperation destination-out; const gradient ctx.createRadialGradient( player.position.x, player.position.y, 0, player.position.x, player.position.y, 200 ); gradient.addColorStop(0, rgba(0,0,0,1)); gradient.addColorStop(1, rgba(0,0,0,0)); ctx.fillStyle gradient; ctx.beginPath(); ctx.arc(player.position.x, player.position.y, 200, 0, Math.PI * 2); ctx.fill(); ctx.restore(); }这个效果我调了很久。一开始用的是硬边缘的圆看起来像手电筒太生硬。后来改成径向渐变边缘柔和过渡视觉上舒服很多。半径设成 200 像素刚好能看到一个屏幕范围内的东西再远就模糊了。注意globalCompositeOperation是全局状态用完必须restore()否则会影响后续所有绘制。我在这上面踩过坑忘记恢复导致整个画面变成黑白的。6.3 性能监控与帧率稳定一个简单的 FPS 计数器开发过程中需要一个 FPS 计数器来监控性能。实现很简单记录最近 60 帧的时间戳算平均帧间隔。const frameTimes []; function updateFPS(currentTime) { frameTimes.push(currentTime); if (frameTimes.length 60) frameTimes.shift(); if (frameTimes.length 60) { const avg (frameTimes[59] - frameTimes[0]) / 59; const fps Math.round(1000 / avg); document.getElementById(fps-counter).textContent fps FPS; } }这个计数器帮我发现了好几个性能问题。比如有一次物资箱的绘制逻辑里有个shadowBlur每个箱子都加阴影导致帧率从 60 掉到 35。去掉阴影之后立刻恢复。Canvas 2D 的shadowBlur和filter都是性能杀手能不用就不用。7. 踩坑记录那些让我熬夜的 Canvas 2D 陷阱7.1 坐标偏移CSS 尺寸与 Canvas 尺寸不一致的连锁反应这个坑我踩了整整一个晚上。现象是鼠标点击的位置和游戏里实际响应的位置对不上偏了大概几十像素。排查了很久才发现问题出在 CSS 上。我给 Canvas 设了width: 100%但没有设置height导致 Canvas 的显示尺寸被拉伸了但内部像素缓冲区尺寸没变。鼠标事件的clientX是基于显示尺寸的而游戏逻辑用的是内部尺寸两者不一致就产生了偏移。解决方案是永远用 JS 设置 Canvas 尺寸CSS 只控制显示位置。而且鼠标坐标转换要用getBoundingClientRect()来算。canvas.addEventListener(click, (e) { const rect canvas.getBoundingClientRect(); const scaleX LOGICAL_WIDTH / rect.width; const scaleY LOGICAL_HEIGHT / rect.height; const gameX (e.clientX - rect.left) * scaleX; const gameY (e.clientY - rect.top) * scaleY; handleClick(gameX, gameY); });这段代码看起来简单但scaleX和scaleY必须分开算因为宽高比可能不一致。我一开始只算了一个 scale结果在非标准比例的屏幕上坐标还是偏。7.2 状态污染save 和 restore 必须成对出现Canvas 的save()和restore()是成对的但很多人会忘记restore()导致状态污染。我遇到过一次诡异的现象游戏运行几分钟后所有绘制都变成了半透明。排查后发现是在绘制视野遮挡时调用了ctx.save()但中间有个return提前退出了函数restore()没执行。每次渲染都漏一次restore()状态栈越积越深最终导致透明度异常。解决方案是用 try-finally 包裹确保restore()一定执行。function renderWithState(ctx, drawFn) { ctx.save(); try { drawFn(ctx); } finally { ctx.restore(); } }这个模式我后来在所有涉及状态修改的绘制里都用了再也没出现过状态污染的问题。7.3 事件监听泄漏游戏结束后还在跑的定时器游戏结束之后如果不清除事件监听和定时器会导致内存泄漏和奇怪的 bug。我遇到过一次游戏结束后重新开始角色移动速度变成了两倍。原因是上一局的事件监听没清除两个监听器同时响应速度叠加了。解决方案是用一个gameSession对象管理所有监听器和定时器游戏结束时统一清理。const gameSession { listeners: [], timers: [], addListener(target, event, handler) { target.addEventListener(event, handler); this.listeners.push({ target, event, handler }); }, addTimer(id) { this.timers.push(id); }, cleanup() { this.listeners.forEach(({ target, event, handler }) { target.removeEventListener(event, handler); }); this.timers.forEach(id clearInterval(id)); this.listeners []; this.timers []; } };这个清理逻辑看起来不起眼但它是保证游戏可以反复重开而不出 bug 的关键。我建议在项目一开始就把这套机制建好不要等到出问题了再补。8. 从原型到可玩平衡性调整与后续扩展方向8.1 数值平衡让每一局都有取舍原型跑通之后最大的工作量其实是数值平衡。我调了大概三十多局才把几个关键数值定下来。参数初始值最终值调整原因玩家移速300200太快了AI 完全追不上没有紧张感AI 视野距离500300太远玩家刚进图就被发现撤离等待时间3 秒5 秒3 秒太短玩家可以边跑边撤背包容量20 格12 格20 格太宽松玩家没有撤离压力传说物资权重105传说物资出现太频繁失去稀有性这些数值没有绝对的对错取决于你想要什么样的游戏体验。我的目标是让玩家在搜到第三个物资点的时候开始纠结要不要撤所以背包容量和物资价值曲线都是围绕这个目标调的。8.2 音效与反馈没有声音的搜打撤是没有灵魂的Canvas 2D 本身不处理音频但可以用Audio对象或者 Web Audio API。我用的是最简单的Audio对象预加载几个音效文件需要的时候play()。const sounds { shoot: new Audio(sounds/shoot.wav), pickup: new Audio(sounds/pickup.wav), hit: new Audio(sounds/hit.wav), extract: new Audio(sounds/extract.wav) }; function playSound(name) { const sound sounds[name]; sound.currentTime 0; sound.play().catch(() {}); }音效对体验的提升是巨大的。加了枪声之后玩家能通过声音判断敌人的方向和距离这直接增加了信息博弈的层次。拾取音效和撤离音效则提供了即时的正反馈。注意浏览器的自动播放策略会阻止音频在用户交互之前播放。所以第一次播放音效必须在用户点击或按键之后否则会被静默拦截。我在初始化时加了一个点击开始的按钮来解决这个问题。8.3 后续可以扩展的方向这个原型目前只实现了最核心的循环还有很多可以扩展的地方。比如多人在线用 WebSocket 做状态同步把单机 AI 换成真实玩家博弈层次会完全不同。比如装备系统让玩家在局外配置装备带入局内死了就丢失增加风险感。比如地图随机生成每局地图布局不同增加重复可玩性。但我的建议是先把核心循环打磨到好玩再考虑扩展。很多项目死在功能太多、核心不好玩上。搜打撤的核心就是搜、打、撤三个动作的节奏感这三个动作的反馈做好了游戏就成立了。我个人在实际操作中的体会是Canvas 2D 做搜打撤原型最大的优势不是性能而是迭代速度。改一个数值、加一个状态、调一个碰撞逻辑都是改几行 JS 的事保存刷新就能看到效果。这种快速迭代的能力对于需要大量试错来打磨玩法的项目来说比引擎提供的任何高级功能都重要。