基于j2me为平台的坦克大战游戏开发论文

基于j2me为平台的坦克大战游戏开发论文内容摘要：

概念，将数据封装于类中，实现了程序的简洁性和便于维护性，使程序代码可以只需一次编译就可反复利用。 4. 分布式 Java 建立在 TCP/IP 网络平台上，提供了用 HTTP 和 FTP 协议传送和接收信息的库函数，使用其相关技术可以十分方便的构建分布式应用系统。 5. 健壮性 Java 致力与检查程序在编译和运行时的错误，并自动回收内存，减少了 内存出错的可能性。 Java 取消了 C 语言的结构、指针、 define 语句、多重继承、goto 语句、操作符、重载等不易被掌握的特性，提供垃圾收集器自动回收不用的内存空间。 关于 JBuilder9 JBuilder 是目前最好的 Java 开发工具之一，在协同管理、对 J2EE 和 XML的支持等方面均走在其他产品的前面。 JBuilder 是遵循 Sun 公司 J2EE 标准的可视化集成开发工具。 Jbuilder 是一种处于市场领先地位的跨平台环境，主要用于构建具有行业实力的企业 Java 应用程序。 JBuilder 集成了 Borland 公司开发工具系列的优秀特性，使得使用过 C++Builder,Delphi 的程序员很容易的过度到JBuilder 的开发环境当中。 由于 Java 技术的发展迅速，经常有新的组件推出或 7 新的错误修正，致使 JBuilder 的版本升级很快。 当两年前还是 JBuilder6 时，现今已推出了 10的版本。 关于 Wireless Tool Kit WTK(Wireless Tool Kit)是 Sun 公司针对 J2ME 推出的用于手机和 Palm 等移动设备的开发包，是除手机厂商的专用开发包外唯 一的手机模拟器开发包。 它通用性高，开发出的应用程序可保证能运行在大部分设备上，而不像专用厂商具有一定的不兼容性。 虽然它没有强大的功能和完善的调试手段，但它提供运行模拟器的最基本组件 ，是其他 IDE 需集成采用的 必备元素。 Java Appication Manager 手机中负责调配程序运行资源的管理后台是 Java Application Manager。 它 所使用的 传输媒体 可以是 红外线 、 网络、以及其他可用来传输 的 媒体。 Java Application Manager 会 从网络 上 下载 代表 该 Application Suite 的 JAR 档 ，接 着 在手 机 上安裝此 MIDlet Suite， 然后 在手 机开 始 执行该应用程序。 整 个详细 的 运作 流程如 图 21 所示。 本章小结 ： 第二章介绍了 Java 语言的特点、本程序的开发环境及其相关工具的原理和使用。 存储 媒体 手机 内建浏览器 Java Appication Manager KVM 描述档 图示档 JAR 档 Java Servlet HTML 网页 6．安装应用程序 8．载入并执行应用程序 使用者手机 网站 网络 1．浏览网页 JAR 档 图 21 JAM 工作流程图 8 第三章 程序结构、思想和相关技术 本程序需解决的有关技术问题 1. 游戏程序是一项精度要求很高的程序系统，因为其代码利用率很高。 一个实时运行的 最终作品，每秒都会运行成千上万行程序，绘图事件、 键盘事件都会以极高的频率在后台等待响应，若有丝毫的差别都将很容易导致程序在运行不久后可能出现严重错误，甚至死循环。 因此，其逻辑设计应当相当严谨，需将所有可能发生的事件及意外情况考虑在设计中。 2. 游戏中为了美观，适用性强，可能需要采用外部文件引入的图片贴图，有关贴图，在 中提供了用于增强游戏功能的 game 包，使得解决静态或动态、画面背景、屏幕刷新的双缓冲等都有较好的解决方案。 3. 己方坦克的运行可以通过键盘响应事件控制，但敌方则因为是自动运行，就需要有一定其一定的智能性；同时，出现在屏幕 上的敌方可能会有较多的数量，这需要为每个敌方开辟一个线程以便能让其独立运行。 Java 的多线程能力为实现这样的游戏提供了可能。 敌人坦克的运行算法也需要进行适当的设置，以免游戏过于简单，单调。 4. 对于双方坦克发出的子弹的控制也需要 对其跟踪控制，子弹也需要处在独立的线程中。 敌方子弹仅需要扫描用户坦克，而用户坦克需要在每一步扫描所有的敌方坦克。 这需要对所有的对象有较好的控制。 另外，子弹在运行过程中也需要实时扫描是否碰撞到了相关障碍物或屏幕边界。 如此过多的线程同时在本来效率就不高的 KVM 虚拟机上运行，也许会导致 程序的缓慢。 5. 双方的坦克在前进时也需要考虑到是否碰撞到相关物体或对方坦克，以免重叠运行，造成许多物理上不可能的情况，缺乏真实感。 每一次刷新页面、每前进一步都需要将所有的周围环境都进行扫描。 6. 游戏的结束、开始、动态信息画面作为构成一个完美程序都是必不可少的重要部分。 良好的用户界面更是吸引用户的硬指标，相关的美术构图也需要有一定的考虑。 7. 游戏的地图不可能通过绘图来解决。 否则，不仅难于控制和处理过多的元素，也会因过多的大型图片而不能限制程序的大小，失去手机上程序的原则和Java 的优势。 同时 ，地图关卡不宜保存在手机有限的内存中，而最好采取外部文件的读入读出方法。 8. 用户运行游戏时需要有分数记录的可能。 如何采用合理的记分标准，需要进行适当的设计。 记录分数的存储方式也需要有较好的解决方案。 手机中由于处理器和内存空间、存储空间都十分有限，其数据库系统与普通 PC大相径庭。 其数据库结构较为简单，被称之为 RMS 系统。 9. Java 是基于虚拟机的半解释型编译系统，其执行效率较 C++等完全编译 9 后的程序会低很多，程序如果不进行精简和优化，将可能导致运行的不流畅。 除开发过程中对结构上的控制、变量的使用、 算法的优化等优化外，还可以使用混淆器 (Obfuscator)进行程序打包后的优化。 以上相关技术细节和整体流程将分别在以下小节阐述。 程序流程 MIDlet suite 是 MIDP 应用程序的最小单位， JAM 负责将手机内的 MIDlet suite 以图形化的方式呈现，让用户能够选取欲执行的 MIDlet suite，一旦选取了某个 MIDlet suite，操作系统就会激活 KVM 执行里面的 MIDlet。 MIDlet 及相关的支持类组成了 MIDP 应用程序的实际内容。 每个 MIDlet 都必须继承 这个抽象类。 在 MIDP 规格中定义了 MIDlet 的生命周期，以及可以存在的三种状态，包括Paused、 Active 以及 Destroyed，每一个 MIDlet 在任何时刻只可能处于其中的一个状态。 这三种状态的转换关系如图所示： 本程序采用面向对象的设计模式，对游戏中的所有物体赋予对象的概念和属性。 运行程序后允许用户选择执行选项菜单，在开始游戏后将先从外部文件载入地图文件，对背景的所有物体进行绘图。 在主程序运行的线程中，画面刷新将以一定的频率采用双缓冲技术 对屏幕重 绘，实时反映整个游戏的进行状态。 用户控制的坦克运行在主线程中，随屏幕刷新的频率而步进。 敌方坦克将在游戏开始时逐渐新增线程，每增加一个敌方对象就新增加一条线程，一旦线程数满到最大值（本程序暂设置为 6），就不允许敌人再继续出现。 用户坦克自诞生之时起将拥有一发子弹， 子弹虽然开在单独的线程中，但运行结束后（比如撞到相关物体或敌方坦克时）并不结束子弹对象，只是将其线程终止。 用户再次发射子弹 时只是将终止的线程再次激活。 在屏幕重绘的主程序中，将在每次的循环中判断若干事件。 如：用户坦克的生命是否已完全用尽，敌方坦克数是否已 经为零，屏幕上的消减状态 (Destroyed) 停止状态 (Paused) 运行状态 (Active) StartApp() DestroyApp() 呼叫 MIDlet的构造函数 DestroyApp() PauseApp() 图 31 MIDlet 的流程 10 坦克数量是否少 于仍剩下的坦克数量等。 以便程序进入相关的分支执行相关的反应代码，结束游戏或统计分数等。 主程序流程如图 32所示： 程序为需要完成独立功能的需显示的模块设置了单独的类。 TankMain 类是继承自 MIDlet的控制主程序启动的首先被载入系统的部分。 载入程序后首先启动的是程序介绍的信息画面。 闪过后载入 StartChoice 类，为用户提供可选择的选项。 在选择开始后，将运行BattleCanvas 类中的总流程控制。 它决定了游戏何时该结束，何时分配敌人数量， GameOver字样的闪现规 则，地图的绘制及整个游戏的调度。 图 33是程序中类之间的 UML 分析图。 敌方坦克与用户坦克的相关功能和具体行为分别图 33 与主程序相关的类的 UML 视图 Logo 画面 选项画面 主程序 屏幕绘图 本关记分统计 显示GameOver 显示历史记分表 About 开始 敌方需要出坦克时，生成坦克 初始化参数 死亡时 符合结束条件时 图 32 本程序的主流程图 11 定义在 EnemySprite 和 UserSprite 类中，它们都继承自 TankSprite 公共类，以简化程序的代码、理清结构。 在每关的结束或死亡后都将载入 ScoreScreen 类，统计当前的分数。 如果已死亡或完成所有的关数，程序将用户所得的分数记载到 RMS 数据库中，进行永久性保存。 载入过程中将对所得分数与以往历史比较，放置到合适的位置中，形成排序。 绘图与 新增的 GameCanvas 包 提供低级绘制的 Canvas 类 为了能有程序开发人员控制接口的外观和行为，需要使用大量的初级用户接口类，尤其在游戏程序中，几乎完全依赖的就是 Canvas 抽象类进行绘图。 从程序开发的观点看， Canvas 类可与高级 Screen 类交互，程序可在需要时在 Canvas中掺入高级类的组件。 Canvas 提供了键盘事件、指点杆事件（如果设备支持），并定义了允许将键盘按键映射为游戏控制键的函数。 键盘事件由键代码指定，但这样控制游戏会导致缺乏通用性，并不是每个设备的键盘布局都适合游戏的操作。 应 当将键代码转换为游戏键的代码，以便硬件开发商能定义他们自己的游戏键布局。 本程序中，操纵用户坦克运行的按键都定义为游戏控制键，这样便能适应所有的机器。 Graphics 类 Graphics 类提供了简单的 2D 绘图功能。 它具有 24 位深度色彩的绘制能力，以三原色分别各占一个字节表示其颜色。 程序只能在 paint()函数中使用Graphics 绘制， GameCanvas 可 调用 getGraphics()函数 直接绘制在缓冲区上，可以在任何时间请求传输到前台。 其对象会被传给 Canvas 的 paint()函数，以便 最终显示。 PNG 格式 PNG(Portable Network Graphics)格式是 MIDlet 唯一支持的图象格式， PNG具体格式由 PNG Specification,Version 定义的。 PNG格式提供透明背景的图象，这对绘制游戏画面和被操纵主角极有帮助。 坦克之间或与障碍物碰撞时就不会因为背景有特定的颜色，显示出的效果像贴上的图片而缺乏真实感，物体之间轻微重叠时最上层图片也不会覆盖超过其有效象素外的部分。 PNG 格式图片中包含许多定义其图片特性的冗余部分 (Chunks)。 这些 代码包含在每一个单独的 png 格式图象中，然而如果将多个 png 图象合并在一张幅面稍 12 大一些的整图中，多个 chunks 就可以得到精简，图片的大小可以得到控制。 使用 Image 类中的 createImage 函数可从整图中分割出所需要的元素。 在 Game 包中的 TiledLayer 和 Sprite 类都整合了这样的功能。 本程序中的地图元素都集成在一张 图片中 ，实现了方便的管理和程序体积的精简。 Game包中的新功能 MIDP 自 以后新增了 Game 包，为游戏的开发带来了极大的便利。 地图绘制、主角的动态显示、按键的检测、图层的控制等游戏专属的特性都得到了在移动设备上最大的发挥。 LayerManager（以下简称 LM） 提供控制整体画面层的控制。 它包括了一系列自动获取了代号和位置的层，简化了各层加入游戏画面的过程，提供了自动排序和绘制的能力。 LM 存储了一个层的列表，新的层可以用 append 函数附加、删除和插入。 层的序号相当于坐标的 Z轴， 0层表示最接近用户视觉，层数越高，离用户越远。 层号总是连续的，即使有中间的层被移除，其他层的序号会作相应的调整以保持整体的完整性。 LM 中的 View Window 控制着与 LM 相对坐标的可视区域。 改变 View Window 的位置可以制造出滚动。