概述
先来看一段视频。这个视频很短。4分钟。是我的一个技术demo演示视频。
http://www.tudou.com/programs/vi ... sourceId=0_07_10_28
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种基本操作。
- 单个手指滑动代表拖曳游戏场景。
- 两个手指代表缩放游戏场景。
- 点击屏幕同时也代表选中一个单位。
腾讯的《城堡争霸》的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*算法》
之前我有尝试，把寻路算法改成开一个线程来计算，这样的话，就可以不卡住界面。传统软件的编写经常这样用。但后来再改的过程中遇到不少麻烦和问题，遂暂时搁浅之。
编写真正的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数据的解析，我写过一个比较完善的类，有兴趣的话，看看我的这篇博客：《CSV文件格式解析器的实现：从字符串Split到FSM》。目前，我的这个demo也只用了CSV类型的数据做配置，并且也是我用之前博客中写的那个CSV类去做解析。
思考的过程
这里也和大家分享下，我思考的过程。
《暗时间》这本书中讲过，思考是要借助笔和纸的。记录下当前自己探索到的、思考到的步骤和环境。以便于回溯思维的时候，防止忘记自己推理到哪一步了。
一个人独立开发，很多时候是自己和自己对话。自己提出设想，自己论证。这种情况就更加需要笔和纸。
下面是我的一些草稿纸截图。
最后
目前我没发现市面上有任何一本书去教如何写RTS游戏。一个月的尝试，还是有价值的。
仅仅是做类COC的话，感觉并不很复杂。而一旦加入真正的RTS元素，就知道红警、帝国、魔兽的技术含量有多高了。腾讯等公司可以模仿出COC，什么城堡争霸，陌陌争霸 等。但他们目前做不了“类魔兽3”，“类星际2”，魔兽争霸3 不仅是一个真正的现代RTS，还是3D的。我估计，不是他们不想，而是“类魔兽3”这个玩意“确实有点难度”。
目前本人入游戏领域不久，菜鸟一枚，欢迎游戏同行与我交流讨论。
