Unity雷霆战机Demo源码解析：对象池、碰撞体与WebGL性能调优

简介：这是一份基于Unity引擎的雷霆战机Beat U游戏Demo源码包，适合有一定C#基础、想学习飞行射击类游戏整体架构的Unity开发者。资源共599个文件，压缩包约11.7MB，主要包含21个C#脚本、11个Prefab、40张PNG图片、6个动画控制器，以及Asset、Mat、MP3音频和场景文件，覆盖了战机武器升级、蓄能攻击、重型武器、辅助导弹等核心玩法模块。每架战机拥有独立武器逻辑，Xtom和VXmk II使用机枪、Warlock使用激光，升级后伤害提升或生成辅助小飞机；按住攻击键可蓄能释放能量，重型武器可清除敌方子弹，拾取飞碟可获得跟踪或直线导弹，完整度较高，可直接在Unity编辑器中查看运行。已有931人学习下载，无论是用于课程设计、毕设参考，还是入门Unity游戏Demo开发，都能提供实用的代码结构与资源组织参考。

1. 用 Unity 复刻雷霆战机 beat u，为什么值得研究这套 Demo 源码

如果你打开 Unity Asset Store 搜索 “Space Shooter” 或 “Vertical Scroller”，能翻出几百个项目，但绝大多数要么是纯美术资源包，要么是半成品工程。而一套名为 beat u 的雷霆战机类 Demo 源码，恰好落在这两者中间：它具备完整的竖版弹幕射击玩法闭环，包含玩家战机操控、子弹系统、敌机生成、碰撞判定、计分和 UI 流程，代码组织上接近商业项目的分包习惯，又不像商业源码那样堆了太多框架层。对想学 Unity 游戏开发的人而言，把这类 Demo 源码逐行读一遍，比看十遍教程视频都更有价值。

这套项目的价值不只在“能跑起来”，而是它背后覆盖了 Unity 开发里几个高频刚需：对象池管理、MonoBehaviour 生命周期控制、预制体实例化与复用、物理碰撞和触发器判定、以及游戏状态流转。这些知识点单独拎出来都能搜到教程，但把它们串在“飞机大战”这一个具体游戏里，你才能看见真实工程里它们是怎么配合的。读完这套源码，你能回答一个常见问题：为什么别人写的飞机大战子弹再多也不卡，我自己写了三百颗子弹帧率就掉到二十？

本文基于一套典型的 Unity 雷霆战机类 Demo 工程结构，结合我平时在模拟飞行类和射击类小游戏项目里的落地经验，把源码拆成五个部分：场景搭建、子弹池、敌机波次、碰撞奖励、验证调优。新手可以按章节逐步把代码抄进自己的工程跑通，有经验的开发者可以直接看参数设计和性能关键点，对照检查自己的实现有没有埋雷。

2. 先看清 beat u Demo 的场景结构与核心组件

2.1 竖版射击场景的摄像机、背景和坐标约定

打开这个 Demo 工程的第一件事，不是看代码，而是看 Hierarchy 面板里挂了哪些东西。正常情况下，一个完整的竖版射击场景应该有这几类对象：Background（滚动的星空背景层）、Player（玩家战机）、EnemySpawner（敌机生成器）、BulletPool（子弹池容器）、UI（分数和血条）。如果源码里还挂着一个 GameManager 空物体，那说明作者用了单例或静态类管理全局状态。

坐标系是最容易忽视的坑。竖版射击游戏通常把摄像机设为正交投影（Orthographic），Size 值决定屏幕上下各能看到多少世界单位。大多数人会直接套用默认的 5，然后发现飞机在屏幕上看起来特别小，子弹飞出去瞬间就出画面了。我一般会把 Camera 的 Size 设成 9 左右，背景图按 1080×1920 的比例切好，铺满整个视口后边缘不留黑边。这个参数直接决定后面所有物体的移动速度基准，比如子弹每帧移动 20 个单位时，如果 Size 是 5，子弹不到半秒就飞出屏幕，玩家根本来不及反应。

背景滚动是这个类型游戏里最容易被写坏的地方。常见的错误做法是把一张大图放在场景里，然后用代码改它的 Y 轴位置。正确做法是把背景图设成 Wrap Mode 为 Repeat 的 sprite，在 Shader 或代码里让材质 Main Texture Offset 的 Y 值随时间递减，从而实现无限滚动而不用复制多张图。对应代码大致是这样：

public class ScrollingBackground : MonoBehaviour { public float scrollSpeed = 0.5f; private Renderer bgRenderer; void Start() { bgRenderer = GetComponent<Renderer>(); } void Update() { Vector2 offset = bgRenderer.material.mainTextureOffset; offset.y -= scrollSpeed * Time.deltaTime; bgRenderer.material.mainTextureOffset = offset; } }

这段代码的关键在mainTextureOffset的 Y 值持续递减，配合材质面板里把纹理 Wrap Mode 设为 Repeat，就能让背景无限向下滚动。如果滚动过程中出现接缝或闪断，优先检查 Sprite 的 Mesh Type 是不是 Full Rect，以及纹理导入设置里 Compression 是否过高导致边缘采样异常。scrollSpeed 的基准值我建议按 0.3 到 0.6 之间调，太快会让玩家视觉疲劳，太慢则缺乏飞行速度感。

2.2 玩家操控：用 Input 系统还是直接改坐标

在 Analog 摇杆和触屏手势普及之前，传统竖版射击游戏都是键盘方向键加空格射击。这个 Demo 里十有八九用的是老的Input.GetAxisRaw方案，因为它在 PC 上最直观。核心逻辑在 PlayerController 的 Update 里：

public class PlayerController : MonoBehaviour { public float moveSpeed = 10f; public float padding = 0.5f; private float xMin, xMax, yMin, yMax; void Start() { Camera mainCamera = Camera.main; float distance = transform.position.z - mainCamera.transform.position.z; Vector3 bottomLeft = mainCamera.ViewportToWorldPoint(new Vector3(0, 0, distance)); Vector3 topRight = mainCamera.ViewportToWorldPoint(new Vector3(1, 1, distance)); xMin = bottomLeft.x + padding; xMax = topRight.x - padding; yMin = bottomLeft.y + padding; yMax = topRight.y - padding; } void Update() { float moveX = Input.GetAxisRaw("Horizontal"); float moveY = Input.GetAxisRaw("Vertical"); Vector3 newPos = transform.position; newPos.x += moveX * moveSpeed * Time.deltaTime; newPos.y += moveY * moveSpeed * Time.deltaTime; newPos.x = Mathf.Clamp(newPos.x, xMin, xMax); newPos.y = Mathf.Clamp(newPos.y, yMin, yMax); transform.position = newPos; } }

这段代码有两点值得细看。第一，用ViewportToWorldPoint结合摄像机算出移动边界，而不是写死某个数字，这样不管调 Size 还是改分辨率，玩家飞机都不会飞出屏幕。第二，Mathf.Clamp同时约束 X 和 Y，防止玩家从上下边缘溜出去。很多新手会漏掉 Y 轴 clamp，导致飞机可以贴着画面顶边飞行，视觉上像是卡到背景图上。

移动速度 10 这个值不是随便拍的。在 Size 为 9 的正交摄像机下，屏幕可见高度约 18 个单位，宽度取决于纵横比。以 16:9 计算，屏幕宽度约 32 个单位，穿越整个屏幕大约需要 3 秒。这个手感偏慢，适合还没有做子弹加速和敌方弹幕复杂的早期版本。到后期如果要加敌人弹幕，建议把 moveSpeed 提到 14 左右，同时把移动方向输入改成GetAxis（带平滑过渡），否则直接按方向键输入会有阶梯感。

2.3 开火点位置和子弹初始朝向

开火点设计往往是源码阅读者最容易忽略但实际最影响手感的部分。好的开火点要贴合飞机贴图——机头两侧各一个，子弹从机翼前端出现而不是从飞机中心冒出。如果飞机贴图挂在 Player 根物体上，而开火点挂在两个子物体上（GunLeft、GunRight），那么子弹生成位置就应该取这两个子物体的transform.position，而不是在 Player 坐标上加偏移。这样如果以后给飞机加左右倾斜动画，开火点会跟着机身动作走，不会出现子弹从旁边飘出来的违和感。

子弹朝上飞还是朝前飞，取决于你的场景坐标系设定。如果玩家飞机面朝正 Y 轴（Unity 2D 默认），子弹刚体的 velocity 应该是Vector2.up * bulletSpeed。这里有个容易错的地方是子弹用transform.Translate移动时，如果父物体是 Player 而 Player 本身在动，子弹会继承父物体的位移导致轨道偏移。稳妥的做法是在生成子弹后，把子弹设为独立物体或者 BulletPool 的子物体，并用刚体加 velocity，而不是用 Transform 移动。

3. 子弹对象池的合理设计，让万发子弹不掉帧

3.1 为什么雷霆战机类游戏必须用对象池

如果在这个 Demo 源码里只挑一个模块来精读，那必须是对象池。原因很简单：雷霆战机的高射速加多敌机意味着每秒钟可能同时存在数百颗子弹，如果每颗子弹都走Instantiate和Destroy，Unity 会不断分配和释放内存，触发频繁的 GC Alloc，表现为帧率随时间快速下降，或者卡顿瞬间掉到个位数。

对象池的核心思想是：第一次生成时批量创建指定数量的子弹预制体，全部隐藏放到一个容器下；需要发射时从池里取出一个并激活，设置好位置和速度；子弹飞出边界或命中目标后不销毁，而是再次隐藏并归还给池子。这样整个游戏过程中，子弹的实例化只发生在前几秒，后续全是激活和隐藏的状态切换。

有些 Demo 里的对象池只是简单封装了一个 List 加一个取用方法，够用但不够好。一个更稳健的设计应当在取用子弹时支持三种情况：池里有空闲子弹则直接取；池里有实例但全部占用则按需扩展；池里为空则新建实例。这样既保证极端情况下不会因无子弹可用而卡壳，又不会在游戏一开始就创建几百发可能永远用不到的子弹。

3.2 一份可直接用的子弹池实现

using System.Collections.Generic; using UnityEngine; public class BulletPool : MonoBehaviour { public GameObject bulletPrefab; public int preloadCount = 30; public Transform poolContainer; private List<GameObject> pool = new List<GameObject>(); void Start() { for (int i = 0; i < preloadCount; i++) { CreateNewBullet(); } } GameObject CreateNewBullet() { GameObject bullet = Instantiate(bulletPrefab, poolContainer); bullet.SetActive(false); pool.Add(bullet); return bullet; } public GameObject GetBullet(Vector3 position, Quaternion rotation) { foreach (GameObject bullet in pool) { if (!bullet.activeSelf) { bullet.transform.position = position; bullet.transform.rotation = rotation; bullet.SetActive(true); return bullet; } } GameObject newBullet = CreateNewBullet(); newBullet.transform.position = position; newBullet.transform.rotation = rotation; newBullet.SetActive(true); return newBullet; } public void ReturnBullet(GameObject bullet) { bullet.SetActive(false); } }

这个实现的取用逻辑是顺序遍历池子找空闲子弹，找不到就新建并加入池中。在子弹数量几百发这个量级下，顺序遍历的开销完全可以忽略。使用时的配套逻辑是：射击时调用GetBullet，子弹脚本里检测到飞出屏幕或命中敌人时调用ReturnBullet把自身归还。从 Player 脚本那边调用的写法大致是：

GameObject bullet = bulletPool.GetBullet(gunLeft.position, Quaternion.identity); bullet.GetComponent<Rigidbody2D>().velocity = Vector2.up * bulletSpeed;

这里把poolContainer设为子弹池物体自身比较合适，这样 Hierarchy 面板里能看到所有子弹整齐地挂在池子下面，调试时一目了然。preloadCount 我一般设成玩家射速乘以同时在场子弹最大存活秒数再乘 1.5。比如射速每秒 10 发，子弹从发射到飞出屏幕约 3 秒，那就是 10×3×1.5≈45，初始预载 45 发足够覆盖大多数情况。

3.3 用 OnBecameInvisible 还是手动边界检测

子弹飞出屏幕后的回收有两种常见做法：OnBecameInvisible回调或者手动比较坐标。前者在子弹离开所有摄像机视野时自动触发，但有个隐蔽的问题——如果多个摄像机存在或者子弹刚生成时还没进入任何摄像机视野，回调可能不会立即触发。后者是自己写一个边界判断，超出范围直接回收，逻辑透明。

手动坐标判断的代码在子弹脚本的 Update 里加几行就够了：

void Update() { Vector3 pos = transform.position; if (pos.y > 20f || pos.y < -20f || pos.x > 30f || pos.x < -30f) { pool.ReturnBullet(gameObject); } }

边界值 20 和 30 来源于摄像机 Size 为 9 时的可見范围，比可视区域略大一圈，保证子弹完全离开画面后再回收，不至于在屏幕边缘闪没。注意这里的数值没有考虑摄像机可能移动的情况，如果游戏里有屏幕震动或摄像机跟随，边界应该从摄像机的ViewportToWorldPoint动态计算。

4. 敌机波次与碰撞体设计——从生成器到命中判定

4.1 用数据驱动生成敌机波次，而不是每波写死脚本

雷霆战机类游戏最忌讳把每一波敌人的生成逻辑写在 Update 里用 if 计数硬编码，因为改一波敌人就要改代码再重新编译。成熟的 Demo 会采用数据驱动思路：把每一波的敌机类型、数量、生成间隔、横向位置、移动路径存放在一个配置类或 ScriptableObject 里，让一个 EnemySpawner 按配置驱动生成。

实际工程里最常见的方式是写一个 WaveConfig：

[System.Serializable] public class WaveConfig { public GameObject enemyPrefab; public int count = 5; public float spawnInterval = 1f; public float moveSpeed = 3f; public float startX = 0f; public float startY = 10f; }

一个波次就是 List 里的一项。EnemySpawner 协程依次读取这些配置，在每个间隔里实例化敌机。这种设计的最大好处是调整难度只需要改序列化数据，策划同学在 Inspector 里就能配置整关敌人的排布，不用动代码。如果要加新的敌人类型，新建一个预制体往配置里一拖就行。

生成器的协程写法大致是这样：

IEnumerator SpawnWave(WaveConfig wave) { for (int i = 0; i < wave.count; i++) { Vector3 spawnPos = new Vector3(wave.startX + Random.Range(-1f, 1f), wave.startY, 0); GameObject enemy = Instantiate(wave.enemyPrefab, spawnPos, Quaternion.identity); EnemyController enemyCtrl = enemy.GetComponent<EnemyController>(); enemyCtrl.moveSpeed = wave.moveSpeed; yield return new WaitForSeconds(wave.spawnInterval); } }

这里每次生成都用了Random.Range给 X 坐标加了一点随机偏移，目的是让敌人不是一列纵队，否则玩家只需要定点站着就能全清，毫无压力。如果波次里敌人数量大而生成间隔短，可以配合对象池来实例化敌人，逻辑和子弹池一样，不重复展开。

4.2 碰撞体配置：Trigger 还是 Collider，层级怎么分

碰撞检测是飞机大战里最讲究细节的部分。很多 Demo 里玩家飞机、敌人、子弹、敌方子弹全部使用 Collider2D，然后通过碰撞回调处理逻辑，结果就是玩家撞到子弹的同时会被敌人的身体连续触发多次伤害判定，血条一瞬间就空了。

我一般会按物理层级把碰撞对象分成两组：玩家子弹 vs 敌人，敌方子弹 vs 玩家。这两组之间用 2D Physics 碰撞矩阵区分——在 Edit > Project Settings > Physics 2D 里，把 Player 层和 PlayerBullet 层的碰撞设为不响应，同时把 Enemy 层和 EnemyBullet 层也设为不响应。这样一来，碰撞回调里只需要简单判断对方所属层级就能决定是造成伤害还是忽略，不会出现同类互撞误伤。

碰撞回调代码可以这样组织：

void OnTriggerEnter2D(Collider2D other) { if (gameObject.CompareTag("PlayerBullet") && other.CompareTag("Enemy")) { EnemyController enemy = other.GetComponent<EnemyController>(); enemy.TakeDamage(1); bulletPool.ReturnBullet(gameObject); } else if (gameObject.CompareTag("Enemy") && other.CompareTag("Player")) { PlayerController player = other.GetComponent<PlayerController>(); player.TakeDamage(1); ExplodeAndDestroy(gameObject); } }

这里用 Tag 而不是用层来判断，是因为 Tag 语义更直观，且场景里对象的数量不多，字符串比较的性能损耗完全可忽略。用 CompareTag 而不是直接other.tag ==是因为前者会做内部优化，避免产生 GC 垃圾。

4.3 敌机死亡时播放爆炸效果，怎么做到不卡顿

敌机被击毁时播放一个粒子爆炸效果是雷霆战机类游戏的高频操作。常见的错误做法是每次爆炸都新建一个粒子系统然后等它播放完再 Destroy，几十个敌人同时爆炸时帧率会断崖式下跌。更稳的做法是做一个爆炸效果池，和子弹池同理，预创建若干个粒子系统实例，需要时取出一个重置其位置和粒子状态，播放完再回收。

一个可用的粒子回收代码片段：

public class ExplosionPlayer : MonoBehaviour { private ParticleSystem explosionEffect; public void PlayAt(Vector3 position) { transform.position = position; explosionEffect.Clear(); explosionEffect.Play(); } }

粒子播放结束后的回收用协程或粒子系统的 Stop Action 属性都可以。如果使用粒子池，记得把 ParticleSystem 的 Stop Action 设为 None，以免系统自动销毁 GameObject 破坏池结构，导致后续取用时对象为空。

5. 计分、血量与游戏状态流转——如何把玩法串起来

5.1 分数更新与 UI 绑定：避免每帧刷新 Text

计分在源码里看起来最简单，但实际踩坑的人不少。新手通常会写这样的代码：

void Update() { scoreText.text = score.ToString(); }

每一帧都修改 UI Text 的 text 属性，会产生字符串拼接的 GC 垃圾，频繁触发不必要的内存分配。正确做法是在分数变化时才刷新 UI：

public void AddScore(int points) { score += points; scoreText.text = "分数: " + score; }

这样游戏期间分数不变时，UI 层完全不动；只有敌人被消灭时才会触发一次字符串更新。在大量敌人同时死亡的场景里，这种写法能明显减少 GC Alloc。

5.2 游戏结束和重新开始的流程怎么管理

一套完整的雷霆战机 Demo 需要处理玩家死亡、显示结算面板、重新开始三个状态。用 Unity 的SceneManager.LoadScene重新加载整个场景是最简便的方式，但会重置所有池子和缓存，部分老手会改用状态机加手动重置的方式。对一个学习用 Demo 而言，重载场景完全够用。

重新开始的代码基本长这样：

public void RestartGame() { Time.timeScale = 1f; SceneManager.LoadScene(SceneManager.GetActiveScene().name); }

这里要提一个新手常犯的错：游戏结束弹出面板后，通常会设置Time.timeScale = 0来暂停游戏。但如果面板上的按钮点击事件仍依赖 Update 里的输入逻辑，你会发现按钮怎么点都没反应。此时需要在按钮回调里先把 timeScale 恢复到 1，再执行重载场景。换个角度，如果不想动 timeScale，可以把暂停逻辑改成在 UI 里挂一个全屏射线拦截物体，让点击事件只落在按钮上。

5.3 加入奖励型的无人机僚机机制

很多进阶 Demo 会加入僚机或护盾这种道具系统。僚机的实现思路很简单：生成一个子物体挂到玩家下面，位置跟随玩家，同时按固定间隔向敌人发射子弹。如果是双翼僚机，左右各挂一个，开火时间交错半拍，视觉上就有连续弹幕的效果。

public class DroneFollower : MonoBehaviour { public Transform player; public Vector3 offset = new Vector3(-1.5f, -1f, 0); public float fireInterval = 2f; private float timer; void Update() { transform.position = player.position + offset; // 跟随玩家 timer += Time.deltaTime; if (timer >= fireInterval) { Shoot(); timer = 0f; } } }

僚机本质上就是把玩家的开火逻辑复制一份，挂到另一个物体上。只要注意两点：一是僚机不要跟随玩家的旋转，只跟随位置，否则飞机翻转时僚机位置会很怪异；二是僚机的子弹也要走和玩家同一个子弹池，否则会新起一套实例，导致内部产生的集合出现两份。

6. WebGL 导出验证与性能监控技巧

6.1 用 WebGL 验证 Demo 跑起来后该看哪些参数

Unity 工程写完 Demo 后，最直接的验证手段是导出 WebGL 版在浏览器里跑，这也是热词里“unity 发布 webgl 使用 idbfs 写入失败”出现的典型场景。这里有个常见坑：如果项目里用了 PlayerPrefs 存档，WebGL 平台下会写入浏览器的 IndexedDB，当你从本地文件直接打开 HTML 时，部分浏览器会因安全策略拒绝写入，表现为保存后刷新记录丢失或报 IDBFS 写入失败。解决办法是起一个本地静态服务器运行，或者用 Unity 的 WebGL 构建面板直接预览。

验证游戏循环是否正常工作的几个关键参数：

在 WebGL 版里按 F12 打开浏览器控制台，能看到 Unity 输出的 Console 日志。这里的错误信息往往直接指向问题所在。最常见的几类：找不到预制体、空引用、物理层级设置错误导致子弹穿越。

6.2 帧率统计代码直接贴在 GameManager 里

一套稳定的帧率和 GC 监控代码是雷霆战机这类高频实例化游戏的必备工具。一个最轻量的实现是每秒统计一次帧数：

public class FPSDisplay : MonoBehaviour { private float deltaTime = 0f; private float fps; void Update() { deltaTime += (Time.unscaledDeltaTime - deltaTime) * 0.1f; fps = 1.0f / deltaTime; } void OnGUI() { GUIStyle style = new GUIStyle(); style.fontSize = 24; style.normal.textColor = fps >= 45 ? Color.green : Color.red; GUI.Label(new Rect(10, 10, 200, 40), $"FPS: {fps:F1}", style); } }

把这段代码挂到 GameManager 物体上，用 OnGUI 显示帧率比较直接，方便快速看效果。如果不想在游戏画面上显示，也可以把它改成定时输出到 Unity Console。要注意的是Time.unscaledDeltaTime不能换成Time.deltaTime，因为游戏结束时的暂停逻辑会设置timeScale = 0，如果使用缩放后的 deltaTime，帧率统计也会停止，看不到暂停时的真实表现。

6.3 验证 Demo 源码里对象池是否真的工作的技巧

在地面验证对象池有没有真正生效，可以打开 Unity 的 Profiler，录制游戏前 10 秒的 CPU 数据，重点看 Msg 栏里的 Instantiate 和 Destroy 调用次数。如果前几百帧里这两个操作的次数一直为一个固定值不再增长，说明池子生效了。如果随着游戏进行 Instantiate 次数持续增长且对应 Destroy 出现明显滞后，那说明池子的回收逻辑有漏洞，部分子弹或敌机没有被归还进池中，一直在场景里堆积。

另一个快速检查方法是打开 Hierarchy 面板，在游戏运行过程中看 BulletPool 和 EnemyPool 下的活动子物体数量。如果这个数字在波动但始终维持在一个区间内，说明复用正常；如果持续上涨且从不回落，就说明有对象漏在了场景某个角落，它的 Update 还在跑，但已经飞出玩家视野之外。此时排查方向是它的回收边界判断是否和摄像机实际视口匹配，比如改了摄像机 Size 但没改回收边界常量。

本文还有配套的精品资源，点击获取