2019年开始了一个令人振奋的消息：我在Dots接受了工作面试！ 作为该过程的一部分，我得到了一项实际的任务：在Unity中创建其核心游戏的简化版本。 这使我设定本月的范围和目标变得非常容易。
目标
- 创建一个点集的副本，让我进行面对面采访
- 练习编写高性能的Unity代码
范围
点招聘经理向我提供了基本范围。 由于该列表不是我的分享对象，因此我将添加一些我要炫耀的附加功能😎
- 实现点提供的功能列表
- 使审阅者可以在Unity编辑器中轻松更改点的颜色，而无需更改代码（以及点颜色的数量）
- 使审阅者可以在编辑器中轻松设置点网格的尺寸
- 清除点后，新的点将从屏幕顶部以随机分配的颜色下降。 利用策略模式，审阅者可以在编辑器中轻松地在多个点颜色“替换”策略之间进行切换。 可能策略的示例包括“所有一种颜色”或“在每种可用颜色之间旋转”
回顾：进展顺利
进入下一轮！
首先，团队非常喜欢我的项目，可以进行下一轮的采访！ 除了达成这个目标，我对能够很快完成任务感到满意。 我被告知要“花尽可能多的时间”，我设法在一周内完成了工作，而没有忽略自己的日常工作。
实践写作表现团结
根据Unity关于优化脚本的指南，我非常小心地减少了使用诸如GetComponent方法的GetComponent 。 在呈现方式和游戏逻辑重叠的游戏中，这可能会变得棘手，因为圆点的颜色既充当呈现细节， 又是核心游戏机制的基础元素（即“我将圆点悬停在与我以前选择的点？如果是，请在它们之间画一条线”）。
一种简单的方法是创建一个带有SpriteRenderer组件的“点”预制件。 设置SpriteRenderer的颜色用于演示。 为了确定点颜色是否匹配，可以简单地调用：
dotPrefabInstance.GetComponent().color
但是，由于我一直在尝试避免调用GetComponent ，因此最终创建了一个普通的旧C＃类“ Dot”，其中包含一个Color值，一个点SpriteRenderer和一个对其SpriteRenderer的缓存引用。 所有游戏逻辑都在一系列Dot实例上运行，最终在缓存的SpriteRenderers 。 这消除了对GetComponent的绝大多数调用。
权衡？ 增加了代码复杂度。 我现在正在维护重复的数据，因为Dot实例和SpriteRenderers现在都需要知道它们的颜色。 需要额外的代码来封装诸如设置点颜色之类的逻辑。 否则，该颜色数据不同步很容易危险。
我还通过利用对象池来最大程度地减少Instantiate / Destroy点和线的次数，从而减少了CPU开销。
老实说，在这种范围内的游戏中，这些性能提升永远不会引起注意。 游戏逻辑很简单，一次在屏幕上永远不会有太多的点，而且GetComponent也不会那么慢（一个不错的CPU每秒可以执行10+百万个GetComponent调用）。
但是，将点数据与Unity的GameObjects和Components分开会使实现诸如“两点”中引入的“锚点”之类的功能变得容易得多 。 另外，这是一次很好的学习经历。 由于这些原因，我认为值得进行权衡！
回顾：进展不顺利
没有报价
虽然我确实进入了最后一轮的面试……
…我没有收到要约…
反馈并不令人惊讶：他们希望有人拥有更多Unity经验。 因此，除了每月制作一个游戏外，我还将通过一些深入的Unity教程来对引擎的工作原理有更全面的了解。
无论如何，这是一次很棒的经历。 关于这个过程以及采访我的人，我只好说些积极的话。 我很高兴能做到我所能做到的！
一个偷偷摸摸的虫子
面对面访问中指出了我的代码中的一个细微错误。 创建点的“循环”之后，可以继续重新选择循环中已经存在的点：
面试官试图通过说“每个人都错过了这个案子”使我感觉更好，但是从我的角度来看，这意味着我错过了一个使自己与“每个人都与众不同”的机会。
总结：在计划项目时仔细考虑极端情况时要格外小心。 特别是在提供规格时。 我一完成列表中的所有项目，就觉得该项目已“完成”。 但是重要的是要记住，编写需求的人不一定会想到所有可能的极端情况，而质量检查是每个人的工作。 所以没有任何借口！
结果
在这里查看最终产品！ 单击一个点以将其选中，拖动以加入到相同颜色的相邻点，然后松开以清除它们。
下个月
去年夏天，我创建了一个第一人称游戏，玩家试图从程序生成的迷宫中逃脱。 我非常想让人们创建自己的游戏内容，因此下个月我想创建一个游戏级别的分支，级别不是随机的，而是由用户在易于使用的浏览器应用程序中创建的。 回头见！
