java编写的坦克大战的游戏毕业设计

第三章 程序结构、思想和相关技术

3.1 本程序需解决的有关技术问题

1. 游戏程序是一项精度要求很高的程序系统，因为其代码利用率很高。一个实时运行的最终作品，每秒都会运行成千上万行程序，绘图事件、键盘事件都会以极高的频率在后台等待响应，若有丝毫的差别都将很容易导致程序在运行不久后可能出现严重错误，甚至死循环。因此，其逻辑设计应当相当严谨，需将所有可能发生的事件及意外情况考虑在设计中。

2. 游戏中为了美观，适用性强，可能需要采用外部文件引入的图片贴图，有关贴图，在MIDP2.0中提供了用于增强游戏功能的game包，使得解决静态或动态、画面背景、屏幕刷新的双缓冲等都有较好的解决方案。

3. 己方坦克的运行可以通过键盘响应事件控制，但敌方则因为是自动运行，就需要有一定其一定的智能性；同时，出现在屏幕上的敌方可能会有较多的数量，这需要为每个敌方开辟一个线程以便能让其独立运行。Java的多线程能力为实现这样的游戏提供了可能。敌人坦克的运行算法也需要进行适当的设置，以免游戏过于简单，单调。

4. 对于双方坦克发出的子弹的控制也需要对其跟踪控制，子弹也需要处在独立的线程中。敌方子弹仅需要扫描用户坦克，而用户坦克需要在每一步扫描所有的敌方坦克。这需要对所有的对象有较好的控制。另外，子弹在运行过程中也需要实时扫描是否碰撞到了相关障碍物或屏幕边界。如此过多的线程同时在本来效率就不高的KVM虚拟机上运行，也许会导致程序的缓慢。

5. 双方的坦克在前进时也需要考虑到是否碰撞到相关物体或对方坦克，以免重叠运行，造成许多物理上不可能的情况，缺乏真实感。每一次刷新页面、每前进一步都需要将所有的周围环境都进行扫描。

6. 游戏的结束、开始、动态信息画面作为构成一个完美程序都是必不可少的重要部分。良好的用户界面更是吸引用户的硬指标，相关的美术构图也需要有一定的考虑。

7. 游戏的地图不可能通过绘图来解决。否则，不仅难于控制和处理过多的元素，也会因过多的大型图片而不能限制程序的大小，失去手机上程序的原则和Java的优势。同时，地图关卡不宜保存在手机有限的内存中，而最好采取外部文件的读入读出方法。

8. 用户运行游戏时需要有分数记录的可能。如何采用合理的记分标准，需要进行适当的设计。记录分数的存储方式也需要有较好的解决方案。手机中由于处理器和内存空间、存储空间都十分有限，其数据库系统与普通PC大相径庭。其数据库结构较为简单，被称之为RMS系统。

免责声明：文档在线网（文档中国）中所有的文档资料均由文档在线网会员提供。文档在线网会对会员提供的文档资料进行筛选和编辑，但是并不声明或保证其内容的合法性、正确性或可靠性。该文档资料的版权属于提供者所有，有关版权的问题请直接与提供者联系。

9. Java是基于虚拟机的半解释型编译系统，其执行效率较C++等完全编译后的程序会低很多，程序如果不进行精简和优化，将可能导致运行的不流畅。除开发过程中对结构上的控制、变量的使用、算法的优化等优化外，还可以使用混淆器(Obfuscator)进行程序打包后的优化。

以上相关技术细节和整体流程将分别在以下小节阐述。

3.2 程序流程

MIDlet suite是MIDP应用程序的最小单位，JAM负责将手机内的MIDlet suite以图形化的方式呈现，让用户能够选取欲执行的MIDlet suite，一旦选取了某个MIDlet suite，操作系统就会激活KVM执行里面的MIDlet。MIDlet及相关的支持类组成了MIDP应用程序的实际内容。

每个MIDlet都必须继承javax.microedition.midlet.MIDlet这个抽象类。在MIDP规格中定义了MIDlet的生命周期，以及可以存在的三种状态，包括Paused、Active以及Destroyed，每一个MIDlet在任何时刻只可能处于其中的一个状态。这三种状态的转换关系如图所示： 呼叫MIDlet的构造函数 停止状态 (Paused) StartApp() DestroyApp() 运行状态 (Active) PauseApp() DestroyApp() 消减状态 (Destroyed) 图3-1 MIDlet的流程

本程序采用面向对象的设计模式，对游戏中的所有物体赋予对象的概念和属性。运行程序后允许用户选择执行选项菜单，在开始游戏后将先从外部文件载入地图文件，对背景的所有物体进行绘图。在主程序运行的线程中，画面刷新将以一定的频率采用双缓冲技术对屏幕重绘，实时反映整个游戏的进行状态。用户控制的坦克运行在主线程中，随屏幕刷新的频率而步进。敌方坦克将在游戏开始时逐渐新增线程，每增加一个敌方对象就新增加一条线程，一旦线程数满到最大值（本程序暂设置为6），就不允许敌人再继续出现。用户坦克自诞生之时起将拥有一发子弹，子弹虽然开在单独的线程中，但运行结束后（比如撞到相关物体或敌方坦克时）并不结束子弹对象，只是将其线程终止。用户再次发射子弹时只是

免责声明：文档在线网（文档中国）中所有的文档资料均由文档在线网会员提供。文档在线网会对会员提供的文档资料进行筛选和编辑，但是并不声明或保证其内容的合法性、正确性或可靠性。该文档资料的版权属于提供者所有，有关版权的问题请直接与提供者联系。

将终止的线程再次激活。在屏幕重绘的主程序中，将在每次的循环中判断若干事件。如：用户坦克的生命是否已完全用尽，敌方坦克数是否已经为零，屏幕上的坦克数量是否少于仍剩下的坦克数量等。以便程序进入相关的分支执行相关的反应代码，结束游戏或统计分数等。主程序流程如图3-2所示：

程序为需要完成独立功能的需显示的模块设置了单独的类。TankMain类是继承自MIDlet的控制主程序启动的首先被载入系统的部分。载入程序后首先启动的是程序介绍的信息画面。闪过后载入StartChoice类，为用户提供可选择的选项。在选择开始后，将运行BattleCanvas类中的总流程控制。它决定了游戏何时该结束，何时分配敌人数量，GameOver字样的闪现规则，地图的绘制及整个游戏的调度。

图3-3是程序中类之间的UML分析图。敌方坦克与用户坦克的相关功能和具体行为分别显示历史记分表 图3-2 本程序的主流程图 选项画面 开始 主程序 敌方需要出坦克时，生成坦克 Logo 画面 About 初始化参数 屏幕绘图 符合结束条件时 死亡时 显示GameOver 本关记分统计 免责声明：文档在线网（文档中国）中所有的文档资料均由文档在线网会员提供。文档在线网会对会员提供的文档资料进行筛选和编辑，但是并不声明或保证其内容的合法性、正确性或可靠性。该文档资料的版权属于提供者所有，有关版权的问题请直接与提供者联系。

图3-3 与主程序相关的类的UML视图

定义在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)。这些代码包

免责声明：文档在线网（文档中国）中所有的文档资料均由文档在线网会员提供。文档在线网会对会员提供的文档资料进行筛选和编辑，但是并不声明或保证其内容的合法性、正确性或可靠性。该文档资料的版权属于提供者所有，有关版权的问题请直接与提供者联系。