简介：这款基于UE4.22引擎开发的3D塔防游戏工程，是作者的个人学习项目，面向想从零接触虚幻引擎与C++游戏开发的学习者。玩法是在地图周围的岩石区域布置炮塔，抵御连续11波士兵进攻；每波敌人数量与生命值都会逐步提升，玩家需综合决定建塔顺序和点位，整体考验防守策略。工程文件以zip压缩包形式发布，大小约1.01GB，其中包含项目场景、音频素材和来自Epic Games的敌人角色网格体等资源。说明文档中附带了启动崩溃的处理经验：可先切换默认地图再重新选回，能规避一些不稳定的编辑环境问题。目前已有647人学习浏览，对想理解塔防波次控制、炮塔交互、AI敌人生成及虚幻引擎C++项目结构的人而言，这是一份完整可直接运行的实例工程，便于在此基础上进行二次修改与毕业设计参考。
1. 拿到一个 UE4 塔防工程：先看它的 C++ 骨架值不值得沾手
做游戏开发的都知道，塔防是最容易“看着简单、改着上火”的品类。最近拆了一份 UE4 塔防资源，标题写的是“士兵-塔-防御-UE4”，用 C++ 实现的 3D 塔防游戏，工程里包含完整的敌人 AI、防御塔攻击逻辑、波次刷怪、以及一套基于 Unreal Engine 4 的 RTS 式操作框架。我第一反应是这玩意儿八成是教学 Demo，打开工程扫了一圈才发现，它把塔防该有的模块都做成了可扩展的 C++ 类，不是把逻辑全焊死在蓝图里。对想学 UE4 C++ 塔防实现的开发者，或者打算拿塔防做毕业设计、游戏 Demo 的人来说，这份资源能省掉从零搭框架的时间。
它适合两类人：一类是刚啃完 UE4 C++ 基础、想在具体玩法里把 Pawn、AIController、碰撞、对象池这些概念串起来的新手；另一类是手里有玩法想法、但不想从建工程开始写塔防骨架的独立开发者。下文我按自己拆项目时的顺序，把类结构、生成机制、AI 与波次配置、高频踩坑依次过一遍。
2. 塔防核心机制的实现拆解：C++ 类结构、攻击逻辑与对象池
2.1 从这五个核心类看懂工程的架构思路
任何 UE4 塔防项目，都逃不开几个固定角色：防御塔、敌人、炮弹/投射物、玩家控制器、以及刷怪波次的管理器。这份资源里对应的 C++ 类分别是基于 ACharacter 的敌人基类、基于 AActor 的防御塔基类、投射物类、PlayerController 和波次管理器。我拆工程的习惯是先看 .h 文件里的 UCLASS 声明和 UFUNCTION 标记，因为这些直接决定哪些逻辑暴露给蓝图、哪些是纯 C++ 内部实现。
敌人基类的核心设计值得先说。它的移动不是简单用 CharacterMovement 的直走，而是在 BeginPlay 里从全局寻路系统拿到路径点数组，用 Spline 或者逐个 PathPoint 的方式推进。我实际看到的写法是每个敌人持有一个路径点索引，Tick 里朝目标点移动，距离小于阈值就切换下一个点。这套设计的优点是不依赖 NavMesh 也能跑，缺点是路径点一变，所有敌人的索引都要重新计算，所以工程里把路径管理单独抽了一个类，专门负责广播路径变化。
防御塔基类则是典型的“检测-索敌-攻击”三段式。每座塔在 Tick 里遍历攻击范围内的 Actor，用 GetOverlappingActors 或者手动 SphereOverlap，筛选出存活的敌人，然后旋转炮管、生成投射物。这种写在 C++ 里的方式比纯蓝图性能好不少，但也要求你理解 Actor 的 Tick 频率和碰撞通道。资源里提供了一个距离排序函数，索敌时会优先攻击离终点最近的敌人，这个逻辑很实用，能避免塔“谁近打谁”导致漏怪的问题。
2.2 投射物与伤害计算的 C++ 实现：别把伤害写死在碰撞事件里
很多新手做塔防投射物，喜欢在 OnActorHit 里直接写 ApplyDamage，但这会导致伤害类型、护甲减伤这些后续扩展很难加。这份资源里的投射物类做了一个简洁的分层：投射物只负责飞行、检测碰撞、然后把自己的伤害值和伤害类型传给目标的接收函数。敌人基类里有一个虚函数 CalculateDamage，子类可以重写它来加入护甲、抗性、暴击等逻辑。我一般会建议把伤害计算独立成函数而不是直接调 ApplyDamage，就是考虑到后期加各种 buff 时不需要翻投射物的代码。
投射物的飞行用的是 ProjectileMovement 组件，初始速度、最大速度都在构造函数里用 UPROPERTY 暴露到蓝图。资源里的默认值分别是 2000 和 2500，这两个值在 3D 塔防地图里手感比较合适。有一点要注意：ProjectileMovement 的初始速度方向默认是 Actor 的前向，所以生成投射物时务必先调整塔的朝向，否则炮弹会横着飞。常见做法是用塔的 GetActorForwardVector 给 ProjectileMovement 赋值。下面给出投射物类的构造和初始化逻辑示例：
AProjectileBase::AProjectileBase() { PrimaryActorTick.bCanEverTick = true; RootComp = CreateDefaultSubobject<USceneComponent>(TEXT("Root")); RootComponent = RootComp; MeshComp = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("Mesh")); MeshComp->SetupAttachment(RootComp); MeshComp->SetCollisionProfileName(TEXT("Projectile")); MoveComp = CreateDefaultSubobject<UProjectileMovementComponent>(TEXT("ProjectileMove")); MoveComp->InitialSpeed = 2000.f; MoveComp->MaxSpeed = 2500.f; MoveComp->ProjectileGravityScale = 0.f; MoveComp->bRotationFollowsVelocity = true; } void AProjectileBase::InitProjectile(FVector Direction, float DamageValue, TSubclassOf<UDamageType> DmgType) { MoveComp->Velocity = Direction * MoveComp->InitialSpeed; Damage = DamageValue; DamageType = DmgType; } void AProjectileBase::OnHit(UPrimitiveComponent* HitComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, FVector NormalImpulse, const FHitResult& Hit) { AEnemyBase* Enemy = Cast<AEnemyBase>(OtherActor); if (Enemy && !Enemy->IsDead()) { Enemy->TakeDamageWithType(Damage, DamageType); } Destroy(); }逻辑说明：构造函数里关掉重力，让炮弹走直线，这对塔防比抛物线更容易控制命中节奏；InitProjectile 在生成时被塔调用，设置方向和伤害；OnHit 里只判断是否为敌人，再把伤害转发给敌人的伤害接收函数。参数说明：DamageValue 每座塔在蓝图里配置，DamageType 是 UDamageType 子类，用来区分物理、火焰等，实战中建议至少做两种，否则后期做抗性没地方挂。
2.3 对象池：敌人刷多了不掉帧的底气
塔防的资源密集点不在塔而在敌人。后期一波动辄三四十个敌人同时在场，如果每波都 SpawnActor 再 Destroy，引擎的 GC 压力和碰撞重建会让帧率肉眼可见地掉。这份资源里的对象池设计不算花哨但很实用：波次管理器在游戏开始时预生成一批敌人，标记为 Inactive，刷怪时只激活、重置属性，敌人死亡或到达终点则 Deactivate 回池子。
池子的核心是链表和索引栈。我用 TArray 存储所有实例，再用一个 TArray 存当前空闲索引。Activate 时从空闲栈 Pop 一个，Deactivate 时 Push 回去。这样避免线性查找，敌人数量到一两百时依然能保持稳定。给一段池子的核心实现：
void AEnemyPool::InitializePool(int32 PoolSize, TSubclassOf<AEnemyBase> EnemyClass) { for (int32 i = 0; i < PoolSize; i++) { AEnemyBase* Enemy = GetWorld()->SpawnActor<AEnemyBase>(EnemyClass, FVector::ZeroVector, FRotator::ZeroRotator); Enemy->SetActorHiddenInGame(true); Enemy->SetActorEnableCollision(false); Enemy->SetActorTickEnabled(false); Enemy->PoolIndex = i; AllEnemies.Add(Enemy); FreeIndices.Push(i); } } AEnemyBase* AEnemyPool::GetEnemy(FVector SpawnLocation) { if (FreeIndices.Num() == 0) { ExpandPool(10); } int32 Index = FreeIndices.Pop(); AEnemyBase* Enemy = AllEnemies[Index]; Enemy->SetActorLocation(SpawnLocation); Enemy->SetActorHiddenInGame(false); Enemy->SetActorEnableCollision(true); Enemy->SetActorTickEnabled(true); Enemy->ResetEnemy(); return Enemy; }逻辑说明：SetActorHiddenInGame 和 SetActorEnableCollision 双开关是重点，只隐藏不关碰撞的话，投射物会被“看不见的敌人”挡住，这是新手最容易忽略的。ExpandPool 在池子不够时按 10 个一批扩容，避免极端波次下刷怪失败。参数说明：PoolSize 建议按单屏最大同时存活敌人数乘以 1.5 来配，太大会浪费内存，太小会中途扩容产生卡顿。
3. 敌人 AI 与波次配置的落地方式：从 AIController 到数据驱动刷怪
3.1 敌人不用行为树：路径点推进这套 AI 更适合塔防
塔防的敌人说到底是“沿路走到终点”，所以这里完全没有引入行为树和黑板，而是用一个轻量的 AIController 配合路径点数组。AIController 的职责只有两个：从路径管理器拿到路径点列表，然后控制 Pawn 依次移动。相比 UE4 的 BehaviorTree，这种方案的启动开销小，逻辑直观，而且不容易出现行为树节点执行顺序导致的“敌人原地发呆”问题。
实现上，AIController 在 Possess 后调用一次 MoveToNextPoint 函数，用 MoveToActor 或者直接给 Pawn 的 CharacterMovement 设置目标。资源里用的是手动计算方向加 AddMovementInput，理由是 MoveToActor 在路径点转弯处有转向延迟，敌人多的时候看起来会“排队拐弯”，影响节奏。手动方案加上一个转向插值能让敌人更贴路径。下面是敌人 AI 控制器的核心逻辑：
void AEnemyAIController::Tick(float DeltaTime) { Super::Tick(DeltaTime); if (!CurrentTargetPoint || bReachedEnd) { return; } AEnemyBase* Enemy = Cast<AEnemyBase>(GetPawn()); if (!Enemy) return; FVector EnemyLoc = Enemy->GetActorLocation(); FVector TargetLoc = CurrentTargetPoint->GetActorLocation(); float Distance = FVector::Dist(EnemyLoc, TargetLoc); if (Distance <= ReachThreshold) { int32 NextIndex = CurrentPathIndex + 1; if (NextIndex >= PathPoints.Num()) { bReachedEnd = true; Enemy->ReachEnd(); return; } SetNextPathPoint(NextIndex); } FVector MoveDir = TargetLoc - EnemyLoc; MoveDir.Z = 0.f; MoveDir.Normalize(); Enemy->AddMovementInput(MoveDir); }逻辑说明：整个移动靠高度归零的方向向量驱动，避免敌人飞行时往地下钻；ReachThreshold 设为 60 时转弯平滑，设为 10 时转弯生硬但贴路精准，实战里根据地图形状调整。参数说明：PathPoints 在 BeginPlay 时从路径管理器拷贝而来，每次 SetNextPathPoint 会重新赋值 CurrentTargetPoint。
3.2 波次配置的数据驱动：用 DataAsset 管理刷怪表
拆这份资源时最让我满意的部分是波次管理器的设计。它没有把波次数据 hardcode 在 C++ 里，而是用一个继承自 UPrimaryDataAsset 的配置类，里面定义了一个结构体数组。每个结构体包含敌人类型、数量、生成间隔、两次生成之间的延迟、以及这一波结束后的奖励金币数。这意味着调关卡难度只需要在内容浏览器里改数据资产，不需要碰一行 C++ 或蓝图逻辑。
波次管理器本身是个 Actor，持有当前的波次索引和剩余敌人计数。每波开始前先读取 DataAsset 里的敌人类型，并通过敌人工厂的 CreateEnemy 函数生成敌人。敌人死亡时通过回调通知管理器，计数归零后自动启动下一波。这种数据驱动的好处是平衡性调整可以由策划或你自己直接改数据，不用版本管理冲突。给出波次数据结构定义：
USTRUCT(BlueprintType) struct FWaveSpawnInfo { GENERATED_BODY() UPROPERTY(EditAnywhere, BlueprintReadOnly) TSubclassOf<AEnemyBase> EnemyClass; UPROPERTY(EditAnywhere, BlueprintReadOnly) int32 EnemyCount = 10; UPROPERTY(EditAnywhere, BlueprintReadOnly) float SpawnInterval = 1.5f; UPROPERTY(EditAnywhere, BlueprintReadOnly) float PreDelay = 2.0f; UPROPERTY(EditAnywhere, BlueprintReadOnly) int32 RewardGold = 50; }; UCLASS(BlueprintType) class UWaveConfig : public UPrimaryDataAsset { GENERATED_BODY() public: UPROPERTY(EditAnywhere, BlueprintReadOnly) TArray<FWaveSpawnInfo> Waves; UPROPERTY(EditAnywhere, BlueprintReadOnly) int32 MaxWave = 15; };逻辑说明：EnemyClass 是 TSubclassOf 而不是硬编码类名，资源里每种敌人单独建了一个蓝图层，敌人外观和数值可以在蓝图里覆盖。PreDelay 的作用是给玩家看到“下一波敌人来了”的预警时间，我一般建议至少给 2 秒。参数说明：RewardGold 走玩家手里的全局变量，塔的费用在防御塔蓝图里配置，经济循环是否紧张，完全看这两个数值的比值——这也是塔防里最花时间的调参环节。
3.3 一波多类型敌人混刷：从顺序循环到权重随机
资源里默认的刷怪逻辑是“先刷完这一类再刷下一类”，也就是顺序遍历 WaveSpawnInfo。这种逻辑简单、可预测，但玩到后面会显得呆板，因为敌人总是按固定顺序出场。我拆过不少塔防工程，发现多数开发者最后都会改成权重随机：某波次里配置多种敌人，每种给一个权重值，刷怪时按权重随机抽取。这个改动在编程上很小，但游戏体验提升非常明显。
AEnemyBase* AWaveManager::SpawnEnemyByWeight(const FWaveSpawnInfo& WaveInfo) { int32 TotalWeight = 0; for (const auto& SpawnEntry : WaveInfo.SpawnEntries) { TotalWeight += SpawnEntry.Weight; } int32 RandomValue = FMath::RandRange(1, TotalWeight); int32 AccumulatedWeight = 0; for (const auto& SpawnEntry : WaveInfo.SpawnEntries) { AccumulatedWeight += SpawnEntry.Weight; if (RandomValue <= AccumulatedWeight) { return CreateEnemy(SpawnEntry.EnemyClass); } } return nullptr; }逻辑说明：先把所有权重累加，再取一个 1 到总权重的随机数，逐个减权重定位到具体类型。注意 FMath::RandRange 的第二个参数是闭区间，这和其他语言的 rand 到 n-1 的惯例不同，容易写错。参数说明：SpawnEntries 是该波次里不同敌人的配置数组，Weight 越大出现概率越高，这个方案适合做“普通怪多、精英怪偶尔出”的混合波次。
4. UE4 塔防实装避坑：五个高频问题与排查思路
4.1 敌人批量死亡时引擎崩溃：原因在池子回收时碰撞没关
现象：某个波次敌人同时被多座塔集火，然后引擎直接崩溃，日志报碰撞相关错误。
原因：检查后发现问题不出在伤害计算，而在对象池回收逻辑。我的池子 Deactivate 函数里只调用了 SetActorHiddenInGame，忘了关碰撞。敌人虽然隐藏了，但碰撞体还挂在世界中，投射物仍然会命中它们，而命中回调尝试访问已经被重置的敌人数据，导致空指针。印象里大部分池子类崩溃都是这个原因。
解决：Deactivate 里把 SetActorEnableCollision(false) 和 SetActorTickEnabled(false) 都补上，与激活时的状态严格对应，两条缺一不可。另外还要在 OnHit 里加 IsDead 判断，双保险。
4.2 防御塔不攻击：Tick 里检测的碰撞通道不对
现象：塔周围明明有敌人，但塔就是不动，放置之后完全是个装饰。
原因：塔的攻击范围检测用了 Overlap 事件，但敌人的碰撞通道没有响应塔的查询通道。我在默认的 Pawn 碰撞通道上设置的是“Block”，而塔的索敌查询只检测了“Overlap”，两者对不上。
解决：把敌人的碰撞预设改成 Custom，ObjectType 设为 Pawn，Response 里把 WorldDynamic 设为 Overlap，同时塔的检测组件也要勾上对应的碰撞预设。排查步骤：先在游戏里运行时按打开控制台，输入show collision` 可视化碰撞体，确认敌人碰撞体是否存在、通道是否正确。
4.3 敌人寻路卡在拐角：Clearance 和目的地判定同时出问题
现象：敌人走到某些障碍物的拐角处会来回震荡，像在原地打转，偶尔能绕过去，大部分时候卡死。
原因：我用的手动方向推进没有处理“到达障碍物时的绕行”，同时 ReachThreshold 太小，敌人已经贴到障碍物边缘，但始终离目标点差那么一点，于是两个逻辑互相拉扯。
解决：两个方向一起修。一是把 ReachThreshold 从 20 调到 80，给转弯留出容错空间；二是在关卡里检查路径点是不是放在了障碍物内部，最常见的原因是路径点贴地面太近，被地面的碰撞盒挡了一部分，把路径点 Z 轴抬高 30 到 50 就能解决。
4.4 蓝图子类覆盖 C++ 函数不生效：缺了 BlueprintNativeEvent 或 BlueprintCallable
现象：我在 C++ 里写的敌人死亡函数，在蓝图里重写之后完全不执行，C++ 版的逻辑照样跑。
原因：C++ 函数没有标记 BlueprintNativeEvent。在 UE4 里，只有标记了 BlueprintNativeEvent 或 BlueprintImplementableEvent 的函数才能被蓝图覆写，普通 UFUNCTION 即使暴露出来，蓝图也只能调用不能重写。
解决：把死亡函数声明改成 BlueprintNativeEvent，在 C++ 里实现为函数名加 _Implementation 后缀。注意别在蓝图里直接盖掉 C++ 逻辑，正确姿势是蓝图侧调用 Parent 节点后再写自己的逻辑。
4.5 编译后蓝图变量丢失：UPROPERTY 没加 EditAnywhere 只加了 BlueprintReadOnly
现象：资源里的防御塔蓝图升级 C++ 后，所有配置好的变量值全部变回默认，得重新填一遍。
原因：UPROPERTY 只写了 BlueprintReadOnly，没有 EditAnywhere，蓝图里能读不能改，所以序列化时不会保存改动。这个在所有 UE4 工程里都会发生，动不动上百个属性要重新配置，挺折磨人。
解决：凡是需要在蓝图实例里配置的数值属性，必须写UPROPERTY(EditAnywhere, BlueprintReadOnly)。只读的计算属性才用 BlueprintReadOnly 配 VisibleAnywhere。我后来形成习惯：写完类第一件事就是检查所有 UPROPERTY 的编辑标记，避免升级后丢配置。
5. 用日志与数据驱动验证塔防数值：从“能刷怪”到“能通关”
5.1 用 UE4 的 Log 系统做击杀记录与伤害复盘
除非做完整的单测框架，否则塔防数值平衡的验证基本都是靠打日志。UE4 自带的 UE_LOG 配合 LogTemp 分类，可以把每次击杀的时间、敌人类型、造成伤害记录下来。我拆完这份资源后建议的做法是：在 WaveManager 的每个敌人死亡回调里输出一条带波次号、敌人类型、当前时间的日志，打几局之后把日志导出来跑一遍文本统计，看每一波的平均存活时间是否正常增长。
UE_LOG(LogTemp, Warning, TEXT("[Wave %d] Enemy killed at time %.2f, Type: %s, TotalKilled: %d"), CurrentWaveIndex, GetWorld()->GetTimeSeconds(), *Enemy->GetEnemyTypeName(), TotalKilledCount);逻辑说明：多打一条 Wave 信息能快速看出某一波是不是难度跳跃太大。参数说明：GetEnemyTypeName 是敌人基类里返回 FString 的虚函数，射击手、重甲兵等子类各自覆写即可。如果日志里某波的击杀时间比上一波翻了三倍，基本就是数值出了问题，不用等到玩家来骂。
5.2 数值动态调整的验证路径：改数据资产不比改代码更轻松
数据驱动的好处是改东西快，但调完我没法立刻知道是好是坏，必须反复跑同一波，然后盯着伤害数字和时间点判断。我一般的节奏是：单波测试关只放一座塔、一种敌人，且塔的升级链路开到最大，看这座塔的击杀时间曲线。如果后几级曲线突然平了，说明攻击力上升跟不上敌人血量增长，要么塔的成长系数太高要么敌人血量曲线太陡。
我用到的另一个验证技巧是“双倍时间录像法”：在同一地图同一波次配置下，分别记录一个高配置玩家的通关时间和一个最低配置玩家的通关时间，两者差距控制在两倍以内，说明难度梯度可以接受。这份资源里还额外给了世界总金币量和塔的总消耗额这两项数据，可以拿来做收支曲线图，曲线上升说明玩家有钱攒塔，下降说明数值偏紧。
5.3 进阶扩展：把技能系统挂到现有塔基类上
如果要把这份资源继续往上走，最顺手的扩展点是防御塔基类。它已经分离了“检测-索敌-攻击”三个阶段，所以加技能系统时不需要重写整座塔，只要在攻击阶段之前插入一次技能检测。比如给塔加一个减速光环，做法是新建一个技能组件，在 Tick 里对攻击范围内的敌人施加减速 buffer，再把这个组件挂到塔的蓝图上。
void UTowerSkillComponent::ApplySlowToEnemies(float Range, float SlowFactor) { TArray<AActor*> OverlappedActors; GetOwner()->GetOverlappingActors(OverlappedActors, AEnemyBase::StaticClass()); for (AActor* Actor : OverlappedActors) { AEnemyBase* Enemy = Cast<AEnemyBase>(Actor); if (Enemy) { Enemy->ApplySpeedModifier(SlowFactor, 2.0f); } } }逻辑说明：技能组件完全复用塔已有的 Overlap 范围检测，不需要额外写范围判断，敌人身上的 ApplySpeedModifier 负责管理减速的持续时间与叠加规则。参数说明：SlowFactor 取 0.5 表示移速减半，2.0 是持续时间秒数。这个组件独立于塔的攻击逻辑，放在任何一类的防御塔蓝图里都能工作，扩展成本很低。
我后来在另一个项目里复用这套骨架，最大的收获是明白了塔防工程真正难的不是“在路口放一座塔然后开火”，而是“敌人池稳定、波次可配置、数值可调整”这三件事同时做好。从那以后我每次接手 UE4 游戏资源，都会先花一个晚上摸清类结构和数据资产的关系，再动手改任何逻辑。这份资源给了你一个可靠的起点，剩下的就是往上面叠你自己的玩法。希望帮到你。
本文还有配套的精品资源，点击获取
