看了所有的回答，都把焦点放在了「如何判定在背后」，其实这只是一个初中算数的问题，那么思考一个问题——这几个人的攻击恰好是近战攻击，我们是否允许设计一个英雄，他也有「任何伤害背后攻击必爆」的特性，但是他的4个技能是：
1，向前丢出一个回力标，飞到一定距离后折返，类似LoL的轮子妈的Q，策划要求「如果背后命中敌人则必爆」。
2，在身边召唤雷电球顺时针环绕自己，击中敌人后会爆炸，策划要求「如果从背后击中敌人则必爆」。
3，飞出鱼叉，抓住一个目标并拽回，目标被拽回的路径上的敌人碰到目标都会受到伤害，策划要求「如果目标被拽回时，从背后撞击了路径上的人，则此伤害必爆」。
4，大招：在远处召唤8道水柱，水柱顺时针螺旋向中心（即释放技能时候角色的位置）移动，对碰到的敌人造成伤害，对碰到的友军造成治疗，策划要求「如果是从正面碰到友军则治疗必爆，如果时从背后碰到敌人则伤害必爆。」
思考一个问题——以上四个需求为什么不可以？那么问题来了！—— 这4个伤害的「背后判定」，一定与「我」（释放这个技能的人）的位置有关吗 ？所以我想说，楼上的大多是纸上谈兵，那么作为一个实际干出过数款上线并有几款成绩不错的Moba游戏的我就从最简单的实现来谈谈这个在真实的Moba游戏中是如何实现的。
在这个问题中，涉及到的数据以及他们的最基础属性：
1，CharacterObj（角色对象），有一个属性面向（FaceDirection），为了编写lua脚本的策划便于理解，我们通常使用0-359的整数，描述了一个角色面向的角度，这里还要注意一点——在很多游戏设计的需求下，面向的角度不等于角色移动的方向的角度，你可以根据需要把面向（FaceDirection）和移动角度（MoveDirection）做一个分家，但是这个问题下，我们关注的只是FaceDirection。
2，DamageInfo（伤害信息），通常新手会认为这个是一个多余的环节，但是如果你真的理解了我的buff机制（你可以从知乎搜索「如何设计一个易扩展的游戏技能系统」），你会发现整个流程中这是一个必要的东西。首先我们来说DamageInfo通常包含的内容（与本次讨论无关的属性就不再这里列出了，根据项目的实际需求扩展这个结构就行了）：
1）Damage: 通常在Moba中是int，如果你还会用到金木水火土等属性伤害，那么可以把它定位Array，如果你是传统页游，那int其实很难满足你的需求。无论如何，你需要一个地方暂时记录这次伤害的值。
2）isHit：boolean，是否命中，是否能够命中并不影响造成的伤害，伤害管伤害（Damage）计算值，会影响最后命中的因素非常多，所以这里只记录当前伤害信息能否命中。
3）isCritical：boolean，是否暴击，同是否命中，你不应该因为暴击了直接就把Damage进行运算，我们说DamageInfo这个信息用于最后的伤害计算，所以最后实际算伤害的时候，会根据DamageInfo.damage和DamageInfo.isCritical得出一个合适的伤害数字的。
4）degree：int，0-359，伤害来源的角度，这个角度就是当前问题的关键，由于游戏中有太多的因素会产生伤害，所以每一个因素在产生伤害的时候都会有不同的赋值方式，因此这里会涉及到另外一个课题——将伤害来源做个抽象归类，合理的设计下应该是这样的：
当你的游戏依赖的逻辑对象是：
bulletObj：在Moba类游戏中那些必定命中的、通常用于单体的技能，请记住，技能的效果未必是伤害，伤害只是效果之一，这才是对的抽象！
aoeObj：在Moba类游戏中通常是一些范围性技能。
buffObj：给角色添加buff的处理。
这3个逻辑对象的对应「效果」（确切的说是回调点）的函数中，可能带有产生伤害信息的接口，由此，我们可以获得这个DamageInfo，也正是在此时，根据游戏的规则来赋值了这个DamageInfo.degree：
bulletObj的degree，通常等于这个bulletObj在命中时候的方向。之所以说是「通常」，因为游戏策划可以重新定义他的用法，下同。
aoeObj的degree，通常等于aoeObj.position到产生伤害信息的对象角色的向量的角度。
buffObj的degree，通常是0，也有用buffObj.caster（释放这个buff的角色）当前（buffObj逻辑回调瞬间）的面向作为degree的，两者都是科学的，取决于策划设计需要。
实际上我们看开篇我命题设计的4个技能，他们的degree的确和「我与目标」的位置没什么关系，而是与「我」发出的aoe/bullet与目标的位置有关系。
也许我需要进一步的解释一下好的伤害流程的抽象，才能让你更明白DamageInfo的意义，那么我们就接着说：
请注意，这个伤害流程适合于任何需要伤害逻辑的游戏，在这里我们穿插了对buffObj的回调点的处理，把这些处理丢给脚本也好，丢给其他程序逻辑代码段也好，这都OK，关键在于—— 整个伤害流程是一个变化DamageInfo值的过程，最后依赖于DamageInfo的数据，我们产生了真正的伤害 。事实上，很多类似「背后必爆」的处理，都是在这一段里通过buff机制来实现的。
当你理解了这个流程的时候，我想你不难写出这样一个buffModel（用于创建一个添加在角色身上的buffObj），伪代码如下：
buff.id = "crit_behind";
buff.visible = false;
buff.onHit = function(buffObj, target, damageInfo, designParam) {
if (math.abs((360 + damageInfo.degree - target.faceDirection) % 360) <= 60) {
//在逻辑的世界，命中的时候，2个点（伤害来源和挨打者）必然重合，所以我们只能认为如果2个人的面向是相向的，并且差距在一个可接受范围内，那么就是「背后攻击」（因为来源会定义不同的方向，这是给来源留个活路，这里涉及到一个逻辑架构能力）
damageInfo.isCritical = true;
}
return damageInfo;
}
就是这样的简单思路，很轻易的就能实现你来自任何渠道的伤害和你能想到的一切处理，比如说「来自正面的伤害会治疗目标」这种，我相信聪明人看到这里已经狠轻易就能知道怎么做了。 所以说，这个问题的根本，并不是用一个数学公式解决2个点的方向问题，而是一个逻辑抽象问题——合理的游戏逻辑业务框架该如何设计才是问题的根本 。
