Question

本节将演示移动开发人员写入代码并构造游戏，以便让游戏运行更快的方法。本节的核心理念是游戏设计和优化实际上并不是分离的过程；您在设计游戏时做出的决定可以让游戏乐趣十足且运行流畅。

一个历史性的示例

您可能还记得一些老游戏，在这些游戏中，玩家每次只能在屏幕上射击一次，并且装弹速度取决于子弹是否打偏，而不是计时器。这种技术被称之为对象池 (object pooling)，它简化了内存管理，让程序运行更加流畅。

太空入侵者的创作者仅拥有非常少量的 RAM，他们必须确保程序无需分配超过可用的 RAM。如果他们让玩家每秒钟射击一次，并且提供 可以将装弹时间减少至半秒钟的动力恢复，那么在玩家尽快射击，并且所有射击都保持尽可能长的有效时间的情况下，就必须确保有足够的内存空间来分配大量爆弹。这可能给他们新的问题，因此，他们仅分配了一颗爆弹，仅此而已。如果爆弹爆炸，它只会变得无效，并在再次射击时复位并激活。但是，它始终在内存中位于同样的空间，而不会到处移动或不断地删除和重建。

优化，或是最佳游戏设置？

这很不现实，但却非常有趣。当外星入侵者接近地面的高潮时刻，压力会不断释放，就像电影或文学作品的高潮部分。入侵者的贴近给熟练的玩家接近瞬时的装弹速度，允许玩家力挽狂澜，通过在完美的时机扣动射击键，保卫地球。交互式叙事方式以及提供 动力的背景技术之间的奇幻空间采用了精良的游戏设置。事实上，要规划这样精良、有效且富有乐趣的游戏并非易事，因为代码逻辑和玩家交互是两个截然不同且异常苛刻的方面，同时使用这两者合成新鲜有趣的游戏需要多方面考虑和反复试验。

您可能难以考虑到游戏的所有方面，同时规划游戏的交互并很好地利用移动硬件。这些双方和谐共处的“最佳设置”更有可能在您实验期间像一场事故一样突然出现。但是，深刻理解代码在您想要部署的硬件上的运行方式，将带来很大的帮助。如果想要了解详细的技术说明，证明技术池是更好的选择的，并了解更多内存分配的信息，请参阅脚本优化页面。

X 在移动设备上是否运行更快？

假设您正开始构建一个游戏，并且想通过大量的动作和闪亮的物体让玩家眼前一亮，应该如何进行规划？如何了解哪些地方存在限制，用游戏术语说，就是要多少金币，多少僵尸，多少对手车辆？这都取决于您如何为游戏编写代码。

一般而言，如果使用简单的方式或最为普遍或通用的方式编写游戏代码，您将更快遇到性能问题。越是依赖某种特定结构和技巧来运行游戏，就可以更好地扩宽视野，也可以在屏幕上呈现更多物体。

简单通用，但运行缓慢

• 在二维游戏中，刚体限制为 2 维。
• 爆弹刚体。
• 经常使用“实例化并摧毁 (Instantiate and Destroy)”。
• 大量单独的三维对象用于收藏或角色。
• 每一帧执行计算。
• OnGUI 用于 GUI 或 HUD。

复杂且受限，但运行更快

• 为二维游戏编写自己的物理代码。
• 自行处理爆弹碰撞检测。
• 使用“对象池 (Object Pooling)”而不是“实例化并摧毁 (Instantiate and Destroy)”。
• 粒子使用动画子画面代表简单的对象。
• 每隔几帧执行昂贵的计算，并缓存结果。
• 自定义 GUI 解决方案。

示例

同时在屏幕上呈现数百旋转、动态光照、金币收集。

• 不可以：每个金币都是一个附有刚体和脚本的独立对象，以旋转并允许拾起金币。
• 可以：金币是带动画纹理的粒子系统，一个脚本对所有金币进行碰撞检测，并按照它们与光源的距离设置颜色。
  • 这个示例在脚本优化页面实现。

您的定制软体模拟

• 不可以：这是一个枕头的世界，您可以到处乱扔并将其堆在一起。
• 可以：您的角色就是一个枕头，且只是其中一个，它所处的环境在某种程度上是可以预测的（它仅仅与球体和轴对齐立方体碰撞）。对于功能并非全面，但是外观精致运行快速的软体模拟，可以为其编写代码。

30 个敌人角色同时向玩家射击

• 不可以：每个敌人都有自己的蒙皮网格，拥有独立对象的武器，并在每次射击时实例化基于刚体的爆弹。在每帧运行的复杂的 AI 脚本中，每个敌人都考虑到其他同伴所处的状态。
• 可以：大部分敌人距离很远，并且由单个子画面作为代表；或者，敌人是二维角色且不管如何只有一对子画面。每颗敌人的子弹都由同样的粒子系统绘制，并由只由处理基础物理的脚本模拟。每个敌人都按照该区域内其他敌人的状态，每秒更新两次 AI 状态。

脚本优化的方式和原因

请参阅脚本优化。