去年一月，我们的千年手游正式立项开工，到现在刚好一年。这一年经历许多，感悟良多，总结一下，与诸位分享。

这一年杂七杂八做了挺多事情的，值得说一说的倒没多少。

第一件值得分享的是，发现了一个arm mali texture compression tool(tct) mac版的bug，将一张png图片通过tct压缩成一张上半部分带rgb通道，下半部分带alpha通道的图片，压缩完成后，alpha值相对原始的alpha值，是偏小的。经过几番与arm开发的邮件沟通，发现是因为tct使用了较老版本的ImageMagick，手动替换最新版本，应该能够解决该问题。查看arm官网，这个问题应该依然没有修复，最新的tct版本还是能够重现bug的4.3。（注：tct 4.3 win版本并没有这个bug）

最近正在看《大教堂与集市》这本书，书中所提倡的集市模式令我深有感触。

集市模式的概念有很多方面，其中一点就是强调“齐心协力”，一般一个开源项目，就像一个自由市场，大家依靠兴趣集结在一起，这个时候“命令模式”是行不通的，系统中每个个体都追求自身效用的最大化，在其共生的过程中，能够自然建立一种具备自我纠错能力的秩序，这个所谓的“共识原则”达成的秩序往往比集中式规划都要精妙和高效。

在为项目搭建持续集成环境时，碰到了git记录乱码的问题。

方法一： 网上有个解决方案，是修改jenkins.xml文件，不过这个方法并没有解决git记录乱码的问题（方法如下）。 x:\Jenkins\jenkins.xml 新增蓝色粗体标记参数(-Dfile.encoding=utf-8)，然后重启Jenkins服务，完毕！

1

<arguments>-Xrs -Xmx256m -Dfile.encoding=utf-8 -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar “%BASE%\jenkins.war” –httpPort=8080</arguments>

方法二： 后来尝试修改本地git的设置，修改logOutputEncoding为gbk，顺利解决jenkins中git记录乱码的问题。

1

$git config --global i18n.logOutputEncoding gbk

最近尝试在项目中使用Jenkins，即持续集成。不过在Shell脚本中使用TexturePacker的打包命令时，却无法成功，不管是Mac还是Windows，都会出现同样的提示。

1

You must agree to the license agreement before using TexturePacker. Please run the graphical user interface and accept the license terms.

奇怪，明明这个agreement，之前在使用TexturePacker GUI时，都已经同意过了的嘛。倒腾了一段时间，才发现，无论是Windows，还是Mac，运行Jenkins的都不是当前的用户。Mac系统下，可以在/Users/Shared中找到一个名为Jenkins的文件夹，Jenkins运行是就用的是这个同名的用户。Windows系统下，可以在《服务》中找到名为Jenkins的服务，右键该服务，选择属性，选择登录这个标签，可以看到运行Jenkins服务的实际上是本地系统账户，而非当前帐号。正因为之前没有在实际运行Jenkins服务的账户下同意过TexturePacker的Agreement，才导致命令行命令无法执行。知道原因后，解决方案就相对简单啦。

Mac: 在terminal中依次使用如下两个命令后，就能看到license agreement弹出来，点击I agree即可。

1
2

1. sudo su jenkins
2. TexturePacker —gui

Windows:　如果之前有查看过Jenkins服务的属性，就会发现登录标签页中，不光可以用本地系统账户登录服务，也可以用自己的账户登录Jenkins服务。因此登录自己的账户，同意agreement，TexturePacker的命令行就能用啦。

这几天在公司做一个2D RPG游戏的demo，涉及到寻路的问题，于是自己写了A*寻路算法，分享一下。

地图初始化时，只需要告诉PathFind这个类地图的宽度跟高度，并且初始化障碍点即可。

1
2
3
4
5
6
7
8
9
10
11
12

PathFind::InitMap(_tileMap->getMapSize().width, _tileMap->getMapSize().height);

for (int i=0; i<_tileMap->getMapSize().width; ++i)
{
  for (int j=0; j<_tileMap->getMapSize().height; ++j)
  {
      if (!isWalkable(Vec2(i,j)))
      {
          PathFind::UpdateMapPoint(i, j, false);
      }
  }
}

使用时，只需要调用FindPath方法，设置能够行走的方向（八方向or四方向），是否无视边角。该方法返回寻路是否成功。如果成功，路径数据会被存入栈中m_pathList，调用NextPathPoint方法，即可获得下一个目标点。

1
2

m_pathFind.FindPath(start, end, m_directionMode==kDirectionMode8?true:false)
m_pathFind.NextPathPoint()

源码在最下面—–>>

参考文章：

1. 理解A*寻路算法具体过程 (http://www.cnblogs.com/technology/archive/2011/05/26/2058842.html)

2. A* Pathfinding for Beginners (http://www.policyalmanac.org/games/aStarTutorial.htm)

另外提一下，网上热传的一个45度ARPG demo <<热血沙城>>，我下载了它的Cocos2d-x2.2.5 C++修改版，虽然作者说该demo使用了A*寻路，但是实际运行起来，效率很低，一个稍微需要绕道的路径，电脑能够卡好几秒，且人物走的并不是最短路径，更像是广度优先搜索的结果。 (http://blog.csdn.net/zym_123456/article/details/42641591)

想看实现方式请直接跳到Part 2。

Part 1: 我上一个游戏项目使用的是Cocos2d-x 2.1.2，那时候CCLabelTTF还没有支持描边的API，后来的版本加上了enableStroke这个接口，可是实现起来的效果是内描边，内描边的效果并不是很理想，如果字体本身很细的话，内描边后，基本全是描边，没剩多少肉了。

当时搜寻网上，找到一个可行的外描边方案。这个方案是修改CCLabelTTF::updateTexture()这个方法，原理是将原来字体的纹理，往字的360度方向位移描边的宽度距离，然后绘制生成新的纹理，如果每40度绘制一次的话，360度就需要绘制9次，最后再将字体本身绘制一次，本来一个label 的drawcall消耗是1次，这种方案drawcall消耗就是10次。

这个方案能够勉强实现外描边的效果，在苹果设备上的效果还是可以的，但是一拿到android设备上检查，就会发现描边并不是连贯的，有点坑坑洼洼的感觉。更让人无法接受的是，该方案会导致label的draw call剧烈增加，一些label比较多的页面，如果都需要描边效果的话，会导致游戏每一帧的绘制时间变长，造成游戏明显的卡顿。这个问题在android的低端设备上尤其明显。于是项目后期，我们放弃了字体描边的效果。

下面为该方案的源码：

前一段时间买了这本代码大全2，厚厚一大本，最近每天基本都要加班，于是早上或者晚上抽空翻一翻。今天看到一段文字，无比认同，忍不住摘录下来分享。

摘录（协同构建有利于传授公司文化以及编程专业知识）：

复查是一个很重要的机制，它可以让程序员得到关于他们自己代码的反馈。
程序员除了需要得到他们是否很好地遵循了标志的反馈之外，还需要得到程序设计主观方面的反馈，例如格式、注释、变量名、局部变量和全局变量的使用、设计方法以及“我们这里采用的解决方法”等。刚出道的编程人员需要那些有更丰富知识的前辈给予指导，而资深程序员们往往太忙而没时间同他人分享他们的知识。复查为这两种人提供了一个技术交流的平台，所以，无论在未来还是现在，复查都是培养新人以提高代码质量的好机会。

在平时工作中，我们有时候会抱怨现在公司没有太多的技术氛围，其实在同一个项目组内，程序员与程序员之间还是存在很多沟通的盲区，往往每位程序员负责一个独立的模块，如果有空，相互之间分享各自模块的设计思路，互通有无，也是极好的。

通过写博客来记录自己的成长，出发。。