在某些情况下，全局变量/子集在游戏开发中有用吗？[关闭]

我知道拥有全局变量或单例类会创建很难测试/管理的案例，而我在代码中使用这些模式的工作已陷入困境，但常常需要交付。

那么在游戏开发中是否存在全局变量或单例实际上有用的情况？

这些东西总是有用的。到底是最漂亮还是最安全的解决方案是另一回事，但我认为游戏开发涉及一定程度的实用主义。

绝对不是穷举列表，但这里有：

缺点

• 终身管理。Singleton和Globals可能希望在初始化关键系统（例如堆）之前启动，具体取决于您如何设置它们。如果您想拆除它们（例如，在进行泄漏跟踪时很有用），则必须注意拆除顺序，或者开始接触诸如phoenix singletons之类的东西。（请参阅静态初始化顺序失败。）
• 访问控制。渲染应该只具有对游戏数据的const访问，而更新却不是const吗？使用单例和全局变量可能更难执行。
• 状态。正如Kaj所指出的那样，在非共享内存体系结构中，很难对功能进行分解和转换的单例完全起作用。对于其他类型的NUMA系统（访问非本地内存），它也可能会影响性能。单例通常表示集中状态，因此是通过纯度使转换变得容易的对立面。

赞成或反对

• 并发性。在并发环境中，单例可能会很麻烦（您必须考虑数据争用/可重入问题）或很幸运（更容易集中化并进行锁定和资源管理的推理）。诸如线程本地存储之类的东西的巧妙使用可以在某种程度上缓解潜在的问题，但这通常不是一个容易的问题。
• Codegen（取决于编译器，体系结构等）：对于朴素的首次使用时创建单例实现，您可能正在为每次访问评估一个额外的条件分支。（这可能加起来。）函数中使用的多个全局变量可能会使文字池膨胀。一种“所有全局结构”的方法可以节省文字池中的空间：结构的基址只有一个入口，然后在装入指令中编码偏移量。最后，如果不惜一切代价避免使用全局变量和单例，通常需要至少使用一些额外的内存（寄存器，堆栈或堆）来传递指针，引用甚至副本。

优点

• 简单性。如果您知道上面列出的缺点对您的影响不大（例如，您正在为单个CPU手持式平台在单线程环境中工作），则可以避免使用某些体系结构（例如前面提到的参数传递）。对于经验不足的编码人员，单例和全局变量可能更易于理解（尽管错误使用它们可能更容易）。
• 终身管理（再次）。如果您使用“全局结构”或除“首次请求创建”以外的某种机制，则可以轻松地读取并且可以对初始化和销毁​​顺序进行细粒度的控制。您可以在某种程度上将其自动化或手动进行管理（根据全局变量/单例的数量及其相互依赖关系来进行管理可能是有利的也可能是不利的）。

我们在掌上电脑游戏中经常使用“全局单例结构”。PC和游戏机名称往往较少依赖它们。我们将更多地转向事件驱动/消息架构。话虽这么说，PC /控制台标题仍然经常使用中央TextureManager。由于它通常包装单个共享资源（纹理内存），因此对我们来说很有意义。

如果您保持API相对整洁，则在需要时将其重构为单例模式可能不是很困难。

它们可能非常有用，尤其是在原型设计或实验实现期间，但是总的来说，我们更喜欢为管理器之类的结构传递引用，这样您至少可以对从何处访问它们进行控制。全局变量和单例变量的最大问题（我认为）是它们对多线程的不友好，并且使用它们的代码更难移植到非共享内存（例如SPU）。

我会说单例设计本身根本没有用。全局变量肯定是有用的，但是我宁愿看到它们隐藏在编写良好的界面后面，以便您不知道它们的存在。使用单例，您可以清楚地知道它们的存在。

我经常将全局变量用于需要整个引擎访问的事物。我的性能工具是一个很好的例子，我在整个引擎上都使用它来进行调用。调用很简单；ProbeRegister（），ProbeHit（）和ProbeScoped（）。他们的实际访问更加棘手，并且在某些情况下使用全局变量。

全局变量和单例实现不佳的主要问题是模糊的构造和解构错误。

因此，如果您使用没有这些问题或非常了解指针问题的原语。这样就可以安全地使用它们。

全局变量具有与goto相同的位置，因此不应一概而论，而应谨慎使用。

《Google C ++样式指南》对此有很好的解释。

全局变量在快速原型化在函数调用之间需要某种状态的系统时非常有用。一旦确定系统可以正常工作，就将状态移到一个类中，然后将功能放入该类的方法中。

单身人士对于给自己和他人造成问题很有用。引入的全局状态越多，代码正确性，维护性，可扩展性，并发性等问题就会越多。请不要这样做。

我倾向于建议使用带有自定义生存期管理的某种DI / IoC容器，而不要使用单例（即使您使用“单实例”生存期管理器）。至少那么很容易换出实现以方便测试。

如果您想要单例的内存节省功能，也许可以尝试使用flyweight设计模式？

http://en.wikipedia.org/wiki/Flyweight_pattern

就上述多线程问题而言，出于某种先见之明，应该很简单地为可能在线程之间共享的资源实现锁定机制。 http://en.wikipedia.org/wiki/Read/write_lock_pattern

单例是在早期原型中存储共享状态的好方法。

它们不是灵丹妙药，并且存在一些问题，但是对于某些UI /逻辑状态，它们是非常有用的模式。

例如，在iOS中，您使用单例来获取[UIApplication sharedApplication]，在cocos2d中，您可以使用它来获取对某些对象的引用，例如[CCNotifications sharedManager]，就我个人而言，我通常从[Game sharedGame]单例开始存储许多不同组件之间共享的状态。

哇，这对我来说很有趣，因为我个人从未遇到过单例模式的问题。我当前的项目是Nintendo DS的C ++游戏引擎，并且我将许多硬件访问实用程序（即VRAM Bank，Wifi和两个图形引擎）实现为单例实例，因为它们旨在包装全局C基础库中的函数。

仅当您拥有一个只有一个控制器但由多个模块处理的项目时。

例如鼠标界面。或操纵杆界面。或音乐播放器。或声音播放器。或屏幕。或保存文件管理器。

全球人要快得多！因此，它非常适合性能密集型应用程序，例如游戏。

单例是更好的全局，IMO，因此是正确的工具。

谨慎使用！