看题目,你想到了什么?
如果你也用FLASH做过飞机游戏,你一定会对子弹碰撞这部分有很强烈的印象.
因为碰撞检测便是整个飞机类游戏的灵魂.
想象一下,你的子弹因为不能响应碰撞而打不烂敌机,而敌机的子弹也因为不能响应碰撞而打不烂你.那该有多无趣.
所以说,碰撞检测在飞机类游戏里是非常重要的啦.=_=0
那么,你是怎么处理这个碰撞的检测的过程的呢?
一般做法:将hitTest方法加到子弹MC上.接合FOR...IN...循环检测所有的敌机是否与子弹发生碰撞.
试想一下,如果屏幕上有50发子弹.敌机2架.那么,为第一个子弹上加上这样的代码
bullet.onEnterFrame=function(){
for(enemy in enemyarea){
if(this.hitTest(eval("enemyarea."+enemy)))
{removeMovieClip(this);removeMovieClip(eval("enemyarea."+enemy))}}
}
先不说可能出现的碰撞误差了.就刚刚这个假设,50发子弹,2架敌机,也就是每一桢,就有50个onEnterFrame中进行2次判断.处理复杂度也就是50*2=100
现在我们换一下思路,把碰撞检测写在敌机上呢?毕竟大多数情况下,飞机要比子弹少.
当然,如果我们还用和上边类似的FOR...IN...循环,那处理复制度还是一样的.不过是变成2*50=100罢了.
所以,要想一种更有靠和高效点的办法.
可以从传统做法上看出.大过数的子弹都在做无效检测.也就是说,他本身并没有碰到任何东西,但检测碰撞这一操作仍然是在进行.只不过hitTest不会返回TRUE值罢了.所以,资源就浪费在了那些没有结果的检测上了.所以我们下边在用敌机做检测者的时候,要用到另一种检测手段了.
注意上边那段代码里的那个"enemyarea",这个MC是包含了所有敌机的MC.我把相同类型的对象封装在一个大的MC中.这样便于FOR...IN...查询,而不用在FOR...IN...里再嵌套多的对象名判定.同理,下面我将所有的子弹MC也封装在一个大的MC中.我为它取个实例名叫"bulletarea".
而子弹的设计上又要有一点技巧了.
子弹由两部分组成,一个是看得见的子弹形状,一个是看不见的感应域.后者比前者大.用来感应碰撞.
看得见的子弹形状也是一个MC,实例名就设为"inbullet".整个子弹的实例名为"bullet"
好,MC设计好了.假设还是开始的那种情况,即,屏幕上有50发子弹,2架敌机.
现在我们在敌机上写上代码.
this.onEnterFrame=function()
{
if(bulletarea.hitTest(this._x,this._y,true))
{checkcol(this)}
}
function checkcol(who)
{ for(each in bulletarea){
if(eval("bulletarea."+each).inbullet.hitTest(eval(who))){
removeMovieClip(eval("area."+each));removeMovieClip(eval(who))
}}
}
看出区别来了么?
因为这句"if(bulletarea.hitTest(this._x,this._y,true))"的判定,让飞机直接去检测整个子弹域--bulletarea,查看是否有碰撞的情况发生.这里检测的是整个大的MC,而不是去盲目地检测是否和每一颗子弹发生碰撞.毕竟,要同时和所有子弹发生碰撞也不容易.所以,先确定一下到底有没有碰撞的情况发生再说吧.
当真的有碰撞发生了,再执行checkcol(who)函数,用for...in...接合子弹内核inbullet碰撞检测,从而从子弹域里找到和自己发生碰撞的那个子弹.并删除它,然后再删除自己,当然,你也可以不急着删除自己.因为你还可以考虑血量嘛.这样一来,一般情况下影片每运行一桢只做了2次判断.如果有一个飞机出现碰撞情况了,那个飞机执行checkcol函数,那么就会有2+50=52次.如果不幸两个飞机都中弹了.那也无非比传统的检测方式多两次判断而已.总体来说,资源大大节约啊.
所以说,这种方式的碰撞检测,从一定程度上避免了"无用功检测"的情况.且运用了反馈式检测,即,先由敌机上的轴心点与子弹进行点检测,再由子弹内核进行边沿检测.这样,检测的效率也就更高,更可靠了.
以上便是我对飞机游戏碰撞检测的一点经验之谈.如有雷同,不胜荣幸.
呼~5点了...歇息去了...
这里就是模拟性质的源文件.
点击浏览该文件
用户登录
