企业官网建设流程全解析

从PIXI引擎搭建到完整玩法，这里记录了把经典坦克射击游戏搬到HTML5的完整过程。没有华丽的包装，只有一步步可执行的思路和能直接用的代码。

1. 项目拆解：从游戏玩法到技术清单

1.1 经典坦克大战的核心玩法元素

先抛开代码，想想坦克大战这游戏到底在做什么。玩家控制一辆坦克，在由砖墙、钢墙、水域、树林组成的地图里移动，射击敌人坦克，保护地图中央的基地。敌人一波波从固定出生点刷出来，打完一波进下一关，基地被摧毁或所有坦克耗光则游戏结束。

听起来简单，但拆成技术问题后你会发现，这几乎是2D游戏开发里所有基础系统的迷你集合：地图数据表示、渲染分层、玩家输入、移动与碰撞、发射物管理、简单AI、状态控制、UI更新。能把这一套走通，后面做任何同类型2D游戏都会顺手很多。

所以在动手写代码前，我建议先列一张清单，把玩法元素映射成技术模块：

这张清单就是整个项目的开发序章。我建议按它从上到下推进，每完成一行就算一个里程碑，调试起来思路也会非常清晰。

1.2 为什么选PIXI而不是原生Canvas，也不用重型引擎

很多第一次做HTML5游戏的人会纠结，直接用Canvas写不行吗？Phaser、Cocos不是更省事？

直接用Canvas写完全行，但问题出在资源管理和渲染性能上。坦克大战的贴图虽然不多，可一旦子弹、爆炸动画、敌人同时出现，原生Canvas如果代码组织得不好，很容易陷入“每次都重绘整张画布”的坑。PIXI提供的是场景图结构，你可以把背景、坦克、子弹、UI拆成不同容器，引擎只更新有变化的部分，而且底层默认走WebGL，渲染效率比2D Canvas高不少，同时也保留了Canvas回退模式——这对老机器和低端手机很重要。

Phaser这类完整游戏框架确实强大，但学习曲线更陡，很多功能对坦克大战这种小体量项目是过载的。PIXI更像一个“渲染引擎”而不是“游戏引擎”，它不强行规定你用什么碰撞系统、怎么组织游戏循环，只把精灵、容器、动画、交互这些底层能力给你。对想搞懂游戏逻辑本身的人来说，PIXI是更好的教学工具：你需要自己搭游戏循环，自己写碰撞，自己管理状态，但对PIXI的掌控感会非常强。

这个选择适合当前项目，也适合这个系列的循序渐进思路。先用PIXI把渲染和结构跑顺，后续如果遇到需要场景管理、寻路、复杂动画的项目，再上Phaser也不迟。

1.3 文件结构与渲染层级的初步设计

动手写代码前，先想清楚文件结构。我习惯按“入口层 → 场景层 → 实体层 → 工具层”四层切分：

src/ ├── main.js // 入口，初始化PIXI应用，加载资源 ├── scenes/ │ └── GameScene.js // 主游戏场景，管理整个游戏流程 ├── entities/ │ ├── Tank.js // 坦克基类，玩家坦克和敌人坦克共用 │ ├── PlayerTank.js │ ├── EnemyTank.js │ └── Bullet.js ├── map/ │ ├── TileMap.js // 地图数据与静态物体管理 │ └── levels.js // 关卡地图数据 ├── systems/ │ ├── Input.js // 键盘输入管理 │ └── Collision.js // 碰撞工具 └── utils/ └── constants.js // 颜色、尺寸、速度常量

渲染层级方面，PIXI的容器就是天然的分层工具。我的做法是把场景分为四个容器，从底到顶依次是：背景容器、障碍物容器、坦克容器、子弹容器，UI单独再放一层。这样做的最大好处是层级关系一目了然，而且调试时可以单独隐藏某一层观察问题。坦克在移动时只需要在坦克容器内更新坐标，子弹层、背景层都不用动，减少了不少不必要的重绘操作。

2. 环境准备与PIXI引擎接入

2.1 初始化项目并安装PIXI

我用Vite搭基础工程。为什么选它？启动快，开发时热更新体验好，打包产物干净，对小游戏项目来说足够轻量，而且对ES模块支持得比老式Webpack配置省心得多。

mkdir tank-battle cd tank-battle npm create vite@latest . -- --template vanilla npm install pixi.js

装的是PIXI v7版本。注意v7和v8的API有不少差异，网上很多教程还在用v6甚至v5的写法，版本不同会出现“拿不到某个属性”的情况。如果你跟着改报错，先检查package.json里的pixi版本。我的代码示例按v7写，v8需要改的地方我会在对应位置单独提示。

2.2 创建应用实例与自适应画布

PIXI v7里创建一个应用的标准方式是：

import * as PIXI from 'pixi.js'; const app = new PIXI.Application({ width: 832, height: 832, backgroundColor: 0x000000, resolution: window.devicePixelRatio || 1, autoDensity: true, antialias: false, }); document.getElementById('game-container').appendChild(app.view);

这里有几个细节值得说明：

• width和height我用832，是因为我设计的瓦片地图是26×26，每个瓦片格子32像素，26×32=832，正好整除。做像素风游戏，尺寸尽量是瓦片尺寸的整数倍，这样地图边界、碰撞计算都干净。
• resolution和autoDensity这两个参数是让画面在高分屏上保持清晰的关键。手机屏幕像素密度比是2甚至更高，不设置分辨率就会发虚。
• 像素风游戏建议把antialias设为false，否则边缘会被插值模糊，失去颗粒感。配合CSS里的image-rendering: pixelated效果更纯粹。

自适应方面，项目很可能要在不同尺寸的屏幕上玩。我在CSS里用一个简单方案：外层容器设max-width,max-height，然后给canvas设width:100%; height:100%，让canvas在保持比例的前提下缩放。

2.3 素材处理：自己画还是找贴图

坦克大战的素材可以自己用像素绘图，也可以用程序临时生成。我第一版为了快速跑通逻辑，直接用了PIXI的Graphics来画简单的方块坦克。就是两个矩形拼起来，一个车体一个炮管，颜色区分玩家和敌人。

用程序画图的好处是：零素材依赖、加载快、方便改尺寸。但等到要做爆炸动画、多帧履带效果时，程序画就会非常吃力，这时候最好切换成贴图。

如果用贴图，建议做“精灵图集”。把多张坦克图、墙体图、爆炸帧拼成一张大图，再用工具生成对应的atlas JSON。PIXI加载图集用Assets（v7以上）或loader（v6以下），v7的写法是：

PIXI.Assets.add('atlas', 'assets/tank-atlas.json'); const atlas = await PIXI.Assets.load('atlas'); // atlas.textures 里就是各个帧的纹理对象

这里踩过一个大坑：如果图集里带Trim信息（为了节省空间裁掉透明区域），锚点和碰撞框的位置会和你预期的不一样，所有坐标都会莫名其妙偏移。后来我果断关掉了Trim，宁愿文件大一点，也不跟它折腾。

3. 地图系统与瓦片碰撞

3.1 瓦片地图数据结构怎么定

坦克大战的地图适合用二维数组表达。每一个数字代表一种地形，我给不同地形分配的编号是：0空地，1砖墙，2钢墙，3水，4树，5基地。关卡数据就是这样的一串数组：

export const LEVEL_ONE = [ [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,1,0,0,0,0,0,0,0,0,0,0,0,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], ];

地图的边界干脆直接用钢墙兜一圈，这样玩家和敌人的移动范围天然被限制住，不用单独写边界检测。这个设计让碰撞逻辑少了一大分支，很划算。

3.2 从地图数据到PIXI显示对象的映射

拿到二维数组后，映射给PIXI渲染：遍历数组，每遇到非0值就在对应位置生成一个Sprite或Graphics对象，放进障碍物容器。坐标换算公式是：

const x = col * TILE_SIZE; const y = row * TILE_SIZE;

我在这个环节不把地图数据直接画成一张大图，而是一个个独立对象，这样后续子弹打掉某块砖时，可以精准删除对应的那个精灵，而不是重新绘制整张地图。这也是PIXI容器和对象模型带来的便利。

砖墙我处理成“单块瓦片即一个碰撞体”。为了让坦克打起来有破碎感，可以在瓦片内部再拆成四小份，被子弹打中时只销毁命中的小份。这个效果不难实现，但会让视觉反馈丰富不少。我后续会更新到这个版本，第一版先保持整块砖的逻辑。

3.3 特殊地形：水、树、冰面的行为差异

不同类型的地形不只是贴图不同，碰撞规则也不同，整理如下：

• 砖墙、钢墙：硬障碍，坦克和子弹都过不去。砖墙可以被子弹摧毁。
• 水：子弹直接穿过，坦克不能通行。这在经典规则里是铁律，我按这个做。
• 树：贴图盖在坦克头上，但碰撞不拦截，坦克可以穿过。实现上是把树层画在坦克层上面，且不参与碰撞计算。
• 基地：玩家要保护的核心位置，被子弹打中游戏直接结束。它本身按砖墙物理来算。

这个“视觉层和碰撞层分离”的思路很重要。很多新手把“能看到的东西”和“能撞到的东西”当成一回事，结果做树或装饰物时，明明应该让玩家穿过却被挡住，或者反过来。一个好的做法永远是把碰撞数据独立于显示对象，显示层只是拿来给人看的。

3.4 基地防御设计与地图刷新

基地在地图上位于正中央下方。我用一个标记位isBase来区分它和普通砖墙，这样子弹命中时的处理逻辑可以分支：打基地转成“游戏结束”流程，打砖墙则转成“扣除血量/移除瓦片”。

关卡切换时，要清空障碍物容器里的所有瓦片精灵，重新读取下一关数据并生成。这时候容器的removeChildren()很省事。但不能只清显示对象，碰撞数据也要同步重置。我的碰撞数据就挂在每个瓦片精灵的collidable属性上，清掉显示对象就等于清掉了碰撞体，只要记得把地图数据数组换成新关卡的数据即可。

4. 坦克实体与玩家控制

4.1 坦克类的基础属性设计

玩家和敌人都叫坦克，所以我把通用逻辑放在一个Tank基类里，它包含的字段有：

direction这个字段很关键，因为坦克移动和炮管朝向是绑定的，我通过方向值计算出旋转角度，再应用到炮管精灵的rotation属性上，省得每次单独记录炮管坐标。

4.2 键盘输入与八方向移动

玩家控制我用了方向键或者WASD两组按键，方便不同习惯。输入模块要解决的第一个问题是“按一下键盘却持续移动”——靠keydown/keyup维护一组按下状态，而不是在keydown里直接改坐标，否则玩家按住按键时会断续移动。

const keys = {}; window.addEventListener('keydown', (e) => { keys[e.code] = true; }); window.addEventListener('keyup', (e) => { keys[e.code] = false; }); function handleMovement(delta) { let dx = 0, dy = 0; if (keys['ArrowUp'] || keys['KeyW']) dy = -1; if (keys['ArrowDown'] || keys['KeyS']) dy = 1; if (keys['ArrowLeft'] || keys['KeyA']) dx = -1; if (keys['ArrowRight'] || keys['KeyD']) dx = 1; // 归一化斜向移动速度 if (dx !== 0 && dy !== 0) { const len = Math.hypot(dx, dy); dx /= len; dy /= len; } const speed = TANK_SPEED * delta; this.x += dx * speed; this.y += dy * speed; }

为什么要归一化？如果不归一化，斜着走的合成速度是1.414倍，玩家会明显感觉“斜着走比直线走快”，这对坦克大战这种偏严肃操作的游戏来说很不专业。

4.3 移动碰撞检测：我是这么处理的

坦克的碰撞目标是静态瓦片和动态坦克。这里有两种常见方案：一种是先尝试移动，然后与所有碰撞体做重叠检测，发生重叠就回退；另一种是预检测，先算目标位置是否与碰撞体重叠，不重叠才真正移动。

我用的是“移动后修正”的方式，因为它对高速移动的对象更稳健，不会因为单帧位移过大直接穿墙。具体做法是：

this.x += dx * speed; if (this.collidesWithWall()) { this.x -= dx * speed; // 回退X方向 } this.y += dy * speed; if (this.collidesWithWall()) { this.y -= dy * speed; // 回退Y方向 }

这个“分轴回退”的好处是，坦克贴着墙横向移动时不会因为竖向探测失败而被卡住。X和Y分开处理，等于得到了滑墙的手感，对操作流畅度提升非常明显。很多新手把X、Y合在一起回退，坦克稍微碰一点墙就完全卡死，这其实就是这个细节没处理好。

4.4 炮管朝向与开火冷却

炮管方向应该和坦克最后移动的方向一致，而不是实时跟随移动键。这个逻辑在实战中要稍微处理一下：记录上次改变移动方向的时间，开火时使用“当前朝向”或“目标朝向”都行，但画面表现上炮管要先转向再开火。

开火冷却我用简单的Date.now()时间戳判断，两次开火之间至少间隔400ms。采用了“按住开火键连发”的模式，按住空格键会以冷却时间为间隔持续发射。这是我个人觉得手感最好的方式，比“每按一次发一枪”更符合街机习惯。

5. 子弹系统与命中反馈

5.1 子弹的生成与生命周期管理

子弹也是精灵，挂在子弹容器下。玩家子弹和敌方子弹外观不同，我用颜色区分：玩家金色，敌人银色。子弹的移动方向和发射时的坦克朝向一致，速度是坦克的三倍左右。

子弹生命周期的核心问题是“什么时候消失”。我定义了几个条件：

• 超出地图边界
• 命中砖墙并摧毁砖块
• 命中钢墙不摧毁但子弹消失
• 命中坦克
• 接触水或树则穿过去

因为子弹可能一帧内移动超过一个瓦片（速度很快时），只检测子弹中心点与瓦片是否重叠是不够的，会漏判。我在子弹对象上额外记录上一帧的位置，用两点连线与瓦片做相交检测，避免“子弹穿墙”的视觉穿帮。

5.2 子弹与墙、坦克的命中判定

碰撞检测我写了一个统一函数，接收两组“矩形数据”（x, y, width, height），判断是否相交。这是最老套但最可靠的方案。

命中瓦片判定时，遍历当前地图中所有collidable瓦片，找到相交的第一个瓦片就停止。命中坦克同理，遍历所有alive坦克，玩家子弹跳过玩家自己的坦克，敌方子弹跳过射击者自己。

关键点是“同一个子弹在同一帧内不要命中多个目标”。我通过碰撞后立即把子弹标记为dead，并且在遍历循环里跳过已死子弹来保证。

5.3 爆炸动画与命中反馈

坦克被摧毁后，不能直接destroy()，玩家需要看到爆炸反馈。我用一个简单的动画实现：

const explosion = new PIXI.AnimatedSprite(explosionFrames, true); explosion.anchor.set(0.5); explosion.position.set(tank.x + TILE_SIZE / 2, tank.y + TILE_SIZE / 2); explosion.animationSpeed = 0.2; explosion.loop = false; explosion.onComplete = () => explosion.destroy(); app.stage.addChild(explosion); explosion.play();

这套思路适用于子弹打中砖墙时的小碎裂动画，也适用于坦克被摧毁时的大爆炸。爆炸结束后记得移除精灵，否则每次爆炸都会残留一个显示对象，时间久了内存和渲染都会扛不住。

5.4 屏幕震动：低成本但反馈明显的技巧

屏幕震动是一个非常划算的反馈手段。实现方式是：发生爆炸时，把游戏内容容器（除UI外）的位置短暂偏移几像素，然后通过缓动恢复原状。

function shakeScreen(intensity = 4, duration = 150) { const startTime = performance.now(); const container = gameContainer; const origX = container.x, origY = container.y; function updateShake() { const elapsed = performance.now() - startTime; if (elapsed >= duration) { container.x = origX; container.y = origY; return; } const strength = intensity * (1 - elapsed / duration); container.x = origX + (Math.random() - 0.5) * strength * 2; container.y = origY + (Math.random() - 0.5) * strength * 2; requestAnimationFrame(updateShake); } updateShake(); }

注意：震动只会影响游戏内容层，不能把UI也带着抖，否则计分文字会晃得看不清。所以我把UI放在独立的UI容器里，不参与震动。

6. 敌人AI与关卡判定

6.1 敌人基础AI：巡逻、追击、随机开火

敌人AI不用多先进，够用就好。我的策略是三个状态轮着来：

• 状态A：直线移动。按当前方向前进，碰到障碍物或边界就换向。
• 状态B：随机转向。每隔一段时间随机挑一个新方向，防止敌人永远困在一个角落。
• 状态C：射击。当玩家在敌人前方直线视野内且没有墙体阻挡时，敌人开火。否则按固定概率随机放枪。

这套AI会让敌人看起来“有点聪明但并不狡猾”，和原作的观感很接近。

update(delta) { // 每隔2~4秒随机改变一次方向 this.aiTimer -= delta; if (this.aiTimer <= 0) { this.changeRandomDirection(); this.aiTimer = 2 + Math.random() * 2; } // 如果玩家大致在自己的前方直线视野里，尝试瞄准并开火 if (this.hasLineOfSightTo(playerTank) && Math.random() < 0.3 * delta) { this.shoot(); } this.moveForward(delta); }

hasLineOfSightTo的实现很简单：比较坦克朝向与玩家相对方向，如果同轴且在有效距离内，再检查中间是否有砖墙或钢墙。不让子弹穿透墙打人，这个判断能降低AI的“作弊感”。

6.2 敌人刷新机制与波次控制

原作中敌人是“活着到上限，死了补新”。我做的是更保守的模型：同一时间屏幕上最多3个敌人，敌人池总数为20个。每死一个，过2秒从出生点补充一个，直到池子清空。

这样做有几个好处：战斗节奏比较平稳，不会被一窝蜂的敌人压垮；性能也更容易控制。

出生点有3个，每个都是单独的坐标。刷新时优先选择离玩家当前位置较远的出生点，避免敌人刚刚出生就踩脸开火，这个设计对新手玩家非常友好。

6.3 胜负判定与关卡切换

胜负判定有两个条件：

• 玩家生命数耗尽，或者基地血量归零 → 游戏结束
• 所有敌人清空且无剩余待刷新 → 过关

我单独维护一个gameState枚举，取值是playing,victory,gameover。只有playing状态下更新游戏逻辑，避免游戏结束后还继续刷子弹和AI，这点很容易被忽略。

过关后展示一个短暂的全屏遮罩，显示“进入下一关”，然后重置坦克位置、子弹、瓦片和敌人池。切换关卡时还要注意清空所有子弹，否则上一关残留的子弹会飞到下一关打穿墙。

6.4 调试辅助：状态可视化和慢速模式

敌人AI这类逻辑看不见摸不着，调试时我加了一个“调试开关”，把每个敌人的状态直接用文字精灵显示在头顶上。按D键可以切换显示，T键可以让时间流逝速度变慢，方便观察AI决策。

这个习惯强烈推荐。游戏逻辑层的问题，用眼睛看比用console.log有效率得多。PIXI里给对象加一行文字的代码也就十行，但排查问题能省半小时起步。

7. 常见问题与踩坑记录

7.1 WebGL初始化失败与PIXI回退

PIXI优先用WebGL，但有些浏览器或旧设备不支持。这时候PIXI会自动尝试回退到Canvas渲染器，但前提需要在创建Application时开启forceCanvas参数吗？实际上，PIXI v7的错误处理方式是：如果WebGL创建失败会抛异常。我的做法是捕获异常并再次创建应用：

let app; try { app = new PIXI.Application({ ... }); } catch (e) { app = new PIXI.Application({ ..., forceCanvas: true }); }

不过在几乎所有的现代浏览器里，WebGL 1都是可用的，这个兜底更多是保险。

7.2 碰撞抖动与分离向量

坦克贴墙移动时，如果用简单的“整体回退”，会发生抖动：因为回退量可能不够，下一帧又撞上，再回退，来回反复。解决的思路我在前面提到过——分轴回退，但还有一个进阶技巧是计算最小分离向量（MTV）。简单说就是：如果坦克与墙发生重叠，找出重叠最小的方向，把坦克沿这个方向推出。这个技巧在新手阶段不一定要实现，但如果你发现坦克抖动严重，优先检查回退逻辑是不是把X、Y绑架在一起了。

7.3 键盘粘滞与页面焦点丢失

一个特别典型的坑：玩家按住方向键的同时切到别的窗口，回到游戏后会发现自己没按任何键但坦克还在移动。原因是keyup事件在窗口失焦时丢失了，按键状态停留在true。修复方法是监听窗口的blur事件，在失焦时清空所有按键状态：

window.addEventListener('blur', () => { Object.keys(keys).forEach(k => keys[k] = false); });

这个坑要是没有处理，会让人误以为是移动逻辑写错了，排查了半小时最后发现是焦点问题。

7.4 贴图模糊与像素风适配

如果你用贴图而不是程序绘制，很可能会遇到“像素风画面模糊”问题。原因大多是canvas被插值缩放了。解决方案分两步：

• PIXI创建时把resolution设为window.devicePixelRatio || 1，同时autoDensity: true
• CSS里给canvas加image-rendering: pixelated

7.5 音效无法播出的autoplay策略

浏览器的自动播放限制会让音效在用户交互前无法播放。你可以在用户第一次点击页面时提前“解锁”音频上下文，常见做法是：

window.addEventListener('pointerdown', () => { const ctx = new (window.AudioContext || window.webkitAudioContext)(); if (ctx.state === 'suspended') ctx.resume(); // 把ctx存起来供后续播放音效用 });

把音效播放的时机都放在用户交互或游戏事件后，就不会被浏览器拦截。

8. 性能优化与后续扩展方向

8.1 渲染性能的直觉优化

先看有没有必要优化。坦克大战这种规模，如果只是几十个精灵同时存在，现代设备完全跑得动高帧率。最容易拖垮性能的不是精灵数量，而是“每一帧都重复创建”的临时对象。

子弹和爆炸就是重灾区。我第一版的子弹发射就是new PIXI.Sprite再destroy()，一口气打几十发后发现明显的掉帧和GC卡顿。后面改成“对象池”方案：预先创建一批子弹精灵放在池子里，需要发射时从池子取出，用完了隐藏而不是销毁。这个优化对长期运行时稳定性的提升非常明显，尤其在移动端上。

8.2 自适应的进一步思考

如果你的目标是手机横屏玩，整流不变形、忽略safe area的问题都需要考虑。要做得更好，我建议把游戏核心逻辑建立在固定尺寸的逻辑坐标系上，然后通过一个缩放比例映射到实际屏幕，这样后续适配iPad、折叠屏、异形屏都只需改这一处。

8.3 后面还能怎么扩展

这个项目做完后，我计划从几个方向扩展：

• 双人模式：第二辆坦克用不同的按键控制，UI增加P2生命值。
• 随机地图生成：用简单的BSP算法或Perlin噪声生成砖墙分布，让每一关都不一样。
• 更细腻的动画：履带动画、屋顶被破坏的碎片物理、子弹拖尾光效。

这其中的每一个都对应一个新的技术点，可以在后续系列文章里专门展开。

我最后的几点体会

做这个坦克大战Demo，最大的收获不是“会了PIXI API”，而是把游戏开发里最常用的一套工作流完整跑通了：数据驱动地图、实体管理、碰撞检测、状态机切换、调试技巧。这些是底层能力，换任何引擎、换任何玩法都通用。

如果你正在跟着做，我的建议是：先别用精美素材，用色块和形状把逻辑跑顺，确认操作手感和碰撞反馈都没问题之后，再替换素材、加音效、做优化。模块顺序从地图开始，依次走到坦克、子弹、AI、UI，每完成一个模块就玩一下，亲手感受变化。这种“能看到自己进步”的节奏，比闷头写两小时代码再一次性调试要舒服得多。

如果在某个环节卡住了，欢迎带着问题来讨论。毕竟游戏开发里最常挂在嘴边的三个字就是——试一下，很多问题不亲手试，永远不知道坑在哪里。