设计模式构想RPG游戏开发

对RPG本身特点的分析：

想要分析RPG游戏中用了什么设计模式，首先要对RPG本身有一定的了解。

传统RPG游戏指的是主人公按照一定的主线剧情去往特定的地点完成特定的任务，游戏的主要部分在于对游戏各个场景的刻画，场景的数量非常之多，怪物虽然也有不同的种类但大多数怪物会被重复遇到以便于玩家不断的刷出相应的道具武器和材料，游戏道具种类繁多给了玩家自由发挥的空间拥有着极高的随机性，RPG中除了与主角相关的同伴以外也有着大量的NPC，这些NPC也在游戏内起着重要的重要。RPG的战斗模式也是游戏的一大特点，传统RPG的战斗方式为回合制，在玩家的回合控制角色选择角色对应的技能，攻击，防御或逃跑，然后到达敌人的回合，敌人根据回合数和玩家与自己的剩余血量采取不同的行动。在RPG中技能除了有不同的伤害以外也有着不同的buff和debuff，buff指的是的增益的效果比如攻击力增加，防御力增加，debuff指的是负面效果，如速度减小或者每回合减小固定的HP（HP指的是剩余血量，当血量降低为0时角色阵亡，MP指的是蓝量，释放技能需要消耗蓝量）百分比。RPG本质上是一个数值游戏，比如对怪物的伤害却决于玩家的攻击力和怪物的防御力，游戏的结局一般由玩家的探索度或者说是剧情的推动程度来决定，不同的数值决定了游戏最后的结局。

关于RPG中抽象工厂模式的分析：

因为RPG中无论是场景的数量还是道具和怪物数量都非常的多，如果都采用工厂设计模式无疑会产生大量的类，在使用上造成麻烦，使用抽象工厂模式能在一定程度上减少工厂类的数量。

在游戏中多种游戏场景使用了抽象工厂设计模式，对于工厂方法模式具体的工厂负责生产具体的产品，工厂方法具有唯一性，而在游戏中往往一种场景对应着相关的地图，天气，道具怪物和音乐，比如在雨林地图中，地图往往树木较多，天气多雨，怪物和道具具有雨林特点，音乐中伴随着虫鸣；在海洋地图中，地图往往有着珊瑚海草等，背景为蓝色，怪物和道具具有海洋特点。使用抽象工厂模式就可以一次性生产一种“系列”的产品。使用抽象工厂关键在于理解这种情况下产品族和产品的等级结构，该案例下产品族为游戏的场景，例如雨林，海洋，城堡等，产品等级结构为地图，音乐，怪物，道具和天气。抽象工厂模式需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同等级结构中产品对象的创建。使用抽象工厂模式可以更为简单和富有效率。

还有一个原因是使用抽象工厂后便于创建新的场景，而RPG游戏可以通过添加相应的游戏补丁来增添游戏的内容。比如街巷，商场等，只要创建新的类并实现相应的接口，再编写相应的抽象工厂就能对其进行统一的创建。但由于抽象工厂本身开闭原则的倾斜性，无法解决增加新的产品等级结构，如该场景下的特殊道具获得，与场景本身无关的特殊剧情道具则需要用工厂模式进行补充。需要要求在设计之初就能全面考虑，否则在设计完成之后增加新的产品等级结构会导致出现较大的修改，为后续维护工作带来麻烦。

类图如下所示

关于RPG中创建者模式的分析：

设计RPG游戏，大多数注重玩家对游戏的自由度，其中就包括在游戏一开始的创建角色阶段。在不同类型的角色，其性别，脸型，服装发型等外部特性都有所差别，而玩家本身也有不同职业的选择如弓箭手，魔法师，战士等，不同的职业有着不同的特性和不同的初始装备。如何让玩家设计出符合自己期待的形象，关系到玩家对游戏的体验。使用建造者模式，可以有效的解决这个问题。在创建者模式中，客户端只需要实例化指挥者类，指挥者类针对抽象建造者编程，客户端需要传入具体的参数。游戏更新速度快，使用创建者模式可以在一步一步构建包含多个组件的完整对象的同时，使用相同的构建过程构建不同的产品，并且使系统具备很好的灵活性和可扩展性。在设计该案例时，使用建造者模式前，应该把握角色的关键特征进行创建，给与玩家一定程度自由度的限制，若不同角色的关键特征部位差异过大，如史莱姆这样没有人形的角色将会为设计带来麻烦。

类图如下所示：

关于RPG中观察者模式的分析：

使用观察者模式为游戏添加更多的交互，在RPG中的交互主要分为对游戏场景的探索和进入战斗状态后对队友的辅助和怪物的攻击。在场景的探索过程中，通过点击不同的的NPC和场景中的物品进行交互，玩家将作为观察者，可以被交互的道具和NPC作为观察目标，当玩家进行相关操作后，被观察者对其进行相关性的判断，对玩家进行通知，玩家根据通知结果修改自身的背包和任务状态。在战斗中己方与队友有着联系，也和敌人产生着某种的关联。为了体现这种状态的变化，需要使用观察者模式，对目标进行监听。比如当队友受到攻击时，我方可以看到队友被攻击的提示，被攻击的角色损失相对应的血量产生相应的状态，玩家根据其效果以此来采取相应的对策，当怪物被我方攻击时，怪兽损失相应的血量产生对应的状态，怪物会根据其血量和状态的盘对自动采取行动，如血量低于百分五时怪物会选择逃跑，血量低于百分之二十，怪物会进入狂暴状态提升相应的属性，当敌方被我方击杀时，获得相应的游戏奖励和消息提醒可以使玩家获得更多的游戏性和交互性，无论的对怪物的攻击还是对同伴的辅助这一切都依赖于观察者模式。它定义了对象之间的一种一对多的依赖关系，使得每一个对象状态发生改变的时候，其相关依赖对象皆会得到通知并被自动更新。可以说观察者模式是展现RPG游戏性最重要的模式。

类图如下所示

关于RPG中状态模式的分析：

在RPG游戏中，角色有着非常多的状态，如麻痹，中毒，眩晕，狂暴，强化，死亡，濒死等，这些状态在特定的条件下产生，如特定技能的释放和特定场景的影响，在不同的状态下角色的行为不同，如中毒在每回合减少一定比例的HP，死亡状态下角色无法进行操作可以使用状态模式来设计和实现角色状态的转换。状态模式将一个对象在不同状态下的不同行为封装在一个个状态类中，通过设置不同的状态对象可以让环境对象有不同的行为，而状态转换的细节对于客户端而言是透明的，方便了客户端的使用。状态模式可以将转换代码封装在环境类或者具体状态类中，可以对状态转换代码进行集中管理，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为。可以让对个环境对象共享一个状态对象，从而减少系统中对象的数量。但状态模式对开闭原则的支持不好，增加新的状态需要修改那些负责状态转换的源代码，否则无法转换到新增状态。RPG中状态虽然数量多，但变化不大，基本没有需要新增的可能。

类图如下所示

关于RPG中单例模式的分析：

在RPG游戏中有很多情况我们无需创建多个实例，为了节约系统内存，减少游戏占用空间大小，为了节约系统资源，有时需要确保系统中某个类只有一个实例，当这个唯一实例创建成功后，我们无法再创建一个同类型的其他对象，所有操作只能基于唯一一个实例。在RPG存在传送门和特定NPC，这些NPC和传送门存在于多个场景，他们需要记录玩家过去已经交互的内容，可以将他们理解为同一个交互对象，我们可以通过单例模式来实现。在RPG游戏当中，有着玩家的操作面板，其中包括玩家的属性，技能，伙伴，装备等数据，这些内容对于玩家本身是唯一的，通过单例类封装他的唯一性，可以严格控制客户怎样及时访问它。由于在系统内存只存在一个对象，因此可以节约资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。允许可变数目的实例，使用单例模式相似的方法来获取指定个数的对象实例。

类图如下所示

关于设计缺点的分析：

由于整体涉及多种设计模式，存在多种模式嵌套的情况难以缕清逻辑，难以完全满足开闭原则，为了满足需要设计了大量的类，类的数量过多，不易维护。