本文乃Siliphen原创，转载请注明出处：http://blog.csdn.net/stevenkylelee

概述

先来看一段视频。这个视频很短。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.操作的策划。@H_922_301@

是先定义好操作规则然后实现，还是一面做一面想一面改？

我觉得可能是后者，除非一点都不创新，想原封不动地照搬“被抄袭的产品”。

一开始谁都不太可能把整个系统，整个规则都想清楚，都定义下来。

因为我是一个人，所以，我是一面做一面想一面改。

我一开始不可能把各种细节都想清楚，所以是先做着看看。

腾讯的《城堡争霸》是一款仿COC的产品，操作上和COC有一些不同。

比如：移动建筑，手指放开的时候，就直接摆下建筑了。而COC还要再点击一下确定摆下建筑。

在操作上，COC多了一个再次点击。

2.操作代码的编写@H_922_301@

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@H_922_301@

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

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

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

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

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

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

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

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

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

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

http://www.jb51.cc/article/p-gxfligaz-qy.html

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

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

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

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

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

COC的人物是允许互相穿越的，就是2个行动单位可以互相重叠在一起。

魔兽3的行动单位则不允许。不允许互相穿越是基于现实的模拟。

正是因为不允许穿越，魔兽3才有了“卡位”，”M围杀“等各种操作技巧。

我在实践的过程中发现，魔兽的限制穿越的编写处理是比较麻烦的。

我个人猜测可能Supercell感觉这个问题实在是有点费神，所以就允许穿越了，不做那么真实的模拟。

允许穿越，实际上会极大降低程序的编写复杂度，为什么这样说呢？听我娓娓道来。

不允许穿越通常是用碰撞检测的方法来做，

如果游戏场景很大的话，为了降低碰撞检测的时间复杂度， 需要做空间分割处理。

不允许穿越会涉及更多的AI问题。比如：”移动碰头死锁“。

呵呵，”移动碰头死锁“是我自己发明的名词，用来描述这样一种场景：

在一个狭小且长的通路中，比如一座桥、一个巷子里面、树林的间隙中，或者甚至是空地，

有2个单位，A从左向右行走，B从右向左行走，这2个单位都在同一个水平线上，

那么就有一个”你不让我，我不让你“的问题。

用我的游戏截图，如下图：

上图，A和B都往对方的方向走去，在某个时间上，他们会”碰头“，如下图：

如果没有AI控制的话，就会出现互不相让的”死锁“，双方都在不断往对方的方向”推“

这种情况，我们需要编写AI去决定A和B如何谦让，然后，再行动到各自的目的地。

目前我的做法比较简单，有一个行动体可能会停下来，然后另一个行动体绕过他。

或者是2个行动体都停下来。玩家需要重新控制行动。

这种做法会让玩家觉得游戏中的人物很”蠢“且自己很麻烦，行动体不会聪明避让且需要自己重新控制行动。

还有就是”集体行动“时的控制。如下图：

控制了一帮人往一个地方走，他们之间是不允许互相重叠的。

在碰撞检测中，如果发生了碰撞，需要判断，是之前说的“碰头”还是“大家往同一个方向走”的情况。

如果是非碰头情况，我的做法是：等待前面的单位移动出空位之后，后面的单位才上前挪一点。

代码截图：

从上面代码可以看到，我仅仅是暂停了Node节点的移动Action。

如果检测发现没有碰撞了，就恢复执行之前的MoveTo动作。

目前我的实现还有缺陷，并不完善。

在某种情况下，集体行动，会出现“穿越”的问题，

但在大部分情况下是可以保持不越穿的。

实际上，防穿越还会涉及更多的细节问题，这里我就不一一列举了。

从上可以看到，如果加入了防穿越，会让程序复杂很多。

允许穿越的话，什么“碰头死锁”，“集体移动”等问题都没有了。

从复杂度、开发成本等各方面因素考虑，我想这是Supercell不做防穿越的原因。

2.行军算法、布阵算法@H_922_301@

在魔兽3中，控制部队达到某地，是有行动队形的。

目前我还没有仔细去考虑如何做，但这个在RTS游戏中是存在的。

另一个问题是关于布阵。仔细观察和研究魔兽3，

选中8个农民到某地，那8个农民到目的地后，有一个类似于矩形的阵型。

规则布阵这个问题，我也没仔细考虑。

但不可避免的是随机阵型总要考虑，就是说，如下这种情况：

选中了N个单位，然后指挥他们到某处。这N个单位因为受之前的仿穿越限制，

他们不能集中在一个点上。那么，如何确定各个单位的目的点？

我的做法是：在目的点，进行BFS（宽度优先搜索），寻找每个单位可以被容纳的位置，

为什么用BFS算法？因为BFS有圆形向外扩展的特性。

我的代码截图如下：

有一个细节是，如何保持原先的集体“布局”？

看下图：

A，B，C 对于整个选中的单位集合来说，有自己所处的位置。

移动这些单位到另一处，好的做法是，也同时保持他们原先在集体中的位置。

因为，这样做是对整体行军来说，总体移动成本最小。

总体移动成本就是说，对于集体中每个行动单位的行动耗时、路径长度等之和。

总体移动成本越小，给玩家的感觉就越和谐。

我在实践中，发现了这个问题，做了一些简单处理。

目前来说，效果并不怎么好。

3.A过去如何做@H_922_301@

玩魔兽的朋友都知道“A过去”的含义吧？

A过去就是“攻击过去”的意思，源于魔兽3的A键控制。

“过去攻击”包括2个分解步骤，1.先走过去，2.达到攻击范围后，开始攻击。

A过去有2个作用点：1.玩家A的是地板。2.玩家A的是一个游戏实体，某个敌军单位、建筑等。

玩家A的是地板的话，AI逻辑是：控制行动体走到A的目的点，

如果在行动的过程中有敌军进入了攻击范围，就攻击，歼灭了敌军，继续走到目的点。

玩家A的是某个游戏实体的话，AI逻辑是：记住被A的那个目标实体，追着他打，直到目标被歼灭。

红警的A，坦克会用炮弹攻击地面。

魔兽3的A，只有控制投石车才会攻击地面。

目前我还没实现A过去的逻辑。

4.单位大小通过限制@H_922_301@

魔兽3中的食尸鬼可以通过的地方，剑圣不一定能通过。

因为，食尸鬼、剑圣、尸魔 等 的体积不一样。

单纯的A*算法，只是能找到有联通的最短路径。

剑圣的寻路是怎样做的？

是不是要在A*算法作用的瓦片方格上，把剑圣不能通过的地方，给填充上，再执行A*呢？

这个问题我没想清楚。目前我的游戏也不处理这点。

综上浅谈的4点就可以看到像魔兽这样的RTS游戏编写的难度。

实际上编写一个真正的RTS还远不止这4点那么简单，想想战争迷雾、地形 等等。

肯定还有一些未知的技术难点，我还没意识到。

考虑用数据驱动的方式编写游戏

所谓的数据驱动，就是用一些配置来控制游戏的显示、行为等。

我的demo目前是用COC和其他游戏的素材来做的，

以后要改成 RPG，塔防什么的，肯定不能盗用别人的美术资源，是吧。

为了方便换皮。游戏实体的显示、动画的显示。我都用了配置来搞。如下图：

动画表：

精灵表

行动体的显示控制表

等等。有10个表了。

这些配置表，用Excel来做，然后另存为CSV。

程序去解析CSV文件数据。

关于CSV数据的解析，我写过一个比较完善的类，

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

http://www.jb51.cc/article/p-zrtwbgyl-qy.html

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

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

思考的过程

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

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

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

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

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

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

最后

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

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

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

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

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

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

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

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

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

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

转自：http://blog.csdn.net/stevenkylelee/article/details/39318543

原文链接：https://www.f2er.com/cocos2dx/346982.html