昆特牌Online——客户端设计

OpenSceneGraph介绍:

OpenSceneGraph(以下简称OSG)是一个开源的三维引擎,被广泛的应用在可视化仿真、游戏、虚拟现实、科学计算、三维重建、地理信息、太空探索、石油矿产等领域。OSG采用标准C++和OpenGL编写而成,可运行在所有的Windows平台、OSX、GNU/Linux、IRIX、Solaris、HP-Ux、AIX、Android和FreeBSD 操作系统。

更多关于OSG的信息:http://www.openscenegraph.org/

游戏大致规则:

  昆特牌是一款以北欧风格为背景的回合制卡牌类游戏。每局由两位玩家进行游戏,胜负的判定方式是3局2胜,先赢2局的玩家获胜。玩家开局会在卡组中随机抽取10张卡牌。与一般卡牌游戏不同的是除了依靠少数效果卡和群组效果以外玩家是无法抽取新卡的,也就是说全部的2-3小局游戏里玩家只有10张卡可以用,用过的卡在下个小局中无法再次使用也没有新卡补充。

  单位卡分为3类,近战,远程和攻城。每类占一横排。一小局游戏结束时,全部攻击力量值相加,大的一方获胜。一小局游戏中,双方轮流出卡,一次一张,直到一方没卡或者主动按空格键结束出卡时一小局结束并开始清算力量点数。天气卡会影响双方同一种类的单位。

详细规则参见:

http://witcher.wikia.com/wiki/Gwent

类的设计:

Director负责控制游戏逻辑及行为,下属两个Player对象

Player负责控制一盘游戏中某个玩家的行为,玩家输入由PickHandler检测并给出相应信号以另Player反应

P2Callback是一个响应对象,他的operator方法在每一帧都会被调用一次,用于实现动画效果和网络消息收发。

DataRecieverThread是一个线程,用于接收网络消息。

Deck、Garabge、Hand分别是三个CardStack的子类,CardStack是一个卡牌的栈。

Field下属四个CardStack:weather、meele、archer、siege。

这几个CardStack在游戏中分布如下:

游戏的控制流程如下:

界面设计:

客户端登录时需输入服务器ip地址,登录界面如下:

输入正确的服务器ip后可连入并选择房间,若房间已满会以”full”进行提示,若强行进入会被踢出服务器:

进入房间后等待两位玩家全部进入后即可开始游戏:

时间: 2024-11-08 23:32:55

昆特牌Online——客户端设计的相关文章

昆特牌Online——客户端用到的一些技术

[1]    通过建模软件(如3D Max)对游戏场景中的静态对象和动态角色进行建模. 游戏的牌桌和右下角的工作室标志使用了3ds Max建模 牌桌: 标志: [2]    基于Phong光照模型实现场景的实时光照. 游戏中使用了两个光源: 一个静止的无向光源,放置于与摄像机相同的位置: 一个运动的有向聚光灯,会追踪鼠标的运动,效果如下: 可以看出,截图中鼠标经过的部分(鼠标未在截图中显示)物体被照亮. 代码方面,使用osg::Light和osg::LightSource来指定光源,聚光灯的部分

团队项目:昆特牌Online

昆特牌是出现在游戏<巫师3>中的一款卡牌类游戏,规则易懂玩法独到,深受广大玩家喜爱. 昆特牌规则简单,游戏中每张牌有自己的点数和特殊技能,玩家需利用自己有限的手牌在回合中使自己的点数总和大于对手,即可获胜.游戏采用3局2胜制.玩家开局会在卡组中随机抽取10张卡牌,并且可以选择其中2张放回卡组重抽.与一般卡牌游戏不同的是除了依靠少数效果卡和群组效果以外玩家是无法抽取新卡的,也就是说全部的2-3小局游戏里玩家只有10张卡可以用,用过的卡在下个小局中无法再次使用也没有新卡补充.单位卡分为3类,近战,

基于Html5的智能家居手机客户端设计(一)——找到openhab的rest

今天开始我的毕业设计,基于HTML5的智能家居手机客户端设计.挑剔了好久,终于找到我可以使用国外开源项目智能家居核心,通过restful(我也不是很懂,毕竟我只是电子信息学院爱好网络). REST描述了一个架构样式的网络系统,比如 web 应用程序.在目前主流的三种Web服务交互方案中,REST相比于SOAP(Simple Object Access protocol,简单对象访问协议)以及XML-RPC更加简单明了,无论是对URL的处理还是对Payload的编码,REST都倾向于用更加简单轻量

Android 客户端设计之环境考虑

我做过两三个android客户端应用的整体设计和部分的编码,这里仅仅谈一下设计方面的故事(此乃原创2015:11:02). 做客户端设计,首先要考虑应用所在的环境,包括三方面:1 要设计的apk是在一个低内存,低运行速率,多应用共同运行(现在很多应用都在后台一直存活,不死鸟)的环境中:2 要设计的apk需要调用系统其它的数据或功能接口:3 apk置身于整体手机的运行环境中,必然手机的各种状态的变化,会对apk的运行造成影响,例如开网断网,亮屏灭屏等. 从1来考虑,必须要在设计之初,从数据流考虑a

安卓升级服务端和客户端设计

三.服务器端和客户端设计 服务器端设计: 设计方法应该有很多,下面介绍我的一种方法: a.首先在服务器项目下建立一个文件夹来存放APK安装文件: b.其次在src下建立一个资源文件,apkVersion.properties,属性定义如下: [plain] view plaincopyprint? apkVersion=1 存版本号apkSize=550kb 大小apkPath=http://xx8080/srv/apk/Demo.apk 升级文件 c.定义一个servlet来获取资源中的信息:

关于客户端设计之数据分类和存储 的思考

一.关于数据的分类 在Android 客户端设计过程中,我将数据分为未知,已知(本地),临时,三者之间根据需求相互转化. 未知主要来自用户输入和服务端输入. 已知主要来自sharedPerferences,SQLite等本地存储. 临时主要是指存在于当前内存中的数据.在程序运行后,来自于前两种方式,随载体的生命周期开始,结束.(这里尤其注意单例模式下的数据的特殊,使用static或者Application,各有利弊.) 二.Android下数据单例模式设计 1.Application本身就是单例

GPS部标平台的架构设计(九)-GPS监控客户端设计

交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分. 客户端设计面临两个问题: 1.基于CS还是基于BS,这是个问题 萝卜白菜各有所爱,客户要什么,我们就开发什么,从客户来讲,更适应桌面客户端,没有浏览器的七七八八问题,速度感觉上也比网页的快,操作方便.当然网页客户端也有很大的优势,部署和维护方便,不需要开发升级系统. 2.与服务端的交互通信,采用Socket, WebService还

ACM_题目这么难,来局愉快的昆特牌吧

题目这么难,来局愉快的昆特牌吧 Time Limit: 2000/1000ms (Java/Others) Problem Description: 小Z打比赛,然而比赛太难了,他坐在电脑面前被题淹没不知所措,决定开始打一局昆特牌来舒缓心情,然而这个规则出题人也帮他想好了,他发给小Z三种牌,分别是'A''C''M',每集齐一套'A''C''M',小Z就能放一个技能,听起来酷对不对?现在给出小Z手中的牌,问你他能放多少次技能. Input: 输入包含多组样例,第一行为一个整数T(1≤T≤100)表

《攻城Online》快速原型:客户端设计

“攻城”客户端采用Unity引擎并结合Photon框架进行开发. 关于将Photon配置进游戏引擎中的操作本篇直接省略. 在展开之前,先来看看Unity的文件夹组织层次. Audios放音频文件,Libs放一些外部的动态链接库文件,Models放模型资源,预留的Resources文件夹主要服务于Resource类,Scenes放场景文件,重点是Scripts文件夹. 首先ClientLogic层存放与逻辑相关的脚本.Photon客户端采用事件监听体制,Event中存放事件数据类的定义,从下面的项