1. 为什么我放弃了游戏引擎来做这个搜打撤原型去年年底《逃离鸭科夫》这类搜打撤玩法火起来之后我身边不少做前端的朋友都在琢磨能不能用自己最熟的那套东西快速搓一个能跑起来的原型我自己也动了这个念头。一开始我下意识地想去装个轻量引擎但折腾了半天发现为了一个 2D 俯视角、核心逻辑就是进图—搜刮—打架—撤离的小原型引入一整套引擎反而把简单问题复杂化了。引擎的编辑器、场景树、资源管线、构建流程每一样都要学而我想验证的其实只是玩法循环本身。后来我干脆把引擎全卸了回到最原始的Canvas 2D 原生 JavaScript。结果三天时间一个能跑、能玩、能验证手感的搜打撤原型就出来了。这篇文章就是把这套做法的完整思路和踩过的坑摊开讲清楚。它适合三类人一是想快速验证游戏玩法、不想被引擎学习曲线拖住的前端开发者二是想用一个小项目把 Canvas 2D 真正吃透的人三是做独立游戏、预算和精力都有限、需要最小可行原型的开发者。先说清楚这个原型的边界它是一个单机、俯视角、2D 的搜打撤玩法验证 Demo不是商业级产品。它包含地图生成、玩家移动、视野遮挡、敌人 AI、物品搜刮、背包容量、撤离点判定这一整套核心循环。所有渲染都走 Canvas 2D 的 2D 上下文所有逻辑都是纯 JS没有任何第三方游戏库。下面我会从架构设计、渲染、玩法系统、性能优化几个层面把为什么这么设计和具体怎么做都讲透。2. 不用引擎的底气Canvas 2D 到底能扛住什么2.1 先想清楚引擎替你做了什么很多人一上来就问不用引擎行不行其实这个问题问反了。正确的问法是引擎到底替我做了哪些事这些事我自己做要花多少成本把引擎的能力拆开看无非是这几块渲染循环、资源加载、场景管理、物理碰撞、输入处理、音频、UI 系统。对于搜打撤这种 2D 俯视角玩法物理只需要 AABB 矩形碰撞和圆碰撞场景就是一张地图加若干实体UI 就是几个数字和血条。这些用原生 API 实现代码量远比想象中小。真正需要引擎的是 3D、复杂物理、大规模粒子、跨平台打包这些场景。而一个 2D 搜打撤原型核心难点根本不在渲染管线而在玩法数值和手感调优。引擎在这件事上帮不了你反而会增加你改一个数值就要重新构建的摩擦。这就是我选择裸写 Canvas 的根本原因把复杂度花在玩法上而不是花在工具链上。2.2 Canvas 2D 的性能天花板在哪必须承认Canvas 2D 是有性能上限的。它的绘制是 CPU 驱动的部分浏览器有 GPU 加速合成每帧的fillRect、drawImage、arc调用次数直接决定帧率。我实测下来在普通笔记本上每帧 2000 到 3000 个简单绘制调用基本能稳住 60 帧超过之后开始掉帧。这个数字对搜打撤原型来说完全够用——一张地图上同时存在的实体玩家、敌人、掉落物、子弹、特效通常不会超过几百个。关键在于别做无谓的绘制。我见过太多人写 Canvas 游戏每帧把整个地图重画一遍包括那些根本不在屏幕里的东西。正确做法是视口裁剪只画摄像机可见范围内的实体。这一条优化就能把绘制调用砍掉一大半。另外静态的地图背景不要每帧重画预渲染到一张离屏 Canvas 上每帧只drawImage一次性能立竿见影。2.3 什么情况下你该老老实实上引擎我也得说句公道话如果你的目标是商业发行、多平台、需要复杂动画和特效那还是上引擎。裸写 Canvas 的优势在于快速验证和完全掌控劣势在于所有轮子都要自己造做到后期会越来越累。我的建议是分阶段原型期用 Canvas 裸写验证玩法成立之后再决定要不要迁移到引擎。玩法没验证之前就投入引擎学习成本是最大的浪费。这个原型的意义就在于此——用最低成本回答这个玩法好不好玩。3. 从零搭骨架主循环、坐标系与实体管理3.1 一个稳定的游戏主循环长什么样游戏和普通网页程序最大的区别就是它有一个持续运行的循环。最朴素的写法是setInterval但它有两个致命问题一是时间间隔不精确二是和浏览器刷新不同步会撕裂。正确做法是用requestAnimationFramerAF它由浏览器在每次重绘前调用天然和屏幕刷新对齐。但 rAF 只给你什么时候画不给你过了多久。所以主循环里必须自己算时间差delta time。我用的结构是这样的let lastTime 0; function gameLoop(timestamp) { const deltaTime (timestamp - lastTime) / 1000; // 转成秒 lastTime timestamp; // 限制单帧最大步长防止切后台回来时瞬移 const dt Math.min(deltaTime, 0.05); update(dt); // 更新逻辑 render(); // 渲染画面 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里有个新手必踩的坑如果不限制dt的最大值当用户切到别的标签页再切回来deltaTime可能是好几秒你的角色会瞬间穿过整张地图甚至穿墙。Math.min(deltaTime, 0.05)这一行就是保险丝把单帧步长锁死在 50 毫秒以内。这个细节几乎所有教程都不讲但线上一定会出问题。3.2 世界坐标和屏幕坐标必须分开搜打撤游戏一定有摄像机跟随所以坐标系必须分成两套世界坐标实体在地图上的绝对位置和屏幕坐标实体在画布上的显示位置。两者之间差一个摄像机偏移量。很多新手直接在实体上存屏幕坐标结果摄像机一动所有逻辑全乱。我的做法是所有实体的位置、碰撞、AI 判断全部用世界坐标只有在render的最后一步才通过ctx.translate(-camera.x, -camera.y)把整个世界平移到摄像机视角。这样逻辑和渲染彻底解耦摄像机怎么动都不影响玩法计算。摄像机本身只需要记录一个中心点跟随玩家时做个平滑插值lerp画面就不会生硬地跟着玩家抖。3.3 实体管理别用一堆数组原型阶段最容易犯的错是给每种东西开一个数组enemies[]、bullets[]、items[]、effects[]。一开始没问题但很快你就会发现碰撞检测要写四遍更新逻辑要写四遍删除元素还要处理数组塌陷。我后来统一成一个实体列表 类型标记const entities []; function createEntity(type, x, y, props {}) { return { type, // player | enemy | bullet | item | effect x, y, vx: 0, vy: 0, radius: 12, alive: true, ...props }; }更新时遍历一次按type分发碰撞时用空间网格筛选而不是两两比对。删除实体时不要用splice会改变数组长度导致遍历错乱而是标记alive false在每帧末尾统一过滤。这个模式看起来简单但它让整个项目的扩展性上了一个台阶——加一种新实体只需要加一个type分支。4. 搜打撤的灵魂视野、搜刮与撤离判定4.1 视野遮挡是这类游戏的核心手感搜打撤和普通射击游戏最大的区别就是信息不对称。你看不到墙后面的敌人敌人也看不到你这种未知才是紧张感的来源。所以视野系统不是锦上添花而是核心玩法。我用的是最经典的**射线投射raycasting**方案从玩家位置向四周发射一圈射线每条射线遇到墙体就停下把命中点连起来形成一个可见多边形。具体实现上我发射 360 条射线每度一条对每条射线做射线与线段求交取最近的交点。360 条射线听起来多但每条只和附近的墙体线段求交配合空间网格一帧的开销完全可以接受。得到多边形后用ctx.save()ctx.clip()把它设为裁剪区域只在这个区域内绘制敌人和物品。区域外的实体直接不画玩家自然就看不见了。这里有个性能与观感的权衡射线数量越多视野边缘越平滑但开销越大。我实测 180 条每 2 度一条在观感上已经足够边缘的锯齿几乎看不出来开销却减半。如果你的地图墙体很多可以进一步只对视野范围内的墙体做求交。4.2 搜刮系统容器、容量与贪婪的代价搜刮是搜打撤的经济核心。我的设计是地图上散布若干容器箱子、柜子、尸体玩家靠近后按键打开弹出容器内的物品列表。玩家可以把物品拖进自己的背包但背包有容量上限按格子数或重量算。这个容量限制就是玩法的张力所在——你不可能把所有东西都带走必须做取舍。物品我用一个简单的数据结构表示const itemTemplate { id: medkit, name: 急救包, weight: 2.5, value: 800, stackable: false };背包容量我选了重量制而不是格子制因为重量制更容易做出这件装备很重但很值钱的抉择感。玩家捡起物品时检查当前重量 物品重量 上限超了就拒绝并给个提示。这个判断必须在服务端逻辑这里是本地逻辑层做而不是在 UI 层做否则很容易被绕过——虽然单机原型无所谓但养成好习惯将来联机时不用重写。4.3 撤离点把活着出去变成真正的目标搜打撤的闭环是进图—搜刮—撤离。撤离点通常在地图边缘玩家需要在规定时间内到达并持续站立若干秒才能撤离成功。这个持续站立的设计非常关键它逼玩家在撤离时暴露自己制造最后一波紧张感。如果一碰到撤离点就成功那撤离就毫无压力了。我的实现是给撤离点一个矩形区域和一个计时器。玩家进入区域后开始倒计时比如 5 秒期间如果离开区域或受到伤害计时重置。倒计时结束判定撤离成功结算本局收益。同时地图上会随机刷 2 到 3 个撤离点玩家进图时不知道哪个是激活的需要探索确认——这又增加了一层信息博弈。注意撤离倒计时一定要在 UI 上给足反馈进度条、音效、屏幕边缘的呼吸光效都可以。玩家在紧张状态下如果不知道还差几秒体验会非常糟糕。5. 敌人 AI 与战斗让原型有那味儿5.1 状态机是 AI 最省心的写法敌人 AI 不需要多复杂一个**有限状态机FSM**就够了。我给敌人设计了四个状态patrol巡逻、alert警觉、chase追击、attack攻击。状态之间的切换由感知结果驱动巡逻时沿预设路径点移动如果玩家进入视野锥且没有遮挡切到警觉短暂停顿后切追击追到攻击距离就开火。function updateEnemyAI(enemy, dt) { switch (enemy.state) { case patrol: moveAlongPath(enemy, dt); if (canSeePlayer(enemy)) enemy.state alert; break; case alert: enemy.alertTimer - dt; if (enemy.alertTimer 0) enemy.state chase; break; case chase: moveToward(enemy, player, dt); if (distance(enemy, player) enemy.attackRange) { enemy.state attack; } break; case attack: fireAtPlayer(enemy); break; } }状态机的价值在于可调试。每个状态的行为独立出问题一眼就能定位是哪个状态逻辑写错了。我强烈建议在开发时把敌人的当前状态画在头顶一个小色块或文字调试效率翻倍。5.2 视野锥 射线检测让敌人看得见才合理敌人不能全图感知玩家否则搜打撤的潜行乐趣就没了。我用的是视野锥 射线遮挡检测敌人有一个朝向和视野角度比如 90 度玩家必须在这个锥形范围内且两者之间没有墙体遮挡才算被看见。射线检测复用了视野系统里的线段求交函数代码可以共用。这里有个手感调优的经验视野锥的角度和距离直接决定游戏难度。角度太大玩家无处可藏角度太小敌人形同虚设。我最后定在 90 度、视距 400 像素配合地图上足够的掩体潜行和刚枪两种玩法都能成立。这个数值没有标准答案必须自己反复试。5.3 子弹与命中别做真实的弹道原型阶段千万别去模拟真实弹道和重力那是给自己找麻烦。我用的是瞬时命中hitscan 视觉曳光开火时立刻做一次射线检测判断是否命中同时在画面上画一条快速消失的曳光线。玩家看到的是子弹飞过去实际逻辑是瞬时的。这样既保证了手感又省掉了子弹实体的物理计算。如果一定要做飞行子弹比如狙击枪的延迟感那就用简单的匀速直线运动 每帧碰撞检测别加任何加速度和重力。记住原型的每一分复杂度都要花在玩法验证上而不是物理真实性上。6. 渲染优化与那些让我熬夜的坑6.1 分层渲染把静态和动态分开前面提过静态地图要预渲染。具体做法是地图生成后把所有墙体、地面贴图、装饰物画到一张和地图等大的离屏 Canvas 上之后每帧只drawImage这张大图的可视区域。动态实体玩家、敌人、子弹再画在上面。这一招把每帧的绘制调用从几千降到几十是性价比最高的优化。再进一步可以把 UI 单独放一层。UI 不随摄像机移动所以不要放在translate之后的上下文里画否则坐标全乱。我的做法是渲染分三步先画世界带摄像机变换再restore回屏幕坐标最后画 UI。6.2 我踩过的三个真实坑第一个坑ctx.save/restore不配对。视野裁剪用了saveclip如果某条分支提前return忘了restore裁剪区域会一直累积画面越来越黑。后来我强制规定任何save必须在同一个函数内restore用 try/finally 兜底。第二个坑浮点数导致的碰撞抖动。玩家贴着墙移动时因为浮点误差位置会在墙内墙外反复横跳画面抖动。解决办法是碰撞修正后把位置吸附到墙面取整或对齐到网格而不是简单地回退速度。第三个坑切后台回来时间爆炸。前面主循环里那个Math.min就是被这个坑逼出来的。当时测试时切出去回消息回来角色直接飞出地图排查了半天才想到是deltaTime的问题。6.3 用对象池管理高频创建销毁子弹和特效是高频创建销毁的对象每帧new一堆再让 GC 回收会造成周期性的卡顿。我用对象池解决预创建一批子弹对象用的时候从池里取不用的时候标记归还而不是真的销毁。这样 GC 压力几乎为零帧率曲线平滑很多。对象池的代码不复杂但它是从能跑到跑得稳的关键一步。7. 关于这套原型后续怎么长这套 Canvas 2D 的搜打撤原型我前后迭代了大概两周核心循环已经相当完整。如果继续往下做我会优先补三块一是音效和音乐搜打撤的氛围一半靠声音脚步声、枪声、搜刮声能极大提升沉浸感二是局外成长系统把每局带出的物资转化成永久升级形成长线动力三是数据持久化用 localStorage 存背包和进度让原型有存档的概念。但我想强调的是别急着加内容先把核心循环的手感磨到位。搜打撤好不好玩取决于搜刮的紧张感战斗的爽快感撤离的博弈感这三件事而不是你有多少种枪、多少张地图。我见过太多原型内容堆了一大堆但基础手感稀烂最后没人愿意玩。用 Canvas 裸写的好处就在这里——改一个数值、调一个手感刷新页面就能看到迭代速度快到飞起。这套东西最大的价值不是它多完整而是它让你能用最低的成本把这个玩法到底成不成立这个问题回答清楚。