发布时间 : 星期二 文章基于J2ME的Java游戏--坦克大战的开发毕业设计论文更新完毕开始阅读de8e9b6a561252d380eb6e62
坦克数量是否少于仍剩下的坦克数量等。以便程序进入相关的分支执行相关的反应代码，结束游戏或统计分数等。主程序流程如图3-2所示：
程序为需要完成独立功能的需显示的模块设置了单独的类。TankMain类是继承自MIDlet的控制主程序启动的首先被载入系统的部分。载入程序后首先启动的是程序介绍的信息画面。闪过后载入StartChoice类，为用户提供可选择的选项。在选择开始后，将运行BattleCanvas类中的总流程控制。它决定了游戏何时该结束，何时分配敌人数量，GameOver字样的闪现规则，地图的绘制及整个游戏的调度。
图3-3是程序中类之间的UML分析图。敌方坦克与用户坦克的相关功能和具体行为分别
显示历史记分表 图3-2 本程序的主流程图
选项画面 开始 主程序 敌方需要出坦克时，生成坦克 Logo 画面 About 初始化参数 屏幕绘图 符合结束条件时 死亡时 显示GameOver 本关记分统计 图3-3 与主程序相关的类的UML视图
- 10 -
定义在EnemySprite和UserSprite类中，它们都继承自TankSprite公共类，以简化程序的代码、理清结构。
在每关的结束或死亡后都将载入ScoreScreen类，统计当前的分数。如果已死亡或完成所有的关数，程序将用户所得的分数记载到RMS数据库中，进行永久性保存。载入过程中将对所得分数与以往历史比较，放置到合适的位置中，形成排序。
3.3 绘图与MIDP2.0新增的GameCanvas包
3.3.1 提供低级绘制的Canvas类
为了能有程序开发人员控制接口的外观和行为，需要使用大量的初级用户接口类，尤其在游戏程序中，几乎完全依赖的就是Canvas抽象类进行绘图。从程序开发的观点看，Canvas类可与高级Screen类交互，程序可在需要时在Canvas中掺入高级类的组件。Canvas提供了键盘事件、指点杆事件（如果设备支持），并定义了允许将键盘按键映射为游戏控制键的函数。键盘事件由键代码指定，但这样控制游戏会导致缺乏通用性，并不是每个设备的键盘布局都适合游戏的操作。应当将键代码转换为游戏键的代码，以便硬件开发商能定义他们自己的游戏键布局。本程序中，操纵用户坦克运行的按键都定义为游戏控制键，这样便能适应所有的机器。
3.3.2 Graphics类
Graphics类提供了简单的2D绘图功能。它具有24位深度色彩的绘制能力，以三原色分别各占一个字节表示其颜色。程序只能在paint()函数中使用Graphics绘制，GameCanvas可调用getGraphics()函数直接绘制在缓冲区上，可以在任何时间请求传输到前台。其对象会被传给Canvas的paint()函数，以便最终显示。
3.3.3 PNG格式
PNG(Portable Network Graphics)格式是MIDlet唯一支持的图象格式，PNG具体格式由PNG Specification,Version 1.0定义的。PNG格式提供透明背景的图象，这对绘制游戏画面和被操纵主角极有帮助。坦克之间或与障碍物碰撞时就不会因为背景有特定的颜色，显示出的效果像贴上的图片而缺乏真实感，物体之间轻微重叠时最上层图片也不会覆盖超过其有效象素外的部分。
PNG格式图片中包含许多定义其图片特性的冗余部分(Chunks)。这些代码包含在每一个单独的png格式图象中，然而如果将多个png图象合并在一张幅面稍
- 11 -
大一些的整图中，多个chunks就可以得到精简，图片的大小可以得到控制。使用Image类中的createImage函数可从整图中分割出所需要的元素。在Game包中的TiledLayer和Sprite类都整合了这样的功能。本程序中的地图元素都集成在一张tile.png图片中，实现了方便的管理和程序体积的精简。
3.3.4 Game包中的新功能
MIDP自2.0以后新增了Game包，为游戏的开发带来了极大的便利。地图绘制、主角的动态显示、按键的检测、图层的控制等游戏专属的特性都得到了在移动设备上最大的发挥。
LayerManager（以下简称LM）提供控制整体画面层的控制。它包括了一系列自动获取了代号和位置的层，简化了各层加入游戏画面的过程，提供了自动排序和绘制的能力。
LM存储了一个层的列表，新的层可以用append函数附加、删除和插入。层的序号相当于坐标的Z轴，0层表示最接近用户视觉，层数越高，离用户越远。层号总是连续的，即使有中间的层被移除，其他层的序号会作相应的调整以保持整体的完整性。LM中的View Window控制着与LM相对坐标的可视区域。改变View Window的位置可以制造出滚动屏幕的效果。
本程序中所有的地图、坦克都采用LM控制，敌方坦克的生成由附加一个EnemySprite对象得到。唯有界面右侧的计分栏由Graphics类绘制。
Sprite类是继承自Layer的用于存储多桢的基本可视元素。不同的frame可交相显示，构成动态的效果。图片可翻转、颠倒、由一个主角图片就可以方便的得到所有方向的显示状态，相比原先只能使用Canvas绘图，需要将所有方向的主角图象都绘制在png图象中简化了许多。Sprite也可以从整合的图象中读图，读图时将把大图分解为若干等宽等高的小图。每个小图按照其排列顺序有相应的序号，在程序中调用其序号，就可以绘制出相应的图片。本程序中的双方坦克、子弹都由Sprite继承得到。在有些情况下，控制主角的翻转，尤其是多幅图片配合显示的过程，如果将多图的共享定位点设置在通常的左上角，将很不容易控制，因为许多翻转都是以其他点为参考电的（比如，中心点）。由此，引入参考点的概念。参考点由defineReferencePixel函数确定未翻转图片状态时的坐标。默认是(0,0)点，如果需要，可将参考点设置在画面边界之外。本程序中的坦克的参考点定义在图片正中，以便简便的实现转向等功能。子弹的参考点设置在子弹底部的中心，因为子弹一出炮筒的时候紧挨着坦克的象素就是其底部中心。
TiledLayer是有一组图象格元素(grid of cells)组成的整块虚拟图象。该类使不需要高分辨率的图象就能创建大幅图面成为可能。这项技术通常应用在2D游戏平台的滚动背景的绘图。一块整图可被分割成等大小的图象格，每块格有其对应的序号，按照行列递增。多块格可由大块同时替换组合而模拟动态的背
- 12 -
景，这不需要逐块替换所有的静态图象格而显得非常方便。
本程序中的地图即为游戏背景。每块障碍物都有其响应的代号，其中，用户需保护的总部因为体积稍大，使用了四块图象格显示。地图背景分为20*22个图象格，每个格使用一个字节表示其中的障碍物，图象文件存储在外部文件中，以16进制的整数串表示，因此每个地图的大小为固定的440字节。如果整块地图均由绘图产生，将导致体积迅速增加，且对坦克与障碍物的碰撞也难以检测。J2ME中并没有J2SE中的File类，获取外部文件的手段很有限，仅仅在Class类中提供了一个getResourceAsStream函数，将外部文件获取为输入流，再由InputStream的继承类读出。
3.3.5 有关绘图的一些技术
在没有MIDP2.0前，进行游戏绘图一般需要手动编程使用双缓冲。需要在paint()方法内所想要画的图形画在一张预先准备好的背景，等所有绘图操作都完成后再将背景的数据拷贝到实际的屏幕上。Image类提供了一个建立背景的静态方法createImage(int width, int height)，再利用getGraphics()方法取得属于这个背景的Graphics对象，所进行的绘图操作都会作用在背景上，等到全部的绘图操作完成后，再调用drawImage()方法将背景的数据复制到实际显示的屏幕上。
这样的技术在绘制动画时特别有用。绘制动画时经常需要不断地更新画面，而更新画面的操作就是先将屏幕以fillRect()的方式清除，再将下一张图片画在屏幕上，然而反复的清除及重绘会造成屏幕的闪烁现象（flicker），因此使用双重缓冲的好处就是在背景进行这个清除及重绘的操作，再将完成的绘图拷贝到屏幕上，由于用户看不到清除的操作，因此就不会出现闪烁的现象了。不过在某些MIDP的实现上已经加上了双重缓冲的支持，因此在处理前应先利用Canvas类的isDoubleBuffer()方法来判断。
3.4 坦克的控制和敌方的智能运行
GameCanvas中提供了与以往MIDP1.0不同的键盘采样功能。Canvas类中采取响应键盘事件的方法，每次执行周期时会读取keyPressed函数中需执行的代码。这样的机制并不适合某些游戏场合。在某些不支持keyRepeat功能的设备上，反复执行的按键，比如发射子弹，将不能因为长时间按压而自动重复，这样就需要用户高频率的手动击键，这在操纵空间非常有限的移动设备上是非常困难的。同时，事件的执行周期也并不一定适合游戏的场合，也许需要更高频率执行的按键却只能在指定的周期内规律的响应。对此，针对游戏的开发，Game包提供的键盘状态功能将显得十分有效。
- 13 -