去年，我决定学习编码并尝试制作一款太空主题的视频游戏。 长话短说：我还没有完成，但是我在Unity中做了很多工作。 很多时候，当您需要Unity中的功能时，您可以在YouTube上找到解决方案并使之适应您的目的。 但是，最令人满意的体验是我从整体上提出了自己的解决方案！
这就是我要谈论的内容：为自己找到解决方案，并学会热爱这一过程。 有人说失败不是成功的反面，而是成功的一部分。 当您尝试自己解决问题时，有时您的第一个解决方案无效。 也许这会教给您一些有关您的编码语言如何工作的知识。
当我尝试为游戏制作程序生成的小行星时，我从反复试验中学到了很多东西。 瞧，我发现如果我有恒星和小行星，那将有助于营造太空气氛。 我自己做所有事情，所以我必须以更少的开销来产生更大的影响。
我能够毫不费力地制造小行星。 我从脚本生成球体开始。 我认为，被污染的球体的集合看起来像一块块状的小行星。 生成具有随机尺寸，偏移和旋转的游戏对象是相当容易的。
（对于Unity发起人，我将简要解释游戏对象。游戏对象是Unity中的基本单位。游戏对象通常具有3D模型（称为网格），在该模型上应用了材质（或蒙皮），并且可以具有对撞机检测碰撞事件，它是用于物理计算的刚体，可以附加任意数量的脚本，这些脚本可以在事件（如碰撞或玩家输入）上触发，也可以在更新方法上运行-可能是FPS繁重的）
最初，我希望小行星在相对平坦的平面上绕着玩家飞行，以便玩家可以与它们互动。 我希望玩家能够像《 Gauntlet》中的角色一样操控船，并且我希望游戏体验与《小行星》相似。
我第一次尝试将小行星保持在玩家周围的区域中，涉及到创建一个带有碰撞器的巨型盒子（游戏对象（对于那些使用Unity的人来说）），该盒子将跟随玩家不可见，从而使小行星真正保持在边界内。 问题？ 这导致游戏以大约2FPS的速度运行！
回到绘图板！
我的下一个想法是使边界虚拟化。 我决定在每个小行星上创建一个自毁功能，该功能会在给定的时间和/或距离玩家一定距离后触发。 事实证明，对40个左右的对象进行距离检查要比渲染一个大型3D对象要少得多。
在我真的有时间调整该机制的参数之前，我让我的朋友过来，向他展示了我当时的项目。 当我运行游戏时，令我惊讶的是，有小行星在镜头前飞来飞去，并远远低于玩家，这并不是我最初的想法。 我的朋友认为这很酷，我必须同意。 我意识到，让小行星在垂直轴上的移动幅度超出了我的预期，从而意外地营造了一种氛围！
当我在项目中添加了更多元素（即敌人和他们发射的所有子弹）时，我意识到我用来在小行星上运行自毁机制的计时器可能是个问题。 （项目符号使用了类似的自毁机制。）这是我在Unity开发中吸取了重要的一课时：您必须最小化在脚本的Update方法中放置的代码量。 实际上，我了解到，游戏对象越多，更新例程中没有多少代码就越重要。
这使我发现Unity中的Invoke和InvokeRepeating函数。 这些命令将以给定的周期性运行命名函数，该函数作为Invoke函数的第一个参数给出。 这样做的主要优点是，我可以每两秒钟检查一次小行星的距离，而无需花费与在应用程序渲染的每个小行星上运行计时器一样多的开销。
最终，当小行星从游戏环境中移除后，我将小行星存储在对象池中，从而进一步提高了效率。 我还对小行星进行了编码，以便在它们被摧毁时掉金。 我用掉金的代码创建了健康宝石和速度宝石，它们可以代替小行星中的岩石和掉落的球体产生，从而提高玩家的性能。
一路走来，有好几个星期，我的全部努力只是简单地学习了无效的内容。 这是一个反复试验的过程，提出了一种处理方法，而不是找到某人先前已存在的解决方案进行复制和修改。 我想我找到了一种满足感，信心以及与编码和解决问题的联系，而仅仅通过复制别人的工作是无法找到的。
通常，尝试成为一名编码员最困难的事情是面对未知的事物，一遍又一遍地迈出第一步！ 但是，乐于接受这一飞跃并发现自己可以做到。 而且，如果您不断从不同角度提出问题而拒绝退出，那么您可以做到！
