SpriteKit是否遵循MVC模式？

我目前正在开发一个名为Old Frank的iOS项目，该项目一直在尝试遵循MVC设计模式。

要点是。

GameObjects(model) <- Scene(controller) -> Sprites "SpriteKit" (View)

现在，如果我对MVC的理解正确，那么如果您想遵循MVC，就无法使用SpriteKit提供的许多功能。例如any SKAction，碰撞检测等。

难道不是取决于游戏对象所在的模型以及它们在触摸其他对象时应如何反应吗？确定模型是否随时间推移是否取决于模型？

除了渲染之外，SpriteKit是否有其他部分可以被认为可以用作MVC中的“视图”？

— 斯凯勒·劳伦（Skyler Lauren）
source

“我一直在尝试遵循MVC设计模式”-为什么？

— Paul D. Waite

@ PaulD.Waite我喜欢将模型分开的想法。从理论上讲，这使得在其他平台上移植或重新创建更加容易。这也使持久性的管理更加容易，这是迄今为止的最大原因。

— Skyler Lauren

知道了为了实现持久性目标，记忆模式可能比MVC更适用。您的sprite可能是发起者，它们有责任生成状态的可保存表示形式，并在以后从该表示形式还原自己。您的场景控制器可能是要求他们提供表示的东西。

— Paul D. Waite，2015年

这也可能会导致您的保存游戏可以在其他平台上使用，尽管我怀疑在使用仅限Mac / iOS的框架（如SpriteKit）时，就可移植性而言，这是可以做到的。

— Paul D. Waite，2015年

@ PaulD.Waite感谢您的评论，我将研究memento模式，作为将来要考虑的另一种模式。这两个问题是关于同一个项目的，是的，但无关。惊讶地看到另一个迁移到了stackoverflow，并且今晚晚些时候会再看他的答案=）

— Skyler Lauren

Answers:

您的问题是一个好问题。关于SpriteKit，我有完全相同的问题，并且对网络上缺乏有关此方面的信息感到非常困惑。SpriteKit似乎鼓励您将所有的Model-View-Controller代码放入同一个类（您的SKScene子类）中，这确实让我感到困惑。您将如何使用该技术构建任何复杂程度的游戏？除了简单的游戏之外，将游戏状态（得分，numLives等）与touchesBegan / Ended之类的控制器代码以及视图渲染结合在一起，确实很难管理。

我同意使用memento模式来帮助持久性是一个好主意，但是我也认为转向MVC设计可能是有益的。我目前正在将我的游戏迁移到MVC架构中。我当前的方法是让我的模型（游戏对象）管理PhysicalBodies，SKScene子类充当控制器，一个单独的类充当视图，以配置和渲染场景中SKNodes的视觉效果。我只是整个过程的一部分，所以不能肯定地说这是否是一个好的设计，但似乎比拥有10,000行的SKScene子类要好得多。

— 约翰·克利夫兰
source

感谢您的回答/评论。听起来您感觉使用SpriteKit的功能也不遵循MVC设计模式。随意如果您有关于如何“我”正在使用MVC疑问或想走得更进详细介绍了如何“你”正在使用MVC与SpriteKit =）给我发电子邮件skyler@skymistdevelopment.com

— 斯凯勒·劳伦

没有什么可以强迫您将大多数代码放入SKScene类中的。实际上，我发现使用SpriteKit时，大多数逻辑比场景更自然地落在Node上，因为Node是SpriteKit的首当其冲。场景只不过是用于处理节点树的更新和输入的“控制器”。尽管“ MVC”模型仍不匹配SpriteKit，但由于“节点”往往是“ M”和“ V”。

— Attackfarm 2015年

简单来说，SpriteKit游戏中的常见设计是场景，图层，节点和子节点。

您可以将每个零件制成一个离散的类，该类封装所有零件，属性和方法。

例如，一个具有分层图像，粒子，各种属性（如每层应移动的速度）的Background类以及用于启动和停止滚动背景的公共方法。

在此设计中，您将这些独立的类组装在一起，将各自完成的工作整合到场景中，该场景主要处理运行中的更新：，物理，触摸事件等。

— 杰里米
source