目 录

J2ME RPG游戏边学边做(三)--游戏基本元素类

    虽然我们有了midp2.0的支持,但是有时还是需要一些辅助工具,方便我们使用。这怕是在进行真正的游戏设计之前最有趣的了。

    1,首先是一个ImageTools工具类,提供一个方法帮助调用Image


public class ImageTools {
  protected ImageTools() {
  }
  public static Image getImage(String str){
    Image img=null;
    try {
      img = Image.createImage(str);
    }
    catch (Exception ex) {
      System.out.println(ex);
    }
    finally{
      return img;
    }
  }
}
2.GameObject,提供一个通用的游戏对象。

       有了Sprite类,为什么还要GameObject呢?其实我们一般是将Sprite,看作成一个高级的Image,往往一个Sprite要被多个游戏对象调用,GameObject其实就是Sprite的状态类。GameObject提供简单的生命周期概念,动画更新速度;

public class GameObject {
  public Sprite sprite;//内置的Sprite
  public boolean alive;//存活标记
  private int lifecount=0;//生命周期计数器
  public int lifetime=0;//生命周期,以桢为单位
  public int speed=0;//动画桢更新速度,(0至无穷,0代表每一桢跟新一个画面)
  private int animcount=0;// /动画桢更新计数器
   public GameObject(Image img,int width,int height){
    sprite=new Sprite(img,width,height);
    reset();
  }
   public void move(int dx,int dy){//相对移动
    sprite.move(dx,dy);
  }
   public void moveto(int x,int y){//绝对移动
    sprite.setPosition(x,y);
  }
   public void update(){//更新状态,动画桢更新,生命周期更新
    if(!alive)
      return;
    if(++animcount>speed){
      animcount=0;
      sprite.nextFrame();
      if(lifetime!=0 && ++lifecount>lifetime)
        alive=false;
    }
  }
   public void paint(Graphics g){//Paint
    if(!alive)
      return;
    sprite.paint(g);
  }
  public void reset(){//复位
    alive=true;
    lifecount=0;
    animcount=0;
    sprite.setFrame(0);
  }
}

     3.封装字体类,你需要漂亮的字体吗?

    我们经常需要用图片来输出文字,一个方便的字体类是必须的。我们希望仅仅提供一个图片,一个图片所描述的字符的数组,来初始化一个字体类。字体类提供一个类似Textout的方法,方便得在一个位置输出信息。先封装一个简单的版本,只支持英文和数字,并且输出不能自动换行。可能你有一个简单的思路,就是简单的保存字符数组,当打印的时候遍历数组,来查找每个字符在sprite的frameseq中的index,但当我们打印一个字符串的时候就会发现,太多的遍历操作耽误了宝贵时间,这里我们使用一个小技巧用容量换取速度,我们知道Character. hashCode()可以返回字符的ascii编码,常用字符将返回1-127;利用这一点,我们开辟一个128的数组charhash,将输入的字符c 所在图片index存入charhash[c. hashCode()]中。以后也用这种映射方法来读取字符。charhash的元素初值为-1,以后只要数值大于0就是有效值。


public class Font {
  Sprite sprite;       //Sprite
  int width,height;  //每个char的尺寸
  int[] charhash;    //储存1-127个常见字符在sprite的frameseq中的位置
  Graphics g;
   public Font(Graphics g,Image img, int width,  int height, char[] chars) {
    this.g=g;
    sprite=new Sprite(img,width,height);
    this.width=width;
    this.height=height;
    charhash=new int[128];
    for (int i = 0; i < charhash.length; i++) {
      charhash[i]=-1;//没有代表此字符的图片
    }
    Character c;
    for (int i = 0; i < chars.length; i++) {
      c=new Character(chars[i]);
      charhash[c.hashCode()]=i;
    }
  }
   public void drawChar(char ch, int x, int y){
    Character c=new Character(ch);
    int hashcode=c.hashCode();
    sprite.setPosition(x,y);
    if(hashcode>=0){
      sprite.setFrame(charhash[hashcode]);
      sprite.paint(g);
    }
  }
   public void drawString(String str, int x, int y){
    int length=str.length();
    for (int i = 0; i < length; i++) {
      drawChar(str.charAt(i),x+width*i,y);
    }
  }
}


这样只要有一个实例font,就可以调用font.drawString(“hello”,0,0);

在0,0位置输出漂亮的图片字符串。怎么样还挺好使的吧:)

J2ME RPG游戏边学边做(四)--爆炸效果

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

很多人认为游戏的效果层有时和跟游戏逻辑本身并没有太大的关系,往往就是在最终屏幕上再画上一层效果层。但是游戏逻辑和效果层之间的通信是很重要的。这种通信往往体现在延时与等待上。比如飞机爆炸时,不接受任何用户输入,并且爆炸效果还要继续跟随飞机坠落,甚至爆炸的范围会影响周围的物体,要等待爆炸结果结束了才继续进行游戏。游戏逻辑和效果层之间的通信是很复杂的问题。在这里我突然有了罪恶感,我们没有对游戏进行任何的分析就起步了,游戏完全是基于硬编码的,我想到那儿,大家跟着看到那儿。飞机类仅仅是一个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 : 该邮件地址已受到反垃圾邮件插件保护。要显示它需要在浏览器中启用 JavaScript。",2,115,g.LEFT|g.TOP);
        g.drawString("simulate from:",2,130,g.LEFT|g.TOP);
        g.drawString("Mr.tony 's <hold on 20sec 1.20> ",2,145,g.LEFT|g.TOP);
        g.drawString("hello tony, just funny.",2,160,g.LEFT|g.TOP);
    }
}

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

导弹的是实现,是不是你已经有个想法了呢,其实就是利用Bullets.killbullets。


逻辑处理

J2ME RPG游戏边学边做
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中有欠妥当,生命周期也不一定就是基于桢的,有时基于时间,有时还有别的什么。我是说她足够复杂到交给另一个独立类处理,在这里实际需要的是一个足够强大的显示方法,其支持以桢数为参数显示罢了。