AOE机制的DSL及其实际运用

猴与花果山

　　AOE这个词的意思，我相信玩过WOW的人都不陌生，包括玩过LoL的也不会陌生，说穿了就是一个区域内发生效果(Area of effect)。这里我们要讨论的就是关于一个适合于几乎所有游戏的AOE机制，当然之所以能适合于所有游戏，因为它也只是一个机制，一个机制从策划语法来就是一种思路，而不是一套代码。

　　在这里我可能会用到一些类似DSL的东西，至于DSL是什么，别去百度，那里你得不到答案，这里有一个云风的帖你可以看一下，至于DSL的好坏，我觉得如果你的程序员有一定经验和水平，是不难看出的，怎么说呢，这就好比HTML和SQL的关系，SQL很好用，但是如何让一个HTML程序员用……传送门 http://blog.codingnow.com/2012/01/dev_note_8.html


1，AOE和AOEObj

　　首先要说清的是AOE和AOEObj的区别，这其实本质上是一个Struct和一个Instance的区别，AOE更多的是来自表项的数据，当然拜读了DSL概念之后，我觉得这个表项也可以写成DSL；而AOEObj则是工作的实体，有程序在运行过程中临时创建删除。


2，AOE通用表项

　　这里我用的DSL是一个混合了Pascal Lua和Haxe的写法。

1. Type AOE{
   
2.   id:Int=0; //id，不解释。
   
3.   area:Area; //之所以这里特别定义一个叫做Area的Struct，因为你在不同的项目中的区域概念会不同，简单举例，如果你是个LoL类型的游戏，他可能会需要扇形、圆形等等任何形状；而如果是一个战棋SLG，他可能只需要一个单元个坐标的数组Array<Point>就可以了。
   
4.   sightEffect:String=""; //在区域的中心播放的视觉特效，如果文件不存在则不需要播放。
   
5.   tick:Float; //多久发作一次效果，Float用于计算秒作为单位，而如果是一个回合制游戏，如我叫MT，完全可以用Int，因为它是回合作为单位，如果这个数字小于等于0，那么他将不会发作。
   
6.   onGuyEnter:*AOEObj->*Character->[Void]; //这里是一个函数(haxe)，用于在有角色进入AOE区域时候的回调，第一个参数是AOEObj指针（我定义*XXX代表XXX的指针），第二个参数是进入区域的角色指针，返回值（中括号内）为空。可以为空，空时不执行效果。
   
7.   onGuyLeave:*AOEObj->*Character->[Void]; //角色离开AOE区域的回调函数。
   
8.   onTick:*AOEObj->Array<*Character>->[Void]; //区域自身每一跳的回调，和上面两个函数一样可以是空的，如果为空不论tick写了多少都没意义，因为都不执行。
   
9. }

复制代码

我们可以看到，以上这个数据结构是任何类型游戏的AOE系统所必备的，可以说是基础的东西，当然这不代表AOE只能有这些信息，这还是根据游戏的具体需要进行具体的设计。


3，AOEObj及其工作原理

1. Type AOEObj{
   
2.   aoe:*AOE;  //这是来自于那个AOE模板的，为了范围，我们总得给于一个AOE模板，这里有一个争议就是是否需要通过继承手段来解决相近两个相似区域的问题，我认为这个区域应当是策划认真设计的，所以没有必要，当然另一方面来说，上面我们提到的Area这个东西，其实本质上并没有说明他不可以是通过一个函数return的，所以……
   
3.   caster:*Character; //制造这个AOE的负责人，这当然可以是空的，比如通过GM命令创建了一个AOE，或者某个地形机关创建的AOE，你并不在意他的负责人是谁。
   
4.   casterInfoRecord:ChaProperty;//注意者并不是一个指针，这是一个clone体，我们需要知道这个AOE的创造者再创造AOE时候的属性，即使没有创造者，我们也应该new一个假的数据出来。因为一些AOE的效果的确需要用到这类属性，比如说我们需要暴风雨魔法，对区域内的人每3秒造成一次相当于Magic属性30%的伤害。
   
5.   lastTime:Float; //剩余多少时间后自然消亡，当然用在回合制游戏可以理解为还有多少个回合后消失，看到这里如果你足够有灵性会想到，我们是否有些AOE要在消失的时候干些什么特别的，好主意！那就再Type AOE中加上onRemove之类的东西就好了，你的项目你做主。
   
6. }

复制代码

一个最最基础的AOEObj诞生了，在整个游戏中，我们需要在程序中加入一些时间点去调用AOE的回调函数，通常会有：

1）AOEObj产生时，调用AOEObj.aoe.onCreate(AOEObj)，如果策划有设计这个的话，其实我觉得大多时候是不需要的。
2）当角色进入AOE时，调用AOEObj.aoe.onGuyEnter(AOEObj, guy)，这里涉及到一个遍历，优化关键之一。
3）当角色离开AOE时，调用AOEObj.aoe.onGuyLeave(AOEObj, guy)，同上。
4）当aoe的tick>0同时onTick并不是空的时候，我们要定时触发onTick(AOEObj, guysInAOE)，当然这里有人提出了聪明的做法，就是角色进入AOE给他添加一个Buff，离开时移除这个Buff，这个可以视情况决定，诸如AOE的ontick是当偶数tick冒一下红色火焰，奇数tick冒一下绿色火焰的时候，这个想法根本行不通。而且是用自身的tick精确度会更高，比如一块地刺钉板，每5秒伸出地刺伤害区域内的人，这时候你用onTick的触发就会更精确的反应，而不会因为进入钉板区域的人进入时间不统一而产生麻烦。


4，策划对于这个机制的运用

　　看到这里，有人会觉得这么设计AOE既浪费又不好理解，这是当然，我还是那句话——当你用战斗机只是杀1、2人的时候，他是不如砍刀实惠的，如果你的策划心中的AOE只有那些战斗效果，什么暴风雨魔法，剑刃风暴，那这简直就是浪费这套机制——“剑本凡铁，因执拿而通灵”，这关键还是看策划有没有灵性。

　　最简单的例子，我们在游戏中有个buff叫冒火，每3秒对角色造成一次火焰伤害，可以堆叠20层，默认上10层，这时候我们地图上有2块区域，一个油坑和一片河流，其实我们地图上有3个AOE区域：

1）油坑：玩家进入后，如果身上有冒火，则会每秒中叠加1层冒火。
2）浅水区：如果玩家进入后身上有冒火和翻滚2个buff，那么就删除所有冒火的debuff。
3）深水区：玩家进入后直接消除身上所有的冒火debuff。

　　以上是这3个区域的逻辑效果，但事实上你还需要利用好buff机制和AOE机制，去把细节做到位，比如冒火的buff在buffOccur时判断层数，不同的层数会导致视觉特效不同，或会随层数增加越来越旺；而水的AOE在消除火时会根据冒火的层数来播放不同程度的烟。

　　有人又要说了“啊呀，谁在乎这些细节啊，我把项目做出来就好了就能赚钱了”，我想起一个故事——落潮的时候，沙滩上都是鱼，一个孩子一条一条地捡起沙滩上的濒死小鱼，把它们重新放进大海。有人对孩子说：“沙滩上那么多的小鱼，你捡得过来吗？一条小鱼而已，有谁会在乎呢？”孩子一边不停地往海里扔鱼，一边说：“你看，这一条在乎，这一条也在乎。”，谁在乎呢？其实每一条鱼都在乎，只是他们没有能力自己回到水里罢了。

sea_bug

真不知道该分到策划还是程序~~

terrybiff

宁愿用区域脚本做

firstfish

猴子的文章我都喜欢看，有干货。而且对我这个程序员的胃口。

luyushun

这不属于策划的范畴

它属于游戏引擎技术类，换句话说：它们为一个更加逼真的虚拟世界而服务

独孤逍遥

有干货的文章不多，支持一个。

iamtaro

现在都是理工类的策划居多，直接写lua逻辑几乎没难度，我是认为“DSL”多余。

Yuki001

这个文对程序来说，稍微基础了点，就是个区域触发器的写法。对策划来说又看不懂你的DSL，DSL的本意是让领域专家更方便理解和创造实际的逻辑。这种数据结构的表达，对策划来说还是excel表项再加个图好理解点。

猴与花果山

Yuki001 发表于 2013-10-12 13:37
这个文对程序来说，稍微基础了点，就是个区域触发器的写法。对策划来说又看不懂你的DSL，DSL的本意是让领域 ...

其实DSL的本意是让策划通过一种自己顺手的自定义语法来表现逻辑，它的优势在于当多平台移植的时候，只需要做语法解析起就好

ayasong

说不定以后会懂！