从零拆解网页版植物大战僵尸：HTML+JavaScript塔防游戏开发实战

1. 从零拆解一个网页版植物大战僵尸：整体设计思路

1.1 为什么选 HTML + JavaScript 这套组合

做植物大战僵尸这种塔防游戏，选技术栈其实就两条路：要么用 Unity、Godot 这类游戏引擎，要么用原生 Web 技术手搓。我一开始也纠结过，后来想明白一件事——这个项目的核心诉求是“打开浏览器就能玩，不用装任何东西”，那 HTML + CSS + JavaScript 就是最直接的答案。

原生 Web 技术做游戏有几个实打实的好处。第一是零依赖分发，一个.html文件双击就能跑，发给朋友测试连服务器都不用搭。第二是调试成本极低，浏览器 F12 打开就能看 DOM 结构、打断点、改参数，比引擎里翻日志快得多。第三是渲染方式灵活，植物大战僵尸这种 2D 网格布局的游戏，用 DOM 元素或者 Canvas 都能实现，不像 3D 游戏那样被绑死在 WebGL 上。

具体到渲染方案，我最终选了DOM + CSS 定位而不是纯 Canvas。原因很实际：这个游戏的元素都是规整的格子，植物、僵尸、子弹本质上都是“在某个格子里显示一张图”，用绝对定位的div配合background-image就能搞定，而且每个元素都是真实 DOM 节点，点击事件、层级控制、动画过渡都能直接用 CSS 写，省掉一大堆手写的碰撞检测和重绘逻辑。Canvas 更适合粒子效果多、元素数量上千的场景，植物大战僵尸一屏也就几十个对象，DOM 完全扛得住。

提示：如果你的目标是做成手机端也能流畅玩的版本，元素数量再翻几倍，那时候再考虑迁移到 Canvas 或 WebGL，前期用 DOM 快速验证玩法是最划算的。

1.2 游戏核心循环与模块划分

任何游戏拆到最底层都是一个循环：读取输入 → 更新状态 → 渲染画面。植物大战僵尸也不例外，只不过它的“输入”是鼠标点击种植物，“状态”是阳光数量、植物血量、僵尸位置，“渲染”是把这些数据画到屏幕上。

我把整个项目拆成了六个模块，每个模块职责单一，方便单独调试：

• 网格系统：负责把屏幕划分成 5 行 9 列的战斗区域，提供“像素坐标 ↔ 格子坐标”的双向转换。这是整个游戏的地基，所有对象定位都依赖它。
• 资源管理：统一管理植物、僵尸、子弹的图片素材和基础属性（血量、攻击力、冷却时间）。用配置对象集中存放，改数值不用翻代码。
• 阳光系统：定时掉落阳光、点击收集、数量增减。这是游戏的资源命脉，节奏全靠它控制。
• 植物系统：种植逻辑、冷却判断、攻击行为、被啃食后的血量结算。
• 僵尸系统：生成波次、移动、攻击植物、死亡判定。
• 主循环：用requestAnimationFrame驱动，每帧更新所有对象状态并检查胜负条件。

这样拆的好处是，我想调僵尸速度就只动僵尸模块，想改阳光掉落频率就只动阳光模块，互不干扰。很多新手一上来把所有逻辑塞进一个setInterval里，改一处崩三处，这是要极力避免的。

1.3 坐标系设计：像素与格子的换算关系

这是最容易被忽略但最关键的细节。游戏里所有对象的位置，我统一用格子坐标存储，渲染时才换算成像素。为什么？因为僵尸移动、子弹飞行如果直接用像素，会出现“僵尸走到第 3.7 格”这种尴尬情况，判断“僵尸是否碰到植物”就得做浮点数比较，容易出 bug。

我的做法是：格子宽 80px、高 100px，战斗区域左上角偏移(offsetX, offsetY)。那么格子(row, col)的中心像素坐标就是：

centerX = offsetX + col * 80 + 40 centerY = offsetY + row * 100 + 50

反过来，鼠标点击的像素坐标(px, py)换算成格子：

col = Math.floor((px - offsetX) / 80) row = Math.floor((py - offsetY) / 100)

这套换算我封装成了gridToPixel()和pixelToGrid()两个函数，全项目只在这里做坐标转换，其他地方一律用格子坐标。实测下来，这样写碰撞检测简单到极致——僵尸和植物在同一行、且僵尸的col小于等于植物的col加一个阈值，就算碰到了。

2. 核心细节解析与实操要点

2.1 网格系统的搭建与坐标换算

网格系统说白了就是一张背景图加一套换算规则。背景我用 CSS 的background-image铺一张草坪图，然后用repeating-linear-gradient叠一层半透明的格子线，这样不用额外切图就能看到格子边界，调试的时候特别方便。

#battlefield { position: relative; width: 720px; /* 9 列 × 80px */ height: 500px; /* 5 行 × 100px */ background: url('lawn.png') repeat; background-size: 80px 100px; }

每个格子我不单独创建 DOM 节点，而是用一个透明的“点击层”覆盖整个战场，监听一次点击事件，通过pixelToGrid()算出点的是哪个格子。这样做的好处是 DOM 节点数量少，性能好；坏处是没法给单个格子加 hover 效果。如果你想要“鼠标悬停高亮格子”的体验，那就得老老实实创建 45 个格子 div，用事件委托处理点击。两种方案我都试过，前者性能好，后者交互细腻，看你的取舍。

注意：格子坐标一定要做边界检查。玩家可能点到战场外面，row或col会算出负数或超出范围，这时候必须直接 return，否则后面数组越界会报错。

2.2 植物对象的属性设计与冷却机制

每种植物的属性我用一个配置对象描述，核心字段包括：cost（阳光消耗）、cooldown（冷却毫秒数）、hp（血量）、attack（攻击力）、range（攻击范围，用格子数表示）、produce（是否产阳光）。

以向日葵和豌豆射手为例：

const PLANT_CONFIG = { sunflower: { cost: 50, cooldown: 7500, hp: 300, attack: 0, produce: 25000 }, peashooter:{ cost: 100, cooldown: 7500, hp: 300, attack: 20, range: 9 }, wallnut: { cost: 50, cooldown: 30000,hp: 4000,attack: 0, range: 0 } };

冷却机制是新手最容易写错的地方。我见过有人用setTimeout来重置冷却，结果玩家疯狂点击时创建了几十个定时器，内存直接爆掉。正确做法是记录上次种植的时间戳，每次点击时用Date.now() - lastPlantTime和cooldown比较：

function canPlant(type) { const cfg = PLANT_CONFIG[type]; if (sun < cfg.cost) return false; if (Date.now() - (lastPlantTime[type] || 0) < cfg.cooldown) return false; return true; }

冷却的视觉反馈我用 CSS 的conic-gradient画一个扇形遮罩，随时间从满圆缩到零，比单纯变灰直观得多。这个技巧在很多塔防游戏里都能复用。

2.3 僵尸移动与攻击的帧同步处理

僵尸移动的核心是“每帧走多少像素”。这里有个坑：如果你直接写zombie.x -= 1，那在不同刷新率的显示器上速度会不一样，144Hz 的屏幕上僵尸跑得比 60Hz 快一倍多。解决办法是基于时间差计算位移：

let lastTime = 0; function gameLoop(now) { const dt = now - lastTime; lastTime = now; zombies.forEach(z => { z.x -= z.speed * dt / 1000; // speed 单位：像素/秒 }); requestAnimationFrame(gameLoop); }

这样无论屏幕刷新率多少，僵尸每秒移动的像素数都是恒定的。speed我设成 20 像素/秒，也就是 4 秒走一格，节奏和原版比较接近。

僵尸攻击植物的判定，我用的是“同行 + 横向距离小于阈值”。具体来说，僵尸的col减去植物的col小于 0.3 格时，僵尸停止移动，开始按固定间隔啃食，每次扣植物attack点血。这里要注意，僵尸啃食时不能继续移动，否则会“穿模”走到植物后面去。我一开始就踩过这个坑，僵尸一边啃一边往前挪，最后跑到植物右边去了，画面非常诡异。

2.4 阳光掉落与收集的交互细节

阳光系统有两个来源：天上定时掉落，以及向日葵产出。天上掉落的阳光我用一个独立的定时器，每 8 到 12 秒随机生成一个，从屏幕顶部飘落到随机位置。飘落动画用 CSS 的transition配合transform: translateY()实现，比 JS 逐帧改位置省事。

点击收集的逻辑很简单，给阳光元素绑click事件，点击后sun += 25并移除元素。但有个体验细节：阳光飘落过程中如果玩家没点，落地后要停留几秒再消失，不能立刻没了，否则玩家手速慢一点就亏了。我设的是落地后停留 5 秒，最后 1 秒开始闪烁提示即将消失。

提示：阳光的z-index一定要设得比植物和僵尸高，否则会被挡住点不到。这个 bug 我调了半小时才发现，血的教训。

3. 实操过程与核心环节实现

3.1 从空白 HTML 到可运行战场的完整搭建

第一步，搭 HTML 骨架。整个页面就三个主要区域：顶部状态栏（显示阳光数、波次）、中间战场、底部植物选择栏。

<!DOCTYPE html> <html lang="zh-cn"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>植物大战僵尸 - 网页版</title> <link rel="stylesheet" href="style.css"> </head> <body> <div id="topbar"> <span id="sun-count">阳光: 50</span> <span id="wave-info">第 1 波</span> </div> <div id="battlefield"></div> <div id="plant-bar"></div> <script src="game.js"></script> </body> </html>

第二步，写 CSS 把战场和植物栏摆好。战场固定 720×500，植物栏用 flex 横向排列，每个植物卡片显示图片和阳光消耗。

第三步，写 JS 初始化。核心是三个数组：plants、zombies、bullets，分别存所有活动对象。每帧遍历这三个数组更新状态，然后同步到 DOM。

这里有个性能优化点：不要每帧都重建 DOM，而是对象创建时生成 DOM 节点，之后只改style.left和style.top。我一开始图省事每帧innerHTML重绘，结果僵尸一多就卡成幻灯片，改成复用节点后丝滑多了。

3.2 植物种植的完整交互链路

种植的交互链路是这样的：玩家点击植物卡片 → 卡片高亮，进入“待种植”状态 → 鼠标移到战场上，格子高亮预览 → 点击格子，检查阳光和冷却 → 通过则创建植物对象和 DOM 节点，扣除阳光，记录冷却时间 → 退出待种植状态。

let selectedPlant = null; plantBar.addEventListener('click', e => { const card = e.target.closest('.plant-card'); if (!card) return; const type = card.dataset.type; if (!canPlant(type)) return; selectedPlant = type; highlightCards(type); }); battlefield.addEventListener('click', e => { if (!selectedPlant) return; const rect = battlefield.getBoundingClientRect(); const { row, col } = pixelToGrid(e.clientX - rect.left, e.clientY - rect.top); if (row < 0 || row > 4 || col < 0 || col > 8) return; if (isOccupied(row, col)) return; plantAt(selectedPlant, row, col); selectedPlant = null; });

isOccupied()检查该格子是否已有植物，避免重复种植。这个检查必须做，否则两个植物叠在一起，僵尸啃哪个都乱套。

3.3 僵尸波次生成与难度曲线设计

僵尸生成我用“波次”来管理。每一波定义僵尸数量、类型和生成间隔。第一波 3 只普通僵尸，间隔 3 秒；第二波 5 只，间隔 2.5 秒；之后每波递增，到第 5 波开始混入路障僵尸（血量翻倍）。

const WAVES = [ { count: 3, interval: 3000, types: ['normal'] }, { count: 5, interval: 2500, types: ['normal'] }, { count: 7, interval: 2000, types: ['normal', 'cone'] }, { count: 10, interval: 1800, types: ['normal', 'cone'] }, { count: 15, interval: 1500, types: ['normal', 'cone', 'bucket'] } ];

难度曲线的设计原则是“让玩家刚好喘不过气”。太简单没挑战，太难直接劝退。我的经验是，第一波给玩家足够时间种 2 到 3 个向日葵攒阳光，第二波开始有压力，第三波必须已经布好防线。如果实测发现某波太难，就调大interval或者减少count，多试几次就能找到舒服的节奏。

僵尸从屏幕右侧外生成，随机选一行，然后向左移动。生成位置我设在col = 9.5，也就是战场右边界外半格，这样僵尸是“走进来”的，视觉上更自然。

3.4 子弹发射与命中判定的实现

豌豆射手的攻击逻辑是：每 1.5 秒检查自己所在行有没有僵尸，有的话发射一颗子弹。子弹从植物位置生成，以 300 像素/秒向右飞行，碰到僵尸就扣血并消失。

function updateBullets(dt) { bullets = bullets.filter(b => { b.x += b.speed * dt / 1000; const hit = zombies.find(z => z.row === b.row && Math.abs(z.x - b.x) < 30 ); if (hit) { hit.hp -= b.attack; if (hit.hp <= 0) removeZombie(hit); return false; // 子弹消失 } if (b.x > 720) return false; // 飞出屏幕 return true; }); }

命中判定我用的是“同行 + 横向距离小于 30 像素”，简单粗暴但够用。更精确的做法是矩形碰撞检测，但对这个游戏来说没必要，30 像素的容差已经足够准确，玩家肉眼看不出问题。

注意：子弹和僵尸的数组遍历顺序有讲究。如果先更新僵尸位置再检测子弹，可能出现子弹“穿过”僵尸的情况。我的做法是先更新子弹位置并检测命中，再更新僵尸位置，这样能保证判定准确。

4. 常见问题与排查技巧实录

4.1 游戏卡顿与内存泄漏的排查

游戏跑几分钟后越来越卡，这是最常见的性能问题。我用 Chrome 的 Performance 面板录了一段，发现两个元凶：一是僵尸死亡后 DOM 节点没移除，二是子弹数组只增不减。

排查方法很简单：在控制台定时打印plants.length、zombies.length、bullets.length，如果数字只涨不跌，那就是没清理。解决就是在对象死亡时同时做两件事——从数组里filter掉，以及调用element.remove()移除 DOM 节点。

function removeZombie(z) { z.el.remove(); zombies = zombies.filter(item => item !== z); }

还有一个隐蔽的坑：requestAnimationFrame如果忘记在页面隐藏时暂停，切到后台标签页后游戏还在跑，回来时僵尸已经走到家门口了。解决办法是监听visibilitychange事件，页面隐藏时暂停循环。

4.2 点击事件失效与层级冲突

“点了植物卡片没反应”或者“点了格子没种上”，这类问题八成是事件层级冲突。常见原因有三个：一是阳光元素的z-index太高，盖住了植物卡片；二是战场上的点击层被其他元素遮挡；三是pointer-events: none没设对。

我的排查套路是：打开 F12，用元素选择器点一下没反应的位置，看选中的是哪个元素。如果选中的不是你期望的节点，那就是层级问题。解决方法是给装饰性元素（比如格子线、背景）加pointer-events: none，让点击穿透到真正的交互层。

4.3 僵尸穿模与判定异常的修复

僵尸穿模有两种表现：一是僵尸走到植物右边去了，二是僵尸和植物重叠但不啃食。前者是因为移动和攻击的判定顺序错了，僵尸在啃食状态下还在执行移动逻辑。修复方法是给僵尸加一个state字段，walking状态下才移动，eating状态下只扣血。

后者通常是判定阈值设得太小。我一开始设的是Math.abs(z.x - p.x) < 5，结果僵尸走到植物跟前了还不啃，因为像素差刚好是 6。后来改成< 30，问题解决。这个阈值要根据僵尸和植物的图片宽度来调，一般取两者宽度之和的一半比较合适。

4.4 常见问题速查表

4.5 几个让我少走弯路的实操心得

第一个心得：先做能跑的最小版本，再加功能。我一开始想一步到位，把植物、僵尸、阳光、波次全写完再测试，结果一运行满屏报错，根本不知道从哪查起。后来改成先只做“点击种一个植物”，跑通了再加僵尸，再加子弹，每步都能验证，效率反而高得多。

第二个心得：数值全部抽到配置对象里。僵尸速度、植物血量、阳光掉落间隔，这些数值我改了不下二十遍。如果散落在代码各处，改一次要翻半天。集中到CONFIG对象后，调平衡就是改几个数字的事。

第三个心得：善用浏览器的断点调试。僵尸不啃植物的时候，我在updateZombies里打了个断点，一看state字段一直是walking，瞬间定位到状态切换的条件写错了。比console.log到处打日志高效太多。

第四个心得：图片素材用雪碧图或者 base64 内联。我一开始用一堆独立的 png 文件，加载时闪一下白屏。后来把常用素材转成 base64 直接写进 CSS，一个 HTML 文件自包含，发给别人直接能玩，体验好很多。

5. 素材准备与资源管理

5.1 图片素材的获取与处理

植物大战僵尸的素材网上能找到不少，但质量参差不齐。我的建议是优先找透明背景的 PNG，尺寸统一处理成格子大小的整数倍。植物统一 80×100，僵尸统一 80×120（比格子高一点，视觉上更立体），子弹 20×20。

素材处理我用的是在线的图片编辑工具，批量裁剪、去背景、压缩。压缩这一步别省，原图动辄几百 KB，十几张图加起来好几 MB，加载慢得让人想关页面。压到每张 20KB 以内，整体控制在 500KB 左右，加载就很快了。

如果找不到合适的素材，也可以自己用简单的几何图形拼。我见过有人用纯 CSS 画植物和僵尸，虽然简陋但别有一番风味，而且零素材依赖，一个 HTML 文件搞定。

5.2 用配置对象统一管理游戏数值

所有游戏数值我放在一个CONFIG对象里，分门别类：

const CONFIG = { grid: { rows: 5, cols: 9, cellW: 80, cellH: 100 }, sun: { start: 50, dropInterval: [8000, 12000], value: 25 }, zombie: { baseSpeed: 20, attackInterval: 1000 }, bullet: { speed: 300, size: 20 } };

这样调平衡的时候，我只需要改这个对象，不用碰任何逻辑代码。而且这个对象可以很方便地导出成 JSON，将来想做关卡编辑器，直接读 JSON 就能生成不同难度。

提示：数值配置最好加注释说明单位和含义，比如baseSpeed: 20后面注明“像素/秒”。过一个月再回来看代码，没有注释你根本想不起来这个 20 是什么单位。

5.3 音效与背景音乐的轻量化方案

音效不是必须的，但加上之后游戏体验提升明显。我用的是 Web Audio API 直接合成简单音效，比如种植的“噗”声、僵尸被击中的“啪”声，用振荡器几行代码就能生成，不用加载任何音频文件。

function playSound(freq, duration) { const ctx = new AudioContext(); const osc = ctx.createOscillator(); const gain = ctx.createGain(); osc.frequency.value = freq; osc.connect(gain); gain.connect(ctx.destination); osc.start(); gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime + duration); osc.stop(ctx.currentTime + duration); }

种植时调用playSound(440, 0.1)，僵尸死亡调用playSound(220, 0.2)。这样零音频文件，整个游戏还是一个 HTML 文件，非常干净。如果你想要更丰富的音效，再考虑引入外部音频文件，但要注意版权问题，用自己录的或者明确可商用的素材。

6. 从能玩到好玩：体验优化与扩展方向

6.1 让操作更跟手的几个细节

游戏能跑起来只是第一步，玩起来爽不爽全在细节。我做了几个优化，效果立竿见影。

第一是种植预览。鼠标移到格子上时，显示一个半透明的植物影子，让玩家知道种下去长什么样、占多大地方。实现就是在mousemove时更新一个预览 div 的位置和背景图。

第二是阳光自动收集。原版是要手动点的，但网页版玩家可能懒得点。我加了个开关，开启后阳光落地 1 秒自动收集，适合休闲玩家。这个功能用setTimeout在阳光落地时触发就行。

第三是僵尸血条。僵尸被攻击后头顶显示一个小血条，让玩家知道还差几发子弹能打死。血条用 CSS 的width百分比控制，更新时只改宽度，性能开销极小。

6.2 难度平衡的调整经验

难度平衡是个体力活，没有捷径，就是反复试玩。我的经验是：先定目标时长，再倒推数值。我希望一局游戏 5 到 8 分钟，那么按每波僵尸 30 到 60 秒算，大概 8 到 10 波比较合适。

阳光经济也要算账。一个向日葵 50 阳光，每 25 秒产 25 阳光，100 秒回本。如果玩家第一波前种 3 个向日葵，大概 2 分钟后阳光就充裕了。如果发现玩家总是阳光不够，就把向日葵产阳光的间隔调短，或者初始阳光给多一点。

僵尸强度我用“总血量”来衡量。第一波总血量 300（3 只普通僵尸各 100），第二波 500，第三波 800，这样递增比较平滑。如果某波玩家反馈太难，就把总血量降 20% 再试。

6.3 后续可以扩展的玩法方向

这个项目做完基础版后，可扩展的方向很多。我列几个我觉得有意思的：

• 更多植物类型：樱桃炸弹（范围伤害）、寒冰射手（减速）、土豆地雷（延时爆炸）。每加一种植物，就是加一个配置对象和一段特殊逻辑。
• 更多僵尸类型：撑杆僵尸（跳过第一个植物）、铁桶僵尸（超高血量）、舞王僵尸（召唤小弟）。僵尸的特殊行为用状态机实现。
• 关卡系统：把波次配置存成 JSON，不同关卡读不同配置，加个关卡选择界面。
• 存档功能：用localStorage存最高波次记录，玩家下次打开能看到自己的最好成绩。
• 移动端适配：把战场缩放适配手机屏幕，触摸事件替代鼠标事件。这个工作量不小，但做完之后受众会大很多。

我个人最推荐先做“更多植物类型”，因为这是玩家感知最强的扩展，而且实现成本相对低。每加一种植物，游戏的可玩性就上一个台阶。

6.4 代码组织与后续维护建议

最后说说代码组织。我建议把代码拆成多个文件：config.js放配置，grid.js放网格系统，plants.js、zombies.js、bullets.js各管各的，main.js做主循环和初始化。用 ES6 的import/export组织，浏览器原生支持，不用打包工具。

如果嫌多文件麻烦，至少也要用注释把不同模块分隔清楚，比如// ===== 僵尸系统 =====。我见过有人一个文件两千行没有任何分隔，改个僵尸速度要翻三分钟，太痛苦了。

版本管理用 Git，每完成一个功能就提交一次，写清楚提交信息。这样改崩了随时能回滚，比手动备份game_v1.js、game_v2.js靠谱得多。

我在实际做这个项目的过程中最大的体会是：别追求一次写完美，先让它跑起来，再让它好玩，最后让它好看。很多人卡在第一步，想先把架构设计得天衣无缝再动手，结果迟迟出不了成果。实际上游戏开发就是不断试错和调整的过程，先有个能玩的版本，你才知道哪里需要改。