RPG 游戏循环和类结构(cocos2D for iPhone) [英] RPG Game loop and class structure (cocos2D for iPhone)

问题描述

我希望在 iPhone 上使用 Cocos2D 制作 RPG.我做了相当多的研究，我真的很喜欢 Cocos2D 用于场景的模型.我可以实例化一个场景，设置我的角色等等，一切都非常好……我遇到的问题是构建一个游戏循环并将代码与场景分开.

I'm looking to make an RPG with Cocos2D on the iPhone. I've done a fair bit of research, and I really like the model Cocos2D uses for scenes. I can instantiate a scene, set up my characters etc. and it all works really nicely... what I have problems with is structuring a game loop and separating the code from the scenes.

例如，我应该将用于在多个场景中保持游戏状态的代码放在哪里?我是否将在场景中触发的事件的代码放在该场景的类中?还是我有一些其他类将初始化代码与逻辑分开?

For example, where do I put my code that will maintain the state of the game across multiple scenes? and do I put the code for events that get fired in a scene in that scene's class? or do I have some other class that separates the init code from the logic?

另外，我读过很多提到改变场景的教程，但我没有读过关于更新场景的教程——从用户那里获取输入并基于此更新显示.这发生在场景对象中，还是在单独的显示引擎类型类中.

Also, I've read a lot of tutorials that mention changing scenes, but I've read none that talk about updating a scene - taking input from the user and updating the display based on that. Does that happen in the scene object, or in a separate display engine type class.

提前致谢！

推荐答案

听起来你应该好好阅读一下 模型-视图-控制器 模式.您不必拘泥于它(例如，在某些情况下，允许模型和视图之间有一些重叠是有意义的)，但是对它有很好的理解将有助于您构建任何具有大量图形对象的程序和控制它们的逻辑，以及广播状态或将其保存到光盘(游戏保存)等的需要.

It sounds like you might do well to read up on the Model-View-Controller pattern. You don't have to adhere slavishly to it (for example, in some contexts it makes sense to allow some overlap between Model and View), but having a good understanding of it will help you to build any program that has lots of graphical objects and logic controlling them, and the need to broadcast state or persist it to disc (game save), etc.

您还必须意识到 cocos2d 提供了一个很好的系统来构建图形场景图并有效地渲染它，但它并没有为编程游戏提供完整的基础设施.从这个意义上说，它更像是一个图形引擎而不是游戏引擎.如果你试图让你的游戏架构适应 cocos2d 的结构，你最终可能不会得到最可维护的结果.相反，你应该把 cocos2d 当作它本来的样子:一个很好的工具来处理你的显示和动画需求.

You also have to realize that cocos2d provides a good system for structuring the graphical scene graph and rendering it efficiently, but it doesn't provide a complete infrastructure for programming games. In that sense it's more of a graphics engine than a game engine. If you try to fit your game's architecture into the structure of cocos2d, you might not end up with the most maintainable result. Instead, you should treat cocos2d as what it is: a great tool to take care of your display and animation needs.

除了保持游戏状态的场景之外，你肯定应该有一个对象，否则当你在场景之间切换时，所有状态会去哪里?在场景/关卡中，您应该简单地尝试使用良好的面向对象设计来将状态分布在各种类的对象上.每个角色对象都会记住自己的状态等.在这里您可以看到 MVC 的用处:当您将游戏保存到光盘时，您想要记住每个角色的健康水平，但可能不记得精灵动画显示的确切帧索引.所以你需要区分sprite和character(模型)本身.也就是说，正如我之前提到的，对于没有很多附加逻辑的游戏对象，或者不需要保存的游戏对象，只需将模型和视图融合到一个类中就可以了(基本上是通过继承 CCSprite).

You should definitely have an object other than the scenes that maintain the game state, because otherwise where will all the state go when you switch between scenes? And within scenes/levels, you should simply try to use good Object Oriented design to have state distributed over objects of various classes. Each character object remembers its own state etc. Here you can see where MVC becomes useful: when you save the game to disc, you want to remember each character's health level, but probably not which exact frame index the sprite animation was showing. So you need to distinguish between the sprite and the character (model) itself. That said, as I mentioned before, for game objects that don't have a lot of logic attached to them, or which don't need to be saved, it might be ok to just fuse the Model and View together into one class (basically by subclassing CCSprite).

要以应有的方式实现 MVC，您还应该学习 键值观察.(而且你最好使用 这个替代品对于 Apple 的界面.)在更激烈的实时游戏中，这样的技术可能会太慢，但由于您正在制作 RPG(开始时的好选择)，您可能会牺牲性能以获得更易于维护的架构.

To pull off MVC the way it's supposed to be, you should also learn the basics of Key-Value Observing. (And you'd do well to use this replacement for Apple's interface.) In more intensely real-time games, techniques like this might be too slow, but since you're making a RPG (good choice for starting out) you could probably sacrifice performance for a more maintainable architecture.

游戏场景(只是另一个 cocos2d 精灵)在 MVC 模式中扮演控制器的角色.它自己不绘制任何东西，而是告诉其他所有东西根据输入和状态绘制自己.将各种逻辑和功能放入游戏场景是很诱人的，但是当您注意到它膨胀时，您应该问自己如何将这些功能分离到其他类中.分析您正在实现的功能类型.它与数据和状态(模型)有关吗?还是关于动画和渲染(视图)?还是将逻辑与渲染联系起来(在这种情况下，您应该尝试让 View 直接观察 Model)?

The game scene (which is just another cocos2d sprite) plays the role of Controller, in terms of the MVC pattern. It doesn't draw anything itself, but tells everything else to draw itself based on inputs and state. It's tempting to put all kinds of logic and functionality into the game scene, but when you notice that it swells, you should ask yourself how you could separate that functionality into other classes. Analyze which type of functionality you're implementing. Is it to do with data and state (Model)? Or is it about animation and rendering (View)? Or is it about connecting logic with rendering (in which case you should try to make the View observe the Model directly)?

游戏场景/控制器基本上是一个调度中心，它接受输入事件(例如，来自用户或来自报告他们击中某物的精灵)并决定如何处理它们:它可能会告诉一个或几个例如，模型对象以某种方式更新自己，或者它可能只是触发其他一些精灵中的动画.

The game scene/Controller is basically a dispatch center, which takes input events (from the user or from sprites reporting that they've hit something, for example) and decides what to do with them: it might tell one or several of the Model objects to update themselves in some way, or it might just trigger an animation in some other sprites, for example.

在实时游戏中，场景中有一个tick"或step"方法，它告诉所有对象进行自我更新.这个方法(游戏循环)是程序的核心，每次绘制新帧时都会运行.(在现代游戏引擎中有很多多线程，但我们不要考虑这一点.)但在您的情况下，您可能想要创建一个可以玩游戏"完全独立于游戏场景的模块.想象一下，创建一个可以通过终端下棋的程序，只使用文本输入.如果您以这种方式创建整个游戏系统，然后通过小而干净的界面将其连接到图形引擎，那么您将拥有一个真正可维护的应用程序，其中包含大量可重用的代码供将来的项目使用！

In a real-time game, you'd have a "tick" or "step" method in the scene which tells all objects to update themselves. This method (the game loop) is the heart of the program and is run every time a new frame is drawn. (In modern game engines there's a lot of multi-threading but let's not think about that.) But in your case, you might want to create a module that can "play the game" completely separate from the game scene. Imagine creating a program that can play chess through the terminal, using only text input. If you create the whole game system in that manner, and then connect it to the graphics engine through a small and clean interface, you'll have a really maintainable app with lots of reusable code for future projects!

一些好的经验法则:模型(数据)不应该知道关于精灵或显示状态的任何事情；视图(精灵)不应该包含任何游戏的实际逻辑(游戏规则)，而只知道如何做一些简单的事情，比如在发生复杂事情时如何移动和弹跳以及向场景报告.只要有可能，视图应该直接对模型中的变化做出反应，而无需控制器干预.

Some good rules of thumb: the model (data) shouldn't know anything about sprites or display states; the view (sprites) shouldn't contain any of the game's actual logic (the game rules) but only know how to do simple things like moving and bouncing and reporting to the scene if something complicated happens. Whenever possible, the view should react to changes in the model directly, without the controller having to interfere.

这篇关于RPG 游戏循环和类结构(cocos2D for iPhone)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！