UE5割草游戏玩家受伤模块实战：从HealthComponent到无敌帧的手感打磨

做到系列第5篇，我的UE无双割草项目终于碰到了一个不能再糊弄过去的模块——让玩家能够受伤。前几篇我陆续搞定了角色基础移动、镜头控制、攻击连段和敌人追踪AI，敌人已经会成群结队朝玩家扑过来，但说实话，那个阶段它们扑上来之后什么都不会发生，玩家血条永远是满的，站在尸潮里搓招没有任何风险反馈。这当然不叫割草，割草的核心快感恰恰来自“我同时面对一大群敌人，但危险是真实存在的”，所以受伤反馈必须先落地，否则游戏就不成立。

这一篇我会把玩家受伤模块的完整实现过程拆开讲清楚：从血量属性怎么封装、伤害事件怎么广播，到受击动画、命中停顿、震屏、伤害数字、无敌帧，再到死亡、重试和一系列排错过程。每个环节我都会解释设计原因和我实际踩过的坑。如果你也在用UE做动作游戏或者割草类玩法，可以重点参考这几个部分：DamageInfo结构体的设计、HealthComponent的生命周期管理、攻击命中集合的去重方案、无敌帧的边界处理。我不写空话，全部是实际跑过、调试过的东西。

1. 从“我打人”到“人打我”：这一篇到底要解决什么问题

1.1 为什么割草游戏里同样需要一套高质量的受伤系统

传统ARPG里的受击往往是一种惩罚机制，BOSS战强调的是翻滚、格挡、硬直博弈，玩家要尽量避免被打中。但无双割草不是这个逻辑，割草游戏的爽感来源是“一骑当千”，玩家大部分时间都在主动进攻，如果受伤惩罚太重，玩家就会玩得畏手畏脚，割草感直接归零。

所以割草游戏里的受伤系统，设计目标不是“制造高难度”，而是“提供风险信号”和“调节玩家注意力”。敌人乌泱泱扑过来，玩家需要快速判断哪些伤害可以硬吃、哪些必须躲，这就需要伤害分级。我在项目里参考了传统无双的做法，把敌人伤害分成三档：小兵普攻低伤害加短暂硬直，精英敌人重击高伤害附带击飞，BOSS技能高伤害甚至是秒杀级别的威胁。这样玩家在割草时脑子是不停运转的，虽然大多数小兵打不死你，但混在人群里的那个精英怪蓄力红光，你必须优先处理。

回过头来想，如果敌人攻击玩家没有任何表现，玩家会觉得自己是个无敌橡皮擦，割草快感反而会迅速衰减。危险感和爽快感是硬币的两面，受伤系统做得越扎实，玩家对“无敌”的感受才越强烈。

1.2 需求拆解：一次受击背后需要同时动哪些模块

玩家被打中的一瞬间，系统要做的事情远不止“HP减一”。以我的项目为例，从敌人攻击命中到玩家血条变化，大约要在0.2秒内完成这些事：确定伤害来源、计算扣血数值、切换受击动画、触发命中停顿、播放音效、生成粒子、震动镜头和手柄、弹出伤害数字、更新血条UI，如果血量归零还要进入死亡流程。

这些功能如果全部在角色蓝图里用节点连，后期会非常痛苦。所以我把它拆成四个域来并行推进：

先把这个架构理清楚，后面每个模块单独开发、单独测试就轻松很多。我在这个项目里也犯过上来就写蓝图的毛病，结果改需求时牵一发动全身，后来才老老实实重新设计。

2. 搭建玩家的生命底盘：属性组件与伤害接口设计

2.1 血量属性放在哪：从纯蓝图到C++组件的进化

最开始的版本我用纯蓝图，在玩家角色蓝图上直接拉了几个变量：MaxHP、CurrentHP、IsDead。简单是简单，但问题很快就来了：陷阱要扣血、敌人要扣血、毒区要扣血，所有调用点都直接操作玩家蓝图的变量，哪天想加个护盾或者回血Buff，你会发现所有节点都要改一遍。

后来我把这块重构为一个C++的ActorComponent，名字叫UHealthComponent。它不关心伤害从哪来，只负责接收伤害请求、校验无敌帧、广播事件。组件挂在玩家Character上，以后敌人或者NPC想复用，直接挂上就能用，不用重新写一份。

这里的关键设计是，血量属性不要做成public裸变量让外部随便改。我暴露一个ApplyDamage函数，所有伤害都必须走这个入口，内部统一处理扣血、死亡判定和事件广播。

cpp复制// HealthComponent.h 核心片段
UCLASS(ClassGroup=(Custom), meta=(BlueprintSpawnableComponent))
class UHealthComponent : public UActorComponent
{
    GENERATED_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Health")
    float MaxHP;

    UPROPERTY(BlueprintReadOnly, Category = "Health")
    float CurrentHP;

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Health")
    float InvincibleDuration = 0.4f;

    UFUNCTION(BlueprintCallable, Category = "Damage")
    bool ApplyDamage(const FDamageInfo& DamageInfo);

    UPROPERTY(BlueprintAssignable, Category = "Damage")
    FOnDamaged OnDamaged;

    UPROPERTY(BlueprintAssignable, Category = "Damage")
    FOnDeath OnDeath;
};

cpp复制bool UHealthComponent::ApplyDamage(const FDamageInfo& DamageInfo)
{
    if (bDead)
        return false;

    // 无敌帧校验
    float CurrentTime = GetWorld()->GetTimeSeconds();
    if (CurrentTime < InvincibleUntil)
        return false;

    CurrentHP = FMath::Max(0.f, CurrentHP - DamageInfo.BaseDamage);
    OnDamaged.Broadcast(DamageInfo, CurrentHP);

    if (CurrentHP <= 0.f)
    {
        bDead = true;
        OnDeath.Broadcast();
    }

    return true;
}

注意我这里用动态多播委托OnDamaged和OnDeath，而不是在组件内部直接依赖玩家蓝图，这样表现层和逻辑层就解耦了。UI、动画、音效全部监听OnDamaged事件，谁想响应谁注册，不需要组件自己去调用任何表现节点。

2.2 DamageInfo结构体：一个比“传个数字”更靠谱的方案

新手很容易写出这样的函数：ApplyDamage(float DamageAmount, AActor* DamageCauser)。一开始没问题，但后面你会面临一连串需求：这个伤害是火属性，那个伤害要击退，处决伤害要无视无敌帧，小兵轻击要显示小飘字、BOSS重击要震屏……如果参数是一个个浮点和Actor指针，你只能不停往函数定义里加参数，最后变成一长串让人头皮发麻的签名。

我的做法是先定义DamageInfo结构体，把所有伤害相关信息统一打包。

cpp复制USTRUCT(BlueprintType)
struct FDamageInfo
{
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    float BaseDamage = 0.f;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    EDamageType DamageType = EDamageType::Normal;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FVector HitDirection = FVector::ZeroVector;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    AActor* Instigator = nullptr;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    bool bCanInterrupt = false; // 能否打断无敌帧
};

Enum用蓝图可编辑的EDamageType：Normal、Heavy、Element、Execution之类。后续加属性系统、弱点系统、元素反应，都是往结构体里加字段，而不是改函数签名。敌人、陷阱、环境伤害，统统构造一个FDamageInfo然后调用ApplyDamage，调用方根本不需要知道玩家的血量细节。

提示：结构体字段一开始保留bCanInterrupt这个“无视无敌帧”的标记，是我后来补上的最值钱的一个设计。后面做精英怪和BOSS时，你会发现有些攻击必须能打断玩家，否则玩家只要按住了闪避或者硬顶无敌帧，BOSS战会变得毫无压迫感。

2.3 一条完整的伤害事件流怎么走

把上面的模块拼起来，一条完整的玩家受伤事件流是这样的。

攻击方（敌人AI、陷阱、毒区）拿到目标的IDamageable接口，构造好FDamageInfo，调用ApplyDamage。HealthComponent内部先校验是否死亡、是否处于无敌帧，通过后扣血并广播OnDamaged。表现层收到OnDamaged后，按照DamageType分发表现：普通伤害播轻受击动画，重击播击飞动画，处决伤害强制打断当前动作。UI层收到OnDamaged后更新血条和伤害数字。

我额外做了伤害数字合并。割草游戏里飘字本来就很密集，如果玩家同时被七八个小兵刮到，满屏“-1”根本看不清。我做了一个简单方案：0.5秒内的同类型伤害合并成一个数字，显示合计值，这样既不丢失反馈信息，也保证画面干净。

这套事件流程还有一个好处：后续加“受伤回血”“按百分比扣血”“护盾优先吸收伤害”，都只需要改HealthComponent内部或者往事件总线里加监听，不需要改敌人的任何逻辑。如果项目再大一点，分给两个人并行开发完全没压力——一个改表现，一个改数值逻辑，不会冲突。

3. 被打中那一瞬间：受击反馈的组合拳

3.1 受击动画蒙太奇与状态机优先级

扣血只是底层逻辑，玩家能感受到的“受伤”其实全靠反馈层。最重要的反馈就是受击动画。如果玩家被打了还保持跑步姿势，不管数字飘多漂亮，打击感都是零。

我的玩家动画蓝图为受击专门开了一个Slot，叫DamagedSlot，并把它挂在状态机里比较高的优先级上。动作游戏里动画状态优先级一定要想清楚，我的顺序大概是：Locomotion < Attack < Damaged < Dead。如果攻击和受击同时发生，受击优先打断攻击，这符合传统无双的体感；死亡优先级最高，死了之后任何受击都不能把玩家从死亡动画里拉出来。

受击蒙太奇在设计时有几个细节。第一，受击动画不要每次都用同一个，我做了轻、中、重三套，根据DamageType切换，重击用击飞，轻击用顿挫，这样玩家能从动画上直接判断这次受伤严不严重。第二，受击蒙太奇的时间不要贪长，小兵伤害的硬直控制在0.2秒左右，否则被围殴时玩家会一直处于“挨打硬直循环”，体验极其糟糕。

这里还要提一下伤害结算的时机。我最初是在受击动画播完之后才扣血，结果手感非常奇怪，玩家总觉得“我明明被打中了，血却过一会儿才掉”，延迟感很明显。后来我改成动画开始的同一帧就结算伤害和血条，反馈和动画同步，手感立刻对了。在动作游戏里，0.1秒的反馈延迟都是能感知到的，宁可动画后摇略长，也不能让伤害结算滞后。

3.2 命中停顿、震屏与手柄震动：手感的三驾马车

命中停顿（HitStop）是动作游戏打击感的最重要来源之一。做法是受到伤害的瞬间，让整个游戏世界暂停几十毫秒，然后恢复，视觉上就是“顿了一下”。我在HealthComponent里加了一个受击顿帧逻辑：当一次有效伤害被应用时，立刻设置全局时间膨胀到0.05，然后启动一个延时事件，在60到80毫秒后恢复为1.0。

提示：全局时间膨胀会影响所有Actor的Tick和游戏计时器，如果角色身上还有自定义的CustomTimeDilation，两者会叠加产生预期外效果。我一开始发现HitStop后玩家闪现漂移，查了半天才定位到是因为角色身上挂着一个战斗技能的时间膨胀，叠加后角色运动速度异常。建议HitStop只在短时间影响全局，不要作用到具体的移动组件上。

震屏我用的是PlayerCameraManager的PlayWorldCameraShake，注册一个很小幅度的BaseShake。注意震屏不是越大越好，割草游戏里玩家长期处于大量受击事件中，每次受击都大晃镜头，不出十分钟人就晕了。我的策略是：小兵伤害震屏幅度压到0.3，重击才用0.8的力度，BOSS蓄力攻击命中给一次1.2的强震，用来强调高风险时刻。

手柄震动我用的是PlayerController的PlayDynamicForceFeedback。这个接口支持动态力度曲线，按时间衰减。实测下来，连续受击时如果每次都满强度震动手柄，玩家很容易产生疲劳感，所以我做了一个同类型伤害合并后再震动一次的方案。这个细节不算难，但对“高级感”的提升非常显著。

3.3 血条UI、伤害数字与低血量屏幕特效

玩家受伤最直接的视觉反馈是血条。我用UMG的ProgressBar绑定OnDamaged事件，把CurrentHP / MaxHP赋给进度条。单一红条反馈太朴素，我额外做了一个延迟白条效果：受伤时红条先掉，白条（代表“可回复的最近伤害”）在之后0.5秒内缓慢跟上。这个效果在肉鸽游戏里很常见，割草游戏里用同样能让玩家直观看到“刚才那一击掉了多少血”。

受伤飘字我只对玩家自己受到的伤害做，并且数字要放大加粗。小兵轻击伤害低，飘字颜色用白色；精英重击伤害高，飘字用橙色加粗；BOSS技能伤害最高，飘字用红色并且带一个放大动画。这样的视觉分级能让玩家在大混战中一眼扫出刚才最致命的伤害来自哪里。

低血量提示我做了两层。第一层是屏幕边缘红色渐变材质，通过动态材质实例的透明度参数控制，HP低于30%时开始浮现。第二层是整个画面轻微去饱和度，模拟角色状态不佳的观感。注意这个材质不要用太重的后处理，敌人数量一大，后处理对帧数的影响会非常明显，我只在玩家面板上叠加了一个淡入淡出的通用材质，实测性能开销可以接受。

3.4 无敌帧：既要给保护，也要防滥用

无敌帧是这个模块里绝对不能少的机制。没有无敌帧的话，玩家被三四个小怪围住，受击动画还没播完第二次伤害又来了，硬直循环下只能眼睁睁看着角色被连到死，这绝对不是割草游戏该有的体验。

实现方式非常简单，在HealthComponent里加一个成员变量InvincibleUntil，ApplyDamage时先判断当前时间是否小于这个时间点，是就直接返回false。受击成功时，把InvincibleUntil设置为当前时间 + InvincibleDuration。我测试下来0.35秒的无敌帧体感最合适，太短保不住玩家，太长又会让人觉得在无脑站撸。

但无敌帧有个表现上的问题：玩家无敌期间被攻击，攻击者会看到打中了但没有任何反应，观感很怪。我的解决方法是，无敌帧内虽然不扣血，但依然播放一个极轻的“被蹭到”动作和音效，只是不应用伤害数值。也就是说，外部世界看到的是一致的：攻击命中了、角色有一个轻微反应，只是血条没掉。这样玩家能明显感觉到“我无敌了”，而敌人攻击也保留了基本反馈，不会穿模虚空挥刀。

重击和处决类伤害通过DamageInfo里的bCanInterrupt标记无视无敌帧，用来保证高威胁敌人依然能形成压制力。这个开关不要开太多，只给精英怪的重击和BOSS技能，否则无敌帧形同虚设。

4. 敌人的攻击怎么打到玩家：伤害来源的落地实现

4.1 用物理碰撞还是Overlap查询来判定攻击

玩家能受伤了，敌人总得有办法打中玩家。近战敌人的攻击命中判定，我尝试过两种方案：骨骼挂碰撞体和Overlap查询。

骨骼挂碰撞体的做法是给敌人角色的武器或手臂挂一个Sphere/Capsule碰撞体，攻击蒙太奇播放到某一帧时开启碰撞，结束帧关闭。优点是直观，武器碰到玩家自然触发伤害；缺点是碰撞开关很难维护，武器甩动时很可能一帧内触发多次Overlap，而且物理模拟下偶尔会出现“明明肉眼看到砍中了，碰撞体却没碰到”的漏判。

我最终选的是Overlap查询方案：不在敌人身上挂持续碰撞体，而是在攻击动画的指定帧做一次主动范围检测。我在敌人攻击蒙太奇里放了两个AnimNotify，AttackStart和AttackEnd，AttackStart触发时做一个SphereOverlapActors查询，检查当前攻击范围内有哪些Actor，过滤出带IDamageable接口的玩家角色，然后直接调用ApplyDamage。

对割草游戏来说，敌人数量多、攻击频率高，可控性比物理真实性重要得多。Overlap查询方案让我可以把攻击范围、伤害判定帧做得很明确，后续调手感也方便。

4.2 一次性命中去重：防止一刀扣十次血

用Overlap查询方案最大的坑就是重复触发。我早期版本就遇到过：玩家站在敌人身边，攻击判定像开了闸一样每秒触发十几次，血条直接蒸发。原因很简单：AttackStart触发的Overlap查询如果放在Tick或持续事件里，或者没有清理“本次攻击已经命中过的Actor集合”，那每次查询都会返回同一个玩家。

我做了一个三保险。攻击开始时，创建本次攻击的TArray<AActor*> HitActors，AttackStart的Overlap查询只处理“不在HitActors里”的目标，处理完立刻Add进集合。攻击蒙太奇结束或到达AttackEnd时，清空集合。同时，ApplyDamage里的无敌帧逻辑作为最后一道防线，即使因某种原因重复调用了，也不会重复扣血。

cpp复制// 敌人攻击判定的逻辑片段
void AEnemyCharacter::PerformAttackOverlap()
{
    TArray<AActor*> OverlappedActors;
    UKismetSystemLibrary::SphereOverlapActors(
        this,
        GetActorLocation() + GetActorForwardVector() * AttackRange,
        AttackRadius,
        EnemyAttackFilter,
        APlayerCharacter::StaticClass(),
        TArray<AActor*>(),
        OverlappedActors
    );

    for (AActor* Target : OverlappedActors)
    {
        if (!HitActors.Contains(Target))
        {
            HitActors.Add(Target);
            FDamageInfo DamageInfo = MakeDamageInfo();
            IDamageable* Damageable = Cast<IDamageable>(Target);
            if (Damageable)
            {
                Damageable->ApplyDamage(DamageInfo);
            }
        }
    }
}

我要强调一点：Filter一定得配好。我的敌人攻击通道用了自定义Trace Channel EnemyAttack，只检测玩家角色的碰撞，避免Overlap结果里混进一堆小怪、碎石、掉落物，造成无意义的性能消耗和无厘头的伤害目标。

4.3 伤害数值的前期硬编码与后期数据化预留

原型阶段的伤害数值我直接硬编码在敌人蓝图里：小兵5点，精英20点，BOSS技能60点。这个阶段没必要上数据驱动，快速跑通流程最重要。但我还是做了一点预留——DamageType枚举和结构体里的Tag数组，方便后面开发数值系统时挂接。

下一阶段我计划把敌人的攻击力、攻击范围、前摇时间、攻击频率全部搬进DataTable，策划在表格里配置，不用改代码和蓝图。这是我推荐的演进路径：先做好基础逻辑和接口，再把数据抽离出去。反过来一上来就做数据驱动，多半会在调试手感时浪费时间。

提示：如果你的项目最终会走向复杂Buff和技能效果，可以考虑GAS（Gameplay Ability System）。但我不建议原型阶段一上来就用GAS，学习成本和配置成本都很高，等团队对游戏战斗手感有共识后，再从HealthComponent迁移过去也不迟。

5. 血量归零之后：玩家死亡与关卡重试

5.1 死亡流程状态机：控制权、碰撞、AI目标一步都不能漏

玩家血量归零后，如果只是把角色往地上一倒，那死亡体验就很粗糙。死亡流程有几个容易被忽略的环节，我一个一个说。

流程的第一步是禁用输入。Dead状态后如果玩家还能按攻击键，动作播放就会和死亡动画打架。我在PlayerController上调用DisableInput，同时把玩家的CharacterMovement的MovementMode改成MOVE_None，停止所有移动逻辑。禁用输入不等于禁用相机，镜头还要继续跟随角色尸体，所以InputComponent可以禁用，但CameraBoom和SpringArm的移动要保留。

第二步是碰撞处理。我设置了角色胶囊体CollisionEnabled为NoCollision，防止尸体重叠在地面上被物理引擎推得乱飘。当然如果要做Ragdoll，那就是另一种处理思路，需要在骨骼网格上开启物理模拟。割草项目的死亡演出我选择了播放一段死亡蒙太奇，倒地后隐藏角色，然后过渡到结算UI。

第三步是清仇恨。死亡后敌人的AI感知系统还会牢牢锁定尸体，一大群敌人围着倒地的角色继续做攻击动作，看起来非常滑稽。我在玩家死亡时广播一个事件，所有AI的AIPerception组件调用ForgetActor，强制遗忘目标，让他们停止攻击并回到漫游状态。

5.2 复活方案的取舍：重载关卡还是原地重生

玩家死亡后的处理方式，我权衡过三种方案。

方案A是直接重新加载当前关卡。实现最简单，UGameplayStatics::OpenLevel一下就好，但代价是所有世界状态全部重置，敌人重置、场景破坏物重置、玩家进度清零。原型阶段可以用，但正经游戏体验太生硬。

方案B是原地重生：保留当前关卡里所有敌人和场景状态，只把玩家的位置拉回出生点，恢复满血，清空仇恨。这个方案对玩家来说比较友好，死了不用重打进度，但也少了一点“惩罚”的紧张感。

方案C是濒死机制：血量归零不立刻死亡，而是进入“倒地”状态，等队友救援或者一定时间后自动复活。这个比较适配双人合作，单人割草里用得少。

我当前项目选的是方案B，但加了一个1.5秒的死亡过渡延迟。流程是：OnDeath广播→禁用输入→播放死亡动画→镜头缓缓拉近→显示“你被击败了”结算UI→1.5秒后自动重载位置并恢复满血。这样玩家既能看清死亡原因，又不会因为强制按跳过键打断死亡演出的情绪节奏。

6. 这个模块我踩过的坑，以及你大概率也会踩的坑

6.1 伤害重复触发：Overlap事件里最容易翻车的地方

我最早用碰撞体的方案，把伤害碰撞挂在敌人武器上，然后在OnComponentBeginOverlap事件里直接扣血。测试时人麻了：玩家靠近敌人，血条像被抽水泵抽一样狂掉。打印日志发现，只要玩家站在碰撞体范围内，Overlap的Begin事件会在接触的每一帧都触发，根本没有“只触发一次”的保证。

解决思路后来变成了我在第4节写的三保险：攻击命中集合 + AnimNotify控制触发窗口 + 无敌帧兜底。这套组合拳下来，伤害重复触发的问题才算彻底根治。我做了一个额外的Debug方案：在玩家Character的OnDamaged事件里打印调用栈，谁调用的、什么时间、第几次，全部记录到输出日志。这样每次出现异常扣血，都能快速定位到是哪个敌人在搞鬼。

6.2 无敌帧的时间边界：外部观感和内部逻辑的平衡

无敌帧实现简单，但边界问题很容易被忽视。我最初的设计是：无敌帧内任何攻击都不扣血，也不做任何表现。结果第一个测试版本就发现，玩家在无敌帧内被精英怪蓄力重击打到时，攻击者那边有明显的“挥刀命中空气”感觉，因为玩家角色一点反应都没有。

后来我调整成无敌帧内也播放轻受击动画和音效，只是不结算伤害。这样从外部看，每次攻击打中了玩家，玩家都有一个轻微反应，但血条不动。实测手感提升非常明显，玩家能清楚感知“我此刻是无敌的”，而不是“敌人好像砍不中我”。

另一个边界是持续时间。我最初设了0.5秒，结果发现玩家只要不主动取消无敌，几乎可以无视小兵海；后来压到0.35秒，配合bCanInterrupt标记让重击无视无敌帧，难度曲线终于正常了。调参数这件事没有捷径，只能一遍遍测，我的建议是把这些参数全部暴露到蓝图里，方便在编辑器里实时改，不用每次改代码后重新编译。

6.3 动画Notify在低帧率下漏判问题

敌人攻击判定依赖AnimNotify，但我在测试中发现在低配电脑上偶尔会出现“攻击动画播完了玩家却没掉血”的问题。查了一圈才明白，动画Notify是采样式的，如果帧率太低，两个Notify之间的帧被跳过，通知可能压根不会触发到。

解决方法是把单个AnimNotify改成AnimNotifyState，也就是一个时间窗口：从NotifyState开始到结束的这段时间内，每帧都检查条件，而不是只在一个时间点触发一次。这样即使某一帧被跳过了，只要窗口还没结束，命中判定依然有机会执行。这个坑很隐蔽，没遇到性能瓶颈的机器上基本测不出来，但一旦发布到中低端设备上，就会变成莫名其妙的“敌人打不到我”Bug。

调试动画通知还有一个小技巧：临时在Notify检查和命中判定里加Visual Logger输出，把每次攻击的判定帧、范围、目标数量打出来。不要相信肉眼观察，数据才是定位问题的关键。

6.4 身体记忆调出来的手感参数

最后分享一组我在项目里最终确定的手感参数，都是反复AB测试出来的，可能不适合所有项目，但可以当作起点参考。

我特别想强调前摇信号的重要性。敌人攻击前保留0.4秒左右的蓄力动作，并用红光或音效提示，这比单纯提高伤害值更能塑造“危险感”。割草游戏里玩家面对成百上千的敌人，不可能每个攻击都看清，但精英和BOSS的蓄力前摇必须醒目，否则玩家会觉得被打死是因为游戏不公平。

做完玩家受伤模块后我再回头测最初的攻击系统，发现打击感有了质的提升。原因很简单，伤害是对称的：你能打敌人一个硬直，敌人也能打你一个硬直，双方在同一套反馈规则里，玩家才会真正相信这个战斗世界是真实的。这个模块给我的最大经验是，不要急着堆华丽特效，先把“掉血-反馈-死亡-重生”这条底层链路跑通，手感是后面一点点磨出来的。