图 3.4 坦克剩余数 （4）玩家总成绩 战场右边显示玩家击毁敌方坦克所得到的的总成绩 。
图 3.5 玩家总成绩 第四章第四章 游戏详细设计游戏详细设计 4.1 各个类的设计 (1) 坦克类是系统中最主要的一个类 ， 坦克的属性：速度（X 轴和 Y 轴速度）， 坦 克的大小 ， 坦克所在坐标 ， 坦克的方向 ， 坦克存活与否 。
这些属性都有一个初始 化值 ， 游戏一开始就可以运行 。
设计过程中 ， 坦克出现的位置是由坦克的坐标而定 。
玩家的位置由键盘监听 方向 ， 按照指定方向以一定的速度前进这个速度 。

8、是全局静态变量 ， 当没有键 盘控制的时候 ， 坦克就会保持静止 。
敌方的坦克是用随机数来控制方向和路径的 。
通过 TouchotherEnemy()来判断是否碰撞到别的敌方坦克 。
我方坦克的方向和子弹发射都是由键盘来控制 ， 所以在坦克类里用 keypressed（）方法来接受键盘的按键监听 ， 接受到相应的信息后 ， 例如接到 X ， 则表示发射子弹 ， 此时就要调用坦克类里的 fire（）方法 。
接受到方向键 ，则会对坦克坐标做出相应的变化 。
图 3.1 坦克类 图 3.2 红色我方坦克 黄色敌方坦克 （2）子弹类需要依附坦克类 ， 每个坦克都可以发射子弹 ， 子弹的方向和速度都 在子弹类里 。
当子弹碰到敌方坦克或跑出战场后 ， 子 。

9、弹线程便会结束 。
图 3.3 子弹类 图 3.4 红色我方子弹 黄色敌方子弹 （3）爆炸类是取决子弹类 。
每当子弹碰到敌方坦克时 ， 子弹线程结束 ， 并调用 爆炸类 ， 爆炸类会读取坦克即时的坐标 ， 并用连续的三张图片显示出爆炸效果 。
图 3.5 爆炸类 4.2 程序的其他设计 （1）图形用户界面要用抽象窗口工具 AWT 和 Swing 来实现 ， 在选择开始新游戏 前 ， 实现屏幕中央关数的闪屏效果 。
class StartPanel extends JPanel implements Runnable int time=0;
public void paint(Graphics g) super.paint(g 。

10、);
g.fillRect(0, 0, 900, 600);
if(time%2=0) g.setColor(Color.yellow);
g.setFont(new Font(宋体,Font.BOLD,30);
g.drawString(stage:1, 400, 250);
Override public void run() / TODO Auto-generated method stub while(true) try Thread.sleep(100);
catch (InterruptedException e) / TODO Auto-generated catch block 。

11、 e.printStackTrace();
time+;
/重画 this.repaint();
（2）游戏开始时播放经典坦克大战的游戏音 。
AePlayWave apw=new AePlayWave(111.wav);
apw.start();
第五章第五章 测试测试 5.1 软件测试说明 软件测试是对软件需求分析、设计和编码的审查 ， 通过全面的测试 ， 发现各 阶段的问题 。
软件分析、设计、编码是为了建立一个系统结构 ， 实现系统；而测 试主要任务是实现软件开发问题 ，“破坏”已经做好的软件系统 。
都是为了能够 做出一个好的软件系统 。
5.1.1 软件测试的目标 如今对于软件大家都明白 ， 不可能存在没有缺 。

12、陷的软件 。
软件是人开发出来 的 ， 人不可避免的会产生错误 ， 而产生软件缺陷 。
软件缺陷可能在项目初期就存 在了 。
随着软件不断的开发 ， 缺陷造成的影响不断扩大 ， 可能造成无法弥补的损 害 。
所以 ， 软件测试的目标是：以最少的代价找出软件存在的错误和缺陷 。
在软 件系统的开发过程中 ， 软件测试是保证软件质量的关键 ， 它是需求分析、设计和 编码的最后审核 。
确实做到尽可能的将软件中存在的问题找出来 ， 以保证软件质 量 。
5.1.2 软件测试的原则 软件测试需要一些原则 ， Myers 提出了以下几个测试原则: 1. 程序不能由其程序员来测试 。
测试是为了找错 。
从心理学角度上讲 ， 程 序员对自己做的程序会觉得不会有多少错误 。
而且如果 。

13、程序员的理解错误 ， 程序 员自己测试肯定是查不出错误的 。
2. 在程序测试时 ， 测试人员应有正确的输入和明确的输出结果 。
3. 程序测试需要合理的输入数据 ， 也要不合理的输入数据 。
保留素有的测试案例 ， 并作为一个软件组件 。
花费相当多的精力来射击测试 用例 。
不加以保存 ， 一旦程序错误修正或改进需要重新测试 ， 就要重复上述工作 。
这是不是太浪费了 ， 人们一般不愿重新设计测试用例 ， 测试时难免会没有第一次 测试那么认真 。
这往往无法发现因修改而产生的缺陷 。
程序中有错误的概率和在那段程序中已经发现的错误成比例 。
程序中的错误 总是一起出现 ， 对这种现象 ， 现在还没有令人满意的解释 。

稿源：(未知)

【傻大方】网址：/a/2021/0621/0022536797.html

标题：基于|基于java的游戏坦克大战论文( 二 )