mac*_*_55 6 iphone class-design objective-c cocos2d-iphone
我想在iPhone上用Cocos2D制作一个RPG.我做了很多研究,我非常喜欢Cocos2D用于场景的模型.我可以实例化一个场景,设置我的角色等等,这一切都非常好......我遇到的问题是构建一个游戏循环并将代码与场景分开.
例如,我在哪里放置能够在多个场景中保持游戏状态的代码？我是否将那些在场景类中的场景中被触发的事件的代码放入？或者我有一些其他类将init代码与逻辑分开？
另外,我已经阅读了很多提及改变场景的教程,但是我没有读过任何关于更新场景的内容 - 从用户那里获取输入并基于此更新显示.这是发生在场景对象中还是在单独的显示引擎类型类中.
提前致谢!
Fel*_*xyz 14
听起来你可能会很好地阅读模型 - 视图 - 控制器模式.你不必盲目地坚持它(例如,在某些情况下,允许模型和视图之间有一些重叠是有意义的),但是对它有一个很好的理解将帮助你构建任何有很多图形对象的程序和控制它们的逻辑,以及广播状态或将其保存到光盘(游戏保存)等的需要.
您还必须意识到cocos2d提供了一个良好的系统来构建图形场景图并有效地渲染它,但它没有为编程游戏提供完整的基础结构.从这个意义上说,它更像是一个图形引擎而不是游戏引擎.如果您尝试将游戏架构融入cocos2d的结构中,您可能无法获得最可维护的结果.相反,你应该将cocos2d视为它是一个很好的工具来处理你的显示和动画需求.
除了保持游戏状态的场景之外,你肯定应该拥有一个对象,否则当你在场景之间切换时,所有的状态都会去哪里？在场景/级别中,您应该只是尝试使用良好的面向对象设计,使状态分布在各种类的对象上.每个角色对象都会记住它自己的状态等.在这里你可以看到MVC变得有用的地方:当你将游戏保存到光盘时,你想要记住每个角色的健康等级,但可能不是精灵动画显示的精确帧索引.所以你需要区分精灵和角色(模型)本身.也就是说,正如我之前提到的,对于没有附加大量逻辑的游戏对象,或者不需要保存的游戏对象,可以将模型和视图融合到一个类中(基本上通过继承CCSprite).
要按照预期的方式实现MVC,您还应该学习Key-Value Observing的基础知识.(并且你可以在Apple的界面上使用这个替代品.)在更加强烈的实时游戏中,这样的技术可能太慢,但是因为你正在制作一个RPG(开始的好选择)你可能牺牲性能以实现更易维护的架构.
根据MVC模式,游戏场景(只是另一个cocos2d精灵)扮演控制器的角色.它本身并没有绘制任何东西,而是根据输入和状态告诉其他所有东西.将各种逻辑和功能放入游戏场景是很诱人的,但是当你注意到它膨胀时,你应该问问自己如何将该功能分成其他类.分析您正在实施的功能类型.它与数据和状态(模型)有关吗？或者它是关于动画和渲染(查看)？或者是关于将逻辑与渲染连接(在这种情况下,您应该尝试使View直接观察模型)？
游戏场景/控制器基本上是一个调度中心,它接收输入事件(例如来自用户或来自报告他们已经击中某些东西的精灵)并决定如何处理它们:它可能会告诉一个或几个模型例如,对象以某种方式更新自己,或者它可能只是在其他一些精灵中触发动画.
在实时游戏中,你在场景中有一个"tick"或"step"方法,它告诉所有对象自己更新.此方法(游戏循环)是程序的核心,每次绘制新帧时都会运行.(在现代游戏引擎中有很多多线程但我们不考虑这一点.)但在你的情况下,你可能想要创建一个可以"完全独立于游戏场景"玩游戏的模块.想象一下,只使用文本输入创建一个可以通过终端下棋的程序.如果你以这种方式创建整个游戏系统,然后通过一个小而干净的界面将它连接到图形引擎,你将拥有一个真正可维护的应用程序,为未来的项目提供大量可重用的代码!
一些好的经验法则:模型(数据)不应该知道关于精灵或显示状态的任何信息; 视图(精灵)不应该包含任何游戏的实际逻辑(游戏规则),但只知道如何做简单的事情,如移动和弹跳以及如果发生复杂事件而向场景报告.只要有可能,视图应直接对模型中的更改做出反应,而控制器不得干涉.
| 归档时间： |
|
| 查看次数： |
3300 次 |
| 最近记录： |