c# - Unity 中是否有 "Singletons"(持久游戏对象)的最佳实践？

Question

我对 Unity 相当陌生，事实上，C# 也是如此!

我现在正在做的是:

• 我有一个名为 GameManager 的“单例”(它不是真正的单例，但这不是重点)GameObject，它附加了我的 GameManager.cs 包含大部分游戏信息的脚本(已经显示了哪些教程文本、加载本地化文本的函数、加载的最后一个场景...)
• 作为这个 GameManager 对象的子对象，我有不同类型的游戏对象，我也不想在加载时销毁，例如后处理配置文件、全局灯光、音频管理器、UI Canvas (canvi？)和其他事情......

关于 Unity 有很多很棒的教程，而且这是一个很棒的社区，但我无法真正找到有关 Unity 关于游戏对象管理的“最佳实践”的任何信息。

这是正确的处理方法吗？我以后使用此方法会遇到问题吗？我是否应该创建一个实现 Unity 的 DontDestroyOnLoad() 的通用类，并让我想要保留的对象继承自该类？有更好的办法吗？

目前工作正常，但我想确保我没有以错误的方式执行此操作，并且可能会影响游戏的性能或稳定性。

提前非常感谢。

Answer 1

这里有两个最佳实践。

1. 构建大量单例，并替换Unity内置的初始化系统

2. 构建很少的单例，并在 Unity 的初始化系统中工作，并大量使用新的多场景编辑系统。

选项 1 非常受游戏工作室和专业游戏开发人员的欢迎，他们擅长这样做，并且之前已经做过很多次了。主要问题是，一旦您开始这条路线，您就必须致力于维护自己的并行初始化系统。主要优点是您的系统可能比 Unity 的内部系统更好，肯定更强大，而且通常更快(!)。

选项 2 更受游戏编程新手的欢迎，他们希望尽可能多地利用 Unity 的内置功能。<​​/p><小时/>

也就是说，你的问题中有一些奇怪的事情。

例如...... Canvas ？你究竟为什么要尝试将 Canvas 变成单例？这表明您在很大程度上滥用了 Canvas(可能还滥用了其他一些类)。

标准方法(也是 Unity 支持的唯一方法)是每个场景都有自己独特的 Canvas 。做一些不同的事情......是很奇怪的。

我怀疑您误解了“DontDestoryOnLoad”的作用。它并不能防止东西在加载时被破坏!

相反，它可以防止在加载新场景时被破坏，并且它们只存在于旧场景中。更好的名称应该是:“DontDestroyWhenLoadingANewScene”

Unity 中的 DontDestroyOnLoad 存在很多错误(可以追溯到很多年前)，因此一般来说最好尽可能避免它。对于简单的情况，它工作得很好，但如果你使用它太多，你就会遇到复杂的边缘情况以及与 Unity 自己的内部类的交互。