大多数游戏都有着丰富的效果类，在精灵移动类游戏中曾一度以此为一个重要的卖点，。光光是一些丰富的特效是不能够产生一个好的游戏的，但是一个好的游戏是万万不能缺少好的效果的。

很多人认为游戏的效果层有时和跟游戏逻辑本身并没有太大的关系，往往就是在最终屏幕上再画上一层效果层。但是游戏逻辑和效果层之间的通信是很重要的。这种通信往往体现在延时与等待上。比如飞机爆炸时，不接受任何用户输入，并且爆炸效果还要继续跟随飞机坠落，甚至爆炸的范围会影响周围的物体，要等待爆炸结果结束了才继续进行游戏。游戏逻辑和效果层之间的通信是很复杂的问题。在这里我突然有了罪恶感，我们没有对游戏进行任何的分析就起步了，游戏完全是基于硬编码的，我想到那儿，大家跟着看到那儿。飞机类仅仅是一个sprite，没有设计成一个状态机，这也就使得我们的效果层和逻辑层的通信有些卡通了。也许本文给了你编写自己第一个游戏的喜悦，也带给了你对游戏扩展性与复杂性的一丝担忧。或许这比便一个硬编码的游戏更有意义呢？谁说得好呢，现还是以为那些扩展性良好的游戏是伟大游戏构架师的杰作吧，相信你有了一两个好的想法后会重新设计这个游戏的，使之稍微有一些像个“系统”。然而好的技术不一定产生好的游戏……呵呵

有扯远了，会到现实吧，boys and girls！goon.

描述一下我们的爆炸效果，在子弹击中飞机后，子弹要迅速消失，飞机图像保持不变，此时将爆炸效果至于飞机图像之上，然后开始显示boom动画，在此期间，飞机不接受任何移动指示，因为他lose control。在爆炸效果后飞机消失。

我们的爆炸效果类：

GameObject explosion;//

初始化once：

img=ImageTools.getImage("/pic/explosion.png");//

explosion=new GameObject(img,32,32);

初始化：

explosion.reset();

explosion.lifetime=3;//生命周期定位三桢

逻辑处理：

if (gameover) {//如果游戏结束，显示效果类

explosion.paint(g);

explosion.update();

if(!explosion.alive){//当生命周期结束了

plane.alive=false;//关闭plane

g.setColor(255,255,255);//输出评语，下回分解

g.drawString(StringTools.timeOpinion(gametime),5,22,g.LEFT|g.TOP);

g.drawString("fly 0.1 ver by favo yang",2,100,g.LEFT|g.TOP);

g.drawString("E-mail : favoyang@yahoo.com",2,115,g.LEFT|g.TOP);

g.drawString("simulate from:",2,130,g.LEFT|g.TOP);

g.drawString("Mr.tony 's ",2,145,g.LEFT|g.TOP);

g.drawString("hello tony, just funny.",2,160,g.LEFT|g.TOP);

}

}

现在你看我是如何解决效果层与逻辑层之间的通信的，我使用的是全局变量gameover，在简单游戏中使用大量的全局状态变量也是一种常见的方法,可以避免动脑劲。不过缺点明显，游戏硬编码，结构既不清晰也不漂亮，几乎没有扩展性。所以说最好还是将飞机基于状态机设计，并将效果类设计成含有回调函数的抽象类，然后继承效果类实现回调函数来实现通信。至于总体层次上可以用堆栈将绘画单元串起来。还有分层处理等等…给你个思考的起点…
导弹的是实现，是不是你已经有个想法了呢，其实就是利用Bullets.killbullets。

逻辑处理

if(bomb.alive){

bomb.moveto(plane.sprite.getX()-20,plane.sprite.getY()-20);

bomb.paint(g);

bomb.update();

bullets.killbullets(plane.sprite,32);

}

在这里我不得不提一句，将生命概念封装在GameObject中是很好的（其实我们只是将其用作显示关键字），但将生命周期安排在GameObject中有欠妥当，生命周期也不一定就是基于桢的，有时基于时间，有时还有别的什么。我是说她足够复杂到交给另一个独立类处理，在这里实际需要的是一个足够强大的显示方法，其支持以桢数为参数显示罢了。

其实我觉得自己说多了，也许你也被我搞糊涂了。对了目录上少了一节，我们还缺少游戏的奖惩系统，下回我补上。