帮助逻辑地设置图层以实现良好的游戏设计（涉及 SpaceManager 物理、音乐和游戏逻辑）
我正在创建我的第一个 iPhone 游戏 - 我有 OOP 背景，特别是 C++ 背景，所以我有一些关于如何在保持功能的同时最好地逻辑设置图层的问题。
目前我希望我的游戏具有三个主要层：
- HUDLayer（屏幕上的所有静态对象都在这里 - 游戏控件、用户得分、暂停按钮等）
- PlayLayer（玩家、主游戏循环和所有游戏逻辑都在这里） ）
- 关卡层（玩家与之交互的关卡图像和关卡物理对象，以及特定于该关卡的背景音乐）
请注意，我在这里使用了“想要”这个词 - 因为在我的一生中，我必须不断地移动逻辑对象在 Cocos2d 和 spacemanagers 结构中工作。
下面只是我面临的一些问题，
- 我希望我的 PlayLayer 成为由导演加载的场景 - 但如果我这样做，那么所有 HUDLayer 对象都会被覆盖在 PlayLayer 后面，并且不会留在原处就像他们应该的那样，因此 HUDLayer 是我的场景，我必须这样做只是为了使其工作
- 我想在 LEVEL 层中播放背景音乐（通过 simpleAudioEngine playBackgroundMusic），因为我希望不同的级别有不同的音乐。到目前为止，我让背景音乐工作的唯一方法是将其放在最顶层，即本例中的 HUDLayer
- 因为事实上我必须使用 SpaceManagerCocos2d 对象的实例来创建物理体 - 看起来像我的关卡层必须被杀死并合并到我的 PlayLayer 中，否则我会在尝试检测玩家和关卡之间的碰撞时遇到一场噩梦。
我在这里遗漏了一些非常明显的东西吗？是否有我没有得到的对层的核心理解？我越来越觉得框架推动我在单个类中构建整个游戏，并且仅使用图层作为场景。
还有其他人遇到这些问题吗？我对游戏架构的理解是否错误？任何帮助将不胜感激。
预先感谢各位！
Im in the middle of creating my first iPhone game - I have a background in OOP and in particular C++ so I had some questions with regards to how best to logically setup layers while maintaining functionality.
Currently I WANT for my game to have three main layers:
- HUDLayer (All static objects on the screen are here - game controls, User score, pause button etc.)
- PlayLayer (The Player, the main game loop and all of the game logic here)
- Level Layer (The level images and the level physics objects that the player interacts with, and the background music specific to this level)
Notice I used the word WANT here - because for the life of me im constantly having to move logical objects around just to work within what appears to be Cocos2d's and spacemanagers structure.
Below are just some of the issues that I'm facing
- I would like for my PlayLayer to be the scene thats loaded by the director - but if I do that then all of the HUDLayer objects get covered behind the PlayLayer, and dont stay in place like they should, hence the HUDLayer is my scene and I have had to do that just to make it work
- I would like to play the background music (via simpleAudioEngine playBackgroundMusic) in the LEVEL layer because I want different levels to have different music. So far the ONLY way I have gotten background music to work is to have it in the TOP most layer i.e. in this case the HUDLayer
- Because of the fact that I have to use an instance of the SpaceManagerCocos2d object to create physics bodies - it seems like my level layer has to be killed and just incorporated within my PlayLayer otherwise im having a nightmare of a time attempting to detect collisions between the player and the level.
Am I missing something very obvious here? is there a core understanding of layers that Im just not getting? More and more I feel like im being pushed by the framework to build the whole game inside of a single class and just to use layers as scenes.
Is anyone else having these problems? Am I approaching the architecture of the game wrong? Any help would really be appreciated.
Thanks in advance guys!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，每个游戏都不一样。 cocos2d 论坛上有很多关于 架构，有些人喜欢使用 MVC 方法，有些人喜欢使用
Actor比喻包含物理对象等。这是我的方法：
CCLayer对象（GameLayer 和 HUDLayer）作为一个CCScene的子节点（游戏场景）。这些是“视图”对象。GameController单例（也存储在 GameController 中或单独的文件中）。您还可以子类化 CCScene 并将其称为您的控制器。GameLayer负责渲染游戏关卡和其中所有角色的图形；它还处理通过触摸事件获取游戏输入。HUDLayer放置在比 GameLayer 更高的 z-index 处，并且显然具有用于 HUD 和按钮的所有 CCSprite 对象。HUDLayer和GameLayer之间的交互通过 GameController 进行管理。GameController执行所有状态更改和游戏操作。这只是我的方法，因为它适用于我当前的游戏，但它绝不是最终的答案。
我建议您考虑使用
Actor范例 对于你的物理对象——SpaceManager 做得不错，但你不一定总是希望物理对象扩展 CCSprite。Well, each game is different. There are many good discussions on the cocos2d forums about architecture, some people prefer to use an MVC approach, some like using an
Actormetaphor to contain physics objects, etc.Here's my approach:
CCLayerobjects (GameLayer and HUDLayer) as child nodes of oneCCScene(GameScene). These are the "view" objects.GameControllersingleton that can make changes to the game state (also stored in GameController, or in a separate file.) You could also subclass CCScene and call that your controller.GameLayeris in charge of rendering the graphics of the game level and all actors in it; it also handles getting game input via touch events.HUDLayeris placed at a higher z-index than the GameLayer and obviously has all of the CCSprite objects for the HUD and buttons.HUDLayerand theGameLayeris managed via the GameController.GameControllerdoes all of the state changing and game actions.That's just my approach because it worked for my current game, and it by no means is the definitive answer.
I'd suggest that you look into using an
Actorparadigm for your physics objects -- SpaceManager does a decent job, but you don't necessarily always want physics objects to extend CCSprite.