鸟哥,射击游戏技术分享3

参见游戏图片和视频

四、背景滚动

 首先背景图片做得可以上下连接(上下滚动)，就是画一张图片，下面接着画，或者上面接着画，看起来都是无缝的。然后程序上的处理：计一个变量go值，每桢go += add;add为滚动速度（向上为负值，向下为正值）程序上为向下滚动，这样看起来人就在前进了

go += add;
 int heights = 0;
 int drawY = 0; 
heights = one.getHeight();//图片高度 

drawY = (go >> 2) % one.getHeight();//之前是还有云层什么的， //最底下>>2,第二层>>1的，以控制各层不同速度。后来因为内存不够用，砍层了，>>2就一直没变 
if(drawY - Datas.height < 0)//Datas.height为屏幕高度，如果发现起始画点在屏幕中，则多画一张 
{//达到遮盖目的 
g.drawImage(one, 0, drawY, 20);//one是图片Image对象，xy坐标，20是anchor,鸟哥发现有好些人不是用20,用0的 //经过测试发现0与20其实结果是一样的 
}
 g.drawImage(one, 0, drawY - heights, 20); 

 

五、怪物生成

有些游戏根据坐标，有些游戏根据时间，有些写死，有些随机。本游戏根据时间。

为了确保效果，做了个简单的怪物编辑器，由策划自己编辑：

坐标编辑：

两者结合，策划方便地看到怪运动轨迹。第几秒出现什么线路的怪，啥等级的。都有明确显示。

编辑器上一些描述:

public static String[][][] traces =
    {
         {//蝙蝠：
              {//从上向下飞
                  "飞行速度a1，到达屏幕上方1/4的时候，发射一颗瞄准子弹，子弹速度b1",
                  "飞行速度a2，到达屏幕上方1/4的时候，发射一颗瞄准子弹，子弹速度b2",
                  "飞行速度a1，到达屏幕上方1/4的时候，发射三颗散弹，子弹速度c1",
                  "飞行速度a2，到达屏幕上方1/4的时候，发射三颗散弹，子弹速度c1"},
              {//路线2：...},
              {//路线3：抛物线（从右到左）
              ....
                 },
              {//路线4：飞向屏幕（120，240）这一点，速度较快
                  "无子弹",
                  "刚出屏幕的时候发射一颗瞄准弹（瞄准主角），速度要比自身快"
              }
        }
        ,
        {//刺客：
            ...
        },
        ............
    };

    public static String[][] tracesDescription =
    {
         {//蝙蝠：
              "从上向下飞",
              "路线3：抛物线（从左到右）",
              "路线3：抛物线（从右到左）",
              "路线4：飞向屏幕（120，240）这一点，速度较快"
        },
        {//刺客：
            ...
        },
        {//枪手：
        ...........
        {//将军：
            "路线1：从上往下，到屏幕四分之一出停留一段时间，发弹，离开"
        },
        {//巨兽：
            "路线1：从上往下"
        }
    };

看看这些ai描述，大部分是以屏幕或者时间为参考的，这样，移植不同屏幕的机型时就不用修改了。 

用netbeans开发，很快拉出来两个界面。

 

95;311w-W,h+H//95:第几秒出现;3:怪的id;1:怪的等级;1:怪的线路.最后为出现坐标
94;001w>1+W,-H
94;001w>1-W,-H
93;001w>1,-H-H
93;001w>1-W,-H
93;001w>1+W,-H
90;131w+W,H
86;101-W,-H
86;111w+W,-H
86;211-W,H
84;001w>1+W,-H
84;001w>1-W,-H
83;201w>1,-H
80;301W,h+H
80;131w+W,H
80;201w>1-W-W,-H
80;201w>1+W+W,-H
78;001w>1,-H-H
78;001w>1-W,-H
78;001w>1+W,-H
76;211-W,H
75;401w>1-W,-H
75;401w>1+W,-H
74;001w>1+W,-H
74;001w>1-W,-H
74;311w-W,h+H
70;131w+W,H
70;501w>1,-H
68;201w>1,-H
66;101-W,-H
66;111w+W,-H
66;211-W,H
64;001w>1+W,-H
64;001w>1-W,-H
63;301W,h+H
63;001w>1,-H-H
63;001w>1-W,-H
63;001w>1+W,-H
60;131w+W,H
56;121-W,H
54;001w>1+W,-H
54;001w>1-W,-H
53;201w>1,-H
53;311w-W,h+H
50;131w+W,H
50;401w>1-W,-H
50;401w>1+W,-H
48;001w>1,-H-H
48;001w>1-W,-H
48;001w>1+W,-H
46;101-W,-H
46;111w+W,-H
46;301W,h+H
46;121-W,H
44;001w>1+W,-H
44;001w>1-W,-H
40;201w>1-W-W,-H
40;201w>1+W+W,-H
38;201w>1,-H
36;121-W,H
35;501w>1,-H
34;001w>1+W,-H
34;001w>1-W,-H
33;001w>1,-H-H
33;011-W,-H
33;021w+W,-H
32;311w-W,h+H
30;131w+W,H
28;002w>1,-H
26;101-W-W,-H
26;111w+W+W,-H
26;121-W,H
25;401w>1,-H
24;201w>1+W+W,-H
24;201w>1-W-W,-H
23;201w>1,-H
20;131w+W,H
18;002w>1,-H-H
18;021w+W,-H
18;011-W,-H
14;001w>1+W,-H
14;001w>1-W,-H
12;301W,h+H
11;311w-W,h+H
10;131w+W,H
8;321w>1,-H
6;101-W-W,-H
6;111w+W+W,-H
4;111w+W+W,-H
4;101-W-W,-H
3;201w>1,-H-H
3;001w>1-W,-H
3;001w>1+W,-H

 

  w,h为手机屏幕宽高，W,H为怪身体的宽高。>1表示向右移等。游戏会解析这些坐标值，得到具体坐标数据。

 它们都是以屏幕，或者自己做参考，这样不同手机屏幕移植一样有好处。

六、切图介绍

为了提高速度，游戏中的画图全部没有用到旋转，翻转。游戏本身决定。切图也没有用动编了。如下图：

美术给出对应的坐标，用drawRegion搞定：

也没什么人气，javaeye里j2me关注度本身就小。技术分享就到这里吧。鸟哥，感谢有关注的网友！

 

鸟哥分享不错，不一定是对J2ME有用了，对游戏开发都受益，多点分享吧。

游戏开发一通百通 不一定J2ME用到别的用不到 支持鸟哥分享

对啊，多谢鸟哥分享，思路和原理在其他平台上一样适用！

嗯，原理是一样的。以后会开发其他游戏的，应该是rpg游戏居多。到时再一起分享交流吧。呵呵

国内J2ME开发的状况一直是
凑合的程序员好找，而且手机机能比老40时代提高很多了
好的美工难寻，像素图的做法和普通网游美工要求差非常多
得美工者得天下
玩家根本都不是core player，所以傻点的策划，他们都是不在意的

补充一些技术
1.怪被打时，可以用png换色方法来进行换色，做出被攻击的颜色效果，无需重新做图，美工要给出各点色值。同理，同外形的怪可以用同一张图，比如金怪，银怪，水怪，火怪，换色即可

2.还是现在机能和存储普遍提高了，否则这么大面积的图，是绝对不能这么不镜像的，1.0时代非Nokia机器没办法才不镜像
关底boss，可以让玩家飞行一段时间，给出Warning，在这时把图片镜像了，你用一个原图 + 一个缓存的镜像，和两个原图的内存是一样的，但是打出来的jar包就小了很多，以前40百宝箱可是安装包 < 60k的要求，heap size才200k，基本也就是三屏半还是两屏半的总图片，我记不清了

3.会以上我说的优化技术，还是回到我的老观点，屁用没有，J2ME早已过去，智能机不care这点空间和性能，只能是自己对自己有偏执要求的，才会使用了

1.
这点大哥指的可是把png的PLETE块换掉？如真是如此，美工给的图，可参考上面的boss图，这样也得内存里生出一张图来，这图可是有点大了，有些烂机器会吃不消。小怪的话还是可以的。游戏开发时，考虑过用这种效果，居于这原因最后没有做。
2.
呵呵，大哥的意见非常好。这游戏中见boss时有个过场对话的，每个boss都有，不会马上开战。背景大图，是上下相互可以链接，内存里只有一张，当不够画手机屏幕时就画多一次，拼上去。如果可以，帮忙解析一下镜像的意思吧，小的不懂哈。
3.
这个很难说。反正我在j2me里拼着，呵呵

1.是的，换调色板
这个内存上其实直接打包两张图没区别，存储上节约，工作上节约不节约时间看具体情况

假定你有两种杂兵，一种红色，一种蓝色，外形一样，名字不同，属性不同，姑且叫红僵尸，蓝僵尸
美工帮你画了两张图，打包到jar里，假定一套所有动作是10k，两套就是20k，只用一套就省一半
游戏中第一关，会出现红僵尸，loading进来红的，第二关出现蓝的，loading进来蓝的
假如内存够，那么可以同时出现，我们考虑内存不够的情况，只能出一种，如果用换色法，也就是创建一个Image，然后换色，不会出现同时在内存中有两套图的情况，你换色应该是从流直接读入原图的，然后生成Image, 而不是把原图生成Image再换色

2.
我说的是翻转的意思
你的右边翅膀，是左边翅膀的镜像，你让美工画一个，自己翻转一个，和你直接让美工画好放到res创建2个Image是一样的内存，但是存储省了
现在对于jar包的大小不介意，不在乎这点空间

呵呵，谢谢nypisces大哥指点！！

不管图片存储大小是多大，除bmp外，png,jpg都是经过压缩的
在屏幕上重绘的时候，都是载入内存，无压缩的格式
图片占用的内存，是整个游戏中的大头
开发的时候，应该让策划计算并控制每关的最大内存
计算公式就是 图片面积 x 色深，合理安排出什么大小，出几种怪，在哪些点需要释放资源
这个我觉得对所有手机开发者都需要知道的知识