设计模式课程设计.doc
《设计模式课程设计.doc》由会员分享,可在线阅读,更多相关《设计模式课程设计.doc(17页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、苏州科技学院电子与信息工程学院课程设计报告书课程名称: 软件体系结构设计 班 级: 计算机0911班 学 号: 0920107105 姓 名: 钱 青 指导教师: 倪启东 二一一年十二月 说明:1.本文档是以DragonQuest小游戏为例,进行设计分析的。2.本文档所有类图都是采用UML的Class Diagram(在Rotional Rose2003下绘制)3.代码都是用C#编写。一、 需求分析1、 游戏概述DragonQuest是一个角色扮演类游戏(RPG),该游戏实现的具体功能是设计两种类型的人物,分别为被玩家所控制的玩家人物(Hero)和由系统所控制的外部人物(Enemy),游戏中的
2、主要情节就是Hero与 Enemy之间的战斗,双方互相发射子弹击打对方。 在游戏的设计中要求游戏具有良好的扩展性,游戏界面友好,应方便用户,游戏画面要尽可能直观、美观。游戏角色参考图片:玩家人物Hero敌人1EnemyBoss 敌人2EnemyOne敌人3EnemyTwo敌人4EnemyThree游戏战斗场面:2、 需求描述本游戏名为“DragonQuest”游戏,基本可以实现以下功能:1. 开始游戏2. 退出(分保存进度设置和不保存进度设置两种)3. 属性设置(开始的时候,对各属性值进行初始化操作)4. 清除玩家信息,保存进度对人物,环境的要求如下:1. 人物:游戏中分为两种角色,Hero和
3、 Enemy,两者都有对应的生命值,在所有的Enemy之中,有一个EnemyBoss,他在Enemy之中是最厉害的角色,该游戏中,Hero和EnemyBoss各只有一个,但是其他的Enemy可以有很多个,双方在战斗的过程中,双方的生命值会减少,当EnemyBoss的生命值为0时,游戏胜利,当Hero的生命值为0时,战斗失败,游戏结束。2. 环境:由于游戏规模的限制,游戏中环境的设置比较单一,整个游戏只在一个环境中进行。3. 人物移动:Enemy人物的移动是随机的,每隔一段时间,移动到一个地方,Hero的移动由玩家控制。4. 人物遭遇战:在游戏过程中,Hero和 Enemy相互发射子弹,当子弹打
4、到某个角色时,对应的角色的生命值就会降低,直到生命值为0,该角色死亡。此游戏分为用户和管理员:用户的主要操作:1、 未注册之前的准备2、 注册之后:A 登陆自己的账号,填写密码等信息,读取游戏进度B 开始游戏C 退出游戏D 保存进度 管理员的主要操作:1. 管理注册游戏的玩家信息2. 删除不保存的用户的信息,只保存相应的用户名3、 功能需求: 本游戏的主要功能有:1. 开始游戏2. 退出(分保存进度设置和不保存进度设置两种)3. 属性设置(开始的时候,对各属性值进行初始化操作)4. 清除玩家信息,在各地各种环境下保存进度4、 性能需求:所有操作都应在30ms内得到响应。本游戏主要运行在Wind
5、ows平台上,但以后有可能会扩展到其他平台,服务器数据库选用Mysql。5、 运行需求: 游戏中界面以客户端程序的方式显示,界面能做到简洁,美观,大方,与用户交互友好 。若程序中有微小的错误从而导致游戏的死机,请将信息及时汇报给我们,以便于我们及时的进行修改并完善。 用户忘记账号或者密码,可以通过游戏的说明书上的联系电话来联系管理员,根据注册的数据来判断账号的所属者,从而为用户提供服务。 用户不能运行游戏,则可能是用户的电脑配置太低不适合游戏,可更换电脑的配置来满足游戏所运行环境下的条件。 网络不通,排除故障后需要重新进入系统,系统不保存在用户进行游戏前的临时数据。 在游戏过程中服务器死机,可
6、在重启服务器后再统计一次即可。但不保存上次的临时数据。6、 其他需求: 对该软件的灵活性的要求,即当需求发生某些变化时,该游戏应该能应对如下变化,如: a操作方式上的变化; b运行环境的变化; c精度和有效时限的变化;d计划的变化或改进。 二、 游戏中角色的层次框架:三、 DragonQuest的设计主要包含了以下几种设计模式:1. 单件模式2. 工厂方法模式3. 策略模式4. 观察者模式5. 外观模式6. 代理模式四、 游戏设计中的模式的详细说明(一) 单件模式A. 设计说明 游戏中由于角色,元素比较多,在DragonQuest游戏中设计了一个HitCheck类,该类负责控制游戏中所有元素(
7、角色),包括对角色的增加,删除和控制其各种行为,该类在整个游戏中只有一个实例,这里就可以用到单件模式,如果该类可以被实例化多次,那么游戏就会相当混乱,整个游戏就会失去控制,所以该类只能有一个实例,并且该类提供了一个全局的访问点。该类利用一个私有静态变量来记录HitCheck类的唯一实例私有构造函数private HitCheck()确保该类在类外是无法实例化的,只能在类内进行实例化。利用静态方法GetInstance()实例化对象,并返回这个实例。B. 类图C. 单件模式的实现代码public class HitCheck private static volatile HitCheck in
8、stance;/记录该类唯一的实例 private HitCheck() /私有构造函数public static HitCheck GetInstance()/实例化对象 if (instance = null) instance = new HitCheck(); return instance; (二) 工厂方法模式A. 设计说明游戏中涉及角色较多,每个角色都有自己的子弹,这样就可以用到工厂方法模式,这会使系统具有良好的扩展性和可维护性,达到一种松耦合的目的,以便将代码从具体类解耦,游戏中有两个抽象类Roles和Missiles分别作为工厂的接口和产品的接口,在Roles中有一个抽象工厂
9、方法Fire(),实例化子弹的任务被移动到这个方法中,此方法就如同是一个“工厂”。Roles并不决定要实例化的类,而是由子类(Hero,EnemyOne,EnemyTwo)来决定要实例化的类.抽象类Missiles的子类MissileHero,MissileOne,MissileTwo是由“工厂”(Hero,EnemyOne,EnemyTwo)来实例化的,比如Hero是负责实例化MissileHero的,EnemyOne是负责实例化MissileOne的,EnemyTwo是负责实例化MissileTwo的。这样就可以让把实例化推迟到子类。这个设计模式中运用到的设计原则有:依赖抽象,不要依赖具体
10、的类。B. 类 图C. 工厂模式的实现代码生产子弹的创建者类:public abstract class Roles /属性 public abstract void Fire();/用来生产子弹,实例化子弹的任务被移到一个方法中,此方法就如同是一个工厂方法 /其他的方法生产具体子弹的工厂:public class Hero : Roles /英雄类中的Fire()产生MissileHero public override void Fire() public class EnemyOne : Roles / EnemyOne类中的Fire()产生MissileOne public overr
11、ide void Fire() public class EnemyTwo : Roles / EnemyTwo类中的Fire()产生MissileTwopublic override void Fire() 子弹的抽象类:public abstract class Missiles protected override void Move() protected void Draw(Graphics g) 具体的子弹:/Hero的子弹public class MissileHero : Missiles / EnemyOne的子弹public class MissileOne : Missi
12、les / EnemyTwo的子弹public class MissileTwo : Missiles (三) 策略模式A. 设计说明上面讨论了每个角色都有自己的子弹,但是考虑到每个角色产生子弹的方式又是不一样的,我们可以设计不同的子弹产生方式,比如,Hero在某些时候可以一次产生一个子弹,但是当敌人比较多的时候,可以一次产生两个子弹,或者更多,敌人也是一样的,也可以一次产生多个子弹,达到增强战斗力的效果,这里就可以采用策略模式来设计每个角色产生子弹的行为。设计了一个接口ShotBehavior来封装发射子弹的行为,然后可以定义不同的行为,接着,在Roles类中加入一个实例变量shotBeha
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 设计 模式 课程设计
限制150内