基于 Java 实现的葫芦娃大战妖精游戏课程设计

# 葫芦娃大战妖精游戏 ## 一、游戏简介 葫芦娃大战妖精游戏是一个实时的PVP战斗游戏，您可以操控葫芦娃或者妖精阵营与小伙伴进行对战并获得最终胜利。 葫芦娃大战妖精游戏注重用户的交互体验，游戏开设房间借鉴《人类一败涂地》在本地开设服务器的模式，游戏模式借鉴《英雄联盟》、《风暴英雄》等的分阵营实时战斗模式，对游戏中不同生物操控逻辑借鉴《实况足球》、《FIFA》等的选人逻辑。同时，本游戏也加入了《英雄联盟》、《实况足球》等游戏提供的游戏回放功能，可以随时回看您和小伙伴的战斗录像。 ## 二、设计思想 ### 1. 目录结构 ```shell ├─main │ ├─java │ │ └─nju │ │ └─linhao │ │ ├─ai │ │ │ ├─attack │ │ │ └─direction │ │ ├─battlefield │ │ ├─bullet │ │ ├─controller │ │ │ ├─logic │ │ │ └─window │ │ ├─creature │ │ ├─enums │ │ ├─exception │ │ ├─io │ │ ├─team │ │ └─utils │ └─resources │ ├─css │ ├─docs │ ├─fxml │ ├─icon │ └─pictures │ ├─bullets │ └─creatures └─test └─main └─java └─nju └─linhao ├─controller │ └─logic └─creature ``` 本项目目录结构如上所示，各目录对应包含的内容如下： 1. `ai`：实现没有被当前玩家控制的生物线程自动移动和攻击 1. `attck`：选择攻击的敌方生物 2. `direction`：选择当前生物的移动方向 2. `battlefield`：实现所有关于战场的信息储存和调度控制 3. `bullet`：实现子弹、子弹工厂、子弹管理者和回放中显示子弹 4. `controller`：实现本地游戏逻辑控制器、网络控制器、主窗口控制器和选择房间窗口控制器 1. `logic`：实现本地游戏逻辑控制器和网络控制器 2. `window`：实现主窗口控制器和选择房间窗口控制器 5. `creature`：实现所有生物，同时含有创建生物的工厂 6. `enums`：实现用到的所有枚举类型，包括阵营、网络信息类型、阵型等 7. `exception`：实现自定义的异常处理 8. `io`：实现与文件系统的交互相关内容，包括储存游戏记录和读取游戏记录 9. `team`：实现不同阵营队伍保存信息的相关内容，同时含有构建队伍的建造者 10. `utils`：实现不同的工具包，包括网络传输的信息、IP地址合法性判断者、图片加载器等 ### 2. 设计原则 #### 2.1 SRP单一职责原则 每个类都只完成自己负责的部分，例如未被当前玩家控制的生物的自动攻击类只会选择敌方存活的单位进行攻击，而不会移动或者做其他事情。战场控制器`BattlefieldController`只负责控制战场的逻辑，而不会干涉别的控制器自己的行为。 #### 2.2 OCP开放封闭原则 针对抽象编程，例如生物类的基类`Creature`是一个抽象类，包含了各种抽象的方法，但同时继承生物的类可以覆写自己的方法。达到了面向修改封闭，面向拓展开放的效果。 #### 2.3 LSP里氏替换法则 子类继承父类有严格的限制，例如继承自`Creature`的不同类不会覆写`Creature`的非抽象方法。同时，我计划未来在基类`Creature`中实现不同生物技能的抽象接口，然后在各个子类中进行覆写。 #### 2.4 ISP接口隔离原则 所有的类和属性对外界都保持有所能做到的最小的访问接口，让外界对需要调用的方法进行组合。例如`NetworkController`里面对外界暴露的只有`sendMessage()`方法，所有需要和另一个客户端通信的请求都可以调用这个最小的访问接口，同时不能调用`NetworkController`中任何其它方法（除了设置关键的`NetworkController`信息）。 #### 2.5 DIP依赖倒置原则 高层的实现都依赖抽象的实现，例如需要依赖生物的类都依赖`Creature`，需要依赖子弹的类都依赖`Bullet`。 ### 3. 设计模式： #### 3.1 单例模式 引入单例模式，是因为以下这些类在一个应用程序的生命周期中仅可能存在一个实体；同时，因为引入饿汉式的单例模式，所以保证了多线程安全。 1. `LocalGameController`： ```java private static LocalGameController localGameController = new LocalGameController(); private LocalGameController() {} public static LocalGameController getInstance() { return localGameController; } ``` 2. `Displayer`, `Recorder`, `Restorer`的实现类似`LocalGameController`的实现，不再赘述。 #### 3.2 工厂模式 引入工厂模式，是因为我们需要创建不同的生物和子弹。为了拓展性和易用性考虑，代码改写了原始工厂类的方法，我们可以直接向工厂类中调用`createXXX()`方法创建所需的对象，而不是像传统的工厂类那样写大量的if-else语句。 1. `CreatureFactory`： ```java public class CreatureFactory { private CreatureFactory(){} // for humans public static Grandpa createGrandpa(){ return new Grandpa(); } public static ArrayList<CalabashKid> createCalabashKids(){ ArrayList<CalabashKid> calabashKids = new ArrayList<>(); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_1_NAME)); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_2_NAME)); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_3_NAME)); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_4_NAME)); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_5_NAME)); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_6_NAME)); calabashKids.add(new CalabashKid(DEFAULT_CALABASH_KID_7_NAME)); return calabashKids; } public static Pangolin createPangolin(){ return new Pangolin(); } // for monsters ... } ``` 2. `BulletFactory`的实现类似，不再赘述。 #### 3.3 建造者模式 1. `TeamBuilder`：建造者模式使用多个简单的对象一步一步构建成一个复杂的对象。因为游戏需要区分不同的队伍，对于人类和妖精两个阵营都有复杂的队伍人员构成，因此可以用一个`TeamBuilder`类分别一步一步地创建两支队伍： ```java public class TeamBuilder { private TeamBuilder(){} public static HumanTeam buildHumanTeam(){ Grandpa grandpa = CreatureFactory.createGrandpa(); Pangolin pangolin = CreatureFactory.createPangolin(); ArrayList<CalabashKid> calabashKids = CreatureFactory.createCalabashKids(); return new HumanTeam( grandpa, pangolin, calabashKids); } public static MonsterTeam buildMonsterTeam(int minionNum){ ... } } ``` #### 3.4 中介者模式 因为所有类之间、不同的客户端之间都需要相互通信，这将大大加大通信复杂性，所以需要一个“中介者”充当中间角色，使各部分代码支持松耦合，易于维护。 1. `LocalGameController`：充当本地客户端不同类之间通信的中介者 2. `NetworkController`：充当不同机器上不同客户端之间通信的中介者 #### 3.5 MVC架构 虽然严格说来，MVC架构不算基本的设计模式，但本程序借鉴了MVC架构的设计思想，建立了战场控制器、战场和战场视图之间的MVC架构，让整体控制逻辑�