处理ARPG和RTS中的碰撞技术精萃（原创）

linkfire

昨天我提出的模型 是用圆和矩形都行的  这些我没仔细考虑到 昨天我就是为了画出向量图  就采取了圆的策略  但是用矩形也一样
不过你说的那7种碰撞  可以更精化  比如说2辆汽车的  车头 对车身的碰撞 按你的那7种撞击  
你该把他分在那里  按实际情况的话 会出现3种情况  撞到车身中央   撞到前 后车尾
这样就导致会出现3种情况  撞击车身的那种会出现  2辆车同时平移  撞到前 后车尾的 就会根据某个扭矩进行平行旋转  前后车尾的旋转方向是相反的   你的表  是不是包括到这种情况了   
我知道你前面的意思  就是把一切都可能发生的情况都包括进你的表里
我的算法 更多的是采用了自适应的思想   你说的 H  W  D在物理模型上也都有相应的解释
不过我想做的是1个在十字路口更多辆车相撞的情景  外国电影上经常出现  这个时候你的方法好象就不是很合适的  请问你怎么处理很多不同汽车事故场景   有些车可能物理位子没有动 但是还是被别的汽车压扁了  你是不是要针对这种情况也单独再列个表 然后再给个DEPTH值就是被压扁的程度   我的想法更多是想尊重物理模型 完全用物理公式来解决碰撞问题  也就是把物体的状态一直都设置在等待  当发生物理事件后  只对碰撞的那1刻进行运算 碰撞以后则2车各自回到自己应该的状态  该旋转的就旋转 该翻车的我就制造个翻车的情景   而且翻车的情况 都可以做个不同的表 总之要做的和拳皇对打 一样  每种不同组合出现不同的效果   这个才是游戏可玩性所在 在用计算机进行复杂性科学运算时候  也都是采用这种思想   他们都不会对情况 做各种预测  而是让物理模型自己演算  通过数据传递的手段来达到对复杂情况的真实模拟  
我想做的是更多忠实物理模型的游戏  而不是通过各种计算机特效来达到以假乱真的地步 就算用特效也必须尊重显示 而不是想当然的造出个场景  

PassByYou

看我给的标题，ARPG和RTS，我没有给赛车标题。但是碰撞AI归根结底都是在发生碰撞以后做的事。

我列举的7种碰撞，不存在RTS和赛车类游戏的区别，只要是碰撞，那么都会在这7种碰撞的范围内。车身和另一辆车头发生碰撞，是角碰，车身和另一辆车尾发生碰撞，是分离碰，车身头对头，是对碰，假如车子已经被碰了，并且通过检测以后，车子处于stop的话，这时再发生一个碰撞，那是静态碰。因为那天我没画完这7种碰撞的草图，你多看看我给碰撞起的形象名，然后想象一下。

实际上我们讨论的问题中心不在于碰撞，而在于RTS和赛车这两游戏，它们在与碰撞处理上的不同。因为你提及之前你并没有实际做过，所以很多东西都是概念上的，以至于我不断的解释碰撞种类，碰撞处理流程，解释了很多很多。对于这点，因为我以前也是和你一样，只有概念上的东西。可是我如今已经基于一个实实在在的游戏把碰撞AI开发完了，对于这点，我想提醒你的是，不管是RTS还是赛车，碰撞AI的处理步骤是肯定固定的。第一步，发生碰撞后分析碰撞，第二步，根据分析结果用流程处理碰撞。

另。从你提及堵塞的言辞，我想你还没有想通怎样搞定赌塞吧？我再说一下，关系碰撞的意思是指，场景中每个物体的碰撞，只要是碰撞发生了，那么他们都会互相影响。这里面的关键在于一张关系碰撞表，而这张表的雏形我已经制作好了。因为赛车和RTS的处理不同，对此应该对赛车的碰撞量身去分析，而不是套用RTS，那是套不上的。

碰撞AI中不存在什么物理和模拟，都是在模拟，所谓物理，我指我们经常谈及的物理引擎，那是指基于某个物理引擎的碰撞AI，本质上都是在模拟。别的我不敢乱说，现在布娃娃的开源物理引擎对于开发赛车游戏相信会大有帮助。很多可控的反弹，空阻系数，等等，那也是一种碰撞AI，形势上的不同罢了。你说的使用物理碰撞的AI，是不是就是我这样理解的？

PassByYou

你要是有解决不了的碰撞问题，你最好可以系统的描述一下，我这样才会很好理解你的问题，这样大家才能一起把你的问题给解决了，而不是在没搞明白之前大家就胡乱批评对方。

我比较喜欢按照一个比较简单处理问题的流程来分析。第一步，先把问题搞明白。第二步，分析。第三步，再来讨论结果。你最好先把前两部走出来，然后再来找我讨论我提供的碰撞技术。

linkfire

前几天电脑坏了 现在才能来回个帖
我没有批评你思想的意思 按道理我也不够格   只是我对你的设计思想有点不认同  觉得可以再优化很多    这几天我也仔细考虑了下 怎么把我的思路清楚表达出来
你的说法 更多的是强调 分析碰撞 我的想法更多的是针对碰撞后分析而产生的  
只是你的表 是包括2个物体或者更多物体的总揽 我的分析只是针对单个物体进行
发生碰撞 只是单个物体的行为  拿个最简单的类比 就是小汽车车撞到墙 和小汽车超速撞到1辆大货车后面都是一样的 情形  你说对吗  你的那张表这种情况也都包括了 但是让我很不舒服的 就是你说的那些等待啊 绕开啊   那些不必要的在物体没有发生任何改变情况下 还要记录这些   
我前面说的不管是汽车和人相碰   或者和别的物体相碰 都能很好处理 只是把他们取不同权重罢了    还有我不知道你想过没有 你这个表到底是要给谁看的    工程师吗 还是游戏开发者  我的东西是要给游戏看的   游戏里的单个对象的数据都是独立存储的  而不会和另外个对象存储在一起  你列的那个表其实在我的结构也实用  只是我想提出 把2个表单列    这个 是我受大型角色扮演游戏的启发的  在单机游戏里这个思想也能实用  只有在2对象发生关系时候 才引入表判断  当然引入的对象也都是单个物体  
还有1句 现在BSD比较流行的话    能运行的不一定就是最好的  
看了中国还没有1个WS一样的大手笔游戏   在大学里我就很纳闷   
做游戏还得做那些很COOL的 而不是讨论技术优秀与否  优秀的技术还是为好的游戏策划理念服务的   游戏理念是主人   不能服从主人就是不称职  如果主人本来就不行   再好的技术也是白搭
还是从技术角度讨论怎么做出很COOL的游戏才是做游戏人的责任  如果游戏本身不是很COOL   那做技术的是白忙活了   只有极少的可能因为开发一款不流行的游戏发明一项流行的技术

linkfire

还有我发现你的设计不适合做1个物理引擎 原因就是我上面说的  

物理引擎对事件支持都建立在单个对象的基础上的  而不是把他们开始就汇总  

ffhuangzy

[em1]
我觉得你的思路非常不错。采用关系表的确能够大大提高效率。因为判断语句本身也是有开销的。
我有个疑问。rts游戏通常是大量的个体同时移动的。所以它要判断的通常是一个与周边不确定个数的个体之间的碰撞。我指的不是碰撞的探测。而是说一个个体与多个个体之间同时发生碰撞也是可能的。这样的情形下，可能就不是729种情况了。所以，我觉得可能rts游戏对碰撞的解决并没有那么高的精度要求。他们大概把情况大大简化了。
我另外有一个问题就是，rts游戏种检测碰撞时难道每个个体都要对其他所有个体检测一遍吗？有什么好的思路？或者经验？

gantleman

我想这么做，
第一，根据两车矢量和摩擦系数计算碰撞后的方向和轨迹，
第二，根据强度给出，颤抖，飘逸，翻滚的几种效果。
第三，生成碰撞后的动态效果脚本。
感觉极品飞车动态特效就是这么做。