cocos creator 小游戏源码_cocos creator 小游戏源码「建议收藏」

本文乃Siliphen原创，转载请注明出处：Cocos2d-x 类COC手游与RTS（即时战略）游戏的编程实践总结

概述

先来看一段视频。这个视频很短。4分钟。是我的一个技术demo演示视频。

http://www.tudou.com/programs/view/HL-ZWZkUw9k/?lvt=97&resourceId=0_07_10_28

这个技术演示demo可以在这里下载到安卓平台的APK包：

http://download.csdn.net/detail/stevenkylelee/7929017

2014.08.13-2014.09.15 这一个月左右的时间里，

我独自一人在家做了上面视频中技术演示的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开发商Supercell：3年从0到30亿美元》，《SC官方2013年COC营收9亿美元！利润4.64亿美元！》

大家感兴趣的话，也可以网上自己搜搜关于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种基本操作。

1.单个手指滑动代表拖曳游戏场景。

2.两个手指代表缩放游戏场景。

3.点击屏幕同时也代表选中一个单位。

腾讯的《城堡争霸》的2个手指的捏合缩放是和COC不同的。

《城堡争霸》的实现算是“中心缩放”，不能同时移动游戏场景。

我的实现是仿COC，看视频就知道了，缩放场景的同时还能控制场景移动。

拖动与缩放还需要有限制：不能移动到游戏世界区域之外，看到游戏世界外面的黑块。不能无限放大和缩小。

我目前只做了缩放的限制，还没做移动的限制。移动限制的话，有点麻烦，和缩放是有关系的。

观察COC就会发现，如果在一个建筑上面按下手指，如果没有拖动的话，就是选择这个建筑。

如果拖动了，就不会选择这个建筑，而只是拖动游戏场景。

所以，程序中要做一些判断和记录：是否有拖动等。

像我这种，还加入了RTS控制元素，

可以选择行动体单位并且控制它进行移动和攻击，

这会让操作控制代码变得更复杂。

对于这种复杂的操作，我是用状态机来解决。

在onTouchesBegan，onTouchesMoved，onTouchesEnded 3个触摸函数中都弄了状态机。

触摸函数肯定用的是多点触摸，否者没法搞双手指捏合缩放。

我新建一个触摸层来专门处理触摸，因为操作的控制本身就很复杂，这样做可以分割复杂度。

我的onTouchesMoved的代码截图：

外层代码，先判断是一个点触摸了，还是2个点同时触摸。

然后在2个判断分支中都做switch-case的状态机处理。

有看过设计模式的同学可能会知道，用switch-case写状态机代码是“幼稚的”

我觉得，如果在尝试阶段，还没想清楚的时候，用switch-case也无妨。

等我想清楚的时候，我可能会改成状态模式的实现。

3.角色的AI

COC中有一些“行动自治体”，

比如，有一些角色，会到处走动，一下子摸摸树一下子摸摸石头。空降兵到敌人领地时会进行自动攻击等。

这是一些什么三消，跑酷类游戏都没有的。

编写这些AI，让玩家有一种在“世界”中的感觉，是相对于其他类型的手游额外多出来的部分。

基本上用状态机建模，都可以搞定这些AI。

但目前我的实现程度，还没有做“行动自治体”。

寻路也属于AI部分，求最短路径的A*算法就是人工智能领域中的算法。

其实COC中的寻路是比较简单的，相比红警，帝国，魔兽等这种真正的RTS游戏来说。

我的游戏中用的寻路也是A*，关于A*算法，可以参考下我写的这篇文章：

《Cocos2d-x 地图行走的实现3：A*算法》

Cocos2d-x 类COC手游与RTS（即时战略）游戏的编程实践总结

之前我有尝试，把寻路算法改成开一个线程来计算，这样的话，就可以不卡住界面。

传统软件的编写经常这样用。

但后来再改的过程中遇到不少麻烦和问题，遂暂时搁浅之。

编写真正的RTS游戏的技术点

1.不允许行动体互相穿越的限制

不允许穿越会涉及更多的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数据的解析，我写过一个比较完善的类，

有兴趣的话，看看我的这篇博客：《CSV文件格式解析器的实现：从字符串Split到FSM》：

Cocos2d-x 类COC手游与RTS（即时战略）游戏的编程实践总结

目前，我的这个demo也只用了CSV类型的数据做配置，

并且也是我用之前博客中写的那个CSV类去做解析。

思考的过程

这里也和大家分享下，我思考的过程。

《暗时间》这本书中讲过，思考是要借助笔和纸的。记录下当前自己探索到的、思考到的步骤和环境。

以便于回溯思维的时候，防止忘记自己推理到哪一步了。

一个人独立开发，很多时候是自己和自己对话。自己提出设想，自己论证。

这种情况就更加需要笔和纸。

下面是我的一些草稿纸截图。

最后

目前我没发现市面上有任何一本书去教如何写RTS游戏。

一个月的尝试，还是有价值的。

仅仅是做类COC的话，感觉并不很复杂。

而一旦加入真正的RTS元素，就知道红警、帝国、魔兽的技术含量有多高了。

腾讯等公司可以模仿出COC，什么城堡争霸，陌陌争霸 等。

但他们目前做不了“类魔兽3”，“类星际2”，

魔兽争霸3 不仅是一个真正的现代RTS，还是3D的。

我估计，不是他们不想，而是“类魔兽3”这个玩意“确实有点难度”。

目前本人入游戏领域不久，菜鸟一枚，

欢迎游戏同行与我交流讨论。

今天的文章cocos creator 小游戏源码_cocos creator 小游戏源码「建议收藏」分享到此就结束了，感谢您的阅读。