J2ME游戏开发中，移植是个问题。各种手机的屏幕大小，按键，支持的API和性能各不相同，要想一次开发，到处运行并非易事。本文从几个方面简要讨论一下开发易于移植的J2ME游戏的方法，每一节分别对应一个具体问题。
一 不大不小的Size问题
1 屏幕尺寸不等？把它看做变量！
第一个问题，就是屏幕的尺寸问题。不同牌子不同型号的手机，屏幕尺寸大小不一。在渲染时必须考虑到尺寸的变化，即将尺寸看成两个变量 ScreenWidth和ScreenHeight，将这两个变量代入到渲染时坐标的计算式中。这样屏幕尺寸变了，但想要的效果不会变。举个简单的例子，现在想居中绘制一个Logo图，只要设置渲染的坐标为: x=(ScreenWidth-ImageWidth)/2; y=(ScreenHeight-ImageHeight)/2即可。再举个RPG游戏中绘制地图的例子，假如Tile大小为16*16,屏幕大小为128*128,则一屏正好显示8*8个Tile,但是如果直接用8*8次循环绘制这些Tile,那么程序就写死了，如果屏幕大小变了（换了一个机型或改成使用全屏）或者Tile大小变了，这些地方就要改动。正确的方法还是将尺寸看做变量，可将Tile的宽和高定义为常量，这样需要绘制的Tile数目为 ScreenWidth/TileWidth * ScreenHeight/TileHeight。现在你可以在各种大小的屏幕上正确显示你的地图了。这样的例子很多，也不光是屏幕尺寸需要看作变量，凡是有可能改变的数值，将他们定义成变量或常量，那么可移植性就会提高很多。另外，使用相对坐标也能提高可移植性，比如现在需要绘制超级玛丽中得到的金币数，我们需要显示一个金币的图，然后在它后面写上数字。嗯，将金币的坐标设为gold_x,那么数字显示的起始坐标就是gold_x+金币图标宽度+1。我这儿写了一个1,但这不要紧，我只是想显示数字的时候和金币图标隔开一个象素，这样写后，如果我们想将金币数的显示从左边移到右边，则只要改变gold_x就可以啦。如果我们想让金币数目显示在屏幕的最右边怎么办？只要将gold_x设为 ScreenWidth-金币图标宽度-1-StringWidth(String(金币数目))。嗯，就是这样，这是一句伪码，重点在于我们将表示金币数目的数字的长度也计算了一遍。因为不同机器的字符大小也不同。
2 文字大小不等？还是将它看成变量！
说到文字，大家可能都会很郁闷，因为中文普遍比较大，做到手机里面很不美观。当然也有个别，NokiaS40的小字体看着还不错。这儿我想起了一件事，我将字体设为Large时，MotorolaV600的真机显示的是小字体！呵呵，原来设为Small，它倒是大字体。好了，说正题。既然文字大小不等，那我们还是将它看成变量。Font类有两个方法：getHeight和stringWidth可以帮助我们。如果你的游戏里只使用一种字体，那么只要开始时调用一下getHeight,将字体高度记录下来就可以了。当然要记得在paint里面setFont啊！stringWidth可以计算出一个字符串的长度，这非常有用，因为手机中的英文字体一般不是等宽的，而且中英文数字混排时字符串的长度就更不能用字符数*字符宽度去计算了。有了这个函数，我们就可以准确知道所绘制的字符串的长度。这里有个典型的应用是文本显示的时候换行，通过stringWidth可以计算出文本是否需要换行。再给个小小例子，我写得一个工具函数，用来显示左右软键菜单。
public static void drawSoftKeyMenu(Graphics g,String leftKey, String rightKey, int color, int style)
{
drawString(g,leftKey,0,canvasHeight-mainFontHeight,color,style,GLT) ;
drawString(g,rightKey,canvasWidth-stringWidth(rightKey),canvasHeight-mainFontHeight,color,style,GLT) ;
}
当然这个函数你不能直接用，里面用到了好几个我自己封装的函数，不过意思很明白。绘制左软键菜单的坐标是(0,canvasHeight-mainFontHeight),绘制右软键菜单的坐标是(canvasWidth-stringWidth(rightKey),canvasHeight-mainFontHeight)
3 虚拟屏幕 － 很好玩也很好用
第一个问题说了屏幕的大小，我们将它看作变量，就可以解决移植时屏幕不等大的问题了。这儿提供一个高级技巧，其实很简单:)。就是将屏幕的一部分作为你的游戏屏幕，我称它为虚拟屏幕。请相信，它是很有意思也很有用的。虚拟屏幕用起来很容易，只要将你的坐标范围看作: x=0~vsWidth , y=0~vsHeight。按照这个坐标范围，像原来一样作所有的事情，只是，在最后渲染的时候，将你的坐标转换到真实的屏幕坐标。 real_x = x+vsX, real_y = y+vxY 。那么这个虚拟屏幕有什么好处呢？第一，你可以用一个屏幕很大的模拟器开发了，只要在它的屏幕上设置一块虚拟屏幕就可以了。剩于的屏幕怎么办？可以用来显示一些调试信息什么的。当然最好也定义成虚拟屏幕。就是说你可以定义n个虚拟屏幕。每个屏幕显示自己的内容，互不影响。除了调试，开发分屏游戏时也用得上。
上面提到的虚拟屏幕只是简单的在真是屏幕上挖了一块。其实，我们可以完全按照自己的想法定义它，可以任意定义它的大小，定义一个1024×1024的屏幕也没问题。你现在拥有了一个1024*1024的游戏区域了，在里面可以尽情作所有的东西，只要，在渲染的时候将虚拟屏幕的坐标映射到真实屏幕即可: real_x = x/n + vsX , real_y = y/m + vsY 。这里的n和m是比例系数。
小结：这一章讲了size问题，一句话，将会变的看成变量，这不只是针对size有用，针对游戏开发时的所有量都是有效的。即使你确定它不变，也请使用常量定义，请放心，混淆器会将所有的final static内联的。
二 编写易于移植的J2ME代码
我写第一个J2ME游戏的时候，根本就没想过移植的问题。所以那个游戏也就很难移植了。反过来，如果你已经计划好要移植了，那么事情就简单的多。这一节说的是代码问题。那就想想，不同手机之间在代码上会有哪些差异。
(1) 屏幕尺寸不同
这在第一篇里面已经重点谈过，但这儿谈的是另一个问题，即自适应控件。所谓控件，就是菜单、文本框、列表框、进度条等等。这些控件的大小必须可以根据屏幕大小自适应的调整。按照第一篇说的方法，将屏幕大小作为变量参与到控件尺寸的计算即可得到正确的尺寸（自适应后的）。这儿讲第二个问题，即得到正确尺寸后怎么把它画出来。这要看你的GUI是怎么画得了，如果是用线画的，那就很简单；如果使用了图片，那么就可能要更换图片了。我的控件使用了图片平铺和画线结合，所以可以很容易的改变尺寸。如果控件变大了，则绘制时增加平铺的次数即可。顺便说一下，这些控件我只用了一个类表示，使用参数化的方法区分使用，毕竟咱要尽量少用类吧。
(2) 支持的API不同
如果你的游戏只限于使用Midp1.0，那么移植的时候就不用考虑什么了。实际上由于我们经常要使用图片翻转、象素绘制、全屏等，往往要用到厂商API或Midp2.0。显然移植的时候要考虑到这些api的差异。我的办法是将这些api封装一层，比如我需要使用创建透明子图的API，于是封装了一个函数createSubImg。这是Nokia版本：
public static Image createSubImg(Image img,int []imgRect)
{
Image subImg = DirectUtils.createImage(imgRect[2],imgRect[3],0) ;
subImg.getGraphics().drawImage(img,-imgRect[0],-imgRect[1],20);
return subImg ;
}
这是Midp2.0版本：
public static Image createSubImg(Image img,int []imgRect)
{
return Image.createImage(img,imgRect[0],imgRect[1],imgRect[2],imgRect[3],0) ;
}
对于不同机型，该函数的实现不同，但功能相同，因此使用这个函数的代码在移植时无需修改。当然这样做增加了一些间接性，有可能降低性能。
(3) 按键代码不同
我们知道MIDP提供了Game Action，和按键代码无关，但这不够用啊，我们完全可以定义自己的Game Action，但首先让我们定义自己的虚拟按键码吧。我使用位记录每个键的状态，每个位代表一个按键，一个int有32个位所以足够了。当keyPressed发生时，我记下哪些键被按下；同样当keyReleased时，将那些被松开的键使用的位清0。某个键，也就是这个键盘状态整数里的某个位，就是我定义的一个虚拟键。当然它的值总是2的n次方了，和key code完全不搭边，所以需要我们用一个映射函数将key code映射到这些虚拟键。这个函数就是移植的关键，每个机型都要改写这个映射函数，在里面填入正确的key code。你可以在虚拟键的基础上再定义Game Action,支持在游戏中设置按键，这样就更灵活了。
(4) 封装库
如果想不更改一行代码就从MotorolaV600移植到Nokia N-Gage，那么为他们封装不同的库吧。我就这样在1分钟内完成了移植^-^。我的库包含了一个游戏框架类（内含游戏循环和渲染函数，键盘处理，以及若干跨机型的工具函数），一个图形组管理类（管理图片的载入切割旋转绘制和动画等，有点像GameAPI中的Sprite）和一个控件类（包含了所有我需要的控件）。这3个类封装了不同机型的所有差异，我需要为每种机型改写这三个类，当然大部分代码是相同的了。此外我还写了一个工具支持图形组管理类，所见即所得的编辑动画和管理图片－当然这也对移植有帮助。
总结：
以上几条，总得讲来，无非是拆合而以。主要是要将差异性独立出来，便于更改。但是移植总得来讲还是比较郁闷，主要原因是各种机型有各自的bug，这就需要特殊处理啦。各位写代码时一定要想好移植的问题啊，就算自己不移植也要为移植的兄弟着想啊————
一 不大不小的Size问题
1 屏幕尺寸不等？把它看做变量！
第一个问题，就是屏幕的尺寸问题。不同牌子不同型号的手机，屏幕尺寸大小不一。在渲染时必须考虑到尺寸的变化，即将尺寸看成两个变量 ScreenWidth和ScreenHeight，将这两个变量代入到渲染时坐标的计算式中。这样屏幕尺寸变了，但想要的效果不会变。举个简单的例子，现在想居中绘制一个Logo图，只要设置渲染的坐标为: x=(ScreenWidth-ImageWidth)/2; y=(ScreenHeight-ImageHeight)/2即可。再举个RPG游戏中绘制地图的例子，假如Tile大小为16*16,屏幕大小为128*128,则一屏正好显示8*8个Tile,但是如果直接用8*8次循环绘制这些Tile,那么程序就写死了，如果屏幕大小变了（换了一个机型或改成使用全屏）或者Tile大小变了，这些地方就要改动。正确的方法还是将尺寸看做变量，可将Tile的宽和高定义为常量，这样需要绘制的Tile数目为 ScreenWidth/TileWidth * ScreenHeight/TileHeight。现在你可以在各种大小的屏幕上正确显示你的地图了。这样的例子很多，也不光是屏幕尺寸需要看作变量，凡是有可能改变的数值，将他们定义成变量或常量，那么可移植性就会提高很多。另外，使用相对坐标也能提高可移植性，比如现在需要绘制超级玛丽中得到的金币数，我们需要显示一个金币的图，然后在它后面写上数字。嗯，将金币的坐标设为gold_x,那么数字显示的起始坐标就是gold_x+金币图标宽度+1。我这儿写了一个1,但这不要紧，我只是想显示数字的时候和金币图标隔开一个象素，这样写后，如果我们想将金币数的显示从左边移到右边，则只要改变gold_x就可以啦。如果我们想让金币数目显示在屏幕的最右边怎么办？只要将gold_x设为 ScreenWidth-金币图标宽度-1-StringWidth(String(金币数目))。嗯，就是这样，这是一句伪码，重点在于我们将表示金币数目的数字的长度也计算了一遍。因为不同机器的字符大小也不同。
2 文字大小不等？还是将它看成变量！
说到文字，大家可能都会很郁闷，因为中文普遍比较大，做到手机里面很不美观。当然也有个别，NokiaS40的小字体看着还不错。这儿我想起了一件事，我将字体设为Large时，MotorolaV600的真机显示的是小字体！呵呵，原来设为Small，它倒是大字体。好了，说正题。既然文字大小不等，那我们还是将它看成变量。Font类有两个方法：getHeight和stringWidth可以帮助我们。如果你的游戏里只使用一种字体，那么只要开始时调用一下getHeight,将字体高度记录下来就可以了。当然要记得在paint里面setFont啊！stringWidth可以计算出一个字符串的长度，这非常有用，因为手机中的英文字体一般不是等宽的，而且中英文数字混排时字符串的长度就更不能用字符数*字符宽度去计算了。有了这个函数，我们就可以准确知道所绘制的字符串的长度。这里有个典型的应用是文本显示的时候换行，通过stringWidth可以计算出文本是否需要换行。再给个小小例子，我写得一个工具函数，用来显示左右软键菜单。
public static void drawSoftKeyMenu(Graphics g,String leftKey, String rightKey, int color, int style)
{
drawString(g,leftKey,0,canvasHeight-mainFontHeight,color,style,GLT) ;
drawString(g,rightKey,canvasWidth-stringWidth(rightKey),canvasHeight-mainFontHeight,color,style,GLT) ;
}
当然这个函数你不能直接用，里面用到了好几个我自己封装的函数，不过意思很明白。绘制左软键菜单的坐标是(0,canvasHeight-mainFontHeight),绘制右软键菜单的坐标是(canvasWidth-stringWidth(rightKey),canvasHeight-mainFontHeight)
3 虚拟屏幕 － 很好玩也很好用
第一个问题说了屏幕的大小，我们将它看作变量，就可以解决移植时屏幕不等大的问题了。这儿提供一个高级技巧，其实很简单:)。就是将屏幕的一部分作为你的游戏屏幕，我称它为虚拟屏幕。请相信，它是很有意思也很有用的。虚拟屏幕用起来很容易，只要将你的坐标范围看作: x=0~vsWidth , y=0~vsHeight。按照这个坐标范围，像原来一样作所有的事情，只是，在最后渲染的时候，将你的坐标转换到真实的屏幕坐标。 real_x = x+vsX, real_y = y+vxY 。那么这个虚拟屏幕有什么好处呢？第一，你可以用一个屏幕很大的模拟器开发了，只要在它的屏幕上设置一块虚拟屏幕就可以了。剩于的屏幕怎么办？可以用来显示一些调试信息什么的。当然最好也定义成虚拟屏幕。就是说你可以定义n个虚拟屏幕。每个屏幕显示自己的内容，互不影响。除了调试，开发分屏游戏时也用得上。
上面提到的虚拟屏幕只是简单的在真是屏幕上挖了一块。其实，我们可以完全按照自己的想法定义它，可以任意定义它的大小，定义一个1024×1024的屏幕也没问题。你现在拥有了一个1024*1024的游戏区域了，在里面可以尽情作所有的东西，只要，在渲染的时候将虚拟屏幕的坐标映射到真实屏幕即可: real_x = x/n + vsX , real_y = y/m + vsY 。这里的n和m是比例系数。
小结：这一章讲了size问题，一句话，将会变的看成变量，这不只是针对size有用，针对游戏开发时的所有量都是有效的。即使你确定它不变，也请使用常量定义，请放心，混淆器会将所有的final static内联的。
二 编写易于移植的J2ME代码
我写第一个J2ME游戏的时候，根本就没想过移植的问题。所以那个游戏也就很难移植了。反过来，如果你已经计划好要移植了，那么事情就简单的多。这一节说的是代码问题。那就想想，不同手机之间在代码上会有哪些差异。
(1) 屏幕尺寸不同
这在第一篇里面已经重点谈过，但这儿谈的是另一个问题，即自适应控件。所谓控件，就是菜单、文本框、列表框、进度条等等。这些控件的大小必须可以根据屏幕大小自适应的调整。按照第一篇说的方法，将屏幕大小作为变量参与到控件尺寸的计算即可得到正确的尺寸（自适应后的）。这儿讲第二个问题，即得到正确尺寸后怎么把它画出来。这要看你的GUI是怎么画得了，如果是用线画的，那就很简单；如果使用了图片，那么就可能要更换图片了。我的控件使用了图片平铺和画线结合，所以可以很容易的改变尺寸。如果控件变大了，则绘制时增加平铺的次数即可。顺便说一下，这些控件我只用了一个类表示，使用参数化的方法区分使用，毕竟咱要尽量少用类吧。
(2) 支持的API不同
如果你的游戏只限于使用Midp1.0，那么移植的时候就不用考虑什么了。实际上由于我们经常要使用图片翻转、象素绘制、全屏等，往往要用到厂商API或Midp2.0。显然移植的时候要考虑到这些api的差异。我的办法是将这些api封装一层，比如我需要使用创建透明子图的API，于是封装了一个函数createSubImg。这是Nokia版本：
public static Image createSubImg(Image img,int []imgRect)
{
Image subImg = DirectUtils.createImage(imgRect[2],imgRect[3],0) ;
subImg.getGraphics().drawImage(img,-imgRect[0],-imgRect[1],20);
return subImg ;
}
这是Midp2.0版本：
public static Image createSubImg(Image img,int []imgRect)
{
return Image.createImage(img,imgRect[0],imgRect[1],imgRect[2],imgRect[3],0) ;
}
对于不同机型，该函数的实现不同，但功能相同，因此使用这个函数的代码在移植时无需修改。当然这样做增加了一些间接性，有可能降低性能。
(3) 按键代码不同
我们知道MIDP提供了Game Action，和按键代码无关，但这不够用啊，我们完全可以定义自己的Game Action，但首先让我们定义自己的虚拟按键码吧。我使用位记录每个键的状态，每个位代表一个按键，一个int有32个位所以足够了。当keyPressed发生时，我记下哪些键被按下；同样当keyReleased时，将那些被松开的键使用的位清0。某个键，也就是这个键盘状态整数里的某个位，就是我定义的一个虚拟键。当然它的值总是2的n次方了，和key code完全不搭边，所以需要我们用一个映射函数将key code映射到这些虚拟键。这个函数就是移植的关键，每个机型都要改写这个映射函数，在里面填入正确的key code。你可以在虚拟键的基础上再定义Game Action,支持在游戏中设置按键，这样就更灵活了。
(4) 封装库
如果想不更改一行代码就从MotorolaV600移植到Nokia N-Gage，那么为他们封装不同的库吧。我就这样在1分钟内完成了移植^-^。我的库包含了一个游戏框架类（内含游戏循环和渲染函数，键盘处理，以及若干跨机型的工具函数），一个图形组管理类（管理图片的载入切割旋转绘制和动画等，有点像GameAPI中的Sprite）和一个控件类（包含了所有我需要的控件）。这3个类封装了不同机型的所有差异，我需要为每种机型改写这三个类，当然大部分代码是相同的了。此外我还写了一个工具支持图形组管理类，所见即所得的编辑动画和管理图片－当然这也对移植有帮助。
总结：
以上几条，总得讲来，无非是拆合而以。主要是要将差异性独立出来，便于更改。但是移植总得来讲还是比较郁闷，主要原因是各种机型有各自的bug，这就需要特殊处理啦。各位写代码时一定要想好移植的问题啊，就算自己不移植也要为移植的兄弟着想啊————
841
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
