造物者说：全新弹道系统 实现心形轨道

一张白纸

重做时我们本着4个核心原则：

1 相似的功能性应该在写在同一个代码里，来确保理解方便

2不同功能组之间的依赖性要最少且划分清楚

3弹道基本的形态功能应该要简单明了

4某些特殊弹道要和主要算法直接分离

我们的团队先是确定弹道的核心问题，然后分别对这些问题做出计划。看得出我很喜欢列清单（上面那张你看不懂的表就是我列的，啦啦啦）， 所以我也要陈列一下弹道的工作原理组成：

移动：飞弹飞向一个地方

碰撞：飞弹打击目标

目标追踪：飞弹飞向可移动的目标

脚本交互：飞弹的行为完全由设计师设计

可视性：飞弹的视觉效果

视觉特效和声音：你们都能听到看到的那些

我们就本着上面这些原理进行重做，然后给每个弹道都写入内容。随着工作的逐步进行，当概念设计无法满足需求时，我们开始再次评估然后做出调整。比如，我们把目标追踪的概念加入到移动的代码里，因为我们发现这两者的问题有紧密的联系，再比如我们把脚本交互加入到通用的弹道基础里，因为我们觉得不需要在不同的弹道中进行区分。

最后，我们做出了这样的系统：

我们把第一张表称为“五颜六色喷吐物”，而这张表简直就是由彩虹构成的。

彩虹可是绝佳的建筑材料

这对LOL意味着什么

最后我们的工作带来了两大好处。第一，弹道代码再也不会让我们的程序员感到棘手了，因为发现和解决代码问题变得轻松多了。这为那些原先被视为无法根除的问题，提供了解决的可能性。

例如，我们会看到一些视频里出现飞弹直接飞过目标且未击中的情况，这让我们感到很尴尬。虽说这是小概率事件，但这个bug很有可能决定一场游戏。我们无法重现这个bug，我们也不知道为什么这种情况会出现，所以我们只能把它暂且放下然后继续前进。但是，把所有的碰撞都用同一代码运算，那么一些会使得碰撞失效的情况就很容易被捕捉。等把那些情况处理完，我们就会很有信心的说每一颗飞弹都会击中它该击中的目标。

不过还是给自己留条后路，那种飞弹命中失败的可能性还是存在的。不过我怀疑这可能是由于某些单位位置同步性的错误而导致的，并不是弹道碰撞带来的问题。

当然让程序员轻松一点并让bug少一点，固然是很好，但是第二个更棒的好处在于，我们可以在弹道上更快的做出很新奇的调整。现在我们不用把整个弹道系统都改了才能更变弹道的移动方案，所以我们现在可以轻而易举的做出很多疯狂的改动。下面有一些这些所谓疯狂改动的展示，不过这些都不是真的要上线的：不过是某些程序猿犯蠢的结果罢了。

**爹转啊转

我们把德莱文的平砍加了2圈，看上去挺适合德莱文的张扬个性

稍微改动一下弹道的飞行轨迹点，维鲁斯就在天上画出爱心咯

六边形是最优多边形

现在有没有好想射点什么啊？\o/

再逛逛>>