/** 代表回合结束显示状态的常量 */如图4.9
图4.9回合结束画面
Fig4.9.At an end appearance in bout
Private static final short ROUND_END =9 ;
/** 代表回合过关状态的常量 */如图4.10
图4.10回合过关画面 Fig4.10. Bouts pass the appearance
Private static final short ALL_ROUND_CLEAR =10 ;
另外，除了上述提到的五种状态变量，还涉及到了代表存储现在状态的变量（game state）与暂停状态的标识（ispaused）。代码如下： /** 存储现在显示状态的变量 */
Private short gamestate ; /** 代表暂停状态的标志 */
Private Boolean ispaused ; 4.2.9 按键事件的处理
在进行按键处理的key Pressed方法中，当不是在回合中的时候或是在回合中但暂停中的时候，由于没有必要所以不进行处理。除此之外，在拳击中也不进行任何的处理，这是因为如果在拳击当中若能做出其他动作的话会非常奇怪。当都不符合以上条件时，就要根据所按下的数字按键来更改使用者的状态。在这款游戏中按键是这样分配的：“1”后退、“4”后退、“2”上方防御、“5”下方防御、“3”上方攻击、“6”下方攻击。当为上方攻击和下方攻击时，就要调用出doLifepointCheck4 Enemy( )方法来根据对手的状态减少生命点数，然后根据生命点数的剩余量来结束回合。 4.2.10 设计存在的难点
在这款游戏的设计全过程中，还是存在着一些难点的。首先在开发环境的准备过程中，J2MEWTK中所附带的模拟器除了灰阶的以外还有许多种类，虽然可以在模拟器启动后进行选择，但是要使用彩色画面的模拟器的话，则要在每次启动J2MEWTK后都得进行一次选择，所以说相当不方便。因此，就有必要将默认的模拟器变成彩色移动电话的模拟器，这样一来在启动J2MEWTK之后就不用再去选择使用彩色的模拟器了。
其次，在设置默认模拟器的DefaultColarPhone的时候，其画面大小为纵向100像素、横向96像素。不过，实际上一些移动电话的终端画面都在纵向130像素、横向120像素以上，因此这个设置并不符合现实状况，所以还必须修改属性文件。
最后，在编写程序代码之后，要进行验证处理，另外还要将Class文件与数据文件打包（JAR文件）在一起。要以KToolbar来进行打包时，只要从KToolbar的“project”菜单选择KToolbar的打包处理就会帮助一起进行编译以及运行前的验证处理了。
以上就是对“Pocket Boxing”游戏在整个制作过程中的介绍和对过程中存在的一些难点的分析。
第5章 手机游戏开发过程中的困难
5.1 手机游戏开发存在的困难
当电脑游戏被称为第九艺术，也许我们可以因此期待手机游戏会得到一个冠冕堂皇的称号——因为手机游戏已经渐渐成为游戏业继网络游戏之后，又一座富饶的“金矿”，成为游戏市场中一颗冉冉升起的新星。
但是现在，用“简陋”一词来形容现今的手机游戏并不为过，因为玩家大多无法对那个手掌里的小屏幕集中太多的注意力，特别是手机游戏的分辨率还很低，很容易让人想到十几年前的红白机游戏时代。这是以时尚标榜自己的年轻人无法接受的。而且现在很多手机用户对于手机游戏的认识还停留在经典的“贪吃蛇”，所以那些所谓的手机游戏实在让人提不起什么兴趣来。
在游戏开发的初期阶段，并没有传统游戏的开发者参与。移动游戏时代是从WAP游戏开始的，主要是文字，并配有少量的图形。美国的移动运营商很快地注意并分析了这些问题，他们从日本I-mode的巨大成功中获取了经验。I-mode到去年年底已经有3000万用户下载娱乐游戏，这占公司年收入的很大一部分。移动运营商推出了下一代移动电话，能够支持因特网功能。与老式的黑白文字手机相比，这些手机更加快并且功能更加强大，它们带有彩色的屏幕和因特网浏览功能，使用比大部分个人电脑拨号上网速度更快的连接速度。
虽然新手机还不是最理想的游戏平台，但它已经是个良好的开端。处理器、内存和色彩深度提供了游戏开发所需的因素。开发者正努力把其它游戏平台上的质量标准运用到这个平台上。当然了，一些问题仍然存在，然而这些问题终将被解决，就像PC平台游戏开发者使用不断改进的DirectX一样。
当然在手机游戏投放市场和开发以及具体的制作过程方面还是存在的诸多的问题的。
5.1.1 移动开发存在的问题
开发移动游戏与传统游戏的开发有很多不同，想开发有吸引力的移动游戏尤其困难。这比开发控制台游戏或PC游戏更困难，因为众多的设备具有不同的存贮器、声音和显示性能。除此之外，你还必须合理利用J2ME这样的开发环境。 开发移动游戏需要一套与普通游戏不同的方法和思路。移动游戏的预算很小而且时间安排很短。这个平台有许多种硬件和软件的组合，并且在硬件厂商之间没有多少共同点。
第一、花费更多的时间用来设计。开发者都有想用最简捷经济的方式做事的倾向。然而，为了创作一个世界第一流水平的游戏，你就必须使用世界第一流水平的开发过程。关键步骤是设计思路、试制、生产和产品质量检测。然而，因为设备和移动运营商的多样性，开发者不得不花费更多的时间用于前期的计划。这就存在这一种风险，那就是一个设计可以用于一种设备，但是可能就不能用在另一种设备。
第二、像在PC中一样，为硬件的\最小公分母（\ lowest common denominator ）开发，这意味着你的代码不能对硬件和操作系统以及程序设计语言之间的交互抱过高幻想。
第三、类似于硬件中的问题，开发两个API之间的基本功能。比较软件开发环境和围绕它们的不足进行针对性设计。开发者必须花费更多的时间了解这两个平台，但是最后的效果是很值得的。 5.1.2 操作环境不兼容性问题
本论文讲述的移动开发环境是J2ME，J2ME是获得美国大部分移动运营商支持的移动应用开发平台。J2ME是一个解释语言，运行在有虚拟机的任何操作系统上，通常运行速度很慢，而且在优化代码上有许多的困难。
在过渡期间，为这个环境开发游戏成为一种挑战。例如，BREW 1.0支持掩盖
的位图传送（ Masked-Blit ），而J2ME MIDP 1.4不支持。而且，一些J2ME手机不支持声音。所以你的代码不应该使用掩盖的位图传送支持或者声音支持。比如说，如果你创建自定义位图字体，你可能认为你需要掩盖的位图传送。然而，你可以使用提前修正背景色来创建字体位图。这两个平台可以在载入一个文件的时候改变调色板，允许动态的调整字体背景色，但是文本必须出现在固定的背景上。 5.1.3 显示速度方面的问题
在移动游戏开发过程中，最大的问题是缺乏对显示速度的重视。虽然移动运营商已经选择了强大的处理器和彩色的显示屏，但是他们忽略了对于游戏来说至关重要的一个方面。
手机使用许多绘制程序，一些支持双缓冲技术，而另一些不支持。在某些情况下，可以更容易的直接绘制到屏幕上。直接绘制到屏幕有时比双缓冲更快。然而，使用低刷新速率在屏幕上绘制大的图像可能会引起闪烁。造成这一问题的原因在于，画面在显示的同时，程序又在改变它，于是画面闪烁。 5.1.4 不同的屏幕尺寸问题
图形是游戏的一个关键的方面，描画速度是一个重要的程序函数。不同于控制台游戏和PC游戏，移动设备没有标准的屏幕尺寸或者长宽比，这就导致了很多兼容性问题。开发者可以通过编写非常灵活的背景和前景描画程序来解决这个问题。关键是创建一个允许快速扩展或者缩小游戏视窗的架构，并且不使图像变形或者生成让人看上去觉得别扭的屏幕比例。
当然，你有很多方法来处理这个问题，最坏的情况就是你可以为每种手机的显示屏重新设计图形。或者，你还可以动态地调节你的游戏背景和其它图形。