【GAD翻译馆】Unity UI:要控制器还是不要控制器

发表于2017-09-03
评论0 711浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏美术行业精英群

167422913

翻译:赵菁菁(轩语轩缘)审校:李笑达(DDBC4747


      开发世界的基石之一是“最佳做法”的理念。由于编码与解决具体问题和建模期望结果的方式和灵活性一样重要,所以解决问题几乎没有一个单一的方法……也不应该有!而我们所面临的是一种向特定效率发展的趋势,如:编写最少的代码完成工作、使其可重复使用、确保它不会影响其他代码的正确性等等。当人们坚持认为他们的方法是唯一的出路时,最佳做法可能被滥用,因为任何代码的减少都会引起你应用程序的崩坏。但是最好的做法实际上是一大堆人的尝试和错误的升华,希望能给那些创造语言的人一点忠告。

      寻找“最佳方法”往往是困难的,有几个原因,首先是,通常没有最佳方法。每个人都喜欢用最适合他们的。有些人喜欢汽车,有些人喜欢摩托车,但两者都会把你带到你需要去的地方,所以谁真正在意呢?第二,通常开发者对于他们的知识真的很谨慎。有一些暗流,认为在开发中泄露的开发经验就像一个魔术师告诉人们这个戏法是怎么变的一样,不是因为它破坏了幻象,而是因为如果每个人都可以变同样的戏法,最初魔术师的价值就突然少了好多。

      这就是为什么我把这个想法抛出来,希望有人能至少分享他们自己的经验,因为它看起来更像我们所说的模式而不是方法。一种模式更像是一种心态,而不是一种实际的流动。模式是事情安排的方式,这样你就可以实际去做了。在这种情况下,我希望找到在Unity中构造和控制用户界面的建议。

      在我谈到手头上的问题之前,还需一点点引言。就我使用Unity UI的方式而言,我看到了两种连接交互的方法。第一种方法是让UI本身处理与代码的交互,这些代码从游戏数据存储中输入和提取数据。第二种方法是将与数据存储交互的代码集中起来,然后在UI上编写另一个脚本来处理UI本身。然后,这些脚本相互通信以传递数据。


选项一:直接脚本界面

      第一种选择可能是最直接和最容易概念化的。Unity UI系统可以让我们绘制一个框,比如说包含文本输入字段的框(在我们的例子中)。为了把这个数据存入游戏数据库中,这样我们就可以把数据应用在其他地方,我们需要认识到文本框的存在。

      绘制用户界面后,我们将脚本附到它身上。这个脚本有一些属性,用来保存到UI元素的引用,如文本框(和用于把数据提交到数据存储区的按钮)。当脚本接收从表单读取数据的命令时,它引用这些属性以便读取内容。它会从文本框中取数据,并“做些什么”——把数据发送到游戏的另一部分,或放入数据库或什么的。

      这样的好处是,用户界面是完全能够自给自足。我们可以把代码复制并粘贴到其他地方,工作原理完全相同,这是Unity最大的优点之一。这也更容易管理,因为我们只需要去找到源—— UI元素——我们就可以访问视觉效果和代码。     

      这样做的缺点是我们会有很多重复的代码。在任何我们想要相似但稍有不同的行为的时候,我们都需要修改底层代码,然后添加一个对其他UI的引用。这也意味着我们不能很容易地利用全局模式如单例模式,单例模式保证数据的一致性,而不必去“回到”一个后端系统。最后,如果我们有一个脚本来处理几个UI元素,那么我们将要处理很多与UI元素绑定的属性,这可能使管理成为噩梦。


选项2:MVC风格的界面

      这个选项比较复杂,所以在我解释图的时候请耐心听我说。

      首先,MVC是一种被称为“模型-视图-控制器”的模式,它将展现放在“视图”中,逻辑放在“控制器”中,并使用“模型”表示两者之间传递的数据。这里,UI有一个控制器。这是一个游戏对象,集中了很多行为捆绑起来方便表达的目的。这里,UI控制器将是这个或所有场景UI元素的基础。我们有管理场景中窗体的脚本,也有处理UI元素(文本框、按钮等)的脚本。

      这里的区别在于,这个脚本需要与一个更全局的场景控制器上的另一个脚本进行通信。场景控制器就像来自原始TRON的MCP:它可以访问你可能需要的一切,仅仅是挂在空间中,无论何时何地,只要你需要,都可以轻松访问。

      这种方法的好处是场景控制器是全看全知的。它不仅适用于UI,也适用于游戏的其他元素。此外,合并后它还可以实现单例模式,同时告诉Unity不要在场景转换时破坏对象,为我们提供了一个持久的数据管道。

      至于坏处?太乱了,而且复杂。从技术上讲,这张图可以稍微变形一点。例如,UI不需要它自己的控制器,而界面脚本可以依赖我们需要与场景控制器通信的每个UI的顶层元素(“画布”)。我们也可以避开场景控制器本身,使UI控制器处于数据存储交互的最高水平,虽然我们会失去数据一致性,但除非当我们在场景间移动时有一些地方的单例没有被销毁。


结论

      所以我们确实有我的难题。作为这一领域的业余开发者,我不确定哪个是最好的选择。我以前使用的是更复杂的方法,但是现在我看到了编码中的东西,我正在考虑尝试不那么复杂的方法,尽管我不知道沿着这条小路走会遇到什么陷阱。

      还有其他方法吗?我很想听听那些曾与Unity UI合作并愿意提供建议的开发人员的意见!


 【版权声明】

原文作者未做权利声明,视为共享知识产权进入公共领域,自动获得授权;

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台