RPG游戏循环和类结构（cocos2D for iPhone） [英] RPG Game loop and class structure (cocos2D for iPhone)
问题描述
我想在iPhone上做Cocos2D的RPG游戏。我做了一些公平的研究，我真的很喜欢Cocos2D用于场景的模型。我可以实例化一个场景，设置我的字符等，它一切工作真的很好...我有问题是构建一个游戏循环和分离的代码从场景。
例如，我在哪里放我的代码，将保持游戏的状态跨多个场景？并且我把放置在场景的类中的场景中触发的事件的代码？或者我有一些其他类将init代码和逻辑分开吗？
此外，我已经阅读了很多教程，提到改变场景，读取没有谈论更新场景 - 从用户取得输入并基于此更新显示。
提前感谢！
听起来你可能会在模型 - 视图 - 控制器模式。你不必吝啬地（例如，在某些上下文中允许模型和视图之间有一些重叠是有意义的），但是有一个很好的理解它将帮助你建立任何程序有很多图形对象和逻辑控制它们，需要广播状态或持久化到盘（游戏保存）等。
你还必须意识到cocos2d提供了一个好的系统构建图形场景图并有效地渲染它，但它不提供用于编程游戏的完整基础设施。在这个意义上，它更多的是一个图形引擎而不是一个游戏引擎。如果你试图将游戏的架构适合cocos2d的结构，你可能不会得到最可维护的结果。相反，你应该把cocos2d当做它是一个伟大的工具来照顾你的显示和动画的需要。
你应该肯定有一个对象，而不是场景保持游戏状态，因为否则在所有的状态去，当你在场景之间切换？在场景/级别中，您应该简单地尝试使用良好的面向对象的设计来使状态分布在各种类的对象上。每个字符对象都记住自己的状态等。在这里你可以看到MVC的有用的地方：当你保存游戏到光盘，你想记住每个字符的健康水平，但可能不精确的帧索引sprite动画显示。因此，您需要区分 sprite 和字符（模型）本身。这就是说，正如我之前提到的，对于没有很多逻辑附加到他们的游戏对象，或者不需要保存，可能是确定将模型和视图一起融合成一个类基本上通过子类化CCSprite）。
为了拉开MVC，你还应该学习键值观察。 （您可以使用此替换对于Apple的界面）在更强烈的实时游戏中，这样的技术可能太慢了，但是因为你做了一个RPG（开始的好选择），你可能牺牲性能来维护一个更可维护的架构。 p>
游戏场景（这只是另一个cocos2d sprite）在MVC模式方面扮演了Controller的角色。它不绘制任何东西本身，而是告诉一切，基于输入和状态绘制自己。将各种逻辑和功能放入游戏场景是很诱人的，但是当你注意到它膨胀时，你应该问自己如何将该功能分离到其他类中。分析您要实施的功能类型。它是与数据和状态（模型）？还是关于动画和渲染（查看）？或者是关于连接逻辑与渲染（在这种情况下，你应该尝试让观察模型直接）？
游戏场景/控制器基本上是一个调度中心，它接受输入事件（来自用户或来自sprites的报告他们已经打了一些东西），并决定如何处理：它可能会告诉一个或几个Model对象以某种方式更新自己，或者
在实时游戏中，你可能会在一个游戏中使用tick或step场景，它告诉所有对象更新自己。这个方法（游戏循环）是程序的核心，每次绘制一个新的框架时运行。 （在现代游戏引擎中有很多多线程，但是我们不要这么想。）但是在你的情况下，你可能想创建一个可以游戏完全独立于游戏场景的模块。想象一下，创建一个程序，可以通过终端，只使用文本输入下棋。如果你以这种方式创建整个游戏系统，然后通过一个小而干净的界面连接到图形引擎，你将有一个真正可维护的应用程序，大量的可重用代码为未来的项目！
一些好的经验法则：模型（数据）不应该知道关于精灵或显示状态的任何视图（sprites）不应该包含任何游戏的实际逻辑（游戏规则），而只知道如果发生复杂事情，如何做简单的事情，如移动和弹跳和向场景报告。只要有可能，视图就应该直接对模型中的变化做出反应，而控制器不必干涉。
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.
Thanks in advance!
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.
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.
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).
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.
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.
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屋！
