Cocos2d-x类COC手游与RTS（即时战略）游戏的编程实践总结
招聘信息：
概述先来看一段视频。这个视频很短。4分钟。是我的一个技术demo演示视频。- 这一个月左右的时间里，我独自一人在家做了上面视频中技术演示的demo。用的是Cocos2d-x引擎。说到Cocos2d-x，我接触有一年了。这个demo中的图片资源都是我自己网上找的。而按钮等UI是我用PS自己画的，主要是网上找不到合适的UI。下方的方形按钮，是我模仿COC的来画的。下面截图是Windows上开发环境（VS2013）运行的效果：下图是编译到了安卓手机运行的效果：从上面的视频和截图可以看到，一个月里，对于制作类COC游戏，我在技术上进行了一些尝试和探索。我之前没怎么做过游戏，尝试去做，可以发现编写这类游戏会遇到哪些问题，并且思考怎样解决。算是一种积累经验吧。关于COC，大家应该都不陌生。Supercell公司成立于3年前，后来推出了一款叫 Clash of Clans 的移动游戏，简称COC。这款手游后来成为了地球上2014年最赚钱的手游，并且Supercell市值飙到了30亿美元。关于COC的报道可以看看这2篇文章：大家感兴趣的话，也可以网上自己搜搜关于COC的更多信息。最初我是想模仿制作一个类COC的手游（也许最终会和COC有很大的不同），并且加入RTS游戏的元素。比如：可以直接选中和控制兵的移动和攻击，增加操作感等。为什么我会想加入RTS的元素呢？因为，很久很久以前，我是一个魔兽3遭遇战玩家，曾经BN亚洲战网排名前100-200。在视频中，你会看到。我已经实现的游戏功能有：摆放建筑，拖曳和缩放游戏场景，单位兵种移动和简单的攻击。我没有加入任何游戏的业务逻辑代码。因为我想搭建一个基础框架或者是理清一下思路。熟悉编写这种游戏后，可以改成：RPG（角色扮演），RTS（即时战略），SLG（策略），塔防等多种类型的游戏。试想一下，如果用做RTS的技术来做一个塔防有多酷。RTS对现实世界有更仿真的模拟，但同时技术含量肯定也会比《保卫萝卜》等高。这就是之前为什么说&也许最终会和COC有很大的不同&的原因。COC这类的游戏，相对其他手游来说，编写的难度要复杂很多。下面总结一下，目前我已知的，编写类COC游戏会遇到的技术点。编写类COC游戏的一些技术点1. 操作的策划是先定义好操作规则然后实现，还是一面做一面想一面改？我觉得可能是后者，除非一点都不创新，想原封不动地照搬&被抄袭的产品&。一开始谁都不太可能把整个系统，整个规则都想清楚，都定义下来。因为我是一个人，所以，我是一面做一面想一面改。我一开始不可能把各种细节都想清楚，所以是先做着看看。腾讯的《城堡争霸》是一款仿COC的产品，操作上和COC有一些不同。比如：移动建筑，手指放开的时候，就直接摆下建筑了。而COC还要再点击一下确定摆下建筑。在操作上，COC多了一个再次点击。2. 操作代码的编写COC这种游戏，是一种游戏元素很多的游戏。通常上面有树、石头，建筑，各种兵种角色单位等。有3种基本操作。单个手指滑动代表拖曳游戏场景。两个手指代表缩放游戏场景。点击屏幕同时也代表选中一个单位。腾讯的《城堡争霸》的2个手指的捏合缩放是和COC不同的。《城堡争霸》的实现算是&中心缩放&，不能同时移动游戏场景。我的实现是仿COC，看视频就知道了，缩放场景的同时还能控制场景移动。拖动与缩放还需要有限制：不能移动到游戏世界区域之外，看到游戏世界外面的黑块。不能无限放大和缩小。我目前只做了缩放的限制，还没做移动的限制。移动限制的话，有点麻烦，和缩放是有关系的。观察COC就会发现，如果在一个建筑上面按下手指，如果没有拖动的话，就是选择这个建筑。如果拖动了，就不会选择这个建筑，而只是拖动游戏场景。所以，程序中要做一些判断和记录：是否有拖动等。像我这种，还加入了RTS控制元素，可以选择行动体单位并且控制它进行移动和攻击，这会让操作控制代码变得更复杂。对于这种复杂的操作，我是用状态机来解决。在onTouchesBegan，onTouchesMoved，onTouchesEnded 3个触摸函数中都弄了状态机。触摸函数肯定用的是多点触摸，否者没法搞双手指捏合缩放。我新建一个触摸层来专门处理触摸，因为操作的控制本身就很复杂，这样做可以分割复杂度。我的onTouchesMoved的代码截图：外层代码，先判断是一个点触摸了，还是2个点同时触摸。然后在2个判断分支中都做switch-case的状态机处理。有看过设计模式的同学可能会知道，用switch-case写状态机代码是&幼稚的&，我觉得，如果在尝试阶段，还没想清楚的时候，用switch-case也无妨。等我想清楚的时候，我可能会改成状态模式的实现。3. 角色的AICOC中有一些&行动自治体&，比如，有一些角色，会到处走动，一下子摸摸树一下子摸摸石头。空降兵到敌人领地时会进行自动攻击等。这是一些什么三消，跑酷类游戏都没有的。编写这些AI，让玩家有一种在&世界&中的感觉，是相对于其他类型的手游额外多出来的部分。基本上用状态机建模，都可以搞定这些AI。但目前我的实现程度，还没有做&行动自治体&。寻路也属于AI部分，求最短路径的A*算法就是人工智能领域中的算法。其实COC中的寻路是比较简单的，相比红警，帝国，魔兽等这种真正的RTS游戏来说。我的游戏中用的寻路也是A*，关于A*算法，可以参考下我写的这篇文章：《》之前我有尝试，把寻路算法改成开一个线程来计算，这样的话，就可以不卡住界面。传统软件的编写经常这样用。但后来再改的过程中遇到不少麻烦和问题，遂暂时搁浅之。编写真正的RTS游戏的技术点COC其实并不是一个真正RTS游戏，而是一个经营策略类游戏。之前提到了，我想加入RTS游戏的元素，那么我们来看看RTS游戏有什么技术点。1. 不允许行动体互相穿越的限制COC的人物是允许互相穿越的，就是2个行动单位可以互相重叠在一起。魔兽3的行动单位则不允许。不允许互相穿越是基于现实的模拟。正是因为不允许穿越，魔兽3才有了&卡位&，&M围杀&等各种操作技巧。我在实践的过程中发现，魔兽的限制穿越的编写处理是比较麻烦的。我个人猜测可能Supercell感觉这个问题实在是有点费神，所以就允许穿越了，不做那么真实的模拟。允许穿越，实际上会极大降低程序的编写复杂度，为什么这样说呢？听我娓娓道来。不允许穿越通常是用碰撞检测的方法来做，如果游戏场景很大的话，为了降低碰撞检测的时间复杂度，需要做空间分割处理。不允许穿越会涉及更多的AI问题。比如：&移动碰头死锁&。呵呵，&移动碰头死锁&是我自己发明的名词，用来描述这样一种场景：在一个狭小且长的通路中，比如一座桥、一个巷子里面、树林的间隙中，或者甚至是空地，有2个单位，A从左向右行走，B从右向左行走，这2个单位都在同一个水平线上，那么就有一个&你不让我，我不让你&的问题。用我的游戏截图，如下图：上图，A和B都往对方的方向走去，在某个时间上，他们会&碰头&，如下图：如果没有AI控制的话，就会出现互不相让的&死锁&，双方都在不断往对方的方向&推&。这种情况，我们需要编写AI去决定A和B如何谦让，然后，再行动到各自的目的地。目前我的做法比较简单，有一个行动体可能会停下来，然后另一个行动体绕过他。或者是2个行动体都停下来。玩家需要重新控制行动。这种做法会让玩家觉得游戏中的人物很&蠢&且自己很麻烦，行动体不会聪明避让且需要自己重新控制行动。还有就是&集体行动&时的控制。如下图：控制了一帮人往一个地方走，他们之间是不允许互相重叠的。在碰撞检测中，如果发生了碰撞，需要判断，是之前说的&碰头&还是&大家往同一个方向走&的情况。如果是非碰头情况，我的做法是：等待前面的单位移动出空位之后，后面的单位才上前挪一点。代码截图：&从上面代码可以看到，我仅仅是暂停了Node节点的移动Action。如果检测发现没有碰撞了，就恢复执行之前的MoveTo动作。目前我的实现还有缺陷，并不完善。在某种情况下，集体行动，会出现&穿越&的问题，但在大部分情况下是可以保持不穿越的。实际上，防穿越还会涉及更多的细节问题，这里我就不一一列举了。从上可以看到，如果加入了防穿越，会让程序复杂很多。允许穿越的话，什么&碰头死锁&，&集体移动&等问题都没有了。从复杂度、开发成本等各方面因素考虑，我想这是Supercell不做防穿越的原因。2. 行军算法、布阵算法在魔兽3中，控制部队达到某地，是有行动队形的。目前我还没有仔细去考虑如何做，但这个在RTS游戏中是存在的。另一个问题是关于布阵。仔细观察和研究魔兽3，选中8个农民到某地，那8个农民到目的地后，有一个类似于矩形的阵型。规则布阵这个问题，我也没仔细考虑。但不可避免的是随机阵型总要考虑，就是说，如下这种情况：选中了N个单位，然后指挥他们到某处。这N个单位因为受之前的仿穿越限制，他们不能集中在一个点上。那么，如何确定各个单位的目的点？我的做法是：在目的点，进行BFS（宽度优先搜索），寻找每个单位可以被容纳的位置，为什么用BFS算法？因为BFS有圆形向外扩展的特性。我的代码截图如下：有一个细节是，如何保持原先的集体&布局&？看下图：A，B，C 对于整个选中的单位集合来说，有自己所处的位置。移动这些单位到另一处，好的做法是，也同时保持他们原先在集体中的位置。因为，这样做是对整体行军来说，总体移动成本最小。总体移动成本就是说，对于集体中每个行动单位的行动耗时、路径长度等之和。总体移动成本越小，给玩家的感觉就越和谐。我在实践中，发现了这个问题，做了一些简单处理。不过从目前来说，效果并不怎么好。3. &A过去&如何做玩魔兽的朋友都知道&A过去&的含义吧？A过去就是&攻击过去&的意思，源于魔兽3的A键控制。&过去攻击&包括2个分解步骤，1.先走过去，2.达到攻击范围后，开始攻击。A过去有2个作用点：1.玩家A的是地板。2.玩家A的是一个游戏实体，某个敌军单位、建筑等。玩家A的是地板的话，AI逻辑是：控制行动体走到A的目的点，如果在行动的过程中有敌军进入了攻击范围，就攻击，歼灭了敌军，继续走到目的点。玩家A的是某个游戏实体的话，AI逻辑是：记住被A的那个目标实体，追着他打，直到目标被歼灭。红警的A，坦克会用炮弹攻击地面。魔兽3的A，只有控制投石车才会攻击地面。目前我还没实现A过去的逻辑。4. 单位大小通过限制魔兽3中的食尸鬼可以通过的地方，剑圣不一定能通过。因为，食尸鬼、剑圣、尸魔 等 的体积不一样。单纯的A*算法，只是能找到有联通的最短路径。剑圣的寻路是怎样做的？是不是要在A*算法作用的瓦片方格上，把剑圣不能通过的地方，给填充上，再执行A*呢？这个问题我没想清楚。目前我的游戏也不处理这点。综上浅谈的4点就可以看到像魔兽这样的RTS游戏编写的难度。实际上编写一个真正的RTS还远不止这4点那么简单，想想&战争迷雾、地形 等等。肯定还有一些未知的技术难点，我还没意识到。考虑用数据驱动的方式编写游戏所谓的数据驱动，就是用一些配置来控制游戏的显示、行为等。我的demo目前是用COC和其他游戏的素材来做的，以后要改成 RPG，塔防什么的，肯定不能盗用别人的美术资源，是吧。为了方便换皮。游戏实体的显示、动画的显示。我都用了配置来搞。如下面所示。动画表：精灵表：行动体的显示控制表：等等。有10个表了。这些配置表，用Excel来做，然后另存为CSV。程序去解析CSV文件数据。关于CSV数据的解析，我写过一个比较完善的类，有兴趣的话，看看我的这篇博客：《》。目前，我的这个demo也只用了CSV类型的数据做配置，并且也是我用之前博客中写的那个CSV类去做解析。思考的过程这里也和大家分享下，我思考的过程。《暗时间》这本书中讲过，思考是要借助笔和纸的。记录下当前自己探索到的、思考到的步骤和环境。以便于回溯思维的时候，防止忘记自己推理到哪一步了。一个人独立开发，很多时候是自己和自己对话。自己提出设想，自己论证。这种情况就更加需要笔和纸。下面是我的一些草稿纸截图。最后目前我没发现市面上有任何一本书去教如何写RTS游戏。一个月的尝试，还是有价值的。仅仅是做类COC的话，感觉并不很复杂。而一旦加入真正的RTS元素，就知道红警、帝国、魔兽的技术含量有多高了。腾讯等公司可以模仿出COC，什么城堡争霸，陌陌争霸 等。但他们目前做不了&类魔兽3&，&类星际2&，魔兽争霸3 不仅是一个真正的现代RTS，还是3D的。我估计，不是他们不想，而是&类魔兽3&这个玩意&确实有点难度&。目前本人入游戏领域不久，菜鸟一枚，欢迎游戏同行与我交流讨论。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
点击量4815点击量4345点击量3359点击量3129点击量3126点击量3078点击量2850点击量2731<img src="/api/uploads/bae198f0ae576ceda37c7.jpg"
style="max-height:60px" alt="AFNetworking源码解析"/>AFNetworking源码解析点击量2715
&CocoaChina
京公网安备89Cocos2d-x 3.1 一步步做屏幕适配 - 推酷
Cocos2d-x 3.1 一步步做屏幕适配
本文并不想讲关于屏幕适配的概念或者大道理，如果还不了解cocos2d-x屏幕适配的，请先看这篇文章：
。本文有一些内容和图片是引用这篇文章的。看了那么多网上关于屏幕适配的文章，还是觉得似懂非懂，所以最好的方法就是自己一步步做好适配。
一、根据屏幕尺寸选择“最”合适的图片。
如果根据屏幕尺寸来选择一样大小的图片，那么美工要哭了，因为对于安卓机，各种各样的分辨率啊，不仅美工要哭了，程序员也要哭了。所以，我们只能选择最合适的图片，比如320*500分辨率和300*480分辨率的屏幕可以使用320*480的图片。
1、在Cocos2d-x自带的解决方案中就有针对iphone、ipad和ipadhd所做的适配方案，在工程cpp-empty-test有例子。
// AppMacros.h
#define DESIGN_RESOLUTION_480X320 0
#define DESIGN_RESOLUTION_
#define DESIGN_RESOLUTION_
// 要切换设计方案，改变这一行即可
#define TARGET_DESIGN_RESOLUTION_SIZE
DESIGN_RESOLUTION_480X320
typedef struct tagResource
cocos2d::S
char directory[100]; // 资源路径
static Resource smallResource
{ cocos2d::Size(480, 320),
&iphone& };
static Resource mediumResource =
{ cocos2d::Size(),
static Resource largeResource
{ cocos2d::Size(), &ipadhd& };
#if (TARGET_DESIGN_RESOLUTION_SIZE == DESIGN_RESOLUTION_480X320)
static cocos2d::Size designResolutionSize = cocos2d::Size(480, 320);
#elif (TARGET_DESIGN_RESOLUTION_SIZE == DESIGN_RESOLUTION_)
static cocos2d::Size designResolutionSize = cocos2d::Size();
#elif (TARGET_DESIGN_RESOLUTION_SIZE == DESIGN_RESOLUTION_)
static cocos2d::Size designResolutionSize = cocos2d::Size();
#error unknown target design resolution!
// 480*320的字体大小是24号，根据当前的分辨率来修改字体大小
#define TITLE_FONT_SIZE
(cocos2d::Director::getInstance()-&getOpenGLView()-&getDesignResolutionSize().width / smallResource.size.width * 24)
从上面可以看出，cocos2d-x定义了三种大小，分别是iphone(480*320)，ipad()，ipadhd()，一般用得比较多的是iphone和ipad。
我们再看一下资源文件夹，工程-&Resource下：
iphone目录：
ipad目录：
ipadhd目录：
也就是说，在这三个文件夹里面有三套不同大小分辨率的图片，我们之后根据屏幕大小来选择对应的图片就行了。
2、实现怎么根据屏幕大小来选择图片。
新建一个工程，再将AppMacros.h文件拷贝过去。
// AppDelegate.cpp
bool AppDelegate::applicationDidFinishLaunching() {
// initialize director
auto director = Director::getInstance();
auto glview = director-&getOpenGLView();
if(!glview) {
glview = GLView::create(&My Game&);
glview-&setFrameSize(480, 320); // 在这里设置创建窗口的尺寸，手机上这个就不用啦，因为手机有固定的屏幕
director-&setOpenGLView(glview);
auto screenSize = glview-&getFrameSize(); // 获取屏幕尺寸
std::vector&std::string& searchP
// 这里是实现的重点，比较屏幕的高和设定的三种适配尺寸的高，选择合适的图片
// 然后将对应图片的路径添加到搜索路径中，那么cocos2d-x就会到该目录去寻找图片
if (screenSize.height & middleResource.size.height)
searchPaths.push_back(largeResource.directory);
}else if (screenSize.height & smallResource.size.height)
searchPaths.push_back(middleResource.directory);
searchPaths.push_back(smallResource.directory);
FileUtils::getInstance()-&setSearchPaths(searchPaths);
// turn on display FPS
director-&setDisplayStats(true);
// set FPS. the default value is 1.0/60 if you don't call this
director-&setAnimationInterval(1.0 / 60);
// create a scene. it's an autorelease object
auto scene = HelloWorld::createScene();
director-&runWithScene(scene);
3、改变窗口尺寸来看效果：
窗口尺寸500*300：
因为高300小于320，所以使用480*320的图片。这时候看到的是左右有黑边，上下被截了一点。没事，下面会讲怎么解决。
窗口尺寸700*300：
还是用480*320分辨率的，都是300的错。
窗口尺寸800*480：
这次用的是的了，因为320&480&768。
在500*300尺寸中我们看到图片左右因为不够宽而出现黑边，而上下因为太大了而被截取了一部分，那么要怎么解决这个问题呢？往下看。
二、图片与屏幕“完美”融合
为了使图片能与屏幕“完美”融合，Cocos2d-x提供了一组相关的接口和5种分辨率适配的策略。
首先了解一下三种分辨率：
资源分辨率：也就是图片分辨率，下面宽Resource Width简写为RW，高Resource Height简写为RH。
设计分辨率：也就是我们设定区域的分辨率，下面宽Design Width简写为DW，高Design Height简写为DH。
屏幕分辨率：也就是窗口分辨率，下面宽Screen Width简写为SW，高Screen Height简写为SH。
Cocos2d-x的图片显示有下面两个过程：
从资源分辨率到设计分辨率，从设计分辨率到屏幕分辨率。
这个过程就是：
1、先选定目标的设计分辨率，在AppMacros.h中我们定义了三种分辨率，分别是480*320,8*1536：
2、从资源分辨率到设计分辨率
通过setContentScaleFactor()函数来缩放图片的分辨率，以适应设计分辨率的大小。这个函数的参数不是通过资源宽/屏幕宽、资源高/屏幕高得来的，而是通过资源宽/设计分辨率宽、资源高/设计分辨率高得来的。这样我们就可以不关注屏幕尺寸，先根据现有的资源跟选好的设计分辨率来做好适配。
在上面800*480尺寸的图中可以看到，图片四边都被截取了，原因就是没有做好图片的缩放，接下来我们先用setContentScaleFactor()来做图片缩放。
设计分辨率选择的是480*320，窗口分辨率480*321，这样用的就是分辨率的图片了：
if (screenSize.height & middleResource.size.height)
searchPaths.push_back(largeResource.directory);
director-&setContentScaleFactor(largeResource.size.height/designResolutionSize.height);
}else if (screenSize.height & smallResource.size.height)
searchPaths.push_back(middleResource.directory);
// 缩放因子是资源宽/设计分辨率宽
director-&setContentScaleFactor(middleResource.size.height/designResolutionSize.height);
searchPaths.push_back(smallResource.directory);
director-&setContentScaleFactor(smallResource.size.height/designResolutionSize.height);
用高度比作为内容缩放因子，保证了背景资源的垂直方向在设计分辨率范围内的全部显示。
修改缩放因子为资源宽/设计宽：
// 缩放因子是资源宽/设计分辨率宽
director-&setContentScaleFactor(middleResource.size.width/designResolutionSize.width);
用宽度比作为内容缩放因子，保证了背景资源的水平方向在设计分辨率范围内的全部显示。
可以参考一下这张图，我的是横屏的，这张图画的是竖屏的，不过原理一样：
3、从设计分辨率到屏幕分辨率
设计分辨率是我们自定义分辨率方案，图片根据设计分辨率做好了缩放效果了，如果跟屏幕分辨率适配，说白了就是一厢情愿。最后一步就是使用setDesignResolutionSize()函数来实现设计分辨率到屏幕分辨率的完美适配了：
void GLViewProtocol::setDesignResolutionSize(float width, // DW
float height, // DH
ResolutionPolicy resolutionPolicy) // 适配策略
五种适配策略：
enum class ResolutionPolicy
EXACT_FIT,
NO_BORDER,
FIXED_HEIGHT,
FIXED_WIDTH,
先看不使用适配策略的情况，在第2中，设置窗口分辨率为960*640：
接着，我们使用setDesignResolutionSize()函数来适配设计分辨率和屏幕分辨率：
glview-&setDesignResolutionSize(designResolutionSize.width, designResolutionSize.height, ResolutionPolicy::EXACT_FIT);
这时候就是我们想要的效果了。
上面说到共有五种分辨率适配的策略，其实就是从设计分辨率适配到屏幕分辨率时，图片拉伸的策略：
1、 ResolutionPolicy::SHOW_ALL
屏幕宽、高分别和设计分辨率宽、高计算缩放因子，取较(小)者作为宽、高的缩放因子。保证了设计区域全部显示到屏幕上，但可能会有黑边。
2、 ResolutionPolicy::EXACT_FIT
屏幕宽 与 设计宽比 作为X方向的缩放因子，屏幕高 与 设计高比 作为Y方向的缩放因子。保证了设计区域完全铺满屏幕，但是可能会出现图像拉伸。
3、 ResolutionPolicy::NO_BORDER
屏幕宽、高分别和设计分辨率宽、高计算缩放因子，取较(大)者作为宽、高的缩放因子。保证了设计区域总能一个方向上铺满屏幕，而另一个方向一般会超出屏幕区域。
ResolutionPolicy::NO_BORDER是之前官方推荐使用的方案，他没有拉伸图像，同时在一个方向上撑满了屏幕，但是新加入的两种策略将撼动ResolutionPolicy::NO_BORDER的地位。
ResolutionPolicy::FIXED_HEIGHT和ResolutionPolicy::FIXED_WIDTH都是会在内部修正传入设计分辨率，以保证屏幕分辨率到设计分辨率无拉伸铺满屏幕。
4、 ResolutionPolicy::FIXED_HEIGHT
保持传入的设计分辨率高度不变，根据屏幕分辨率修正设计分辨率的宽度。
适合高方向需要撑满，宽方向可裁减的游戏，结合setContentScaleFactor(RH/DH)使用。
5、 ResolutionPolicy::FIXED_WIDTH
保持传入的设计分辨率宽度不变，根据屏幕分辨率修正设计分辨率的高度。
适合宽方向需要撑满，高方向可裁减的游戏，结合setContentScaleFactor(RW/DW)使用。
屏幕适配的就讲到这里了，由于本人口才不好，所以有些地方可能表达不够清晰，请见谅。
网上讲屏幕适配这方面的文章一搜一大把，但都是理论知识，个人觉得最好的学习方法就是去做个demo，一步步做，看看效果如何，这样才能掌握。
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见cocos2d-x三国策略战争游戏源码
dotawar-master
SceneSetting.cpp
AppController.mm
RootViewController.mm
constraints
constraints
CMakeLists.txt
chipmunk-docs.html
LICENSE.txt
README.txt
base_nodes
draw_nodes
CMakeLists.txt
keypad_dispatcher
label_nodes
layers_scenes_transitions_nodes
menu_nodes
misc_nodes
particle_nodes
Simulation
AccelerometerDelegateWrapper.mm
CCAccelerometer.mm
CCApplication.mm
CCCommon.mm
CCDevice.mm
CCDirectorCaller.mm
CCEGLView.mm
CCFileUtilsIOS.mm
CCImage.mm
CCThread.mm
EAGLView.mm
third_party
script_support
sprite_nodes
data_support
image_support
user_default
CCUserDefault.mm
zip_support
text_input_node
tilemap_parallax_nodes
touch_dispatcher
CocosDenshion
SimpleAudioEngine.mm
CocosDenshion.xcodeproj
project.pbxproj
extensions
AssetsManager
Components
CCControlExtension
CCEditBoxImplIOS.mm
CCEditBoxImplMac.mm
CCScrollView
LocalStorage
physics_nodes
libwebsockets
cocos2dx_support
CCLuaObjcBridge.mm
AudioEngine.lua
CCBReaderLoad.lua
ActorsPack1.plist
ActorsPack1.png
CloseNormal.png
CloseSelected.png
Default.png
fps_images-hd.png
fps_images-ipadhd.png
fps_images.png
GameDate.plist
GameUI01.plist
GameUI01.png
GameUI02.plist
GameUI02.png
grass_ground.png
health_bar_green.png
health_bar_red.png
HelloWorld.png
Icon-72.png
Icon-Small-50.png
Icon-Small.png
Icon-Small@2x.png
Icon@2x.png
Info.plist
iTunesArtwork
Level0.tmx
actorData.lua
Prefix.pch
涓夊浗war.xcodeproj
project.xcworkspace
xcshareddata
涓夊浗war.xccheckout
xcuserdata
ericwang.xcuserdatad
UserInterfaceState.xcuserstate
sev.xcuserdatad
UserInterfaceState.xcuserstate
contents.xcworkspacedata
xcuserdata
ericwang.xcuserdatad
xcschememanagement.plist
涓夊浗war.xcscheme
sev.xcuserdatad
xcdebugger
Breakpoints_v2.xcbkptlist
xcschememanagement.plist
涓夊浗war.xcscheme
project.pbxproj
Level0.tmx
dotawar-master
._AppController.mm
._RootViewController.mm
constraints
._constraints
._chipmunk
constraints
._CMakeLists.txt
._constraints
._chipmunk-docs.html
._LICENSE.txt
._README.txt
base_nodes
draw_nodes
._ChangeLog
._CMakeLists.txt
keypad_dispatcher
label_nodes
layers_scenes_transitions_nodes
menu_nodes
misc_nodes
particle_nodes
Simulation
._AccelerometerDelegateWrapper.mm
._CCAccelerometer.mm
._CCApplication.mm
._CCCommon.mm
._CCDevice.mm
._CCDirectorCaller.mm
._CCEGLView.mm
._CCFileUtilsIOS.mm
._CCImage.mm
._CCThread.mm
._EAGLView.mm
._Simulation
third_party
._libraries
._third_party
script_support
sprite_nodes
data_support
image_support
user_default
._CCUserDefault.mm
zip_support
._component
._data_support
._image_support
._tinyxml2
._user_default
._zip_support
text_input_node
tilemap_parallax_nodes
touch_dispatcher
._base_nodes
._draw_nodes
._keypad_dispatcher
._label_nodes
._layers_scenes_transitions_nodes
._menu_nodes
._misc_nodes
._particle_nodes
._platform
._script_support
._sprite_nodes
._textures
._text_input_node
._tilemap_parallax_nodes
._touch_dispatcher
CocosDenshion
._SimpleAudioEngine.mm
CocosDenshion.xcodeproj
._project.pbxproj
._CocosDenshion.xcodeproj
._proj.ios
extensions
AssetsManager
Components
CCControlExtension
._CCEditBoxImplIOS.mm
._CCEditBoxImplMac.mm
CCScrollView
._CCControlExtension
._CCEditBox
._CCScrollView
LocalStorage
physics_nodes
._AssetsManager
._CCBReader
._Components
._LocalStorage
._physics_nodes
libwebsockets
cocos2dx_support
._CCLuaObjcBridge.mm
._platform
._AudioEngine.lua
._CCBReaderLoad.lua
._cocos2dx_support
._chipmunk
._cocos2dx
._CocosDenshion
._extensions
._libwebsockets
._ActorsPack1.plist
._ActorsPack1.png
._CloseNormal.png
._CloseSelected.png
._Default.png
._fps_images-hd.png
._fps_images-ipadhd.png
._fps_images.png
._GameDate.plist
._GameUI01.plist
._GameUI01.png
._GameUI02.plist
._GameUI02.png
._grass_ground.png
._health_bar_green.png
._health_bar_red.png
._HelloWorld.png
._Icon-72.png
._Icon-Small-50.png
._Icon-Small.png
._Icon-Small@2x.png
._Icon.png
._Icon@2x.png
._Info.plist
._iTunesArtwork
._Level0.tmx
._actor.lua
._actorData.lua
._Prefix.pch
._Resources
涓夊浗war.xcodeproj
project.xcworkspace
xcshareddata
._涓夊浗war.xccheckout
xcuserdata
sev.xcuserdatad
._UserInterfaceState.xcuserstate
._sev.xcuserdatad
._contents.xcworkspacedata
._xcshareddata
._xcuserdata
xcuserdata
sev.xcuserdatad
xcdebugger
._Breakpoints_v2.xcbkptlist
._xcschememanagement.plist
._涓夊浗war.xcscheme
._xcdebugger
._xcschemes
._sev.xcuserdatad
._project.xcworkspace
._xcuserdata
._.DS_Store
._Level0.tmx
._README.md
._涓夊浗war
._涓夊浗war.xcodeproj
._dotawar-master
源代码说明.txt
Mac OS X
 2??ATTR??&
?&com.apple.quarantineq/S03D702D7-A13B-49EB-B8CF-284A3FC40A66
Copyright(C)
OKBASE.NET All Rights Reserved 好库网 版权所有