有谁没玩过植物大战僵尸吗？用Java语言开发了自己的植物大战僵尸游戏。虽然系统相对简单，但是麻雀虽小五脏俱全，对游戏开发感兴趣的小伙伴可以学习一下。
小编在文末给大家准备了除植物大战僵尸外别的游戏的教程和全套Java教程作为礼物哦。
游戏设计植物大战僵尸中有一个小游戏关卡，屏幕的正上方有一个滚轮机，会随机生成植物，玩家可以选中植物后自由选择草坪来进行安放。基于此游戏模式，我将该关卡抽取出来，单独做成了一个简易版的植物大战僵尸。游戏的画面大概如下：
屏幕左侧会自动生成植物的卡牌，单击选中后可以放置在草坪上。右侧会自动生成僵尸，不同的僵尸移动速度不同，血量不同，还有的僵尸有隐藏奖励，比如：全屏僵尸静止、全屏僵尸死亡等。当时竟然没有做游戏的暂停的功能，导致现在截图的时机很难把控，那这里就先说一下游戏暂停的功能应该怎么做吧。
最简单的一种暂停方式是鼠标移出屏幕，游戏暂停。所以这里需要引入一个鼠标监听器事件。
publicvoidmouseMoved(MouseEvent e){
// 当游戏处于运行状态时
if(status == start) {
// 通过鼠标移动事件的对象获取当前鼠标的位置
intx = e.getX();
inty = e.getY();
// 如果鼠标超出了游戏界面
if(x > Game.WIDTH || y > Game.HEIGHT) {
// 将游戏的状态改为暂停状态
status = pause;
}
}
}
当然，这只是一个简单的通过监听鼠标的位置来改变游戏状态方法。还可以使用键盘监听器，当按下某个键时游戏暂停，这样的用户体验更好。但原理是一样的，这里就不展示代码了。
游戏对象
首先分析一下游戏中有哪些对象。各式各样的植物，各式各样的僵尸，各式各样的子弹。那么这里就可以抽出三个父类，分别是植物、僵尸、子弹。在面向对象中，子类将继承父类所有的属性和方法。所以可以将三大类中，共有的属性和方法抽到各自的父类中。比如僵尸父类：
publicabstractclassZombie{
// 僵尸父类
// 僵尸共有的属性
protectedintwidth;
protectedintheight;
protectedintlive;
protectedintx;
protectedinty;
......
// 僵尸的状态
publicstaticfinalintLIFE =0;
publicstaticfinalintATTACK =1;
publicstaticfinalintDEAD =2;
protectedintstate = LIFE;
/*
* 这里补充一下为什么父类是抽象类，比如每个僵尸都有移动方法，
* 但每个僵尸的移动方式是不同，所以该方法的方法体可能是不同的，
* 抽象方法没有方法体，在子类中再去进行重写就可以了，
* 但有抽象方法的类必须是抽象类，因此父类一般都是抽象类
*/
// 移动方式
publicabstractvoidstep();
....
}
植物父类、子弹父类就同理可得了。上面说到子类共有的方法需要抽到父类中，那么部分子类共有的方法该如何处理呢？比如，豌豆射手、寒冰射手可以发射子弹，坚果墙就没有射击的这个行为。所以这里就需要用到接口(Interface)。
publicinterfaceShoot{
// 射击接口 - 将部分子类共有的行为抽取到接口中
// 接口中的方法默认是public abstract的，规范的编码应该将该字段舍去
publicabstractBullet[]shoot();
}
到此为止，游戏对象的属性、方法基本都定义完了，至于图片的显示以及如何将图片画出来，只需要使用相应的API即可，这里就不做描述了。工作一年回过来看看，这里能优化的地方还有很多，比如对象的血量、攻击力、移动等都可以统统写入到配置文件中，这样在做游戏参数的调整时，不需要去修改代码相关的内容，只需要修改配置文件里面的参数即可。
游戏内容现在我们有了游戏的对象，该开始让对象加入到游戏中来，接着让他们动起来，最后还得让他们打起来。首先，让对象加入到游戏中来我是这么做的，这里还是以僵尸为例：
// 首先要有一个僵尸的集合
// 僵尸集合
privateList<Zombie> zombies =newArrayList<Zombie>();
// 接着定义随机生成僵尸方法
publicZombienextOneZombie(){
Random rand =newRandom();
// 控制不同种类僵尸出现的概率
inttype = rand.nextInt(20);
if(type<5) {
returnnewZombie0();
}elseif(type<10) {
returnnewZombie1();
}elseif(type<15) {
returnnewZombie2();
}else{
returnnewZombie3();
}
}
// 僵尸入场
// 设置进场间隔
/*
* 这里补充一下为什么要设置进场的间隔
* 因为游戏的运行是基于定时器的，
* 每隔一段时间定时器就会执行一次你所加入定时器的方法，
* 所以这里需要设置进场间隔来控制游戏的速度。
*/
intzombieEnterTime =0;
publicvoidzombieEnterAction(){
zombieEnterTime ;
// 对自增量zombieEnterTime进行取余计算
if(zombieEnterTime00==0) {
// 满足条件就调用随机生成僵尸方法，并将生成的僵尸加入到僵尸的集合中
zombies.add(nextOneZombie());
}
}
最早时候我用的数据结构是数组，但在后续的编码中发现，对僵尸对象有很多的遍历以及增删操作，数组的增删操作是十分麻烦复杂的，所以我就换成了集合。在工作中也一样，先思考在编码，选择正确的数据结构往往能起到事半功倍的效果。
植物入场的设计，是我当时自认为很精妙的一个点。先说一下当时在编码中发现的问题。首先植物入场时是在滚轮机上的，滚轮机上的移动就会涉及到追击和停止的问题。追击的方式当然是追前一个植物卡牌，但当第一个植物卡牌被选中放置到草地上后，那该如何追击呢？
最开始我的做法是给植物多加几个状态来解决这个问题，但是发现状态过多会导致if判断中的条件将大大增加，并且在尝试后还是没有实现想要的效果，于是我就将植物集合一分为二，在后面的游戏功能设计中，回头过来看才发现将植物集合分为滚轮机上的集合和战场上的集合实在是太精妙了。请听我娓娓道来：
// 滚轮机上的植物，状态为stop和wait
privateList<Plant> plants =newArrayList<Plant>();
// 战场上的植物，状态为life和move -move为被鼠标选中移动的状态，这里设计不合理，会引发后面的一个BUG
privateList<Plant> plantsLife =newArrayList<Plant>();
// 植物在滚轮机上的碰撞判定
publicvoidplantBangAction(){
// 遍历滚轮机上植物集合，从第二个开始
for(inti=1;i<plants.size();i ) {
// 如果第一个植物的y大于0，并且是stop状态，则状态改为wait
if(plants.get(0).getY()>0&&plants.get(0).isStop()) {
plants.get(0).goWait();
}
// 如果第i个植物y小于i-1个植物的y height，则说明碰到了，改变i的状态为stop
if((plants.get(i).isStop()||plants.get(i).isWait())&&
(plants.get(i-1).isStop()||plants.get(i-1).isWait())&&
plants.get(i).getY()<=plants.get(i-1).getY() plants.get(i-1).getHeight()
) {
plants.get(i).goStop();
}
/*
* 如果第i个植物y大于于i-1个植物的y height，则说明还没碰到或者第i-1个
* 植物被移走了，改变i的状态为wait，可以继续往上走
*/
if(plants.get(i).isStop()&&
plants.get(i).getY()>plants.get(i-1).getY() plants.get(i-1).getHeight()) {
plants.get(i).goWait();
}
}
}
// 检测滚轮机上的植物状态
publicvoidcheckPlantAction1(){
// 迭代器
Iterator<Plant> it = plants.iterator();
while(it.hasNext()) {
Plant p = it.next();
/*
* 如果滚轮机集合里有move或者life状态的植物
* 则添加到战场植物的集合中，并从原数组中删除
*/
/*
* 现在发现把滚轮机上move状态的植物添加到
* 战场上植物集合的最佳操作时间点应该是
* 等植物状态变为life后再添加。
* /
if(p.isMove()||p.isLife()) {
plantsLife.add(p);
it.remove();
}
}
}
当然，滚轮机上的对植物状态判断的代码还是显得生涩，也正是自己想优化这段代码时萌生了分享游戏设计过程和游戏代码的念头。那么下面就说说，这段代码该如何优化：
// 先对状态做下说明
// wait - 植物卡牌在滚轮机上移动状态，因为是等着被鼠标选中，所以取名为wait
// stop - 植物卡牌在滚轮机上停止状态，有两种情况，1 - 到顶了 2 - 撞到上一个卡牌了
// 开始对以下代码进行优化
// 如果第i个植物y小于i-1个植物的y height，则说明碰到了，改变i的状态为stop
// if((plants.get(i).isStop()||plants.get(i).isWait())&&
// (plants.get(i-1).isStop()||plants.get(i-1).isWait())&&
// plants.get(i).getY()<=plants.get(i-1).getY() plants.get(i-1).getHeight()
// ) {
// plants.get(i).goStop();
// }
// 优化后的代码是这样的
// 将一个复杂的boolean拆成多个if条件
if(!(plants.get(i).isStop()||plants.get(i).isWait()) {
break;
}
if(!(plants.get(i-1).isStop()||plants.get(i-1).isWait())) {
break;
}
if(!(plants.get(i).getY()<=plants.get(i-1).getY() plants.get(i-1).getHeight())) {
break;
}
plants.get(i).goStop();
boolean条件当然也可以进行优化，甚至还可以简化一下植物的状态。这里因为游戏的规则，僵尸只能攻击在草坪上的植物，所以把带放置的植物和草坪上的植物分为两个集合，是十分合理精妙的。在判断僵尸是否攻击植物，只需要去遍历草坪上的植物集合即可。如果不拆分，当要判断僵尸是否攻击植物的时候，需要遍历的集合将是所有的植物集合，并且需要增加至少2个状态来区分植物是在草坪上还是在滚轮机上，这段代码想想就是又臭又长。
接下来该让对象们都动起来了。之前说到在父类中的移动方法是抽象方法，在各自的子类中都进行重写后，不同的对象移动方式就是各式各样的了。
// 子弹移动
publicvoidBulletStepAction(){
for(Bullet b:bullets) {
b.step();
}
}
//僵尸移动
//设置移动间隔
intzombieStepTime =0;
publicvoidzombieStepAction(){
if(zombieStepTime %3==0) {
for(Zombie z:zombies) {
//只有活着的僵尸会移动
if(z.isLife()) {
z.step();
}
}
}
}
看着代码中对集合复杂的遍历，不得不感概lambda表达式真是个好东西：
// 子弹移动
publicvoid BulletStepAction() {
bullets.forEach((b)->b.step());
....
}
这里好像还是没法展示lambda表达式强大的功能，请看下面的例子：
// 为了应对产品不断变更的需求，前辈们总结经验得出的设计模式已经能在一定程度上应对此问题
// 设计模式，声明策略接口，在实现类中完成过滤逻辑
publicList<Student> filterStudentByStrategy(List<Student> students, SimpleStrategy<Student> strategy){
List<Student> filterStudents =newArrayList<>();
for(Student student : filterStudents) {
if(strategy.operate(student)){
filterStudents.add(student);
}
}
returnfilterStudents;
}
// 当需求变更时，只需要在策略接口的实现类中，变更判断逻辑即可
publicinterfaceSimpleStrategy<T>{
publicboolean operate(T t);
}
但好像还是有点麻烦，又要写接口，又要写实现类，后续的维护也是个头疼问题，这个时候救世主lambda表达式就出现了：
// 无需接口便可实现需求的快速变更
List<Student> lambdaStudents =
students.stream().filter(student -> student.getGender()==1).collect(Collectors.toList());
让我们看看上面到底发生了啥。首先将数据的集合流化，接着调用过滤方法，强大lambda表达式让代码变得简洁，并且判断条件的修改可在代码中直接维护无需在策略接口的实现类维护。最后在转成集合，返回一个满足产品需求的集合。
回到正题，如何让对象们打起来呢？下面以僵尸攻击植物为例：
// 僵尸的超类中定义了僵尸的攻击方法，
// 由于僵尸们的攻击行为是相同，所以这里是普通方法
// 僵尸攻击植物
publicbooleanzombieHit(Plant p){
intx1 =this.x-p.getWidth();
intx2 =this.x this.width;
inty1 =this.y-p.getHeight();
inty2 =this.y this.width;
intx = p.getX();
inty = p.getY();
returnx>=x1 && x<=x2 && y>=y1 && y<=y2;
}
结合图片来看，上述代码应该就更好理解。黑框P代表植物，黑框Z代表植物，虚线是指两者接触的极限距离，当僵尸进入虚线内，就保证可以攻击到植物。
// 僵尸攻击
// 设置攻击间隔
intzombieHitTime =0;
publicvoidzombieHitAction(){
if(zombieHitTime 0==0) {
for(Zombie z:zombies) {
// 如果战场上没有植物，则把所有僵尸的状态改为life
/*
* 这里补充一下为什么要先将所有的僵尸的状态先改成life状态，也就是移动状态
* 因为下面对僵尸是否攻击的植物的判断，是从遍历战场上的植物集合开始的
* 假如有只僵尸在吃植物，把战场上唯一的一个植物吃掉了，
* 那么僵尸的状态将从攻击改成移动呢？
* 所以这里运用了逆向的思想，先将所有的僵尸改为移动状态
* 如果符合攻击的条件，那么再改为攻击状态，
* 即便是战场上没有植物，那么僵尸还依然是移动的状态
*/
if(!z.isDead()) {
z.goLife();
}
// 这里应该有个对战场上植物集合的判断在进行遍历
for(Plant p:plantsLife) {
// 如果僵尸是活的，并且植物是活的，并且僵尸进入攻击植物的范围
/*
* 这里有个BUG，僵尸竟然会攻击鼠标选中还未放下的植物，
* 所以下面的判断条件中应该还需要移除被鼠标选中状态下植物
*/
if(z.isLife()&&!p.isDead()&&z.zombieHit(p)&&!(pinstanceofSpikerock)) {
// 僵尸状态改为攻击状态
z.goAttack();
// 植物掉血
p.loseLive();
}
}
}
}
}
如果出现了一些效果的偏移，造成的原因是图片大小不一造成的坐标偏移，因为图片都是网上找的，所以效果不是太理想。至此，游戏的基本功能基本实现了。Java是一门面向对象的语言，万物皆对象，特征皆属性，行为皆方法。肉眼能看到的僵尸、植物、草坪都是对象，对象的特性比如血量、移动速度都是属性，对象的行为比如移动、攻击、死亡都是方法。
下面说说对游戏功能的优化。
游戏优化1.放置植物的优化
已经放置过植物的草地不能再放置植物了。之前是将草地设计成empty和hold两种状态，现在来看其实只需要返回一个true和false就行了，将整个植物集合定义成一个虚拟的boolean集合即可。
2.移除植物的优化
设计思路是新增一个铲子对象：
// 铲子集合
privateList<Shovel> shovels =newArrayList<Shovel>();
// 铲子入场
publicvoidshovelEnterAction(){
// 铲子只有一把
if(shovels.size()==0) {
shovels.add(newShovel());
}
}
// 使用铲子
Iterator<Shovel> it = shovels.iterator();
Iterator<Plant> it2 = plantsLife.iterator();
while(it.hasNext()) {
Shovel s = it.next();
// 如果铲子是移动状态，就遍历植物集合
if(s.isMove()) {
while(it2.hasNext()) {
Plant p = it2.next();
intx1 = p.getX();
intx2 = p.getX() p.getWidth();
inty1 = p.getY();
inty2 = p.getY() p.getHeight();
if((p.isLife()||((Blover) p).isClick())&&Mx>x1&&Mx<x2&&My>y1&&My<y2&&shovelCheck) {
// 移除植物
it2.remove();
// 移除铲子
it.remove();
shovelCheck =false;
}
}
}
}
