der是遵循Sun公司J2EE标准的可视化集成开发工具。Jbuilder是一种处于市场领先地位的跨平台环境，主要用于构建具有行业实力的企业Java应用程序。JBuilder集成了Borland公司开发工具系列的优秀特性，使得使用过C++Builder,Delphi的程序员很容易的过度到JBuilder的开发环境当中。由于Java技术的发展迅速，经常有新的组件推出或新的错误修正，致使JBuilder的版本升级很快。当两年前还是JBuilder6时，现今已推出了9、10的版本。
    2.4 关于Wireless Tool Kit
     WTK(Wireless Tool Kit)是Sun公司针对J2ME推出的用于手机和Palm等移动设备的开发包，是除手机厂商的专用开发包外唯一的手机模拟器开发包。它通用性高，开发出的应用程序可保证能运行在大部分设备上，而不像专用厂商具有一定的不兼容性。虽然它没有强大的功能和完善的调试手段，但它提供运行模拟器的最基本组件，是其他IDE需集成采用的必备元素。
    2.5 Java Appication Manager
    　　手机中负责调配程序运行资源的管理后台是Java Application Manager。它所使用的传输媒体可以是红外线、网络、以及其他可用来传输的媒体。Java Application Manager 会从网络上下载代表该Application Suite 的JAR 档，接着在手机上安裝此MIDlet Suite，然后在手机开始执行该应用程序。整个详细的运作流程如图2-1所示。
    2.6 本章小结:
    第二章介绍了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在任何时刻只可能处于其中的一个状态。这三种状态的转换关系如图所示:
    　　本程序采用面向对象的设计模式，对游戏中的所有物体赋予对象的概念和属性。运行程序后允许用户选择执行选项菜单，在开始游戏后将先从外部文件载入地图文件，对背景的所有物体进行绘图。在主程序运行的线程中，画面刷新将以一定的频率采用双缓冲技术对屏幕重绘，实时反映整个游戏的进行状态。用户控制的[网学用户上传]运行在主线程中，随屏幕刷新的频率而步进。敌方[网学用户上传]将在游戏开始时逐渐新增线程，每增加一个敌方对象就新增加一条线程，一旦线程数满到最大值（本程序暂设置为6），就不允许敌人再继续出现。用户[网学用户上传]自诞生之时起将拥有一发子弹，子弹虽然开在单独的线程中，但运行结束后（比如撞到相关物体或敌方[网学用户上传]时）并不结束子弹对象，只是将其线程终止。用户再次发射子弹时只是将终止的线程再次激活。在屏幕重绘的主程序中，将在每次的循环中判断若干事件。如:用户[网学用户上传]的生命是否已完全用尽，敌方[网学用户上传]数是否已经为零，屏幕上的[网学用户上传]数量是否少于仍剩下的[网学用户上传]数量等。以便程序进入相关的分支执行相关的反应代码，结束游戏或统计分数等。主程序流程如图3-2所示:
    　　程序为需要完成独立功能的需显示的模块设置了单独的类。TankMain类是继承自MIDlet的控制主程序启动的首先被载入系统的部分。载入程序后首先启动的是程序介绍的信息画面。闪过后载入StartChoice类，为用户提供可选择的选项。在选择开始后，将运行BattleCanvas类中的总流程控制。它决定了游戏何时该结束，何时分配敌人数量，GameOver字样的闪现规则，地图的绘制及整个游戏的调度。
    　　图3-3是程序中类之间的UML分析图。敌方[网学用户上传]与用户[网学用户上传]的相关功能和具体行为分别定义在EnemySprite和UserSprite类中，它们都继承自TankSprite公共类，以简化程序的代码、理清结构。
    　　在每关的结束或死亡后都将载入ScoreScreen类，统计当前的分数。如果已死亡或完成所有的关数，程序将用户所得的分数记载到RMS数据库中，进行永久性保存。载入过程中将对所得分数与以往历史比较，放置到合适的位置中，形成排序。
    3.3 绘图与MIDP2.0新增的GameCanvas包
    3.3.1 提供低级绘制的Canvas类
    
    　　为了能有程序开发人员控制接口的外观和行为，需要使用大量的初级用户接口类

上一篇：基于aspx的个人博客系统毕业设计论文
下一篇：女生一定要看，不看肯定后悔！_精典日记