我是一个相对的Objective-C菜鸟,所以请耐心等待。 Apple文档指出,让两个视图控制器控制单个视图并不是一个好主意。
我正在构建一个在单个视图中进行的游戏。我想创建可以将自己添加到主视图的对象(作为子视图)。可以将这些对象创建为视图控制器子类,还是必须将对象创建为NSObject
的子类并处理视图控制器中的所有视图和子视图?这就是我现在正在尝试做的事情,但它正在变成一个结构性混乱......
答案 0 :(得分:2)
这样的游戏设计的重要部分是确保将大部分逻辑放在游戏的数据模型中,而不是放在视图控制器或视图中。数据模型应该跟踪对象在游戏空间中的位置,它们应该具有哪些逻辑属性和视觉属性以及它们是否与其他游戏对象交互。
视图控制器的功能应该只是将每个对象的逻辑转换为视图。视图的唯一功能应该是笨拙地绘制控制器告诉它的内容。
例如:假设你有一个简单的游戏,有两个球从墙壁或彼此反弹。当他们与另一个球碰撞时,他们会改变颜色。每个球和每个墙将由数据模型中的单个对象表示。每个物体将负责在任何给定时间对球/墙的状态进行建模并确定其位置以及是否发生碰撞。
换句话说,除了实际显示外,数据模型应该处理有关游戏的所有内容。原则上,数据模型应完全独立于任何特定显示。您应该能够在标准视图,webview甚至命令行上玩游戏。
视图控制器的作用是将游戏对象的逻辑位置和逻辑状态转换为游戏屏幕上的子视图。例如。使用UIImageView显示球的图像。视图控制器只是告诉视图使用某个图形在屏幕上的某个位置绘制一个球。而已。随着数据模型的更改,视图控制器会更改绘制的内容,但它不记得上次绘制的内容或下次绘制内容的位置和位置。它只是反射数据模型。
要处理用户输入,它会反转将UI更改转换为数据模型输入的过程。但是,视图控制器不会计算这些输入的结果或结果。这是数据模型的工作。
通过将游戏的所有复杂逻辑放在数据模型中,您可以轻松更改视图控制器/视图对,以及添加,删除或修改许多不同视图。例如,您可能在iPhone,iPad和Mac上拥有相同的游戏。大多数代码在所有三个平台上都是相同的,但每个平台都有自定义的视图 - 控制器/视图对。
模型 - 视图 - 控制器非常重要,随着应用程序复杂性的增加,它变得越来越重要。当您尝试扩展应用程序时,很容易将控制器或视图中的大量数据和逻辑塞入过载并导致相互关系的缠结。首先编写数据模型。使数据模型能够仅使用文本输入来播放整个游戏。然后,只有这样,附加图形界面。如果您遵循这种模式,编写图形元素将非常简单并且非常灵活。
答案 1 :(得分:0)
您的子视图不应该是UIViewController
,而是UIView
。
答案 2 :(得分:0)
是的,您几乎总是需要子视图视图控制器来处理视图的细节。视图中的对象应该是UIViews或其子类。
答案 3 :(得分:0)
您希望UIViewController的一个子类管理整个屏幕。该控制器的视图可能是正在进行的所有事情的大容器。如果你想要其他控制器,只需为它们创建NSObject的子类,并让每个控制器拥有自己的UIView(这是主控制器视图的子视图)
不要让UIViewController的多个子类同时运行。你会得到各种古怪的行为,因为这是一个不受支持的设置。
答案 4 :(得分:0)
我会想象你正在编写一个吃豆人游戏,你的目标是使用主视图作为迷宫和这些子视图来代表你的游戏角色。
表示这种混合的一种方法是使用一个视图控制器(来自UIViewController的子类)来控制所有视图。这是完全合法的。因此,您的一个视图控制器负责您的主视图(迷宫)和子视图(字符)。
我建议您在这种情况下使用Core Animation,并将所有内容视为图层。这样,您只有一个视图支持所有层,并使用一个负责管理字符位置和用户输入的控制器。它应该大大简化你的生活。