单例模式：当很多人第一次接触游戏制作引擎时，她们会遭遇情景转换不容易毁坏数据信息的难题。不建议一些新手犯在当地储存数据信息，随后在下一个情景中载入的不正确。这类立即存取数据是不可取的，如果你想储存一个游戏目标时，没有办法(自然，你能实例化这一目标并在当地储存它，但这依然是不可取的)。这时，最好是将其储存到一个全局性静态数据目标/自变量中，这将导入单例模式。除此之外，比如，一些系统软件只有有一个内容，它是不允许随意应用的，不然会出現不正确，如典型性的文档I/O和控制板键入操纵。

数据驱动：在统一的脚本制作目标中，它显而易见是数据驱动的，它的核心内容是不在更改编码的状况下更改数据信息。当您要想应用数据驱动时，您务必区别什么是硬编码的，什么是数据驱动的。过少的配备会危害开发设计高效率和易读性。

降低表针自动跳转耗费：我觉得它是ECS明确提出的缘故之一。在大型网络游戏中，有很多的手机游戏目标。这时，由手机游戏目标中的各种各样表针弹跳造成的特性耗费不可以被忽视。因而，在撰写编码时，大家应当留意降低表针自动跳转，尽量使运行内存持续遍布，例如应用构造和数组。自然，持续的内存分配还可以降低运行内存残片。

原型模式：这好像早已在Cocos2d-x中见到过，而且应用了一个插口来复制当今目标。实际上，这在具体游戏里面很普遍。比如，在GBA的木叶之战中，鸣人能够应用身影化身为造就一个新人物角色，可是进攻抗压强度和血条递减。在Unity中，当从新项目对话框拖拽到情景时(很有可能)，预置也应用了相近的念头。

它是大量的工作经验，我不能说它做得非常好。维持编码可读，便于您或别人之后回家时能够阅读文章。必须维持单一的职责义务。如果你发觉一些编码被反复写了几回，你应该考虑到是不是应当把它放进一个涵数中。你务必搞清楚的是，不正确将始终存有，总有一天你或别人会再次阅读文章这种编码。假如您在撰写时略微留意一下，之后的维护保养和器重可能相对性简易和非常容易。