★ FEATURED ARTICLE 简介这是一份基于Cocos2D-X引擎的雷电游戏修改版源代码面向已有一定Cocos2D-X基础并希望学习游戏逻辑改造的开发者。资源标签覆盖Android与iOS双平台作者在原作基础上进行简单调整适合作为研究游戏框架、渲染流程与碰撞检测的入门参考。压缩包共179个文件约13.11MB其中包含66个png素材图、17个Java文件Android入口、15个cpp与15个h文件核心逻辑层另有plist、tmx、fnt等资源配置与音频文件目录结构清晰便于对照查看。目前已有251人学习下载。通过学习这份代码读者可以掌握闪电战机类游戏从启动菜单、关卡管理到敌机生成与碰撞处理的整体架构并借鉴作者对源码的修改方式练习自定义游戏玩法与参数调整是Cocos2D-X游戏二次开发的实用范例。1. 拿到一份 Cocos2D-X 雷电游戏代码先别急着改代码如果你手头正好有一份 Cocos2D-X 雷电游戏源码又想在 Android 和 iOS 上跑出效果我建议你先别急着打开工程文件。我接过不止一次这种代码包第一反应都是“这不就是个飞机射击游戏吗”结果一跑起来要么在 PC 上正常、手机上花屏要么触摸没反应要么子弹打出去敌机不掉血。问题大多不在玩法逻辑而在框架理解。所谓“雷电”类游戏核心就是玩家控制飞机、躲避弹幕、击毁敌机、吃道具逻辑不复杂但它把 Cocos2D-X 里最重要的几块全用上了场景切换、节点树、触摸分发、碰撞检测、动画与粒子、跨平台资源加载。换句话说这份资源拿来学习 Cocos2D-X 的完整数据流比拿着官方示例一张一张跑要有用得多。适合谁适合刚学完 Cocos2D-X 基础、想找一个完整项目练手的开发者也适合准备做轻度射击游戏、想站在现成代码上改的人。我不是让你拿它直接上架而是把它当“骨架”把玩法、数值、界面换成自己的。2. 先把工程跑起来Cocos2D-X 雷电项目的目录结构与启动流程2.1 工程目录先认清楚别在文件堆里迷路Cocos2D-X 工程不像普通 Web 项目那样入口明显拿到压缩包之后第一步是找Classes目录和proj.*系列目录。雷电游戏代码也不例外通常结构是这样的project/ ├── Classes/ # 核心 C 源码所有玩法逻辑都在这里 │ ├── AppDelegate.cpp / AppDelegate.h │ ├── GameScene.cpp / GameScene.h │ ├── Player.cpp / Player.h │ ├── Enemy.cpp / Enemy.h │ ├── Bullet.cpp / Bullet.h │ └── ... ├── Resources/ # 图片、音效、字体、粒子文件 ├── proj.win32/ # Windows 调试工程 ├── proj.android/ # Android 构建工程 └── proj.ios_mac/ # iOS / macOS 构建工程这里有个很容易被忽视的点Classes是跨平台共用的代码proj.*各自只放平台相关的入口和配置。很多新手拿到代码后直接在 Android Studio 里打开proj.android然后找不到GameScene.cpp其实源码都在Classes里Android 工程只是通过Android.mk或 CMake 把那些文件包含进来。AppDelegate是整个引擎的启动入口applicationDidFinishLaunching函数里创建导演、设置主场景。雷电游戏通常会把GameScene设为主场景但有些代码包还会附带一个StartScene做开始菜单这时就要看清楚导演切换到了哪个场景。2.2 在 Windows 上先用 VS 跑通这是效率最高的调试方式我一般拿到 Cocos2D-X 源码会先在 Windows 上编译proj.win32。原因很简单在手机上报错要看 Logcat 或 Xcode 控制台而在 PC 上可以直接断点调试渲染窗口也能快速看到效果。前提是你本地装好了 Cocos2D-X 的依赖环境也就是 Python 2.x老版本或 CMake、VS 的 C 开发组件DirectX SDK 一般 VS 自带。打开proj.win32下的.sln解决方案文件直接编译运行。运行后如果看到窗口但黑屏大概率是Resources目录路径没找对检查AppDelegate.cpp里的FileUtils::getInstance()-addSearchPath或setSearchPaths是否正确。// AppDelegate.cpp 中常见的资源路径设置 bool AppDelegate::applicationDidFinishLaunching() { auto director Director::getInstance(); auto glview director-getOpenGLView(); if (!glview) { glview GLViewImpl::create(Lightning); director-setOpenGLView(glview); } // 设置设计分辨率注意这个数值要和 Resources 里的图片设计尺寸一致 glview-setDesignResolutionSize(480, 800, ResolutionPolicy::SHOW_ALL); // 加载资源搜索路径 FileUtils::getInstance()-addSearchPath(Resources); FileUtils::getInstance()-addSearchPath(Resources/Images); FileUtils::getInstance()-addSearchPath(Resources/Audio); auto scene GameScene::createScene(); director-runWithScene(scene); return true; }这段代码里有三个关键参数。setDesignResolutionSize(480, 800, ResolutionPolicy::SHOW_ALL)里的480x800是设计分辨率不是屏幕实际分辨率。SHOW_ALL表示保持宽高比缩放整个画面保证所有内容都能看到但两边可能留黑边。常见的还有EXACT_FIT会拉伸变形NO_BORDER会裁掉超出部分。雷电这类竖屏射击游戏用SHOW_ALL比较多因为玩家需要在屏幕上看到完整的战场。addSearchPath则决定了Sprite::create(player.png)这类相对路径的查找位置如果不加这一行运行时会直接报“找不到文件”。2.3 Android 与 iOS 的构建差异不是改了代码就能出包在 Windows 上跑通只是第一步真正出 Android 包和 iOS 包时坑就开始多了。Android 这边新版 Cocos2D-X 用 CMake 构建旧版有些用Android.mk。如果工程里同时有CMakeLists.txt和jni/Android.mk确认你用哪套别混着改。Android 构建还有一个经典问题NDK 版本。Cocos2D-X 3.x 官方推荐 r16 或更早版本新版 NDK 编译时会报一堆“未定义的引用”原因是新 NDK 移除了部分 GNU STL 支持。我一般推荐用 r16b不要追求最新。iOS 这边相对简单但要注意Resources目录在 Xcode 工程里是不是以 folder reference 方式引用的如果以 group 方式引用运行时文件路径会找不到图片。# Android 构建前先配置 NDK 路径macOS/Linux 示例 export ANDROID_NDK_HOME/path/to/android-ndk-r16b export ANDROID_SDK_ROOT/path/to/android-sdk # 进入 android 工程目录生成 gradle 需要的配置 cd proj.android python build_native.py这段命令的作用是先生成 native 库也就是把Classes下的 C 代码编译成.so文件然后再用 Gradle 打包 APK。build_native.py会读取jni/Android.mk或 CMake 配置来编译如果你改了Classes里的代码只点了 Android Studio 的 Run 按钮有时不会触发 native 重编这就是很多人改了代码却看不到效果的原因。常见做法是重新跑一次build_native.py或者直接执行 Gradle 的clean任务再 build。iOS 那边则是 Xcode 会自动感知.cpp文件变化但如果你新增了文件记得在 Build Phases 的 Sources 里手动添加。雷电游戏代码在移植时如果出现“飞机能显示但不响应触摸”问题往往出在触控坐标转化这个我在第 5 章会详细讲。3. 核心玩法模块拆解雷电的“三件套”如何协同工作3.1 玩家飞机触摸跟随与移动边界限制雷电游戏里玩家操作就是手指按住飞机飞机跟随移动。实现方案有两种一种是让飞机“跳”到手指位置另一种是相对位移。多数代码用第一种即把触摸点转换成游戏坐标然后直接更新飞机的位置。// Player.cpp 中触摸跟随的核心逻辑 bool Player::onTouchBegan(Touch* touch, Event* event) { auto location touch-getLocation(); // 把屏幕坐标转换成游戏世界坐标 auto gamePos Director::getInstance()-convertToGL(location); _targetPos gamePos; return true; } void Player::update(float dt) { // 平滑插值让飞机移过去而不是瞬移 auto currentPos getPosition(); auto delta _targetPos - currentPos; if (delta.length() 1.0f) return; // 限制飞行速度防止飞机“瞬移” float maxSpeed 600.0f; if (delta.length() maxSpeed * dt) { delta delta.getNormalized() * maxSpeed * dt; } setPosition(currentPos delta); }这段代码里最关键的是convertToGL。Cocos2D-X 的 UI 坐标系原点在左上角而 OpenGL 坐标原点在左下角convertToGL就是把触摸事件的屏幕坐标转换成游戏世界坐标。有不少人没做这步转换结果飞机上下方向反了或者触摸位置和飞机位置总是差一段距离。移动边界也很关键。想象一下玩家手指划到屏幕边缘飞机直接出了屏幕这就很出戏。边界限制通常放在update里做Size visibleSize Director::getInstance()-getVisibleSize(); float halfWidth getContentSize().width / 2; float halfHeight getContentSize().height / 2; // clamp 函数将位置限定在可视区域范围内 float clampedX clampf(_targetPos.x, halfWidth, visibleSize.width - halfWidth); float clampedY clampf(_targetPos.y, halfHeight, visibleSize.height - halfHeight); _targetPos Vec2(clampedX, clampedY);clampf是 Cocos2D-X 自带的数学函数比手写if判断简洁。参数方面要注意halfWidth和halfHeight用的是飞机的锚点尺寸如果锚点不在中心边界的计算就要调整。很多代码直接写死0和visibleSize.width导致飞机飞到边缘时有一半机身出屏。3.2 敌机与子弹对象池、刷新节奏与节点层级管理雷电类游戏的一大特点就是大量子弹和敌机同时存在。如果每个子弹都new一个对象碰撞后removeFromParent短期内频繁创建销毁会卡顿。常见的优化方案是对象池——预先创建一批子弹对象用的时候激活用完后回收复用。// BulletPool.cpp 的简化实现 class BulletPool { public: Bullet* getBullet() { // 先检查空闲列表 for (auto bullet : _idleBullets) { if (!bullet-isActive()) { bullet-setActive(true); return bullet; } } // 没有空闲的就创建一个新的 auto bullet Bullet::create(); bullet-setActive(true); bullet-retain(); // 手动管理内存防止自动释放 _idleBullets.push_back(bullet); return bullet; } void recycleBullet(Bullet* bullet) { bullet-setActive(false); bullet-stopAllActions(); bullet-setVisible(false); bullet-removeFromParent(); } };对象池的核心是retain和release的配对。Cocos2D-X 的节点被create()创建后是自动释放的如果你不从场景树里移除它它的内存会一直不被回收但如果你在回收时调用了removeFromParent就得小心引用计数。新手最常见的错误是回收子弹后还继续访问它导致野指针崩溃。敌机刷新节奏一般用“波次”控制。我在源码里见过做得很粗糙的版本直接schedule一个固定时间间隔每 2 秒生成一个敌机。这种做法的问题在于游戏后期难度没有提升。进阶的代码会引入波次结构比如// GameScene.cpp 中简单的波次控制 class WaveConfig { public: std::vectorEnemyType enemyTypes; float interval; // 敌机生成间隔秒 int count; // 本波次敌机总数 float preDelay; // 波次开始前延迟 };void GameScene::startNextWave() { _currentWave; if (_currentWave _waveConfigs.size()) { // 所有波次打完触发胜利逻辑 return; } auto config _waveConfigs[_currentWave - 1]; _spawnInterval config.interval; _spawnCount config.count; _spawnTimer 0.0f; }这样把“生成敌机”和“定义波次”解耦。调节难度只需要改配置文件不用改逻辑代码。如果你发现源码里敌机刷新都是一条直线往下飞建议在Enemy::update里增加飞行轨迹变量比如_movePattern表示直线、曲线或正弦波。节点层级也是被人忽视的点。子弹、敌机、道具、玩家飞机有没有合理的 zOrder 直接决定显示顺序是否正常。雷电游戏的通用层级是背景层 zOrder0子弹层 zOrder1敌机层 zOrder2玩家飞机 zOrder3弹幕层 zOrder4UI 层 zOrder10。如果你发现子弹从敌机上面飞过去多半是 zOrder 没调对。3.3 碰撞检测AABB 的最小实现与检测时序选择雷电游戏的碰撞对象有两类一类是子弹打敌机一类是敌机撞玩家。碰撞检测的方法很多但 2D 射击游戏最常用的是 AABB轴对齐包围盒也就是用矩形的相交判断。// CollisionUtil.cpp AABB 碰撞检测 bool CollisionUtil::isRectCollide(Node* a, Node* b) { Rect rectA a-getBoundingBox(); Rect rectB b-getBoundingBox(); return rectA.intersectsRect(rectB); }getBoundingBox会把节点的位置、锚点、内容尺寸算进去返回一个世界坐标下的矩形。这行代码虽然短但坑在于如果节点的setContentSize和实际精灵图片不一致或者有缩放效果碰撞区域就不准确。我见过一种常见做法是“缩小碰撞盒”因为飞机图片大多是带翅膀的视觉上翅膀碰到了敌机但玩家的核心机身还没碰到。如果直接用精灵原图做碰撞玩家会觉得“我没撞上怎么就死了”。这时候需要自定义碰撞区域// Player.cpp 中自定义碰撞区域 Rect Player::getCollisionRect() { auto pos getPosition(); float width 30.0f; // 比精灵图窄的碰撞宽度 float height 40.0f; // 比精灵图短的高度 return Rect(pos.x - width / 2, pos.y - height / 2, width, height); }碰撞检测的时序也很重要。是在update里遍历检测还是在fixedUpdate里检测Cocos2D-X 没有内置的物理引擎强制要求你选哪种但雷电这类高强度射击游戏推荐在update里做而不是依赖物理引擎。原因很简单物理引擎会带来额外的开销而且物理引擎的碰撞回调会延迟到下一帧对于需要即时反馈的射击手感来说不够直接。// GameScene.cpp update 中碰撞检测 void GameScene::update(float dt) { // 先更新所有子弹位置 for (auto bullet : _bullets) { bullet-updatePosition(dt); } // 再更新所有敌机位置 for (auto enemy : _enemies) { enemy-updatePosition(dt); } // 最后做碰撞检测 checkCollisions(); }这里有一个性能优化的点不要每对都检测那是一个 O(n*m) 的遍历。常见做法是先做一个粗略的筛选比如只检测同一屏幕范围内的对象或者先按 x 坐标排序只检测相邻的对象。雷电的游戏对象密度不算高直接双重循环也能跑 60 帧但如果你的项目里弹幕量大就要考虑空间划分了。3.4 音效与特效一次性加载还是延迟加载雷电游戏里音效是典型的“高频播放、低频切换”场景。子弹发射、敌机爆炸、道具拾取音效在短时间内会大量触发。很多新手直接把音效文件用AudioEngine::play2d每次都是现加载结果内存飙升播放还有延迟。合理做法是启动时预加载常用音效返回一个音频 ID之后播放时复用这个 ID播放快结束时再重新触发避免中断上一次播放造成刺耳的“咔咔”声。// GameScene.cpp 音效预加载 auto audio AudioEngine::getInstance(); // 假设是 Cocos2D-X 3.x 的 AudioEngine int shootSoundId AudioEngine::play2d(sounds/shoot.mp3, false, 0.5f); AudioEngine::stop(shootSoundId); // 预加载完先停掉 // 后面射击时 AudioEngine::play2d(sounds/shoot.mp3, false, 0.5f);play2d的三个参数文件路径、是否循环、音量。音效文件不建议用mp3推荐wav或ogg因为 mp3 解码有延迟触发瞬间容易“慢半拍”。而爆炸这种长时间音效可以用 mp3 或 m4a。这段经验是某开发者总结的他接手雷电源码后第一件事就是把所有音效转成 ogg 格式。特效方面雷电游戏的爆炸效果通常用 Cocos2D-X 自带的 ParticleSystemQuad 实现。常见做法是在敌机死亡时创建一个粒子对象播完自动移除。注意粒子的纹理文件要放在 Resources 里并且setAutoRemoveOnFinish显式开启否则粒子播完却留在节点树上内存只增不减。// Enemy.cpp 爆炸特效 void Enemy::onDead() { auto particle ParticleSystemQuad::create(explosion.plist); particle-setPosition(getPosition()); particle-setAutoRemoveOnFinish(true); getParent()-addChild(particle, 10); // 移除自身 removeFromParent(); }ParticleSystemQuad::create读取的是.plist文件里面定义了粒子数量、生命周期、速度、颜色等参数。如果你感觉爆炸效果不够震撼优先调粒子数量maxParticles和颜色渐变得startColor/endColor不要去改粒子尺寸缩放效果反而假。4. 多分辨率适配与资源规范雷电游戏画面在不同手机上的“不花屏”法则4.1 为何“PC 上正常、手机上缺一块”的本质是分辨率策略雷电游戏的竖屏特性决定了它在不同宽高比手机上的表现差异巨大。早期的安卓手机是 16:9后来出现 18:9、20:9甚至折叠屏。如果代码里用的ResolutionPolicy::SHOW_ALL那么在 20:9 的屏幕上游戏画面会居中显示但左右两侧是黑边或者上下被拉伸。有人会觉得黑边难看于是改成NO_BORDER结果画面被裁掉玩家飞机飞到边缘时直接出画。我在某个雷电代码包里看到它的AppDelegate写的是EXACT_FIT。这种策略会把整个游戏画面拉伸到填满屏幕导致图片看起来“变扁了”或者“被拉长了”飞机圆形的机翼变成椭圆这非常出戏。所以代码的默认设置并不总是合理的你拿到的源码可能只是为了在 PC 上演示效果设置的。合理方案是保持SHOW_ALL然后在画面四周加上动态背景延伸层。让背景图的宽度大于设计分辨率宽度高度也大于这样才能在裁切时看到更多的背景而不是黑边。// 背景层适配让背景图铺满整个屏幕 void GameScene::setupBackground() { auto bg Sprite::create(bg_night.png); Size visibleSize Director::getInstance()-getVisibleSize(); Vec2 origin Director::getInstance()-getVisibleOrigin(); // 等比缩放背景确保覆盖屏幕 float scaleX visibleSize.width / bg-getContentSize().width; float scaleY visibleSize.height / bg-getContentSize().height; float scale MAX(scaleX, scaleY); bg-setScale(scale); bg-setPosition(visibleSize.width / 2 origin.x, visibleSize.height / 2 origin.y); addChild(bg, 0); }这里的关键点是MAX(scaleX, scaleY)用较大的缩放值保证任何方向都不会出现露底。如果你用MIN就可能在上下或左右留出透明空隙。背景层是游戏中最底层露出的空隙如果是纯黑或者纯白那就非常显眼。4.2 坐标体系逻辑分辨率、屏幕坐标与 UI 坐标的关系雷电游戏的代码里坐标转换是无处不在的。Cocos2D-X 的逻辑坐标原点在左下角getPosition()返回的是节点在父节点坐标系中的位置而触摸事件getLocation()返回的是 OpenGL 坐标。这些如果在不同分辨率下混用就会出现飞行位置和实际渲染位置不一致。// 触摸坐标转换示例 Vec2 glPosition Director::getInstance()-convertToGL(touch-getLocation()); Vec2 nodePosition this-convertToNodeSpace(glPosition);第一行把触摸的屏幕坐标转成 GL 坐标第二行把 GL 坐标转成当前节点坐标系下的坐标。如果你处理的是 UI 控件的触摸回调UI 控件内部已经做了坐标空间转换不需要再手动转。如果你在Layer里自己写触摸监听就必须显式调用。很多雷电源码里玩家飞机的触摸处理是写在GameScene里的GameScene 是一个Layer其原点也在左下角。但如果你在 UI 层放了一个关闭按钮按钮的回调里getLocation返回的坐标就不需要再转换因为按钮内部已经处理好了坐标空间。这是个很容易混的坑。4.3 纹理图集与内存控制雷电代码中资源加载的老大难问题雷电游戏的图片资源往往数量可观。敌人的不同形态、子弹的不同颜色、道具图标、UI 按钮加起来可能有上百张。如果每张图都单独加载游戏启动时 IO 压力大内存碎片也多。解决方案就是纹理图集TexturePacker 生成.plist.png。// 加载纹理图集 SpriteFrameCache::getInstance()-addSpriteFramesWithFile(game_texture.plist); auto enemy1 Sprite::createWithSpriteFrameName(enemy_01.png);addSpriteFramesWithFile会把图集里的所有帧提前加载到缓存之后用createWithSpriteFrameName按名字取用速度比Sprite::create(path/to/file.png)快不少。这里有一个隐藏好处同一张图集里的精灵可以合批渲染减少 OpenGL 绘制调用帧率更稳定。内存控制上要注意图集的总尺寸。Cocos2D-X 要求纹理尺寸是 2 的幂次方且最大到 4096x4096部分设备支持 8192但旧设备不支持。一个 4096x4096 的 RGBA 纹理大约占 64MB 内存。如果一张图集太大建议拆成多个 2048x2048 的图集并按功能分组ui.plist、enemies.plist、effects.plist。雷电代码里通常把道具和敌机放在一个图集里UI 单独一个图集这样在加载 UI 时可以按需加载避免一启动就把所有纹理读进内存。5. 避坑与常见问题雷电代码从 PC 到手机的五条实测踩坑记录5.1 手机运行花屏只有 PC 正常纹理压缩格式与内存对齐现象Windows 上一切正常打包到 Android 手机上运行部分图片出现拉伸变形、颜色错乱。 原因Cocos2D-X 在 Android 上默认使用 ETC1 纹理压缩格式但 ETC1 不支持透明通道Alpha 通道。雷电游戏的敌机、子弹、特效资源大多是 PNG 透明图ETC1 压缩后透明信息全部丢失看起来就是花屏。 解决把纹理格式改成 RGBA8888在cocos2d-x的引擎配置里找到纹理格式默认值或者使用UnPacking工具把资源预处理成不带 Alpha 通道的 JPEG Alpha 分离图。但最直接的做法是改引擎的Texture2D配置强制用 RGBA8888。在AppDelegate或platform/android的Java代码里可以设置glview-setPixelFormat。5.2 触摸反馈有延迟UI 坐标转换没做坐标系归一化现象飞机跟随手指移动但手指已经划到屏幕左边缘飞机才慢吞吞地移动到一半且方向偶尔相反。 原因触摸坐标没有经过convertToGL直接用event-getLocation()赋值给_targetPos导致坐标系不一致位置计算是错的。看似有延迟其实是目标点根本不在手指位置。 解决每次onTouchBegan/onTouchMoved里先调用auto location touch-getLocation(); Vec2 gamePos Director::getInstance()-convertToGL(location);如果代码里已经在使用ui::Widget的触摸回调要注意Widget的回调函数传递的坐标是 UI 控件的本地坐标不是全局坐标。我见过一份雷电代码在 Slot 机器上把这两种混用飞机走得歪歪扭扭。5.3 Android 返回键退出后再次进入崩溃AppDelegate 生命周期没有处理好现象按返回键退出游戏再重新打开直接闪退。 原因返回键默认会直接结束 Activity但 Cocos2D-X 的Director里的场景栈没有被正确清理。第二次启动时Director::getInstance()-runWithScene被再次调用之前残留的渲染状态导致崩溃。 解决在AppDelegate::applicationDidEnterBackground或applicationWillEnterForeground里显式暂停和恢复渲染循环。返回键的处理在cocos2d-x3.x 以上可以在AppDelegate::applicationDidFinishLaunching末尾通过EventDispatcher监听键盘事件auto listener EventListenerKeyboard::create(); listener-onKeyReleased [](EventKeyboard::KeyCode keyCode, Event* event) { if (keyCode EventKeyboard::KeyCode::KEY_BACK) { // 先清理场景栈再退出 Director::getInstance()-popToRootScene(); Director::getInstance()-end(); } };5.4 帧率初期 20FPS渲染批次被打爆节点没合并现象打一会儿子弹多了帧率骤降从 60FPS 掉到 20FPS。 原因每个子弹单独Sprite::create每个Sprite是一次单独的 draw call。手机 GPU 的 draw call 数量是有限的百来个子弹加敌机每一个都分开绘制自然卡成幻灯片。 解决把同一个纹理下的子弹合并到同一个SpriteBatchNode里。SpriteBatchNode可以把多个子节点的精灵绘制调用合成一次。雷电代码里适合用SpriteBatchNode包裹子弹和敌机前提是它们使用的纹理都在同一张图集里。auto batchNode SpriteBatchNode::create(game_texture.png); addChild(batchNode); // 之后创建子弹时 auto bullet Bullet::create(); batchNode-addChild(bullet);注意SpriteBatchNode有一个苛刻的前提所有子节点必须使用同一张纹理图集否则绘制报错或者失去合批效果。如果子弹和敌机在不同的图集里就必须拆成两个SpriteBatchNode。5.5 敌机消失瞬间碰撞判定失效遍历删除顺序和碰撞检测冲突现象子弹击中敌机后敌机已从场景树移除但子弹仍然打到“空气”有时玩家还会被已经死掉的敌机“撞死”。 原因removeFromParent之后敌机的内存还在因为引用计数还没到零但节点已经从场景树移除。碰撞检测如果用isVisible或getParent() nullptr没判断就会把已删除的敌机算进来反过来如果在遍历过程中直接删除索引越界导致逻辑混乱。 解决在碰撞检测前加一个有效性判断bool isActiveNode(Node* node) { return node-getParent() ! nullptr node-isVisible(); }删除时统一延迟到update末尾处理用unschedule或标记dirty不要在一帧中间删除否则后续遍历会访问到非法状态。6. 从雷电 Demo 走向完整产品三个改进点和代码级验证方法拿到一份能跑的雷电源码只是起点。真正让它成为一个能上线的小游戏我建议你先做三件事对象池改造、难度曲线、音效预加载验证。第一件事对象池改造不是只针对子弹敌机同样适用。原版源码里敌机死亡即removeFromParent这会在密集波次时造成频繁的内存分配和释放。把敌机也纳入对象池用setActive和setVisible来控制生存周期可以显著降低卡顿。验证方法很简单在 PC 上打开调试统计用Director::getInstance()-setDisplayStats(true)显示帧率和绘制数量连续打五分钟观察绘制数量是否稳定在一个区间内。如果绘制数量持续上升说明节点没有被正确回收。第二件事难度曲线。雷电游戏最重要的留存指标就是“难而不绝望”。你可以在GameScene里加一个全局的difficulty变量每波次更新一次void GameScene::updateDifficulty(int wave) { // 每隔 5 波敌机速度提升 10%生成间隔缩短 0.2 秒 _enemySpeed 80.0f * (1 wave / 5 * 0.1f); _spawnInterval MAX(0.3f, 1.5f - wave / 5 * 0.2f); // 第 10 波开始出现新敌机类型 if (wave 10) { _enemyTypes.pushBack(EnemyType::Type_Boss); } }这种参数化设计的验证方式是把波次数值临时调快 10 倍快速跑到 30 波看玩家飞机在满血情况下能否存活。如果存活时间过短说明曲线太陡需要回调指数或增加道具掉落。第三件事音效预加载。这个改进很小但体验巨大。在GameScene::onEnter里把所有常用音效用AudioEngine::play2d先播一次并立刻暂停确保文件已经被解码到内存之后每次射击按音节拍。从那以后我每次拿到别人的 Cocos2D-X 工程都强制自己先花半小时跑通 PC 和真机然后看一眼setDisplayStats的绘制数据再谈优化。做小游戏最怕在黑匣子里瞎调参数有了数据反馈很多“玄学”问题其实都能量化。希望这个雷电项目能成为你理解引擎渲染、碰撞和资源管理的窗口帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
