设计模式在游戏设计中的应用技术方案.docVIP

Java 设计模式论文 完成人 班级 学号 设计模式在游戏设计中的应用 程序设计目标与使用说明 1.1前言 设计模式在软件工程中有着广泛的应用，如java的MVC框架，用到了Observer模式，c#的LINQ，用到了Iterator模式，甚至连c++的STL中Iterator模式都有广泛的应用，但是我对这些软件工程方面的应用不是很感兴趣，我感兴趣的是设计模式在游戏开发中的应用，因此我尝试着使用Strategy模式和Abstract Factory模式来设计一个角色扮演游戏，来体验设计模式在游戏开发中的优势之处，由于我更善于使用c#编程，因此游戏将以c#为基础，代码运行环境是VS2010。 我始终觉得，设计模式的作用是为了方便开发，如果因为设计模式而使得开发变得复杂，那就得不偿失了，当然由于水平有限，我所能涉及到的只是游戏与设计模式应用的冰山一角，更深入的知识，需要我在以后的学习中不断的去深入和探究。 1.2工程说明 开发环境是vs2010 32旗舰中文版，是控制台应用程序。 需要打开电子档中的pgGame文件夹，双击RpgGame.sln 打开工程后，具体的源在rogram.cs中： 在游戏开发的开始，我设定构建一个魔法世界的游戏，游戏中的角色有魔法师、战士、牧师三种职业，人物有人类、精灵两种种族。三种职业需要施展不同的魔法，因此需要用Strategy模式将角色行为和技能施展分离开来；而两个种族由于有着大同小异的外形，所以可以用Abstract Factory模式提炼出抽象的“身体”和具体的人类和精灵的实现。 2.1.角色技能与Strategy模式 继承实现的问题 在开始游戏之前，我为玩家设定三种职业：魔法师、战士、牧师。正如字面上所看到的，魔法师擅长使用魔法攻击，战士擅长使用物理攻击，而牧师则擅长治疗。 根据面向对象编程思想，我需要先定义一个抽象类作为基类，将三个职业的实现作为子类，以实现代码的重用。对于抽象基类来说，首先要确定的是角色应该拥有的独立于职业的能力： ShowInfo():显示角色基本信息,如魔法师显示：This is a magician. Run():让角色行走，显示：Player is running. Stay():让角色站立，显示：Player is standing. 一般来说，设计时需要遵循这样的原则： 对于所有继承类都有，但是每个继承类的实现各不相同的方法，我们在基类中只给出定义，不给出实现，而在继承类中予以实现。换言之，就是在基类中定义一个抽象方法。 对于所有继承类都有，并且每个继承类的实现完全相同的方法，我们直接在基类中实现它，而由子类去继承，以实现代码重用。 很显然，每个职业都拥有上边定义的三种能力，其中ShowInfo()对于每种职业都不相同，而Run()和Stay()对于每种职业都相同，于是构建基类，实现下面的UML设计： 基类实现和继承实现的问题 实现基本功能后，考虑让所有的职业可以实现技能的释放，因此需要添加一个新的方法ReleaseSkills(),很容易想到的是在基类Charactor中添加方法ReleaseSkills()，这样可以实现代码的重用，但是很容易就可以发现三个子类释放技能的方式并不相同，将方法放在基类中不但没有解决问题，反而使问题复杂了，将问题抽象化，可以得到这样的描述： 给基类添加实体方法，使得不应该拥有此方法的子类也拥有了此方法，也使得所有子类方法拥有了完全一样的实现。 当然可以有另外一种解决的方法，那就是在每个子类中定义各自的ReleaseSkills()覆盖基类的方法，这样似乎解决了问题，但如果有一天需要加入一个新的职业，比如骑士，那就需要重新定义它的ReleaseSkills()，这样的缺陷显而易见： 没有实现代码重用，如果新添加角色的话，就需要重新写代码进行覆盖。 如果释放技能的方法需要改动，那么就不得不在子类中都重新写一遍。 如果新定义一种职业不需要释放技能，但是它也继承了ReleaseSkills()的方法，即使在子类中定义一个空的ReleaseSkills()方法，仍然会暴露出它拥有ReleaseSkills()的能力。 引入接口 继承的使用会带来很多问题，那么尝试使用接口来实现。首先定义ReleaseSkills()接口，然后在子类中实现。当然这里没有考虑战士释放技能的问题，事实上战士一般是不需要释放技能的能力的。由此我们得到下面的UML图： 使用接口虽然解决了部分问题，但是有更多的问题没有解决，例如，子类仍然要重新写自己的释放技能的实现代码，所以为了使释放技能与角色本身分离开来，就需要将释放技能的接口封装起来。 封装行为 面向对象的一个原则是封装变化,在当前的情况中，ReleaseSkills()这个行为是不断变化的，那么在设