Android手机下的斗地主游戏设计与实现毕业论文文档格式.docx
《Android手机下的斗地主游戏设计与实现毕业论文文档格式.docx》由会员分享，可在线阅读，更多相关《Android手机下的斗地主游戏设计与实现毕业论文文档格式.docx（33页珍藏版）》请在冰点文库上搜索。
目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
使用原型化方法有两种不同的策略:
废弃策略,追加策略。
废弃策略:
先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统。
系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:
先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。
进化型属于这种策略。
3.2可行性分析
3．2．1可行性分析的意义
可行性研究能使新系统达到以最小的开发成本取得最佳的经济效益。
可行性研究的目的，是根据所开发系统的请求，通过初步调查和系统目标分析，对要开发的民航票务管理系统从技术上、经济上、资源上和管理上进行是否可行的研究。
这是一项保证资源合理使用、避免失误和浪费的重要工作。
经济上的可行性：
主要分析成本与收益、投资效果等。
技术上的可行性：
要分析技术力量、计算机性能、通讯网络和系统条件等。
资源上的可行性：
主要指管理、经费能否得到保证。
管理上的可行性：
如帐户管理水平、数据收集可能性、规章制度健全程度和领导对发展系统的态度。
3．2．2可行性分析报告
以下为将可行性分析转化为的可行性报告：
●经济上的可行性：
●技术上的可行性：
本系统技术实现简单可靠，通讯组网简单，因为不需要大规模的计算和读取数据，所以对计算机的性能要求并不高，对环境的搭建没有特殊的要求。
●资源上的可行性：
开发本系统无需很特殊设备与环境，所以资源上具有可行性。
●管理上的可行性：
对于每个用户都对应一个帐号和密码，安全性相当的高，且便于管理。
以上可行性分析就各个方面进行了分析，接下来需遵照相关标准和规定进行审议，通过后进入了以下需求分析阶段。
3.3系统定义
本游戏是斗地主游戏（Android版）,是根据地区民间的盛行的扑克牌游戏斗地主，融合最新的移动平台Android的特点和管理需要，推出的体现当前行业最具有代表意义的解决方案。
作为面向广大用户网络游戏，主要用于提供斗地主的游戏平台，提供发牌、叫牌、出牌、胜负判定等主要功能。
3.4系统的组成和功能构想：
●用户动作信息录入功能－－输入
●系统信息显示功能－－输出
3.5研究方法
3.5.1软件工程的定义
软件工程是一类求解软件的工程，它应用计算机科学、数学及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高质量、降低成本的目的。
其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规、设计型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
软件工程是一门指导计算机软件开发和维护的工程学科。
3.5.2软件工程的模型
软件工程的模型是软件开发全部过程、活动和任务的结构框架。
瀑布模型容及特点：
瀑布模型将软件生存周期的各项活动规定为依固定顺序连接的软干阶段工作，是一种线性模型。
各阶段活动为，提出系统需求、提出软件需求、需求分析、设计、编码、测试和运行。
每个开发阶段具有以下特征，从上一阶段接受本阶段工作的对象作为输入，对上述输入实施本阶段的活动，给出本阶段的工作成果作为输出传入下一阶段，对本阶段工作进行评审，若本阶段工作得到确认，则继续下阶段工作，否则返回前一阶段甚至更前阶段。
瀑布模型最为突出的缺点是该模型缺乏灵活性。
演化模型容及特点：
演化模型主要针对事先不能完整定义需求的软件开发，其开发过程一般是首先开发核心系统，当核心系统投入运行后，软件开发人员根据用户的反馈，实施开发的迭代过程，每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，直到软件开发结束。
演化模型在一定程度上减少了软件开发活动的盲目性。
螺旋模型容及特点：
它是在瀑布模型和演化模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。
沿螺旋模型顺时针方向，依次表达了四个方面的活动，制定计划、风险分析、实施工程、客户评估。
喷泉模型容及特点：
它体现了软件创建所固有的迭代和无间隙特征，喷泉模型主要用于支持面向对象开发过程。
增量模型容：
在设计了软件系统整体体系结构之后，首先完整的开发系统的一个初始子集，继之，根据这一子集，建造一个更加精细的版本，如此不断的进行系统的增量开发。
瀑布模型、演化模型、螺旋模型之间的联系：
相同点是这三个模型都分为多个阶段，而瀑布模型一次完成软件，演化模型分为多次完成，每次迭代完成软件的一个部分，螺旋模型也分为多次完成，每次完成软件的一个新原型，并考虑风险分析。
3.5.3本系统的研究方法
本系统的开发严格遵守软件工程开发的标准流程。
实地考察，进行需求分析，书写需求分析表和初步的软件说明书。
在模块设计的同时进行单元测试，系统设计完成进行系统调试和系统集成测试。
设计完成后，编写完整的软件说明书和用户手册，最后还需写对自己所作设计的评价和总结。
经过对各个软件工程的模型的分析，我决定使用瀑布模型进行开发。
因为本系统的开发人员仅为我一人，非小组合作，在对各个阶段的交接上，只能按顺序进行，完成上一阶段后才能进行下一阶段的工作。
我的整个软件开发流程如图：
图3.1Androida斗地主游戏开发流程
第4章概要设计
4.1系统总体设计方案
4.1.1设计原则
（1）戏被运行时，首先生成两个电脑玩家，然后游戏开始发牌，并规定该局首先叫牌者，使之进入叫牌状态。
最终叫到地主的客户端必须首先出牌。
（2）玩家的任何动作必须调用规则控制接口。
当接口返回动作合法的结果时，玩家才能做出所请示的动作（实际上只是显示动作的结果，因为接口已经处理了该动作，在发送许可的同时发送了处理结果）。
否则，接口返回拒绝消息，玩家则显示有关错误信息。
（3）电脑玩家根据牌局生成出牌方案，然后返回数据，并执行相应的显示与相关的游戏设置。
4.2基于Android的模块设计
4.2.1模块设计
（1）游戏规则的实现
通过封装相应的类来实现规则。
类card：
卡片类（牌），数据成员为花色（color）,牌面（value），数目
（num），存在标志（exist）。
枚举colors：
包括方块，梅花，红心，黑桃，小鬼，大鬼总共六种花色。
结构体comb：
含头头是单，双，三顺，炸弹，火箭等所有牌型的标记位。
类player：
玩家类，数据成员：
玩家靓号（m_strplayerID），个性签名（m_strName），登陆密码（m_strPassword）等。
类playingCards：
游戏规则类，数据成员：
玩家数目（numPlayers），有牌数目（numCards），每个玩家有牌数目（cardsEach）等。
成员函数：
游戏初始化initgame（），洗牌suffle（），发牌sendCards（）叫地主candlander（intseat,intpoint），出牌outcards（player&
ThisPlayer）等等。
Card是游戏的对象，一般而言，特定的游戏都有特定的游戏对象。
Colors,comb都是根据需要，对card的补充。
Colors是各个牌的花色共有6种，后两种是小鬼（Bjoke）大鬼（Rjoke），不用于其他牌。
Comb是combo的意思，指牌的类型。
在斗地主中，牌型有单牌，顺子，对子，3带**，4带**，炸弹，火箭等,详细请看附录2网络斗地主的规则简介。
Player是玩家在服务器中的一个映射，玩家的任何动作都由它代为完成，然后将结果返回给服务器的相关存。
playingCards充分利用以上几个类的对象，对附录2中“一副牌的规则”进行了模拟实现，做到了一模一样。
并且加上了方法。
封装起来，外界通过类的对象，只要调用它的方法，就可以实施对玩家出牌的合法性判断，并做相关结果的存储工作。
至于判断结果如何处置，请参看（3）游戏平台的实现
（2）游戏平台的实现：
对话框CdisplayflashDlg：
客户端游戏界面，含与flashUI通信的接口。
数据成员：
积分m_nintegral，剩牌数目m_nsparecards座位号m_norder_seats，放弃动作m_nPass，手上的牌m_strpcards选择的牌m_strselectcards，合法牌m_stroutcards等等。
接收数据OnReceive（），关闭OnClose（）等。
顾名思义，display就是显示的意思，flash就是用动画显示。
在客户端,只通过接收机制判断命令是否针对自己,若是,则执行之,显示服务器处理结果。
否则,不执行,只获取当前玩家状态。
该接收机制就是OnReceive方法。
它通过switch（）-case机制区分不同的消息；
通过msg.InfoAbout和m_norder_seats来判断消息中的指令是否针对自己发出的。
4.3相关技术的处理应用
4.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;
详细代码请看附录或磁盘；
第5章详细设计与系统实现
详细设计是整个设计过程中，最重要的步骤之一。
本系统的功能主要分成两大模块:
服务器端和客户端。
每个模块有可以分成几个子模块。
下面分几个部分对各个模块进行详细设计：
功能模块
●数据接收功能
●显示信息功能
●数据捕获功能
●合法性判断功能
●游戏退出功能
5.1功能模块的实现
5.1.1启动游戏
点击“启动游戏”就可以调用成员函数OnSet（），启动游戏。
这个很简单，就不多讲啦。
5.1.2开始游戏功能
启动游戏后,自动生成两个电脑玩家，开始进入游戏状态。
5.1.3数据捕获功能
OnReceive（）捕获数据
5.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）,否则，提示出牌不合法。
如果牌面大小合法，则出牌最终是合法的，将出牌处理结果，存入List<
Card>
front=newArrayList<
（20），并发送给各个玩家。
值得一提的是，地主开局第一次出牌或者后继两家玩家都pass掉时，List<
front中的value值全为-1，其他诸如：
exist,color,num分别为1,（colors）1,1;
所以此时，当前出牌玩家出的牌，只要是合法的牌型，就可打合法地打出去。
5.2.2玩家操作功能
操作判断机制switch（msg.message）-case中，case共分0:
登录1:
退出2:
开牌3:
叫牌4:
出牌5:
pass6:
计分六种情况。
在此以最重要使用、最频繁的“case4:
出牌”来讲述这个功能。
首先，判断处理结果是否表明前面出牌是否非法，如果是，将给机会客户端重新出牌。
否则，判断，信息是否是发给发出前面动作的本人。
是，则将合法牌显示在UI上，并更新手上的牌。
否则，只显示别人打出来的牌，及其所剩牌数目。
然后，当前面动作者是接收方的直接上家（或逻辑上家）时，接收方获得出牌权。
否则，没有出牌权。
详细规则请参看附录1客店端对出牌的显示控制。
5.2.3显示信息功能
CdisplayDlg.m_strpcards存储玩家手上的牌。
然后实现排序的问题和合法牌打出以及非法牌回收的问题。
排序效果如图:
图5.5玩家收到的牌及其三种排序（按花色,大小,牌型）
排序算法如下:
先将用户手上的牌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中,等待发送至服务器端.当用户选完想出的牌,点击手形图标后,就同时触发方法voidCdisplayflashDlg.OnButtonOutcards（）,msg.m_strpos就随之被发送到服务器端了。
服务器的处理方式请参看5.1.4合法性判断功能
CdisplaySocketDlg.m_stroutcards玩家出如果经服务器判断合法，将被接受并存储在这个参数里。
客户端将合法的牌全部显示在界面中央,并在动作者的手上将相应的牌清除掉（使相应牌的exist=-1）。
如下图：
我们可以看到，动作者手上的梅花3补打出去了，由于这是地主的第一次出牌，服务器判定其合法，客户端收到判断结果后，将牌打出去在界面的中央位置显示，而在自己手上，清除掉该“梅花3”。
图5.6选中一牌并正常打出去
如果不合法,系统将不打出去,并给出错误提示.并且，将不合法的牌还原到动作者手中，让动作者重新选择：
出牌ORPASS。
原理其实与上面的小异，就不必赘述了。
如图:
5.7非法出牌报错
5.2.4游戏退出功能
CdisplayDlg:
:
OnExit（）退出游戏
调用系统方法关闭窗口、关闭对话框。
第6章系统测试与维护
在软件程序编码完成之后，在软件投入使用之前要进行软件测试。
何谓软件测试,简言之：
软件测试是为了发现错误而执行程序的过程。
也就是根据软件开发各阶段的规格说明何程序的部结构而精心设计测试用例，用这些用例去运行程序以发现程序错误的过程。
系统测试在一个系统的周期中占有越来越重要的位置了。
在系统正式投入运行的转换工作之前，还需对系统进行一系列的调试即测试。
系统调试的任务是根据系统说明书和系统实施方案，对程序设计的结果进行全面的检查，找出并纠正其中的错误，使可能发生的问题和错误，尽量消灭在系统正式运行之前。
6.1系统测试的原则
●应当尽早和不断的进行软件测试.
●测试用例应由测试输入数据和预期输出结果两部分组成.（注意:
测试用例包含输入和输出两部分）.
●测试用例应包括合理的输入条件和不合理的输入条件.前者即使程序正常运行的条件,后者即可能引起程序非法操作的条件.
●程序员应避免检查自己的程序.因为父母总是疼爱自己的孩子.程序员总是在潜意识不愿意否定自己的劳动成果.
●注意测试中的群集现象.测试后程序中残存的错误数目与该程序中已发现的错误数目成正比.所以,不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试,相反该程序段更要集中精力测试。
●测试应该制订计划,严格按计划进行测试,避免测试的随意性.
●应对每一个测试结果做全面检查.
有时出错的征兆已经在测试结果中出现了,但由于没有对测试结果进行仔细检查,而使这个错误成了漏网之鱼.
●应妥善保存测试计划,用例,错误记录和分析报告.
6.2测试过程及方法
软件的测试过程有四个步骤:
单元测试,集成测试,确认测试和系统测试.
单元测试即对每一个单元模块进行测试.然后把测试过的模块组装起来进行集成测试,主要是对软件体系结构的构造进行测试.接着进行确认测试,检查软件是否满足了各种需求,以及配置是否合理安全.最后是系统测试,即把经确认测试后的软件放到实际运行环境中,与系统的其他构件一起进行测试.
单元测试时,有时需要为测试的模块编写辅助模块:
驱动模块和桩模块.前者是用来调用被测模块;
后者用来代替被测模块调用的子模块。
集成测试,又叫组装测试,分为两种:
一次性组装和增殖式组装.一次性组装方式即把经单元测试后的模块一次性的组装成系统进行测试.增殖式组装方式即在模块组装的过程中,边组装边测试,每增加一个或几个模块就测试一次,最后组装成最后的系统,它又分为:
自顶向下的增殖,自底向上的增殖,混合增殖等几种方式.
确认测试过程要做的工作包括:
有效性测试,软件配置复审,验收测试和安装测试.在验收测试中常用的有α测试和β测试.α测试时,开发者坐在用户旁边,随时记录用户发现的问题.β测试则开发者不在测试现场,故是在开发者无法控制的环境下进行的测试,通常是由软件开发者向用户散发β版软件,然后收集用户的意见.
测试的方法大体可以分为两种:
黑盒测试和白盒测试.
黑盒测试即把测试的对象看成一个黑盒子,不考虑程序部的逻辑结构和部特性,主要在软件的接口处进行测试,主要测试软件的功能.黑盒测试的方法包括:
等价类划分法,边界值分析,错误推测法,因果图,功能图等.
白盒测试把测试对象看成是一个打开的盒子,程序部的逻辑结构和其他信息对测试人员都是公开的.白盒测试的方法有:
逻辑覆盖（语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖,路径覆盖）,基本路径测试等.
6.3测试环境
测试的硬件环境为：
主机为英特尔赛扬M处理器3601.4GHZ，硬盘为40G，存容量256M。
测试的软件环境是：
用户界面用Android模拟器进行测试，逻辑控制用单元测试工具JUnit进行测试。
最后，在Android模拟器上进行集成测试。
6.4测试中的BUG及问题总结
测试的过程中，我首先进行了代码走查。
对自己编写过的代码进行了全面的检查，发现不仅有很多设计不合理的地方，还有很多潜在的错误。
比如，在定义类的对象的类型时，为了方便，都定义为Public，这对这些都对系统以后的运行造成错误和危险。
对于及时发现的问题，我都进行了改正。
接着是白盒测试，我对各个模块又小到大，有单个到集成进行了测试，发现在模块间的衔接上总会出现些小问题。
但经耐心检查定位，一个个找到了错误的原因，排除了错误。
最后进行的是黑盒测试，由于之前的调试修改为这次测试做了铺垫
升级会员 