Cocos2D-X雷电游戏源码解析：对象池与碰撞检测实战

简介：一份经个人修改的Cocos2D-X雷电游戏完整源码，面向Android与iOS平台上刚接触游戏开发的初学者，也适合想通过纵版射击实战项目学习跨平台引擎、并模仿二次修改思路的读者。整个rar压缩包共179个文件，大小仅13.11MB，体量克制；其中cpp/h构成核心游戏逻辑，java承担Android平台接入，png/jpg提供界面与美术素材，mp3补充音效，plist/xml/tmx/fnt等承载UI、地图和字体配置，整体组织清晰，便于快速定位和替换。目前已有251人学习/下载。源码覆盖开始菜单、飞船操控、敌机生成、关卡推进、特效与碰撞等完整流程；由于是作者二次改动版，读者可以重点观察其在原版基础上调整参数与模块的切入方式，例如修改敌机速度、子弹密度、界面反馈等细节来体会效果差异。对想快速拥有个性化雷电游戏的入门者而言，这份小巧而完整的示例能提供明确的学习起点和可复用的代码框架。

1. 项目定位：一份能跑通双端的 Cocos2D-X 雷电游戏源码

上个月帮人拆一套 Cocos2D-X 的雷电游戏源码，拆完最大的感触是：这类纵版射击游戏，难点从来不在画面上，而在对象管理和碰撞检测。这个工程把玩家操控、子弹发射、敌机波次、爆炸特效串成了一条完整链路，核心逻辑全用 C++ 编写，Android 和 iOS 共享同一份游戏代码，平台层只做窗口和事件适配。对想学跨平台 2D 开发的人来说，它比零散教程更值得下载——你拿到的不只是能玩的 demo，而是一个可以直接改造成自己游戏的工程模板。适合准备用 C++ 做射击游戏的人、在 Cocos2D-X 和 Unity 之间纠结的选型党，以及需要一个完整毕设底座的同学。下面我从工程结构一路拆到核心实现，最后给出构建步骤和二次开发路线。

2. 工程与技术选型：C++ 写逻辑、双端共享的目录骨架

很多人拿到这份源码会先找 README，结果发现文档没几句话，真正的干货全藏在目录结构里。Cocos2D-X 的工程形态和 Unity、Godot 差别很大，它没有可视化编辑器生成的巨大工程文件，而是一套以 C++ 源码为核心的目录骨架，Android 和 iOS 的构建工程只是薄薄一层壳。

2.1 为什么这类游戏适合用 Cocos2D-X

雷电是典型的弹幕类射击游戏，核心诉求有三条：同屏大量子弹和敌机不卡顿、爆炸和弹道的视觉效果流畅、触摸响应足够跟手。Cocos2D-X 是 C++ 直接驱动 OpenGL ES 渲染，没有脚本虚拟机中间层，性能上有先天优势。同一份 C++ 逻辑通过 JNI 桥接 Android、通过 Objective-C 桥接 iOS，两个平台的游戏行为完全一致，这是它最吸引人的地方。

引擎内置的场景管理、Sprite、Action、ParticleSystem、调度器和触摸事件，正好覆盖了雷电需要的全部功能。特别是它的批量渲染能力，把贴图打包成图集后，同一批 Sprite 可以合并渲染调用，弹幕数量上来后帧率也不会断崖式下跌。相比之下，用 Web 方案做同类游戏很容易在低端 Android 机上发热掉帧，用 Unity 则有点杀鸡用牛刀。Cocos2D-X 在这个场景里是性价比最高的选择。

2.2 工程目录：Classes 与 Resources 各管什么

解开源码包后，顶层目录是标准的 Cocos2D-X 工程布局。核心价值集中在 Classes 和 Resources 两个目录里，平台工程目录只是构建入口。

Classes 里的文件划分是典型的功能分文件：AppDelegate 管引擎初始化和场景切换，GameScene 是游戏主场景，Player、Bullet、Enemy 分别封装飞机、子弹和敌机对象，BulletPool 是子弹对象池。这种命名方式让每个文件的责任边界非常清楚，改代码时基本一眼就能定位到该动哪个文件。

Resources 目录里最重要的是 TexturePacker 打出来的图集文件。雷电这类游戏需要频繁创建和销毁精灵，如果每张图都单独加载纹理，DrawCall 会爆炸。图集把几十张小图合成一张大图，引擎通过 plist 文件里的坐标信息裁剪出需要的部分，这也是它能在低端机上跑流畅的关键。音效文件不多，通常只有射击音效、爆炸音效和一段背景音乐。

2.3 平台层与逻辑层如何衔接

Cocos2D-X 的跨平台策略是“逻辑全在 C++，入口各管各”。Android 端从 AppActivity.java 的 onCreate 进入，加载 libcocos2dcpp 动态库，然后调用 C++ 侧的 AppDelegate 完成引擎初始化。iOS 端则是 AppController.mm 在 application:didFinishLaunching 后调用同样的 AppDelegate 逻辑。

AppDelegate::applicationDidFinishLaunching 里做的事情很固定：创建 Director、设置 OpenGL 视图、配置帧率和资源搜索路径，最后把第一个场景 push 进导演栈。以这套工程的常见写法为例：

bool AppDelegate::applicationDidFinishLaunching() { auto director = Director::getInstance(); auto glview = director->getOpenGLView(); if (!glview) { glview = GLViewImpl::create("Thunder"); director->setOpenGLView(glview); } director->setAnimationInterval(1.0f / 60.0f); auto scene = GameScene::createScene(); director->runWithScene(scene); return true; }

这段代码里有几个值得注意的细节。setAnimationInterval 控制游戏帧率，雷电这类动作快的游戏用 1/60 秒，卡顿感会明显小于 1/30。createScene 是 Cocos2D-X 的约定写法，场景类一般提供静态方法创建并返回场景实例。资源搜索路径如果没有在 AppDelegate 里手动添加，Assets 目录下的图片就加载不到，这是后续黑屏问题的一个根源。

平台层和逻辑层的衔接其实非常薄，两份入口文件加起来不过两百行。真正的游戏代码都在 C++ 侧，这意味着如果在 iOS 上修了一个 BUG，Android 端直接重新编译就同步修复了，不需要改任何平台代码。这种一套核心、双端共享的结构，正是这类源码工程最值得学习的部分。

3. 核心模块拆解：子弹对象池、碰撞检测与敌机波次的完整实现

这一章是整份源码最关键的部分。雷电这类游戏玩起来爽，本质是背后有一套高效的对象管理机制在支撑。我会按一次完整对局的时间线：场景初始化、玩家操控、子弹发射、敌机生成、碰撞判定，逐个拆开讲。

3.1 场景入口：GameScene 的图层划分与事件监听

GameScene 是整个游戏的心脏。它的 init 方法里做了三件事：创建玩家和子弹池、注册触摸监听、启动 update 调度器。片段如下：

bool GameScene::init() { if (!Scene::init()) return false; auto visibleSize = Director::getInstance()->getVisibleSize(); _player = Player::create(); _player->setPosition(Vec2(visibleSize.width / 2, 100)); this->addChild(_player, 1); _bulletPool = BulletPool::create(); this->addChild(_bulletPool, 2); auto listener = EventListenerTouchOneByOne::create(); listener->onTouchBegan = [this](Touch* t, Event* e) { _targetPos = t->getLocation(); return true; }; listener->onTouchMoved = [this](Touch* t, Event* e) { _targetPos = t->getLocation(); }; this->getEventDispatcher()->addEventListenerWithSceneGraphPriority(listener, this); this->scheduleUpdate(); return true; }

触摸监听用的是 EventListenerTouchOneByOne，回调直接更新飞机的目标位置。onTouchBegan 返回 true 表示这个事件被消费，配合监听器的 swallowsTouches 设置，可以防止触摸事件穿透到菜单或别的 UI 节点。这里的设计思路是“飞机不直接跟手，而是朝目标点移动”，中间加了一层平滑缓冲，手感会比直接设置位置更柔和。

scheduleUpdate 让场景每帧调用 update 方法，游戏里所有的动态逻辑：玩家移动、子弹飞行、敌机轨迹、碰撞检测，都挂在这一次调度上。这种单帧循环驱动一切的写法，是 Cocos2D-X 游戏的标准形态。

3.2 子弹对象池：如何做到同屏 200 发不卡

雷电的射击频率很高，玩家按住屏幕时会以每 0.1 秒一发的速度发射子弹。如果每发子弹都 create 一个 Sprite 再在飞出屏幕后销毁，频繁的堆内存分配和释放会在低端机上造成明显卡顿，这也是新手做弹幕游戏最容易翻车的地方。这套源码里用对象池解决了这个问题。

Bullet* BulletPool::getBullet() { for (auto bullet : _pool) { if (!bullet->isVisible()) { bullet->reset(); return bullet; } } auto bullet = Bullet::create(); bullet->retain(); _pool.pushBack(bullet); this->addChild(bullet, 0); return bullet; }

void Bullet::update(float dt) { setPositionY(getPositionY() + _speed * dt); if (getPositionY() > _maxY) { setVisible(false); } }

getBullet 的逻辑很简单：池子里找第一个不可见的子弹，重新初始化后返回；一个都找不到就新创建一个并加入池子。子弹飞出屏幕后不会销毁，只是隐藏自己，下次射击时自动复用。这套做法把动态创建对象变成了复用已有对象，内存分配次数从每秒十几次降到了场景启动时的一次。

Bullet::update 里有一个 _maxY 判断，子弹飞过屏幕上边界加一小段距离后隐藏。这个余量要留够，否则子弹在屏幕上边缘直接消失会显得很突兀。常见做法是把 _maxY 设为可见区域高度加 50 像素，这段冗余是给子弹贴图一半高度和飞行缓冲留的，调太小会出现子弹“还没飞出去就消失”的错觉。

对象池的大小不需要手动管理，它会随着游戏难度自动扩容。敌方子弹也可以用同一套池子，只是子弹的飞行方向和速度参数不同。

3.3 碰撞检测：AABB 与圆形检测的取舍

碰撞检测是射击游戏体验的底线。打中了没反应、子弹擦边飞过，玩家立刻就能感觉到。Cocos2D-X 里最直接的做法是拿精灵的包围盒做矩形相交判断：

bool GameScene::isHit(Sprite* a, Sprite* b) { Rect rectA = a->getBoundingBox(); Rect rectB = b->getBoundingBox(); return rectA.intersectsRect(rectB); }

getBoundingBox 会考虑节点的位置、锚点、缩放和旋转，对大多数场景够用。但这套代码里子弹数量一多，每帧做几百次矩形相交运算，每个相交还要做坐标换算，性能开销就上来了。更高效的做法是维护自定义的碰撞圆，用圆心距离的平方做判断，省去包围盒的变换计算：

bool GameScene::isHitByCircle(Node* a, Node* b, float radiusA, float radiusB) { Vec2 posA = a->getPosition(); Vec2 posB = b->getPosition(); float dx = posA.x - posB.x; float dy = posA.y - posB.y; float minDist = radiusA + radiusB; return dx * dx + dy * dy <= minDist * minDist; }

圆形碰撞在弹幕游戏里是更好的方案，因为子弹形状接近圆，运算量小，而且判定结果稳定。radiusA 和 radiusB 并不是直接取贴图尺寸的一半，常见做法是各乘一个 0.8 的收缩系数。这样做的原因是玩家视觉上判定“打中了”的区域比实际贴图小一点，给玩家留出操作余量，手感不会那么苛刻。这个 0.8 是无数游戏验证过的经验值，用血泪经验换来的，改起来要谨慎。

3.4 敌机生成与波次：难度曲线怎么设计

敌机生成如果写死，游戏就会变得单调。源码里的常见做法是用调度器按固定间隔生成一波敌机，波次越高数量越多、速度越快，形成最简单的难度曲线：

this->schedule([this](float dt) { int count = MIN(3 + _waveCount / 2, 8); for (int i = 0; i < count; i++) { auto enemy = Enemy::create(); float x = RandomHelper::random_int(30, (int)(visibleSize.width - 30)); enemy->setPosition(Vec2(x, visibleSize.height + 60)); enemy->setWaveParams(60.0f, 2.0f, i * 0.5f); this->addChild(enemy, 1); } _waveCount++; }, 2.0f, "spawn_wave");

waveCount 每触发一次就加一，count 从 3 开始逐渐递增，封顶 8 个。向左飘的几个参数是敌机的运动轨迹控制项：

void Enemy::setWaveParams(float amplitude, float frequency, float phase) { _originX = getPositionX(); _amplitude = amplitude; _frequency = frequency; _phase = phase; _elapsed = 0.0f; } void Enemy::update(float dt) { _elapsed += dt; setPositionY(getPositionY() - _speed * dt); float x = _originX + sinf(_elapsed * _frequency + _phase) * _amplitude; setPositionX(x); }

amplitude 控制敌机左右摆动的幅度，frequency 控制摆动快慢，phase 让同一波敌机错开相位，不会排成一条整齐的横线。这个正弦轨迹是雷电类游戏最经典的敌机运动方式，改动这三个参数就能衍生出不同的敌机类型，比如 amplitude 很小就是直线俯冲，frequency 很大就是高速蛇形。把参数的取值范围整理成配置表，后续做关卡设计就方便多了。

调度器加第三个参数 "spawn_wave" 是调度任务的键名，需要提前终止波次生成时可以用 unschedule("spawn_wave") 精确移除，不会误伤其它调度任务。这个 API 的用法很容易被忽略，但实际调试时非常实用。

4. 从源码到真机：Android/iOS 构建与运行步骤

源码拿到手，第一件事就是让它跑起来。这一章给你一条能走通的构建路径，Android 和 iOS 分开说，每一步都会说明命令的含义和可能的失败信号。

4.1 环境准备：引擎版本、NDK 与 IDE

Cocos2D-X 的版本选型比较敏感。3.x 系列的 C++ API 在 3.10 到 3.17 之间变化不大，常见做法是直接使用 3.17.2，这是 3.x 系列最后的稳定版本。Android 侧需要准备 Android Studio、SDK Platform 和 NDK，NDK 版本建议 r21 左右，太新的 NDK 可能因为移除了某些编译器选项导致编译报错。iOS 侧需要 Xcode 和 macOS 环境，这个没有替代方案。

4.2 Android 构建：gradlew 编译与 adb 部署

Android 工程的构建入口是 proj.android 目录。如果你用 Android Studio 打开，它会自动识别 gradle 配置，但命令行构建更可控，也更容易看清报错信息：

cd proj.android ./gradlew assembleDebug adb install -r app/build/outputs/apk/debug/app-debug.apk

assembleDebug 会编译 C++ 代码、打包资源、生成可调试的 APK。第一次编译时间会比较长，因为 NDK 要把所有 .cpp 文件编成动态库。编译产物里最关键的是 libcocos2dcpp.so，它包含全部游戏逻辑。如果编译报错集中在 C++ 文件里，八成是 NDK 版本和引擎不匹配，切换到 r21 再试。install 的 -r 参数表示覆盖安装，调试阶段频繁改代码重装时能少点步骤。

arm64-v8a 和 armeabi-v7a 两种架构的 so 库体积不一样，真机调试时建议在 build.gradle 里加上 abiFilters：

defaultConfig { ndk { abiFilters 'armeabi-v7a', 'arm64-v8a' } }

只留这两个架构能减少打包体积。如果要用 Android 模拟器跑，还需要加 x86 架构，但雷电这种触摸密集的游戏在模拟器上体验很差，强烈建议真机调试。

4.3 iOS 构建：Xcode 工程与签名

打开 proj.ios_mac 下的 Xcode 工程文件，选择对应的 Team 签名后直接 Run 即可。iOS 的构建比 Android 顺畅很多，因为 Xcode 管理了编译和链接的完整链路。首次运行需要处理 iOS 的屏幕方向：雷电是竖屏游戏，工程默认支持竖屏，但如果你是从别的项目拷来的工程，可能默认是横屏，需要在 Info.plist 或工程的 Deployment Info 里把支持的屏幕方向改掉。

模拟器上跑方便调试逻辑，但粒子特效和帧率的真实表现必须看真机。模拟器用的是 Mac 的 GPU 和 CPU，性能参考价值很低，帧率的问题一定要以真机为准。

4.4 验证跑通的最小清单

安装成功后，按这个清单快速验证游戏是否正常工作：

启动后能看到游戏标题或主场景，不是黑屏或闪退。按住屏幕拖动，玩家飞机会跟随手指移动，且飞机中心和手指之间保持平滑的滞后感而非跳变。不松手的持续射击状态子弹密集、无卡顿。敌机按固定间隔从顶部出现，全部带有左右摆动轨迹。子弹击中敌机时出现爆炸特效，敌机消失，玩家碰撞敌机后飞机爆炸并出现复活动画。

清单里每一项对应前面章节的一个核心模块。如果在任何一步卡住，下一章的排查记录就是为这些问题准备的。

5. 避坑记录：黑屏、NDK 崩溃与资源加载的真实排查

这一章整理的是实际调试这套工程时踩过的一些坑。每一条都是真实场景，从现象、原因到解决方式按步骤写清楚，希望能帮你少走弯路。

5.1 黑屏但 LogCat 无异常：动态库没进 APK

现象是游戏安装后启动直接黑屏，LogCat 里没有任何 Java 层异常，只有一行若隐若现的提示。

原因是 C++ 动态库没有被正确打包进 APK。Android 构建系统在打包时会把 so 库从 jniLibs 目录或 build 产物里拷贝进 APK，如果 abiFilters 配置和 NDK 编出来的目录不对应，就出现 APK 里没有 so 文件的情况。此时进入应用详情里查看存储占用，如果 APK 解包后没有 lib 目录，基本可以实锤。

解决方法是先用 unzip 命令查看 APK 内容，确认 lib/armeabi-v7a/libcocos2dcpp.so 是否存在。不存在就检查 build.gradle 里的 abiFilters，以及项目里是否有多个 NDK 配置互相覆盖，最常见的是 Application.mk 和 gradle 的 abiFilters 写了不一样的架构列表。

5.2 SpriteFrame not found：路径大小写与加载顺序

现象是游戏能启动、背景正常，但敌机爆炸时精灵直接消失，LogCat 报各种 SpriteFrame not found。

原因是图集加载路径大小写不一致。打包资源时文件名是 Plane.png，代码里却写了 plane.png，在 Windows 上开发时文件系统不区分大小写，问题不会暴露，到了 Android 和 iOS 的严格大小写文件系统上就直接加载失败。另一个常见原因是图集 plist 被加载的时机晚于精灵创建。

解决方法是统一资源命名规范，全部小写加下划线，代码和资源文件严格同名。图集的加载放在 AppDelegate 的启动阶段，用 FileUtils 的 addSearchPath 把 Resources 目录加进搜索路径，这样运行时引擎才能正确找到文件。

5.3 内存只涨不降：敌机销毁与监听器泄漏

现象是游戏玩到后面越来越卡，用内存分析工具看，内存占用随着波次推进不断上涨，即使敌机已经被打到界外也不回落。

原因是敌机被移出屏幕后并没有从父节点移除。Cocos2D-X 里 removeFromParent 才能真正释放节点在场景图中的引用，如果只是 setVisible(false)，节点还挂在渲染树里，每帧依然会被遍历和绘制。另一个泄漏点是节点上的 EventListener 没有在节点销毁时移除。

解决方法是写一个统一的 recycle 方法，敌机出界时先调用 removeFromParent，再把它从 GameScene 维护的敌机数组里 erase。如果节点注册了 EventListener，在 onExit 回调里调用 getEventDispatcher()->removeEventListener 手动解除。这两步缺一不可，处理完内存曲线就能平稳下来。

5.4 触摸穿透：UI 按钮和游戏同时响应

现象是点击暂停按钮时，玩家飞机也同时移动到了按钮位置，游戏暂停状态下手势还在控制飞机。

原因是触摸事件被多个监听器同时订阅。UI 按钮和场景都注册了触摸监听，引擎默认会把事件分发给所有注册过的监听器，场景的监听器没有消费掉事件，UI 层也会响应。

解决方法是给场景的监听器设置 setSwallowsTouches(true)，让事件在第一个监听到的监听器处停止传播。但要注意顺序：如果 UI 层和场景层的监听器优先级不同，需要确认 UI 在最上层先拿到事件。常见做法是 UI 节点单独用一个监听器，且优先级高于场景监听，这样 UI 点按时场景不响应，其余区域点击穿透到场景。

5.5 碰撞检测“打不中”：锚点与包围盒的偏差

现象是子弹明显碰到了敌机贴图，但没有触发爆炸，或者看起来没碰到却爆炸了。

原因是碰撞计算使用的坐标参考点和视觉贴图不一致。Cocos2D-X 的 getBoundingBox 基于节点锚点计算，如果精灵的锚点被设置成 (0,0) 而不是默认的 (0.5,0.5)，包围盒和视觉位置就错开了。另外，敌机在移动过程中如果用了 scale 动画，getBoundingBox 会包含缩放后的尺寸，和实际贴图占据的视觉区域也有偏差。

解决方法是统一锚点约定，游戏中所有动态对象全部使用默认锚点，不使用 scale 动画的节点做碰撞体。碰撞检测用的尺寸直接采用自定义半径而非 getBoundingBox，这也是上一章选择圆形碰撞的原因之一，它天然绕开了锚点带来的盒子偏移问题。

6. 二次开发路线：把单机雷电改成双摇杆射击

如果你想把这份源码改成能做轻度操作差异的游戏，双摇杆射击是个恰到好处的方向。它保留了雷电的弹幕体系和对象池框架，但改变了操控逻辑，玩法和原版完全是两个感觉。

先动输入层。把 GameScene 里的触摸监听替换成两个虚拟摇杆，左边摇杆的触摸位置计算移动方向向量，右边摇杆计算射击方向角度。移动逻辑从位置跟随改成速度累加：

void Player::update(float dt) { _velocity += _joystickDir * _acceleration * dt; _velocity *= 0.92f; setPosition(getPosition() + _velocity * dt); }

0.92 是阻尼系数，代表每帧速度衰减 8%，让飞机松手后能滑行一小段距离再停下。调得越小，惯性越弱，数字越大飞机就越“滑”，手感差异非常明显。

子弹发射方向需要改 Bullet 的初始化参数，传入一个角度，速度方向从固定向上改成沿角度飞行。追踪弹是另一个性价比很高的改造点：

void Missile::update(float dt) { Vec2 toTarget = _target->getPosition() - getPosition(); float angle = atan2f(toTarget.y, toTarget.x); Vec2 dir = Vec2(cosf(angle), sinf(angle)); setPosition(getPosition() + dir * _speed * dt); }

这个逻辑每帧重新计算朝向目标的方向向量，子弹会一直追着敌机跑。为了让追踪不那么无敌，可以给角度变化加一个上限，每帧最多转 3 度，敌人就有机会甩开导弹。

改造完成后验证方式很直接：跑完前三个波次，确认摇杆不跟手、方向发射正确、追踪弹不会飞到屏幕外。从那以后我每次改完操控逻辑，都会强制在低端真机上完整跑一遍前三波，不带调试器纯看体感，这套习惯帮我躲过了好几次手感翻车，也值得你试一试，希望帮到你。

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