Cocos2d-x v3.16开发地牢射击游戏：随机地图与武器系统全解析

这几年经常有人问我：“想做一款元气骑士这种地牢射击游戏，该从哪里下手？”我最初用Cocos2d-x v3.16做原型的时候，也踩过不少坑。这个版本在2D游戏开发里相当能打，C++的性能优势、跨平台支持、成熟的事件分发和动作系统，用来搞弹幕射击、肉鸽地牢这种玩法，几乎是为它量身定制的。但搜了一圈网上的教程，基本都是“教你创建场景、加载精灵图”这种入门级demo，真到了随机房间生成、武器切换、敌人AI弹幕这种核心玩法层面，资料就变得很零散。

这篇文章会把我在Cocos2d-x v3.16下复刻元气骑士风格玩法的完整思路拆开讲，从地牢房间的随机生成到武器系统的抽象设计，再到角色状态机、弹幕碰撞和真机性能优化。每个模块都会给到可落地的方案和关键代码思路。无论你是想完整复刻一个demo，还是只想在项目里实现某个单点功能，都能直接参考。

1. 从零搭建地牢房间随机生成器：分割、生成与连通

地牢射击游戏最核心的体验之一，是每一局的地图都不一样。元气骑士的房间布局看起来随机，实际上背后是一套“空间划分—生成房间—走廊连通”的算法。用Cocos2d-x来实现这套逻辑时，我建议把地图生成和渲染彻底解耦：先生成一份二维逻辑地图数据，再根据数据类型去摆TileMap或绘制碰撞矩形，这样后续调试和扩展都会轻松很多。

1.1 用BSP分割法生成房间布局

我采用的是BSP（二叉空间分割）递归算法。每次把当前矩形区域随机切成上下或左右两块，切到一定深度或面积小于阈值就停止，然后在每个叶子节点内部生成一个小矩形作为房间。

cpp复制struct RoomData {
    cocos2d::Rect rect;
    std::vector<cocos2d::Vec2> doorPoints;
};

class DungeonGenerator {
public:
    void generate(cocos2d::Size dungeonSize, int depth, int minRoomSize) {
        _rooms.clear();
        _corridors.clear();
        auto root = cocos2d::Rect(0, 0, dungeonSize.width, dungeonSize.height);
        splitRect(root, depth, minRoomSize);
        connectRooms();
    }
    
private:
    void splitRect(const cocos2d::Rect& rect, int depth, int minRoomSize) {
        if (depth <= 0 || rect.size.width < minRoomSize * 2 || rect.size.height < minRoomSize * 2) {
            // 叶子节点：生成一个内部房间，四周留墙
            float roomW = rect.size.width * (0.6f + rand() % 30 / 100.0f);
            float roomH = rect.size.height * (0.6f + rand() % 30 / 100.0f);
            float x = rect.origin.x + (rect.size.width - roomW) / 2;
            float y = rect.origin.y + (rect.size.height - roomH) / 2;
            _rooms.push_back({cocos2d::Rect(x, y, roomW, roomH), {}});
            return;
        }
        bool horizontal = rand() % 2 == 0;
        if (rect.size.width / rect.size.height > 1.5f) horizontal = false;
        else if (rect.size.height / rect.size.width > 1.5f) horizontal = true;
        
        if (horizontal) {
            float splitY = rect.origin.y + rect.size.height * (0.4f + rand() % 20 / 100.0f);
            splitRect(cocos2d::Rect(rect.origin.x, rect.origin.y, rect.size.width, splitY - rect.origin.y), depth - 1, minRoomSize);
            splitRect(cocos2d::Rect(rect.origin.x, splitY, rect.size.width, rect.origin.y + rect.size.height - splitY), depth - 1, minRoomSize);
        } else {
            float splitX = rect.origin.x + rect.size.width * (0.4f + rand() % 20 / 100.0f);
            splitRect(cocos2d::Rect(rect.origin.x, rect.origin.y, splitX - rect.origin.x, rect.size.height), depth - 1, minRoomSize);
            splitRect(cocos2d::Rect(splitX, rect.origin.y, rect.origin.x + rect.size.width - splitX, rect.size.height), depth - 1, minRoomSize);
        }
    }
    
    void connectRooms() {
        // 按X坐标排序，然后相邻房间之间开走廊
        std::sort(_rooms.begin(), _rooms.end(), [](const RoomData& a, const RoomData& b) {
            return a.rect.getMidX() < b.rect.getMidX();
        });
        for (size_t i = 1; i < _rooms.size(); i++) {
            connect(_rooms[i - 1], _rooms[i]);
        }
    }
};

这里有几个细节值得注意：首先是分割方向，不能每次都纯随机横切或竖切，要加一个矩形长宽比的判断，否则容易生成细长条房间。我上面代码里就做了这个处理。其次是叶子房间的大小，要跟房间实际显示面积之间留出至少一格墙的余量，防止房间直接怼到地图外边界。

我最初写第一版时没有做长宽比判断，生成出来的地图经常有窄到只能站一个人的走廊，弹幕射击里这种走廊几乎没法走位。后来加了比值修正，整体体验立刻就好了很多。

1.2 走廊连通与入口出口标记

房间连接我采用的是“中点直线走廊”方式。取两个房间的中心点，先水平走到目标房间中心的X坐标，再垂直走到目标房间中心的Y坐标，沿途把格子标记为走廊。虽然这种方式会产生L型或Z型走廊，但实现简单、视觉也算自然，还能在走廊尽头自动形成门洞。

cpp复制void connect(const RoomData& a, const RoomData& b) {
    cocos2d::Vec2 start(a.rect.getMidX(), a.rect.getMidY());
    cocos2d::Vec2 end(b.rect.getMidX(), b.rect.getMidY());
    // 先从起始点走到中间点，再走到终点
    cocos2d::Vec2 mid(start.x, end.y);
    for (float x = std::min(start.x, mid.x); x <= std::max(start.x, mid.x); x += TILE_SIZE) {
        _corridors.push_back({x, mid.y});
    }
    for (float y = std::min(mid.y, end.y); y <= std::max(mid.y, end.y); y += TILE_SIZE) {
        _corridors.push_back({end.x, y});
    }
}

在我的实现里，每个房间的门口列表是在连通阶段动态算出来的。走廊和房间的相交边界就是门洞位置，这里要在该位置放置一个可碰撞的“门框”对象，玩家只有击杀完房间内敌人后门才会打开。这块逻辑单独拆成门组件比较合理，别写进房间类里，否则后期加锁住房间的Boss战会很痛苦。

生成完成之后，把地图数据转成碰撞层。我建议用物理引擎的静态刚体来承载墙体碰撞，Cocos2d-x自带的PhysicsWorld在这块表现很稳定，没必要自己写AABB检测。每个房间的墙矩形直接创建成一个静态PhysicsBody，标记上kRoomWall类型，这样子弹、玩家、敌人就能共用同一套碰撞筛选。

2. 武器系统怎么拆：从射击模式到弹药管理的抽象设计

元气骑士让人上瘾的很大原因是它武器种类非常多，而且每把武器的手感都不同。Cocos2d-x里要实现这种手感差异，最关键的是武器数据要“配置化”，不要一个武器写一坨代码。

我设计的武器基类包含以下几个核心字段：

2.1 武器基类与射击模式的抽象

我给武器设计了一套统一的发射接口，无论单发、三连发还是霰弹散射，都走同一个入口：

cpp复制class Weapon : public cocos2d::Node {
public:
    virtual void onFire(cocos2d::Vec2 aimDir) {
        for (int i = 0; i < bulletPerShot; i++) {
            float angleOffset = spreadAngle * (i - (bulletPerShot - 1) / 2.0f) / bulletPerShot;
            auto dir = aimDir.getRotated(CC_DEGREES_TO_RADIANS(angleOffset));
            spawnBullet(dir);
        }
    }
    
    virtual void onReload() {
        if (_currentAmmo >= _magSize) return;
        // 播放换弹动作，由动画帧事件触发真正的弹匣重置
        _owner->playAnimation("reload");
    }
    
    void updateAmmoDisplay() {
        // UI上显示的弹药数，与magSize、_currentAmmo实时绑定
        auto label = getChildByName<Label*>("ammoLabel");
        if (label) label->setString(StringUtils::format("%d/%d", _currentAmmo, _magSize));
    }
};

这里我想强调一个容易忽略的点：spawnBullet不仅需要拿到子弹纹理和速度，还要把武器自身的当前数据快照传给子弹。比如“拿到武器后就无法再被击穿”这种Buff效果，其实是在子弹生成时把hurtType固化进去，而不是每次碰撞都回头查武器属性。否则切枪之后，已经飞在路上的子弹属性也会变，逻辑就乱了。

2.2 武器抖动、枪口位置与动画联动

元气骑士的打击感有很大一部分来自枪口火焰和武器的上抬抖动。Cocos2d-x要实现这个效果，不需要在动画编辑器里逐帧手K，直接用Action组合就行。

cpp复制auto shootActions = cocos2d::Sequence::create(
    cocos2d::MoveBy::create(0.05f, cocos2d::Vec2(0, 6)),
    cocos2d::MoveBy::create(0.08f, cocos2d::Vec2(0, -6)),
    nullptr
);
node->runAction(shootActions);

枪口位置我习惯单独挂一个空的子节点，方向对准当前瞄准方向即可。这样即使武器本身做了位移和旋转抖动，枪口火焰特效的坐标始终是对的。这里有一个实战中的坑：如果武器模型是左右翻转显示（面向左时整体scaleX=-1），枪口节点的x坐标也必须跟着取反。我第一次做的时候只翻转了主节点，子弹飞出去的方向和枪口偏了一大截，调试了半天才发现是子节点坐标没有同步。

弹匣弹药耗尽后，如果玩家没主动按换弹键，角色应该进入“空仓”状态。这个状态我建议用状态机面板直接锁死攻击输入：

cpp复制bool canFire() {
    return _currentAmmo > 0 && !_isReloading && _stateMachine->getCurrentState() != "reload";
}

换弹动作必须由动画帧事件触发弹药重置，而不是在onReload里立即恢复弹药。这样做的好处是换弹手感能精确对帧：动画播放到某一个关键帧时弹药瞬间填满，视觉和逻辑完全一致。如果提前填满，玩家看到弹匣还空着就已经能开枪了，非常破坏沉浸感。

3. 角色动作状态机与换弹打断机制

Cocos2d-x虽然提供了Action系统，但直接拿Action管理角色行为会非常痛苦。多个Action叠加时，角色经常出现“走路被打断还保持跑步姿势”“攻击动画和移动动画混在一起”这类问题。我把角色行为统一收敛到一个状态机里，这是复刻元气骑士手感的第二根台柱。

3.1 状态划分与切换条件

角色核心状态我划分成这几个：IDLE、RUN、ATTACK、RELOAD、DODGE、DEATH。每个状态进入时，调用统一的enter方法，只做三件事：切换动画、重置该状态专属的计时器、设置当前状态下允许的输入掩码。

cpp复制enum class HeroState {
    IDLE, RUN, ATTACK, RELOAD, DODGE, DEATH
};

class HeroStateMachine {
public:
    void changeState(HeroState newState) {
        if (_currentState == newState) return;
        exitState(_currentState);
        _currentState = newState;
        enterState(newState);
    }
    
    void update(float dt) {
        switch (_currentState) {
            case HeroState::ATTACK:
                _attackTimer += dt;
                if (_attackTimer >= _weapon->getFireInterval()) {
                    changeState(HeroState::IDLE);
                }
                break;
            default:
                break;
        }
    }
};

这个状态机的核心哲学很简单：状态切换必须是显式调用，不允许通过runAction后自动跳到另一个状态。比如攻击动作播完后，由状态机的update检测攻击计时器超时，然后调用changeState(IDLE)。所有切换都在一个地方维护，排查BUG时查这一个文件就够了。

状态切换的合法路径我整理成了表：

这里有一个反直觉但重要的设计：换弹状态允许被闪避打断，但打断后换弹进度要保留一半。否则玩家每次闪避都等于从零开始换弹，实战中压力会非常大。元气骑士的换弹读条被打断后也是保留部分进度的，这种细节直接决定游戏好不好玩。

3.2 攻击状态与换弹读条的协同

攻击状态不只是播放一个攻击动画那么简单。我建议把攻击分成“开火瞬间”和“后摇”两个阶段，开火瞬间由动画帧事件触发伤害结算、生成子弹、弹药减一。后摇阶段用状态机的计时器控制，而不是让动画自己播完。因为Cocos2d-x的动画帧率会受到设备性能影响，动画播慢了，攻击节奏就会被拖慢；用计时器控制后摇，攻击手感反而更稳定。

换弹读条我直接用进度条UI绑定到状态机上，这样不管玩家切换武器、触发闪避还是被击退，读条都能保持视觉同步：

cpp复制void Hero::startReload() {
    if (_stateMachine->getCurrentState() == HeroState::RELOAD) return;
    _stateMachine->changeState(HeroState::RELOAD);
    _reloadProgress = 0.f;
    _reloadDuration = _weapon->getReloadTime();
    // UI上绑定进度
    _reloadBar->setVisible(true);
    _reloadBar->setPercentage(0.f);
}

void Hero::update(float dt) {
    if (_stateMachine->getCurrentState() == HeroState::RELOAD) {
        _reloadProgress += dt;
        _reloadBar->setPercentage(_reloadProgress / _reloadDuration * 100.f);
        if (_reloadProgress >= _reloadDuration) {
            _weapon->refillAmmo();
            _stateMachine->changeState(HeroState::IDLE);
            _reloadBar->setVisible(false);
        }
    }
}

闪避状态的实现也值得单独讲一下。Cocos2d-x的Roll动作做闪避时，角色会在短时间内朝一个方向位移，同时获得短暂的无敌帧。我建议无敌帧的判定不要写在碰撞回调里，而是放在角色碰撞体上动态开关碰撞Mask：

cpp复制void Hero::setDodging(bool dodging) {
    auto body = this->getPhysicsBody();
    if (dodging) {
        body->setCategoryBitmask(kHeroDodging);
        body->setCollisionBitmask(0);
        _dodgeTimer = 0.3f;
    } else {
        body->setCategoryBitmask(kHero);
        body->setCollisionBitmask(kEnemy | kEnemyBullet | kObstacle);
    }
}

这个方案的好处是弹幕检测根本不需要知道“这个人在闪避”，碰撞系统自动帮你过滤掉了。性能上也没有额外开销。

3.3 把角色技能拆成独立组件，别塞进状态机

元气骑士的角色都有主动技能，技能表现五花八门。如果把这些技能逻辑都写进状态机里，状态机会越来越臃肿，后期维护非常痛苦。我建议给角色挂一个SkillComponent，它只暴露两个接口：bool canUse()和void use()。具体是放一圈火球还是触发短时间加速，全在组件内部实现。

cpp复制class SkillComponent : public cocos2d::Component {
public:
    bool canUse() const { return _cooldownTimer <= 0.f; }
    void use() {
        if (!canUse()) return;
        _cooldownTimer = _cooldownDuration;
        // 触发技能效果，比如生成一圈子弹、给自己加护盾
    }
    void update(float dt) {
        if (_cooldownTimer > 0) _cooldownTimer -= dt;
    }
};

这样状态机和技能之间的耦合降到了最低。角色攻击动画、闪避动画照常播放，技能只是“额外插入”的效果，不会打断角色当前行为。我试过把技能放进状态机，维护到第三个角色时会发现状态数量爆炸，每个技能都要接管攻击和移动，调试起来想骂人。

4. 弹幕、碰撞与敌人AI：让肉鸽手感成立的关键细节

地牢射击游戏的手感最终要落到子弹和碰撞交互上。Cocos2d-x自带的物理引擎默认按刚体质量碰撞，但弹幕射击里我们不希望子弹之间有物理碰撞，也不想让子弹被玩家的身体弹开。这块需要用碰撞筛选矩阵仔细设计。

4.1 碰撞层设计与碰撞矩阵

Cocos2d-x物理引擎最核心的就是三个Bitmask：Category（自己属于哪类）、Collision（和谁产生物理碰撞）、ContactTest（和谁产生接触回调）。我的设计如下：

这里最关键的是“Collision”和“ContactTest”要分开设置。Collision管的是物理阻挡，比如玩家不能穿过墙、子弹被墙挡住；ContactTest管的是逻辑接触，比如子弹打到敌人触发伤害。两者完全独立。

拿玩家子弹举例：ContactTest只监听敌人，Collision才处理墙体。这样子弹碰到敌人时只会触发onContactBegin，而不会因为物理碰撞被弹开。

多个对象同时接触时，只在onContactBegin返回true的那个回调里做伤害计算，返回false的话碰撞会被物理引擎忽略，跟性能关系很大。我踩过一个坑：子弹和敌人碰撞时，既想在onContactBegin里扣血，又想让子弹在onContactSeparate时回收，结果一颗子弹可能掉两次血。解决方案是给子弹挂一个hasHit标记，伤害结算只执行一次。

4.2 子弹池与命中特效池

元气骑士一个屏幕最多能出现几十颗子弹，每颗子弹都有自己独立的Node、PhysicsBody、渲染纹理。如果每次射击都创建、命中后销毁，频繁的内存分配不仅掉帧，还会在低端安卓机上触发频繁GC，直接导致卡顿。我用对象池统一管理子弹和命中特效。

cpp复制class BulletPool {
public:
    Bullet* getBullet(const std::string& textureName) {
        Bullet* bullet = nullptr;
        if (!_pool.empty()) {
            bullet = _pool.back();
            _pool.popBack();
            bullet->setVisible(true);
            bullet->getPhysicsBody()->setEnabled(true);
        } else {
            bullet = Bullet::create();  // 初始化时统一加载纹理
            bullet->retain();
        }
        bullet->reset();
        return bullet;
    }
    
    void recycleBullet(Bullet* bullet) {
        bullet->stopAllActions();
        bullet->removeFromParent();
        bullet->getPhysicsBody()->setEnabled(false);
        bullet->setVisible(false);
        _pool.pushBack(bullet);
    }
};

子弹池有一个容易忽略的细节：子弹的Node树结构里面通常还会挂一个Sprite和一个ParticleSystem。如果每个子弹都独立创建一份粒子系统，对象池的意义就直接减半。正确的做法是子弹池只池化Node骨架，命中特效单独池化，粒子系统只在需要时才从特效池里取出并播放一次。

我实测下来，子弹池初始容量设成400、命中特效池设成64就够用了，再高就是浪费内存。

4.3 敌人AI：不是所有敌人都需要行为树

不是所有敌人AI都值得上行为树。元气骑士里的普通小怪行为非常简单：朝玩家移动、射一发子弹、再移动。用Cocos2d-x的Action或直接写状态机就能搞定，上行为树反而增加调试成本。

cpp复制void NormalEnemy::update(float dt) {
    switch (_aiState) {
        case EnemyState::CHASE:
            moveTowardPlayer(dt);
            if (distanceToPlayer() < _attackRange) {
                _aiState = EnemyState::ATTACK;
                _attackTimer = 0.f;
            }
            break;
        case EnemyState::ATTACK:
            _attackTimer += dt;
            // 在攻击计时到某个点时射出子弹
            if (_attackTimer >= _attackWindup) {
                fireBulletTowardPlayer();
                _aiState = EnemyState::CHASE;
            }
            break;
    }
}

真正复杂的是“射击型敌人”的弹幕形态。扇形弹幕、环形弹幕、螺旋弹幕，其实都是数学计算：

• 扇形弹幕：把目标方向作为中心，左右各偏移若干角度，每度射出一颗子弹。
• 环形弹幕：从0到360度均匀射出N颗子弹，相邻子弹角度差为360/N。
• 螺旋弹幕：每帧增加一个小角度，把当前角度作为发射方向。

弹幕生成之后，我用moveToward让子弹沿固定方向匀速运动：

cpp复制void Bullet::setup(cocos2d::Vec2 dir, float speed) {
    _velocity = dir.getNormalized() * speed;
}

void Bullet::update(float dt) {
    this->setPosition(getPosition() + _velocity * dt);
}

这里有个非常重要的参数调优经验：子弹的速度、尺寸应该与玩家无敌帧、碰撞体大小数值联动。如果玩家碰撞体半径是10像素，子弹直径却只有6像素，玩家会觉得“明明躲过去了还是被击中”。我调试时把玩家判定圈从16像素缩小到8像素之后，手感立刻清晰了很多——弹幕游戏里“判定点应该比视觉模型小一圈”基本是共识。

4.4 障碍物遮挡与可被击碎物

元气骑士的房间里有很多可被击碎的箱子、路障，这些物体本质上是静态物体加上一个HP属性。我实现这类物体时，给它们挂一个DestructibleObstacle组件，内部维护一个HP值，接收伤害后播放破碎动画并移除物理体。

但要注意，这类物体会大幅影响弹幕的通行路线。玩家和敌人的子弹都应该被障碍物挡住，但闪避和近战攻击不应该被障碍物挡住。这个碰撞筛选矩阵在前面已经体现出来了：障碍物的Category设为kObstacle，碰撞Mask同时覆盖玩家子弹和敌人子弹，但不和玩家、敌人发生物理碰撞。

有的障碍物不阻挡子弹但阻挡角色（比如“栅栏”），有的障碍物阻挡子弹但不阻挡角色（比如“水潭”），这两种类型要把物理体分开建，不能用同一个kObstacle类型，否则会出现子弹穿透栅栏的诡异表现。

5. 性能、资源与真机适配的实战问题

Cocos2d-x v3.16在PC模拟器上怎么跑都流畅，但一上安卓中低端机就会暴露问题。这里整理几个我在真机适配中踩过最深、也最有共性的坑。

5.1 DrawCall合并：美术资源别裸用PNG

地牢游戏每个房间的墙体、地板、装饰物数量庞大，如果每个Sprite都是独立纹理，DrawCall会迅速飙到几百。我一开始为了省事直接加载散图，结果在红米低端机上走到大厅就只剩20多帧。

后来我把地板、墙壁、装饰物全部打进了图集（TexturePacker或Cocos Studio自带的资源打包工具都行），并且用SpriteFrameCache统一加载。Cocos2d-x对图集的批量渲染是自动的，只要你用的是同一个纹理，DrawCall会合并。这个优化做完，同场景DrawCall从400多降到了60以内，帧率直接满60。

Cocos2d-x v3.16里Sprite的批量渲染是按“全局纹理顺序”合并的，中间如果插入了一个别的纹理的Sprite，后面的合并就断了。所以美术资源规划时，同类物件尽量放在同一个图集内，不同图集之间不要交叉使用，否则优化效果会打折扣。

5.2 对象池的上限与回收策略：GC和卡顿

除了子弹池，敌人也要做池化。地牢里敌人是被动态生成的，每个敌人身上带着物理体、动画、AI组件，创建销毁一多，内存碎片化就会出现。我给的方案是：敌人池初始容量设为30，每个敌人实例保留完整的动画缓存和骨骼数据，recycle时只隐藏和禁用，不销毁节点。

真正的敌人池回收时机不是敌人死亡瞬间，而是死亡动画播放完毕之后。这里要特别注意，死亡动画里如果包含特效节点比如碎成碎片的粒子，必须在回收前把特效单独扔到特效池里，否则下次复活时还带着上一具尸体的特效，看着非常诡异。

Cocos2d-x的Action回调里有一个隐藏陷阱：在回调里执行removeFromParent()或pool->recycle()，有时候会导致节点在Action调度器里被提前释放，之后Action再访问它就直接崩溃。我处理这种场景的统一规范是：对象池回收统一走一个scheduleOnce，把回收操作推迟到下一帧。

cpp复制void Enemy::playDeathAndRecycle() {
    auto seq = cocos2d::Sequence::create(
        cocos2d::Animate::create(_deathAnim),
        cocos2d::CallFunc::create([this]() {
            // 延迟一帧回收，避免Action回调中直接销毁节点导致的崩溃
            this->scheduleOnce([this](float) {
                EnemyPool::getInstance()->recycle(this);
            }, 0.f, "recycle_delay");
        }),
        nullptr
    );
    this->runAction(seq);
}

5.3 音频缓存与NativeAudio兼容

Cocos2d-x v3.16提供的音频引擎在不同平台上有坑，尤其是一片接一片播放音效时容易出现音频资源竞争。我的方案是：所有短音效统一用AudioEngine预加载，并使用播放ID做计数。平时开枪、命中、拾取这些高频短音效，不要直接play2d，要先从缓存池取一个空闲的音频播放器，播放结束再放回去。否则压力测试下同一把霰弹枪连发8颗子弹同时播放8个音效，安卓机上会直接出现音画不同步。

BGM则单独用一个原生音频播放通道，不与音效池混用。我在项目里把BGM音量、音效音量、UI音量拆成了三个独立控制参数，UI交互音效单独小音量播放，这样玩家在战斗中不会因为BGM音量忽大忽小而烦躁。

5.4 UI节点遮挡与多点触控的冲突

地牢游戏常见的UI包括大血条、小地图、技能图标、弹药显示。这些UI节点如果挂在主场景里，会参与游戏场景的物理计算和渲染顺序，导致UI遮挡了子弹、触摸判断被UI区域吃掉。

我建议UI整体放进一个独立的Layer里，设置成不吞触摸事件。同时技能按钮最好单独设置触摸区域，不应该影响玩家移动摇杆的输入。移动摇杆的输入区分虚拟摇杆触摸和技能按钮触摸，不能让玩家按技能时移动摇杆突然失灵。

我实现在虚拟摇杆的触摸回调里，先判断触摸点是否在摇杆区域内，如果不在就忽略。技能按钮则在UI层放置一个空的EventListenerTouchOneByOne，并设置swallowTouches = true，这样它的触摸不会穿透到底下的场景。两个区域重叠时，UI层的按钮自然会优先响应，这个优先级机制非常有用。

写在最后：关于手感与帧率的一点小建议

如果你只是照着教程把房间生成、武器、敌人、子弹都拼出来了，但总觉得“差点意思”，那问题多半出在手感调优上。Cocos2d-x里同样一套逻辑，攻击动画的EaseOut曲线、子弹飞行速度、敌人生成速度和玩家移动速度的配比，会直接决定游戏是“爽游”还是“卡顿模拟器”。

我个人实测下来，玩家常规移动速度在每秒240到280像素之间比较合理，子弹速度在500到700像素之间时弹道清晰且不飘。太快的子弹虽然看起来炫，但玩家反应不过来；太慢了弹幕压迫感不足。数值调整建议以“玩家能否在紧急情况下靠一个短距闪避躲开扇形弹幕”为基准线，不断调优，直到这个感觉自然为止。

另外，Cocos2d-x v3.16的项目最好从一开始就开启setProjection为透视投影还是正交投影，地牢游戏是严格的正交视角，千万别糊涂地开了透视。精灵图的锚点、坐标系这些基本功如果当时没有注意，后期大量玩法逻辑叠加后，坐标偏移问题会让你排查到你怀疑人生。

地牢射击游戏的开发难点不在某个单独功能上，而在所有系统的衔接。房间生成完了接敌人，敌人接掉落物，掉落物接武器，武器接状态机，状态机接碰撞。每个接口多留一点数据位，后期接系统时就能少拆一次重构。如果你也打算用Cocos2d-x做类似的游戏，建议先把自己的最小闭环跑通，再逐步往上叠加肉鸽元素。这套架构搭好之后，后续换皮或加模式都只是配置层的事。