基于android系统的塔防游戏.docx
《基于android系统的塔防游戏.docx》由会员分享，可在线阅读，更多相关《基于android系统的塔防游戏.docx（32页珍藏版）》请在冰豆网上搜索。
基于android系统的塔防游戏
目录
摘要4
第1章需求分析13
1.1需求分析13
1.1.1需求分析过程14
1.1.2需求分析的方法14
1.2可行性分析15
1．2．1可行性分析的意义15
1．2．2可行性分析报告15
1.3系统定义16
1.4系统的组成和功能构想：
16
1.5研究方法16
1.5.1软件工程的定义16
1.5.2软件工程的模型17
1.5.3本系统的研究方法18
第2章概要设计19
2.1系统总体设计方案19
2.1.1单机模式19
2.1.2设计原则19
2.2基于单机的模块设计20
2.2.1AI端模块设计20
2.2.2客户端模块设计21
2.3相关技术的处理应用23
2.3.1面向连接的套接字编程23
2.3.2数据格式转换的问题24
第3章详细设计与系统实现26
3.1AI端各功能模块的实现26
3.1.1AI的启动功能26
3.1.2接收连接请求功能27
3.1.3数据捕获功能28
3.2客户端各功能模块的实现29
3.2.1登录功能功能29
3.2.2数据接收功能30
3.2.3显示信息功能30
3.2.4游戏退出功能33
第4章系统测试与维护34
4.1系统测试的原则34
4.2测试过程及方法35
4.3本系统测试环境36
4.4测试中的BUG及问题总结36
4.5软件的维护37
结束语38
致谢39
主要参考文献40
附录A部分源程序清单41
第1章需求分析
1.1需求分析
1.1.1需求分析过程
需求分析阶段的工作,可以分为四个方面:
问题识别,分析与综合,制订规格说明,评审。
●问题识别:
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：
功能需求（做什么）,性能需求（要达到什么指标）,环境需求（如机型,操作系统等）,可靠性需求（不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求（软件运行是所需的内存,CPU等）,软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标。
●分析与综合:
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分。
最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型（做什么的模型）。
●制订规格说明书:
即编制文档,描述需求的文档称为软件需求规格说明书。
注意需求分析阶段的成果是需求规格说明书,向下一阶段提交。
●评审:
对功能的正确性,完整性和清晰性,以及其它需求给予评价。
评审通过才可进行下一阶段的工作,否则重新进行需求分析。
1.1.2需求分析的方法
需求分析的方法有很多。
这里只强调原型化方法,其它的方法如:
结构化方法,动态分析法等（个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法）在此不讨论。
原型化方法是十分重要的（是软考等常考的知识点）。
原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷。
建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等。
如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型（软考考过）:
探索型,实验型,进化型.探索型:
目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性。
实验型:
用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠。
进化型:
目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
使用原型化方法有两种不同的策略:
废弃策略,追加策略。
废弃策略:
先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统。
系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:
先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。
进化型属于这种策略。
1.2可行性分析
1．2．1可行性分析的意义
可行性研究能使新系统达到以最小的开发成本取得最佳的经济效益。
可行性研究的目的，是根据所开发系统的请求，通过初步调查和系统目标分析，对要开发的民航票务管理系统从技术上、经济上、资源上和管理上进行是否可行的研究。
这是一项保证资源合理使用、避免失误和浪费的重要工作。
经济上的可行性：
主要分析成本与收益、投资效果等。
技术上的可行性：
要分析技术力量、计算机性能、通讯网络和系统条件等。
资源上的可行性：
主要指管理、经费能否得到保证。
管理上的可行性：
如帐户管理水平、数据收集可能性、规章制度健全程度和领导对发展系统的态度。
1．2．2可行性分析报告
以下为将可行性分析转化为的可行性报告：
●经济上的可行性：
●技术上的可行性：
本系统技术实现简单可靠，通讯组网简单，因为不需要大规模的计算和读取数据，所以对计算机的性能要求并不高，对环境的搭建没有特殊的要求。
●资源上的可行性：
开发本系统无需很特殊设备与环境，所以资源上具有可行性。
●管理上的可行性：
对于每个用户都对应一个帐号和密码，安全性相当的高，且便于管理。
以上可行性分析就各个方面进行了分析，接下来需遵照相关标准和规定进行审议，通过后进入了以下需求分析阶段。
1.3系统定义
本游戏是塔防游戏（Android版）,塔防游戏指一类通过在地图上建造炮塔或类似建筑物，以阻止游戏中敌人进攻的策略型游戏所谓塔防游戏即指一类通过在地图上建造炮塔或类似建筑物，以阻止游戏中敌人进攻的策略型游戏，要有阵图。
比较有名的像《防御觉醒》、《植物大战僵尸》。
这种游戏多见于flash游戏，手机上也不少，比较耐玩。
1.4系统的组成和功能构想：
●用户动作信息录入功能－－输入
●系统信息显示功能－－输出
1.5研究方法
1.5.1软件工程的定义
软件工程是一类求解软件的工程，它应用计算机科学、数学及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高质量、降低成本的目的。
其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
软件工程是一门指导计算机软件开发和维护的工程学科。
1.5.2软件工程的模型
软件工程的模型是软件开发全部过程、活动和任务的结构框架。
瀑布模型内容及特点：
瀑布模型将软件生存周期的各项活动规定为依固定顺序连接的软干阶段工作，是一种线性模型。
各阶段活动为，提出系统需求、提出软件需求、需求分析、设计、编码、测试和运行。
每个开发阶段具有以下特征，从上一阶段接受本阶段工作的对象作为输入，对上述输入实施本阶段的活动，给出本阶段的工作成果作为输出传入下一阶段，对本阶段工作进行评审，若本阶段工作得到确认，则继续下阶段工作，否则返回前一阶段甚至更前阶段。
瀑布模型最为突出的缺点是该模型缺乏灵活性。
演化模型内容及特点：
演化模型主要针对事先不能完整定义需求的软件开发，其开发过程一般是首先开发核心系统，当核心系统投入运行后，软件开发人员根据用户的反馈，实施开发的迭代过程，每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，直到软件开发结束。
演化模型在一定程度上减少了软件开发活动的盲目性。
螺旋模型内容及特点：
它是在瀑布模型和演化模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。
沿螺旋模型顺时针方向，依次表达了四个方面的活动，制定计划、风险分析、实施工程、客户评估。
喷泉模型内容及特点：
它体现了软件创建所固有的迭代和无间隙特征，喷泉模型主要用于支持面向对象开发过程。
增量模型内容：
在设计了软件系统整体体系结构之后，首先完整的开发系统的一个初始子集，继之，根据这一子集，建造一个更加精细的版本，如此不断的进行系统的增量开发。
瀑布模型、演化模型、螺旋模型之间的联系：
相同点是这三个模型都分为多个阶段，而瀑布模型一次完成软件，演化模型分为多次完成，每次迭代完成软件的一个部分，螺旋模型也分为多次完成，每次完成软件的一个新原型，并考虑风险分析。
1.5.3本系统的研究方法
本系统的开发严格遵守软件工程开发的标准流程。
实地考察，进行需求分析，书写需求分析表和初步的软件说明书。
在模块设计的同时进行单元测试，系统设计完成进行系统调试和系统集成测试。
设计完成后，编写完整的软件说明书和用户手册，最后还需写对自己所作设计的评价和总结。
经过对各个软件工程的模型的分析，我决定使用瀑布模型进行开发。
在对各个阶段的交接上，只能按顺序进行，完成上一阶段后才能进行下一阶段的工作。
我的整个软件开发流程如图：
图1.1Androida塔防游戏开发流程
第2章概要设计
2.1系统总体设计方案
2.1.1设计原则
（1）被运行时，首先生成两个电脑玩家，然后游戏开始出杂兵。
（2）玩家的任何动作必须调用规则控制接口。
当接口返回动作合法的结果时，玩家才能做出所请示的动作（实际上只是显示动作的结果，因为接口已经处理了该动作，在发送许可的同时发送了处理结果）。
否则，接口返回拒绝消息，玩家则显示有关错误信息。
（3）电脑玩家根据地图类型生成出兵方案，然后返回数据，并执行相应的显示与相关的游戏设置。
2.2基于Android的模块设计
2.2.1模块设计
（1）游戏规则的实现
通过封装相应的类来实现规则。
类card：
卡片类（兵），数据成员为属性卡（color）,属性值（value），数目
（num），存在标志（exist）。
枚举colors：
包括速度兵，轻骑兵，铁甲兵，爆破兵，小鬼，大鬼总共六种属性卡。
结构体comb：
内含头头是单，双，攻城，炸弹，火箭等所有兵型的标记位。
类player：
玩家类，数据成员：
玩家靓号（m_strplayerID），个性签名（m_strName），登陆密码（m_strPassword）等。
类playingCards：
游戏规则类，数据成员：
玩家数目（numPlayers），有兵数目（numCards），每个玩家有兵数目（cardsEach）等。
成员函数：
游戏初始化initgame（），载入地图suffle（），出杂兵sendCards（）叫BOSScandlander（intseat,intpoint），出兵outcards（player&ThisPlayer）等等。
Player是玩家在AI中的一个映射，玩家的任何动作都由它代为完成，然后将结果返回给AI的相关内存。
playingCards充分利用以上几个类的对象，封装起来，外界通过类的对象，只要调用它的方法，就可以实施对玩家出兵的合法性判断，并做相关结果的存储工作。
至于判断结果如何处置，请参看（3）游戏平台的实现
（2）游戏平台的实现：
对话框CdisplayflashDlg：
客户端游戏界面，内含与flashUI通信的接口。
数据成员：
积分m_nintegral，剩兵数目m_nsparecards座位号m_norder_seats，放弃动作m_nPass，手上的兵m_strpcards选择的兵m_strselectcards，合法兵m_stroutcards等等。
成员函数：
接收数据OnReceive（），关闭OnClose（）等。
顾名思义，display就是显示的意思，flash就是用动画显示。
在客户端,只通过接收机制判断命令是否针对自己,若是,则执行之,显示AI处理结果。
否则,不执行,只获取当前玩家状态。
该接收机制就是OnReceive方法。
它通过switch（）-case机制区分不同的消息；通过msg.InfoAbout和m_norder_seats来判断消息中的指令是否针对自己发出的。
2.3相关技术的处理应用
2.3.1数据实体定义
当玩家接收派兵时，类Card的定义是这样的：
publicclassColors{
staticfinalintdiamond=1;//速度兵
staticfinalintclub=2;//轻骑兵
staticfinalintheart=3;//铁甲兵
staticfinalintspade=4;//爆破兵
staticfinalintbjoke=5;//小鬼
staticfinalintrjoke=6;//大鬼
}
publicclassCard{
intvalue;
Colorscolors;
intexist;
intnum;
publicColorsgetColors（）{
returncolors;
}
publicvoidsetColors（Colorscolors）{
this.colors=colors;
}
publicintgetExist（）{
returnexist;
}
publicvoidsetExist（intexist）{
this.exist=exist;
}
publicintgetNum（）{
returnnum;
}
publicvoidsetNum（intnum）{
this.num=num;
}
publicintgetValue（）{
returnvalue;
}
publicvoidsetValue（intvalue）{
this.value=value;
}
第3章详细设计与系统实现
详细设计是整个设计过程中，最重要的步骤之一。
本系统的功能主要分成两大模块:
AI端和客户端。
每个模块有可以分成几个子模块。
下面分几个部分对各个模块进行详细设计：
功能模块
●数据接收功能
●显示信息功能
●数据捕获功能
●合法性判断功能
●游戏退出功能
3.1功能模块的实现
3.1.1启动游戏
点击“启动游戏”就可以调用成员函数OnSet（），启动游戏。
3.1.2开始游戏功能
启动游戏后,自动生成两个电脑玩家，开始进入游戏状态。
3.1.3数据捕获功能
OnReceive（）捕获数据
3.1.4合法性判断功能
playingcards1来调用类playingCards中的封装的规则实现方法，最终完成合法性判断。
首先，在OnRecieve（）方法中，实现对用户出兵的m_strpos（里面包含的是客户端点击的兵的position）的剥离，使之转换成整型数组pos[lenpc]，lenpc是客户端实际出兵的长度。
然后，调用出兵方法playingcards1.outcards（&当前发出动作的玩家），进行出兵动作;
再就是，经过选兵selectcards（PlayerthisPlayer），返回Cardpc;以及兵型处理方法：
CardplayingCards.dealcards（Cardpc）返回Cardcard1和CombplayingCards.dealcaa（Cardcard1），返回comb1;
最后，兵型合法性判断booleanplayingCards.legalcomb（Combcomb1,Cardcard1），如果兵型合法，则继续下面的属性值大小合法性的判断booleanplayingCards.biggerthanfront（Cardcard2）,否则，提示出兵不合法。
如果属性值大小合法，则出兵最终是合法的，将出兵处理结果，存入Listfront=newArrayList（20），并发送给各个玩家。
值得一提的是，BOSS开局第一次出兵或者后继两家玩家都pass掉时，Listfront中的value值全为-1，其他诸如：
exist,color,num分别为1,（colors）1,1;所以此时，当前出兵玩家出的兵，只要是合法的兵型，就可打合法地打出去。
3.2.2玩家操作功能
操作判断机制switch（msg.message）-case中，case共分0:
登录1:
退出2:
开兵3:
叫兵4:
出兵5:
pass6:
计分六种情况。
在此以最重要使用、最频繁的“case4:
出兵”来讲述这个功能。
首先，判断处理结果是否表明前面出兵是否非法，如果是，将给机会客户端重新出兵。
否则，判断，信息是否是发给发出前面动作的本人。
是，则将合法兵显示在UI上，并更新手上的兵。
否则，只显示别人打出来的兵，及其所剩兵数目。
然后，当前面动作者是接收方的直接上家（或逻辑上家）时，接收方获得出兵权。
否则，没有出兵权。
详细规则请参看附录1客店端对出兵的显示控制。
3.2.3显示信息功能
CdisplayDlg.m_strpcards存储玩家手上的兵。
然后实现排序的问题和合法兵打出以及非法兵回收的问题。
效果如图:
排序算法如下:
先将用户手上的兵card20copy到cardHit中去.
然后,按其数据成员color,value,num设置为不同级别的关键字.
（1）按属性卡排序:
主关键字color,次关键字value
（2）按大小排序:
主关键字value,次关键字color
（3）按兵型排序:
主关键字num,次关键字value,color
前两种排序只是处理调用sortOnValue（）与sortOnColor（）的先后关系.而按comb排序稍复杂一点,先按大小排序,再从右边开始查找.先找只有2个兵相同的,找到就往最左边放.然后依同理查找只有3个兵相同的和只有4个兵相同的,再就是查找火箭.最后剩下单兵就留在最后边.
CdisplayDlg.m_strpos玩家通过点击flashUI上面的兵，flashUI把各个被选中的兵的position传递至这个参数，并被存储起来。
当玩家用鼠标点击某个兵时,该兵会弹出来,高出其他兄弟兵半截,此时,它在兵组cardHit中的位置position已经被取出并存入msg.m_strpos中,等待发送至AI端.当用户选完想出的兵,点击手形图标后,就同时触发方法voidCdisplayflashDlg.OnButtonOutcards（）,msg.m_strpos就随之被发送到AI端了。
AI的处理方式请参看5.1.4合法性判断功能
CdisplaySocketDlg.m_stroutcards玩家出如果经AI判断合法，将被接受并存储在这个参数里。
客户端将合法的兵全部显示在界面中央,并在动作者的手上将相应的兵清除掉（使相应兵的exist=-1）。
如下图：
我们可以看到，动作者手上的轻骑兵3补出去了，由于这是BOSS的第一次出兵，AI判定其合法，客户端收到判断结果后，将兵打出去在界面的中央位置显示，而在自己手上，清除掉该“轻骑兵3”。
如果不合法,系统将不打出去,并给出错误提示.并且，将不合法的兵还原到动作者手中，让动作者重新选择：
出兵ORPASS。
原理其实与上面的大同小异，就不必赘述了。
如图:
3.2.4游戏退出功能
CdisplayDlg:
:
OnExit（）退出游戏
调用系统方法关闭窗口、关闭对话框。
第4章系统测试与维护
在软件程序编码完成之后，在软件投入使用之前要进行软件测试。
何谓软件测试,简言之：
软件测试是为了发现错误而执行程序的过程。
也就是根据软件开发各阶段的规格说明何程序的内部结构而精心设计测试用例，用这些用例去运行程序以发现程序错误的过程。
系统测试在一个系统的周期中占有越来越重要的位置了。
在系统正式投入运行的转换工作之前，还需对系统进行一系列的调试即测试。
系统调试的任务是根据系统说明书和系统实施方案，对程序设计的结果进行全面的检查，找出并纠正其中的错误，使可能发生的问题和错误，尽量消灭在系统正式运行之前。
4.1系统测试的原则
●应当尽早和不断的进行软件测试.
●测试用例应由测试输入数据和预期输出结果两部分组成.（注意:
测试用例包含输入和输出两部分）.
●测试用例应包括合理的输入条件和不合理的输入条件.前者即使程序正常运行的条件,后者即可能引起程序非法操作的条件.
●程序员应避免检查自己的程序.因为父母总是疼爱自己的孩子.程序员总是在潜意识不愿意否定自己的劳动成果.
●注意测试中的群集现象.测试后程序中残存的错误数目与该程序中已发现的错误数目成正比.所以,不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试,相反该程序段更要集中精力测试。
●测试应该制订计划,严格按计划进行测试,避免测试的随意性.
●应对每一个测试结果做全面检查.
有时出错的征兆已经在测试结果中出现了,但由于没有对测试结果进行仔细检查,而使这个错误成了漏网之鱼.
●应妥善保存测试计划,用例,错误记录和分析报告.
4.2测试过程及方法
软件的测试过程有四个步骤:
单元测试,集成测试,确认测试和系统测试.
单元测试即对每一个单元模块进行测试.然后把测试过的模块组装起来进行集成测试,主要是对软件体系结构的构造进行测试.接着进行确认测试,检查软件是否满足了各种需求,以及配置是否合理安全.最后是系统测试,即把经确认测试后的软件放到实际运行环境中,与系统的其他构件一起进行测试.
单元测试时,有时需要为测试的模块编写辅助模块:
驱动模块和桩模块.前者是用来调用被测模块;后者用来代替被测模块调用的子模块。
集成测试,又叫组装测试,分为两种:
一次性组装和增殖式组装.一次性组装方式即把经单元测试后的模块一次性的组装成系统进行测试.增殖式组装方式即在模块组装的过程中,边组装边测试,每增加一个或几个模块就测试一次,最后组装成最后的系统,它又分为:
自顶向下的增殖,自底向上的增殖,混合增殖等几种方式.
确认测试过程要做的工作包括:
有效性测试,软件配置复审,验收测试和安装测试.在验收测试中常用的有α测试和β测试.α测试时,开发者坐在用户旁边,随时记录用户发现的问题.β测试则开发者不在测试现场,故是在开发者无法控制的环境下进行的测试,通常是由软件开发者向用户散发β版软件,然后收集用户的意见.
测试的方法大体可以分为两种:
黑盒测试和白盒测试.
黑盒测试即把测试的对象看成一个黑盒子,不考虑程序内部的逻辑结构和内部特性,主要在软件的接口处进行测试,主要测试软件的功能.黑盒测试的方法包括:
等价类划分法,边界值分析,错误推测法,因果图,功能图等.
白盒测试把测试对象看成是一个打开的盒子,程序内部的逻辑结构和其他信息对测试人员都是公开的.白盒测试的方法有:
逻辑覆盖（语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖,路径覆盖）,基本路径测试等.
4.3测试环境
测试的硬件环境为：
主机为英特尔赛扬M处理器3601.4GHZ，硬盘为4
升级会员 