小编Sul*_*vus的帖子

我正在尝试为SceneKit iOS游戏设计一个架构.我已经在下面展示了我目前偏好的两个粗略 的高级对象图/图表.

我目前只关注高级架构,即管理Menu/GameLevel/Config/Paused应用状态之间的转换,并使应用程序数据驱动,以便它可以处理多个级别等.一旦我开始工作,然后我将解决较低级别的体系结构,例如对于GameLevel状态,我将有一个GameLevelModel对象来表示实际的游戏级别逻辑.

很高兴听到哪一个看起来更有前途,任何明显的陷阱或要避免的事情？

版本A)基于MVC,具有自定义容器和嵌套VC

我试图与这个版本保持接近MVC范式.

应用程序的行为在其不同状态(Menu/GameLevel/Config/etc)之间发生显着变化,因此我将使用永久容器视图控制器,该控制器将根据Apple的父子关系在多个嵌套的VC之间进行管理/转换"适用于iOS的View Controller编程指南".这些将是有效的整个MVC.

因为Apple的容器控制器(UINavigation-,UISplitScreen-,UITabBar-)都不合适(我需要整个屏幕),所以我将拥有一个自定义容器VC(RootViewController),它将始终具有一个嵌套子VC.每个孩子VC的视图将始终完全覆盖容器的一个.子VC之间的转换将由RootVC管理并由其StateMachine驱动.

每次子VC(实际上是整个MVC)在每次相应的状态变为当前状态时被创建,然后在被替换为下一状态且不再需要时被解除分配.类似于UINavigationController如何处理它包含的VC.

我唯一担心的是这种架构看起来有点沉重.SceneKit看起来像是设计用于单个 SCNView,并在我们需要更改3D内容时在多个SCNScenes之间进行转换.这也提供了更多的过渡选项.

                         --------------------------
                         |   RootViewController   |
                         --------------------------
                           |  |   |        |    |
     ------------------    |  |   |        |    |      ------------------
     | GameLevelsData |-----  |   |        |    -------|     SCNView    |
     ------------------       |   |        |           ------------------
     ------------------       |   |        |
     |   PlayerData   |--------   |        |
     ------------------           |        |
                                  |        |
                       ----------------    |
                       | StateMachine |    |
                       ----------------    |
                         |                 |
                         |-(*MenuState)    |
                         |-(LevelState)    |
                         |-(ConfigState)   |
                                           |
                                           |
                         ------------------------ …