Unity3D塔防游戏虚拟现实大作业：从零到exe完整实现指南

简介：面向Unity3D初学者及虚拟现实课程作业需求，这份塔防游戏项目提供了从源代码、可执行程序到设计报告的完整学习闭环。压缩包约37.3MB，虽未显示文件总数，但主要文件包括Unity工程源程序、可直接运行的EXE以及游戏设计报告；源代码中涉及路径规划、敌人AI、炮塔攻击等关键组件，设计报告则涵盖概念设计、关卡设计、用户界面与技术实现细节等内容。目前已有2055人学习下载。借助源码可掌握脚本编写与Unity组件化开发，借助可执行程序能直观感受虚拟现实交互和构建打包流程，报告还整理了性能优化、测试调试与发布策略，适合作为大作业模板并形成自己的项目思路。这份资源对期末大作业参考或自学虚拟现实游戏设计很有帮助，对照设计报告与实际运行效果，可以较快理解从场景搭建、脚本逻辑、虚拟现实交互到构建发布的全过程。

1. 为什么 unity3D塔防游戏-虚拟现实大作业 是最划算的课程设计选题

期末周临近，很多同学拿着「unity3D塔防游戏-虚拟现实大作业」这个标题在找可复现的完整方案。它之所以反复出现，是因为这类交付物踩中了大学课程设计最常见的需求：一个人、一两周时间、一台普通笔记本，要交出一个能当场演示、有交互、有文档、还能打包成 exe 的完整游戏。塔防恰好是「unity3d简单小游戏项目」里性价比最高的选题——敌人沿固定路线走，塔自动攻击，玩法边界清楚，代码量可控，俯视场景对美术要求也不高。

但这不代表它不会翻车。我见过太多人卡在最后一步：工程结构写乱，想加一种塔就得改三个脚本；虚拟现实课程要求没落实，演示现场拿不出 VR 相关交互；exe 导出后到教室电脑上黑屏、缺文件；游戏设计报告憋了两页就写不下去。下面按这套交付物的四个重点——源程序、玩法、虚拟现实交互、exe 与报告——拆清楚每一步怎么做、参数怎么设、坑在哪。

2. 搭工程骨架：Unity 版本、场景对象树与脚本分层

2.1 版本选型：2021.3 LTS 配内置渲染管线

B站和文档里的 Unity 教程大部分基于 2021.3 或 2022.3 LTS，我一般建议直接用这两个版本。LTS 版本维护周期长，网上踩坑记录最多，碰到问题基本能搜到答案。更重要的是，如果三个人分工或老师要检查工程，版本不一致会直接导致工程打开报错、脚本丢失。选定一个 LTS 版本后，整个组都用同一个版本，能省掉大量沟通成本。

渲染管线别折腾 URP 或 HDRP。作业规模下，内置渲染管线（Built-in）最省心：默认材质全部兼容，不会出现模型紫粉色那种让人抓狂的情况；对集成显卡笔记本友好，打包后体积也小。URP 在低端显卡上确实有性能优势，但需要额外处理材质、Shader、后处理的兼容性，这些时间花在玩法上更值。报告里写「采用内置渲染管线以减少低端设备兼容风险」，这一句就是技术选型意识，老师是认的。

2.2 场景对象树：管理器、路径点、塔与敌人全部用 Prefab

打开 Unity 后，先别急着摆场景。把对象树按职责分成四块：管理器、路径点、塔与敌人的 Prefab、终点 Base。用 text 看起来是这样的：

GameManager # 空物体，挂 GameManager.cs WaveSpawner # 空物体，挂 WaveSpawner.cs PathPoints # 空物体容器，下面按出生点到终点顺序排列子物体 Waypoint 0 Waypoint 1 Waypoint 2 ... Towers # 塔实例统一放在这个容器下 EnemySpawnPoint # 空物体，标记敌人出生位置 Base # 终点，带 BoxCollider，勾选 Is Trigger

所有逻辑管理器挂在空物体上，不要挂在 Camera 上。原因是运行时切换视角、移动摄像机，管理器不会跟着销毁，游戏状态保持连贯。空物体没有渲染开销，作为纯逻辑节点非常干净。

塔和敌人一律做成 Prefab，路径点单独用空物体摆好。一个很常见的翻车是：路径点直接拖到 Enemy Prefab 的持有脚本上，运行时把 Enemy 实例化出来，路径引用却指向场景物体，切换场景后引用断裂，敌人原地发呆。正确做法是路径点只挂在一个容器下，由 WaveSpawner 运行时注入给敌人实例。

2.3 核心脚本职责：GameManager 用单例，事件用 UnityEvent

塔防最忌讳把所有逻辑塞进一个脚本。敌人血量、塔的攻击、波次生成全写在一个脚本里，后面每加一种塔就要复制粘贴一堆代码，改一个功能崩三处。把脚本按「管理器、实体、行为组件」分三层，是作业规模下最能控制复杂度的做法。

GameManager 是中央状态管理器，负责生命、金币、波次和游戏结束。给一个可以直接抄的骨架：

using UnityEngine; using UnityEngine.Events; public class GameManager : MonoBehaviour { public static GameManager Instance { get; private set; } [Header("玩家数值")] public int lives = 20; // 基地生命，敌人到达终点时扣减 public int money = 120; // 初始金币，用于放置塔 public int currentWave = 0; public UnityEvent onGameOver; // 在 Inspector 中拖入 UI 显示函数 private void Awake() { if (Instance != null) { Destroy(gameObject); return; } Instance = this; } public void LoseLife(int damage) { lives -= damage; if (lives <= 0) { onGameOver?.Invoke(); Time.timeScale = 0f; // 暂停游戏，而不是直接销毁场景 } } }

逻辑说明：单例模式在作业规模下够用，任何脚本都能用GameManager.Instance.LoseLife(1)直接访问，不用到处拖引用。但要注意在Awake里判空，防止场景切换或重复挂载时生成两个实例。UnityEvent的好处是把「游戏结束」这个事件暴露在 Inspector 面板上，UI 显示函数直接拖进去绑定，不用在代码里FindObjectOfType找 UI 对象，这能让逻辑之间解耦。

Time.timeScale = 0f是暂停游戏的标准做法。注意Update里用Time.deltaTime计算的逻辑都会停，但 UI 动画如果用Time.unscaledDeltaTime还会继续转。能在报告里写出这个区别，是个不错的加分项。

3. 塔防玩法落地：路径点寻路、波次生成与三类塔的攻击逻辑

3.1 固定路径点寻路：作业场景别碰 NavMesh

塔防敌人要不要用 Unity 的 NavMesh？我的答案是不用。NavMesh 适合给自由移动的人形角色做动态寻路，但塔防的路线本该是「可预测」的：玩家需要看着敌人从哪条路来、在哪拐弯，才好决定塔的位置。NavMesh 的烘焙过程还自带几个坑：场景地板漏标 Static、动态加载的地块没有 Bake、烘焙边角导致敌人绕路。这些不确定性在作业演示时都是风险。

固定路径点方案只需要一个Transform[]数组，从出生点到终点顺序排列。敌人运行时只做一件事：朝当前路径点移动，到达后换下一个，走完就从终点扣基地血量。代码量极小，逻辑完全可控。

using UnityEngine; public class EnemyMotor : MonoBehaviour { public Transform[] waypoints; // 由 WaveSpawner 运行时注入 public float moveSpeed = 2.5f; private int _index = 0; private const float ArriveDistance = 0.05f; private void Update() { if (waypoints == null || waypoints.Length == 0 || _index >= waypoints.Length) return; Transform target = waypoints[_index]; Vector3 pos = transform.position; // MoveTowards 是匀速直线移动，没有趋近衰减，到达判断干净 transform.position = Vector3.MoveTowards(pos, target.position, moveSpeed * Time.deltaTime); if (Vector3.Distance(transform.position, target.position) < ArriveDistance) { _index++; if (_index >= waypoints.Length) { GameManager.Instance.LoseLife(1); Destroy(gameObject); } } } }

逻辑说明：为什么用MoveTowards而不是Vector3.Lerp？Lerp 是按比例趋近，永远差一点，到达判断会变得很麻烦；MoveTowards 是等速移动，配合ArriveDistance判断非常干净。为什么不用transform.LookAt？LookAt 会让敌人抬头看向路径点，路径点高度只要有偏差，模型就会仰头或低头，俯视视角下非常难看。如果要让敌人朝向移动方向，正确做法是：

Vector3 direction = target.position - pos; direction.y = 0f; if (direction.sqrMagnitude > 0f) { transform.rotation = Quaternion.LookRotation(direction); }

路径点距离通常是三到五米，ArriveDistance = 0.05f足够判定到达，又不会在转角处来回抖动。如果你把它调到 0.001f，浮点误差会让敌人在到达前反复横跳，这是常见玄学问题，其实原因就在这里。

3.2 波次生成：协程控制刷怪节奏

波次生成用IEnumerator协程是 Unity 的常规做法。相比在Update里写计数器，协程可以把「生成 n 个敌人、每 0.5 秒一个、生成完等待 8 秒进入下一波」这种顺序逻辑直接写成同步代码，思路清晰，调试也方便。

using System.Collections; using UnityEngine; public class WaveSpawner : MonoBehaviour { public Transform enemyPrefab; public Transform spawnPoint; public Transform waypointsRoot; public float timeBetweenWaves = 8f; // 上一波结束后到下一波的间隔 public float firstWaveDelay = 3f; // 开局给玩家摆塔的时间 private int _waveIndex; private float _nextWaveTime; private void Start() { _nextWaveTime = Time.time + firstWaveDelay; } private void Update() { if (Time.time < _nextWaveTime) return; StartCoroutine(SpawnWave(_waveIndex)); _waveIndex++; _nextWaveTime = Time.time + timeBetweenWaves; } private IEnumerator SpawnWave(int wave) { int count = 4 + wave * 2; // 波次越大敌人越多 float interval = Mathf.Max(0.3f, 1.2f - wave * 0.05f); // 波次越大刷怪越密 Transform[] waypoints = CollectWaypoints(waypointsRoot); for (int i = 0; i < count; i++) { Transform enemy = Instantiate(enemyPrefab, spawnPoint.position, Quaternion.identity); EnemyMotor motor = enemy.GetComponent<EnemyMotor>(); motor.waypoints = waypoints; yield return new WaitForSeconds(interval); } } private Transform[] CollectWaypoints(Transform root) { Transform[] result = new Transform[root.childCount]; for (int i = 0; i < root.childCount; i++) { result[i] = root.GetChild(i); } return result; } }

逻辑说明：路径点数组在生成每个敌人实例后注入，而不是在 Prefab 上手动拖引用，避免实例化后引用断裂。CollectWaypoints用GetChild(i)而不是GetComponentsInChildren<Transform>()，因为后者会把容器自身也收进去，索引就乱了。

WaitForSeconds(interval)必须放在 for 循环内部。如果放在循环外，整波敌人会一次性全部刷出来，屏幕瞬间涌出几十个敌人，帧率直接掉到个位数，演示当场翻车。数值曲线方面，敌人数量每波加 2，刷怪间隔最低限制在 0.3 秒，防止后期波次无限加速导致逻辑失控。timeBetweenWaves = 8f是按地图长度经验取的，如果敌人走完全程需要 15 秒，这个值可以放到 10 到 12 秒，给玩家留出调整塔的时间。

3.3 塔的攻击逻辑：数据驱动三种塔，一个脚本搞定

塔和敌人之间的数据流应该是单向的：塔锁敌后生成子弹，子弹命中敌人调TakeDamage，敌人自己负责扣血、死亡、发金币。如果让塔直接改敌人血量，再加一个减速塔就得把所有逻辑复制一遍。

using UnityEngine; public class TowerShooter : MonoBehaviour { public float range = 4f; public float fireCooldown = 0.8f; public int damage = 10; public float slowFactor = 0f; // 0 表示不减速，0.5 表示减速一半 public GameObject bulletPrefab; private float _nextFireTime; private EnemyHealth _target; private void Update() { float timer = Time.time; if (timer < _nextFireTime) return; FindTarget(); if (_target != null) { Fire(timer); } } private void FindTarget() { float minDistanceSqr = range * range; _target = null; foreach (EnemyHealth enemy in EnemyRegistry.All) { if (enemy == null) continue; float distSqr = (enemy.transform.position - transform.position).sqrMagnitude; if (distSqr <= minDistanceSqr) { minDistanceSqr = distSqr; _target = enemy; } } } private void Fire(float time) { _nextFireTime = time + fireCooldown; Bullet bullet = Instantiate(bulletPrefab, transform.position, Quaternion.identity) .GetComponent<Bullet>(); bullet.Init(_target, damage, slowFactor); } }

逻辑说明：这里有个关键设计——敌人通过EnemyRegistry静态列表登记，而不是让每座塔每帧调Physics.OverlapSphere做球形扫描。OverlapSphere 是物理查询，塔一多、敌人一多，开销成倍增长。静态列表配合距离平方比较，省掉了每帧的物理查询和开方运算，这是塔防在敌人数量大时还能不掉帧的关键。

EnemyRegistry的实现很简单：敌人脚本在OnEnable加入列表，OnDisable移除。注意敌人销毁时会先置 null，遍历时要跳过空引用。

子弹脚本对应如下：

using UnityEngine; public class Bullet : MonoBehaviour { private EnemyHealth _target; private float _speed = 12f; private int _damage; private float _slowFactor; public void Init(EnemyHealth target, int damage, float slowFactor) { _target = target; _damage = damage; _slowFactor = slowFactor; } private void Update() { if (_target == null) { Destroy(gameObject); return; } transform.position = Vector3.MoveTowards( transform.position, _target.transform.position, _speed * Time.deltaTime); if (Vector3.Distance(transform.position, _target.transform.position) < 0.1f) { _target.TakeDamage(_damage); if (_slowFactor > 0f) _target.ApplySlow(_slowFactor); Destroy(gameObject); } } }

逻辑说明：子弹是「必中」逻辑，不要用刚体碰撞。Unity 的物理碰撞在高速运动下会有穿透问题，还得调碰撞检测模式，纯属给自己加活。这里简短后改用距离判断，命中后调TakeDamage，血量扣减和死亡结算由敌人自己完成，职责清晰。

三种塔用同一个TowerShooter，只改配置参数：

建造塔时用鼠标射线打地面，命中后判断金币是否足够，够就扣钱并在点击位置实例化塔。这段代码放第 4 章和 VR 放置对比，目的是让你看到同一套玩法在鼠标输入和 VR 输入下，只是「输入来源」换了，玩法逻辑完全不用动。

4. 虚拟现实交互：两种落地路径，选错直接在演示现场翻车

4.1 先判断验收红线：头显方案不是唯一解

标题里有「虚拟现实」，这里说点实在的。课程叫「虚拟现实技术」时，老师要的大多是「你用了 VR 相关的技术并体现交互」，不是非得让你在教室用头显演示。真实情况是：很多笔记本带不动 VR 双屏渲染，教室设备没有驱动，头显借来了也初始化失败。所以先花十分钟确认验收标准：如果老师接受「可探索的虚拟空间 + 第一人称巡视视角」，就走低成本方案；如果明确要求必须有头显交互，再走完整 XR 方案。两条路线的取舍直接决定你接下来一周的时间分配。

4.2 完整 XR 方案：XR Interaction Toolkit 配置与手柄放塔

官方现在推荐的是 XR Interaction Toolkit（简称 XRIT）。在 Unity 2021.3 LTS 上，Package Manager 里搜索安装 XR Interaction Toolkit 2.x，它会自动带上 OpenXR Plugin。配置步骤是固定的：

第一，Project Settings > XR Plug-in Management，勾选 OpenXR；在 OpenXR 的 Interaction Profiles 里添加 Motion Controller 对应的手柄配置文件。第二，场景里删掉默认 Camera，在 Hierarchy 右键选择 XR > XR Origin (VR)。XRIT 2.x 会生成一套标准结构，包含 Camera Offset 和左右手控制器模型。第三，给右手控制器挂上 XRRayInteractor 组件，让它发射一条激光射线，用于指向场景物体。第四，塔放置点需要一个可交互的地面层，专门给射线检测用。

手柄放塔的脚本可以直接挂在右手控制器上：

using UnityEngine; using UnityEngine.XR.Interaction.Toolkit; public class TowerPlacerVR : MonoBehaviour { public XRRayInteractor rightRay; public GameObject towerPrefab; public LayerMask buildLayerMask; // 只检测地面层 private void Update() { if (rightRay == null) return; // 从手柄射线拿到当前命中的 3D 点 if (rightRay.TryGetCurrent3DRayHit(out RaycastHit hit)) { // isSelectActive 对应手柄扳机按下的状态 if (rightRay.isSelectActive && (1 << hit.transform.gameObject.layer & buildLayerMask.value) != 0) { Vector3 spawnPos = hit.point; Instantiate(towerPrefab, spawnPos, Quaternion.identity); GameManager.Instance.ChangeMoney(-towerCost); } } } }

逻辑说明：锤子射线每隔几帧才刷新一次命中点，扳机按下时立刻放置。buildLayerMask的作用是只允许射线打中地面，避免手柄指向敌人或 UI 时误放。TryGetCurrent3DRayHit是 XRRayInteractor 的现成方法，它内部已经做了射线命中检测，不需要自己写 Physics.Raycast。注意放置后塔的 y 坐标可能跟着射线命中点浮动，如果地面不平整，可以在spawnPos上取整或固定到地面高度。

一个高频坑：VR 里操作 UI 时，射线打不中 Canvas 上的按钮。因为世界空间 Canvas 默认只有GraphicRaycaster才响应 UI 射线。必须在 Canvas 上额外挂一个TrackedDeviceGraphicRaycaster组件，否则手柄戳按钮完全没有反应。这个坑在 XRIT 2.x 里几乎必踩。

4.3 低成本方案：第一人称巡视视角代替头显

如果没有头显，或者演示机性能撑不住双屏渲染，第一人称巡视视角是最划算的降级方案。玩家用 WASD 在场景里走动，鼠标环视整个塔防战场，既保留了「在虚拟空间里观察」的体验，又对电脑配置完全无要求。

using UnityEngine; public class FreeLookController : MonoBehaviour { public float moveSpeed = 5f; public float lookSensitivity = 2f; private float _pitch; private void Update() { // 鼠标环视 float mouseX = Input.GetAxis("Mouse X") * lookSensitivity; float mouseY = Input.GetAxis("Mouse Y") * lookSensitivity; _pitch = Mathf.Clamp(_pitch - mouseY, -80f, 80f); transform.localRotation = Quaternion.Euler(_pitch, 0f, 0f); transform.Rotate(Vector3.up * mouseX, Space.World); // WASD 移动 float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 dir = (transform.forward * v + transform.right * h).normalized; transform.position += dir * moveSpeed * Time.deltaTime; } }

逻辑说明：_pitch单独累加并 Clamp 在正负 80 度之间，是为了防止你抬头翻过 90 度时视角倒转。transform.Rotate(Vector3.up * mouseX, Space.World)是绕世界 Y 轴旋转，这样角色抬头时不会发生万向锁翻滚。移动方向由forward * v + right * h合成后 normalize，保证斜着走时不会比直线走更快。

这套方案写在报告里要如实说明：第一人称巡视视角用于展示虚拟场景空间感和塔防战局，交互方式由 VR 手柄简化为鼠标键盘。老师看的是你「有没有实现虚拟现实空间」，而不是「有没有买头显」。低成本方案在教室电脑上双击 exe 就能跑，这比任何炫技都重要。

4.4 渲染注意点：VR 对帧率的要求

不管是头显还是巡视视角，渲染性能都是演示成败的关键。头显对帧率的容忍线很高，双屏渲染掉到 45 FPS 以下，眩晕感立刻出来，演示效果直接减分。巡视视角虽然对帧率宽松，但卡顿同样会显得作品业余。

几个最见效的调整：第一，Project Settings > Quality，把正式交付的 Quality Level 拖到 Low 或 Medium，不要开 Ultra。第二，主方向光的 Shadows 改为 No Shadows，实时阴影在低端机上是性能杀手。第三，塔防场景的静态地面、墙体全部勾选 Static，方便系统做静态合并。第四，后处理特效能不开就不开。

对比两种方案再决定投入方向：

5. 导出exe和游戏设计报告：常见问题与避坑排查

5.1 Build 前先做四件事，导出 exe 才有底

源程序能跑只是第一步，老师验收时更多时候是直接打开你导出的 exe。Build 之前，按顺序检查四个设置。

第一，Edit > Project Settings > Player > Product Name。这个值会变成 exe 文件名，建议写成英文，例如TowerDefenseVR。中文文件名在部分老系统上会出现乱码，没有回报。

第二，Other Settings 里把 Scripting Backend 选 Mono 还是 IL2CPP。作业规模下我推荐 Mono。Mono 构建快、调试方便、兼容性好；IL2CPP 是把 IL 转成 C++ 再编原生码，好处是更难被反编译，坏处是首次构建时间翻倍。除非报告里要强调「发布安全性」，否则 Mono 足够。Architecture 选 x86_64，这是当前 Windows 系统的主流，别选 x86。

第三，Resolution 部分把 Default Fullscreen Mode 改成 Windowed，默认分辨率 1280x720。这里设定好，能避免演示现场全屏黑屏、投影仪分辨率不兼容的问题。

第四，勾选 Run In Background。不勾的话，演示时老师切到桌面看别的程序，游戏立刻暂停，切回来后画面停在原地，体验很差。

Build 时选择 PC, Mac & Linux Standalone -> Windows，点 Build 后选择英文路径。注意工程路径和导出路径都不能有中文，Unity 在非 ASCII 路径下偶发打包失败，这是老玄学了，别赌。

导出目录里除了 exe，还会有一个<项目名>_Data文件夹，里面是全部资源、配置和 DLL。这个文件夹不能删，也不能和 exe 分开拷贝。交付时把整个目录压缩，或者要求对方整体拷贝。

5.2 导出的 exe 在别人电脑上跑不起来：5 条踩坑排查

给一个导出后的冒烟检查脚本，放在 Build 目录下执行，可以快速验证交付物是否完整：

# build_smoke_test.ps1 $buildRoot = "C:\Build" $exePath = Join-Path $buildRoot "TowerDefenseVR.exe" $dataDir = Join-Path $buildRoot "TowerDefenseVR_Data" if (-Not (Test-Path $exePath)) { Write-Host "缺少 exe：" $exePath exit 1 } if (-Not (Test-Path $dataDir)) { Write-Host "缺少 Data 目录：" $dataDir exit 1 } Write-Host "构建目录完整，可以打包交付"

逻辑说明：这个脚本只做两件事——检查 exe 是否存在、检查同名_Data目录是否存在。做交付包之前跑一遍，能防止「拷了个空文件夹就交作业」的尴尬。

下面按「现象 → 原因 → 解决」记五条高频问题。

现象一：双击 exe 黑屏，编辑器里明明正常。原因：目标电脑显卡不支持 Unity 默认选择的 DirectX 12，或显卡驱动太旧。解决：在 Player Settings > Other Settings 里，取消勾选 Auto Graphics API，列表里只保留 Direct3D11，重新 Build。教室电脑和旧笔记本上这个修改最有效。

现象二：游戏窗口切不出来，鼠标被困在里面。原因：全屏独占模式导致的。解决：默认改成 Windowed，分辨率设置 1280x720，并把 Resizable Window 勾上。演示时老师可以随便拖动窗口，观感更从容。

现象三：杀毒软件把 exe 删了，或者报毒。原因：Unity 导出的 exe 没有代码签名，偶尔被误报。解决：把整个构建目录压缩成 zip 再传；交付说明里写一句「杀毒软件误报请加白名单」，别裸发 exe 文件，几乎必被删。

现象四：Build 卡住几个小时。原因：选了 IL2CPP 后端，首次构建要生成 C++ 代理，时间长且占用磁盘。解决：换回 Mono 能明显加快构建；如果非要 IL2CPP，保持耐心别关窗口，中途关掉容易留下损坏的缓存，下次 Build 更慢。

现象五：构建报错，提示路径非法。原因：导出路径或工程路径里有中文、空格、特殊符号。解决：路径全部改英文，Build 目录建议直接放在磁盘根目录下，例如C:\Build。

5.3 游戏设计报告：按评分结构写，别写成流水账

游戏设计报告不需要文学性，需要让老师快速看到「你做了设计、写了代码、测过、反思过」。一个能拿分的结构是这样的：

报告里的核心是中间三章：玩法设计必须有数值表，直接把第 3 章塔的参数表和波次公式贴进去；系统设计必须有类图，把GameManager、WaveSpawner、EnemyMotor、TowerShooter、Bullet的关系画出来，用 draw.io 画完导出图片插入 Word。

测试记录尽可能写真实数字。哪怕只有一行「普通敌人 20 个同屏，帧率 58 FPS；波动 40 个同屏，帧率 50 FPS」，也比「经测试游戏流畅」有说服力得多。帧率在 Windowed 模式下能被窗口标题栏直接显示，或者用 Unity Profiler 记录。数值不用夸大，真实就行。

5.4 交付目录的建议组织方式

资源文件放在一块，老师检查也方便。常见做法是：

TowerDefense_Delivery/ Build/ TowerDefenseVR.exe TowerDefenseVR_Data/ Source/ Assets/ ProjectSettings/ Docs/ 游戏设计报告.docx README.txt

README.txt 里写两行：运行环境要求（Windows 10/11 64 位，DirectX 11），操作方式（鼠标放置塔，空格开始波次）。让老师拿到手就知道怎么跑，演示现场不容易出状况。

6. 用 Profiler 定位塔防性能瓶颈，再加一个数据驱动的小进阶

塔防作品交付前最值得花时间做的验证，是打开 Window > Analysis > Profiler，跑一局录一段 CPU 数据，看哪个脚本在Update里耗时最大。大概率命中的问题是「每帧搜索敌人」：塔数量一多，每座塔每帧遍历一遍所有敌人，性能就崩了。常见做法是降低搜索频率——敌人移动速度是 2.5m/s，塔的瞄准延迟 0.15 秒，肉眼完全感知不出来。

private float _nextSearchTime = 0f; private const float SearchInterval = 0.15f; private void Update() { // 索敌从每帧一次改成每 0.15 秒一次 if (Time.time >= _nextSearchTime) { _nextSearchTime = Time.time + SearchInterval; FindTarget(); } // 射击冷却仍按每帧判断 if (_target != null && Time.time >= _nextFireTime) { Fire(); _nextFireTime = Time.time + fireCooldown; } }

逻辑说明：搜索和射击分离之后，即便有 20 座塔同时在场景里，每秒也只触发约 130 次目标搜索，而不是 20 乘以帧率（比如 1200 次）。这个改动对后期波次的帧率提升非常明显，是性价比最高的一招。

再进一步的话，可以加一个TowerConfig数据驱动结构，把塔的数值从脚本字段挪到 ScriptableObject 上：

using UnityEngine; [CreateAssetMenu(fileName = "TowerConfig", menuName = "塔防/TowerConfig")] public class TowerConfig : ScriptableObject { public string displayName; public int cost; public int damage; public float range; public float fireCooldown; public float slowFactor; }

逻辑说明：在 Project 窗口右键创建三种 TowerConfig 资产，填好参数，把数组拖到 BuildManager 里。放置塔时直接取config传给TowerShooter。加第四种塔时不用改任何代码，只需要新建一个配置资产。这个设计放进报告的话，写在「可扩展性设计」一节，评分会往上走。

我自己的习惯是导出 exe 后，先在一台没有装 Unity 的电脑上双击完整跑一遍，再拿去教室演示。这个动作能筛掉绝大多数交付事故：缺 Data 目录、黑屏、杀软拦截、窗口切不出来。塔防大作业做到这一步，剩下的就是验收时自信地讲玩法、讲设计、讲你踩过的坑了。希望帮到你。

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