第六章 进阶知识
经过前边几章的讲解和演练，相信各位已经对自定义技能有了初步的了解了，同时也能做出一些简单的自定义技能来了。但是，这些对于一个想在自定义技能，尤其是T技能上有进一步发展的人来说，还是远远不够的。下边我们就一起来聊聊进阶知识。
首先说一下编程习惯，也许有人会说这都是细枝末节的问题，但是如果不注意，恐怕很难跻身高手行列。
一.变量类型和变量命名
WE中用到了很多类型的变量，当然有许多变量类型本质上是一样的，但是既然触发器里它们看起来不一样，那么我们就要尽量在命名上把他们区分开。按照大部分编程语言的惯例，使用3个字母的英文缩写来做变量名前缀，以便区分。另外该变量代表什么，就用拼音或者英文来命名它，而不要胡乱打几个字母。比如，布尔型的通用前缀为bln，假如有一个布尔型变量用于纪录单位是否存活就可以这样命名：blnCunhuo或者blnLive；又如一个纪录英雄的单位类型变量可以命名为 untYingxiong或者untHero等等。这样做是为了方便日后自己修订地图，也方便别人看懂自己的代码。如果命名没有规则，很可能时间长了自己都不知道该变量代表什么了。
下边是变量类型的中英文对照和建议前缀表，当然某些变量还没有约定俗成的所写前缀，是我根据英文音节自编的，如果你有更合理的缩写方法，请指出来。
英文名称 | 中文名称 | 建议前缀 |
boolean | 布尔型(用于真/假判断) | bln |
destructable | 可破坏物 | des |
dialog | 对话框 | dlg |
button | 按钮 | btn |
texttag | 漂浮文字 | txg |
integer | 整数 | int |
item | 物品 | itm |
leaderboard | 排行榜 | lbd |
player | 玩家 | ply |
force | 玩家组 | frc |
location | 位置(点) | loc |
real | 实数 | rel |
rect | 地区 | rec |
effect | 特效 | eff |
string | 字符串 | str |
terraindeformation | 地形 | tfm |
timer | 计时器 | tmr |
timerdialog | 计时器窗口 | tdg |
unit | 单位 | unt |
group | 单位组 | grp |
playerscore | 玩家积分 | psc |
二.触发器的整合
有不少人在刚接触WE的时候基本去注意触发器的整合，想到几个动作，就去新建一个触发器。甚至光初始化就有好几个，为阅读增加难度不用说，还因为执行顺序不可预料而增加了出现BUG的机会，想去修正有很难找出毛病所在。为了让自己的触发器变的有条理，就需要把多个触发整合到一个上边，这样做还有一个好处就是，可能有几个不同作用的触发器组他们有一个或几个触发器事件相同，那么使用条件判断依次去执行各动作，不但条理清楚，而且为维护提供了方便。当然，如果触发器本身条件判断过于复杂，那么还是让他们分着吧，弄到一起反到容易出错误。
通常我们要遵循以下原则，除非特殊需要，否则事件相同的触发器尽量整合到一个触发器中，通常不在条件中写东西（除非所有触发有共同的条件），然后再动作里使用if-then语句来做分支。比如，每张地图只做一个地图初始化的触发器；可能有多个自定义技能需要用到
单位发动技能效果这个事件，那么就用这个事件做一个触发器，条件留空，在动作里写：
如果使用的技能是aa，那么
....
否则
如果使用的技能是bb，那么
....
否则
....
把后边的小分块依次写进前边的分块里（前边的否则套嵌后边的分块），根据条件判断，选择执行其中某一个分块，结构简单明了。
可能有多个自定义技能需要用到循环逝去时间这个事件，那么动作可以这样写：
如果符合条件aa，那么
......
否则
......
如果符合条件bb，那么
......
否则
......
并列写很多小分块（前边的否则不套嵌后边的分块），根绝条件一次执行一个或者多个分块。
当然有时做多个触发是不可避免的，尤其是循环逝去时间这类事件，因为可能要顺序执行多个小分块，那么就不允许前边的分块使用等待时间、跳过剩余动作这样的语句，遇到必须要写的，就要另立触发了。
三.尽量排除内存泄漏
什么是内存泄漏呢？简单来说，我们在WE中要用到很多数据，这些数据有时候不用变量纪录，或者使用变量纪录了没有清除，那么这些数据就可能堆积在内存中，内存中的有效空间越来越少，游戏就越来越卡，甚至跳出来。对于单个技能的示例来说，内存泄漏显的微不足道。但是我们做技能最终目的还是应用的成图中，大量技能反复使用，内存泄露就成了大问题，所以应当养成排漏的习惯。
要想知道怎么排漏，就先明白那些数据需要清理。一般来说，基本的数据类型不用特别清理，包括数值，字符串，布尔型。除非使用字符串数组记录了多的变态的字符，否则它占的体积是很小的，没必要设置为空串，另两个则体积固定。而必须清理的变量类型主要有下边这几个：
1.点 点这个东西真是让人又爱又恨，写技能几乎离不开它，可是造成内存泄漏的罪魁祸首也非他莫属。我们还看教程最开始做的群体风暴之锤：
来看红框里的句子，每使用一次群体风暴之锤，他就创建了两个点-技能目标的位置，我们没有处理它，那么就导致内存泄漏了。怎么办？使用变量记录这个位置，用完之后清除它。
这样，我们就解决这个点的问题了。
2.单位组 单位组是内存第二杀手，我们再看上边绿色框框里的语句，它定义了一个单位组，但是没有清除它。我们可以在使用完后使用这个语句清除它：
3.单位 几乎所有入了门的人都知道，创建辅助单位要加上上边黑框框里的那句话，就是变成定时的单位，单位死亡以后，过一段时间就自动被清除了，但是对于英雄，死亡后会被保留，我们必须使用 删除单位 这个语句来删除。
4.特效 包括闪电特效和特殊效果，创建了就需要用变量来记录，用过之后要删除，需要说明的是，删除特效与删除单位不同，是会播放死亡动画的。
好了，我们来为这个群体风暴之锤做一个排漏吧：
群体风暴之锤.w3x (19.02 KB)
上边简单介绍了一下内存泄漏的排除方法，当然这只是最重要，也是最常见的部分。实际上使用触发器在很多时候是不可能实现完美排漏的，我们所做的，只是尽最大的努力少遗留一些问题。在后边我们还会继续通过实例来顺便练习排漏，这里就不多做介绍了。现在留给大家一个问题，前边那个模拟星际蜘蛛地刺基本没有做排漏工作，那么就尝试一下刚刚介绍的方法吧。
我们都知道，自定义技能除了实际效果要新颖、没有严重BUG之外，最重要的就是特效要漂亮了。当然，这里所说的漂亮不仅限于华丽，还包括素雅，灵动，简约等等。实际上，在成图中，太华丽的技能反而不多，因为在照顾视觉感
受的同时，更应该考虑到运行速度、触发器冲突等问题。
在前边已经提到过，特效可以用原模型的固有效果，也可以使用多个模型一点、线、面的方式拼凑出新效果。使用原模型的固有效果创造优秀的特效需要很扎实的基本功，多看，多学，多做，尽可多能的掌握原有的模型，包括直接使用时的效果，经过缩小、放大、旋转之后的效果，静止时是什么样子，缓慢移动是什么样子，快速移动又是什么样子。没有长期的浸淫是很难做到这一点的。
使用多个模型拼凑特效，相比较而言需要基本功少一点，但是需要一定的数学和编程基础，总的来将也不简单。在这一章了我们简单介绍一下使用固有模型效果的基本方法，着重讲解一下拼凑特效。
[
本帖最后由 yxxiaobin 于 2008-10-31 12:50 编辑 ]
