（正经。我在收集坛子众高手意见）。邀请TV3D二位版主

PassByYou

文章名：深入分析角色系统。望反馈批注。

处于写作时间浪费，以及阅读浪费，本文采用撰写较短小。

一，定义角色系统
在角色系统中，末端是角色动画系统，最前端则是角色的机能系统，角色的物品关系系统，角色系统的躯干部分则是数模系统。

划分原理：划分角色系统的末尾，前端，躯干时，是按照一贯的循序渐进开发原则来的。开发步骤是由末尾到躯干再到前端。因为图形引擎作为游戏引擎的基础层，而角色动画归属于图形范畴，所以角色系统在末端是角色的动画系统。然后在技能，物品系统中，几乎99%的数字操作都是基于数模系统来工作。所以角色的数模系统是作为躯干，提供给前端以基础去工作。

用形象方式来纵观整体，从角色系统的末端，再到最前端的机能，物品。相当易理解。

下面来分别阐述双极中的各个模块的工作原理。

一，角色动画系统
角色动画系统最简单的做法是使用数据驱动。数据驱动在概念上是这样的，角色进攻时，空闲时摇头晃脑，等等，这些动画使用一系列预先定义好的数据，然后在播放时通过程序对数据的处理，最后便形成了多种不同的动画效果。这就是数据驱动。

角色动画系统第二种做法是使用脚本驱动。脚本驱动在概念上是，脚本本身具有播放动画的功能，然后脚本以流程方式来运行，将各种不同的动画全部子程序化。最后组合在一起时，通过不同的脚本子程序的工作，最后产生出角色的各种不同的动画效果。

两种方式的优略比较：使用数据驱动的动画系统，因为配置和驱动的简单，在一些大型的多角色游戏中比较常见，比如即时战略，比如ARPG。使用数据驱动做出的角色系统统一性是非常好的。而使用脚本驱动的动画系统，因为配置和驱动比较专业，这种是非标准的专业，所以在统一性上并不如数据驱动。但是因为脚本驱动特定的纯程序的工作方式，这使得脚本驱动的角色系统在灵活性上很见长，比如角色可以脑袋飞起来在天上转360度，然后再掉落在角色身上，比如角色可以根据环境的条件，而产生特定的动作。

简单来总结：使用数据驱动，统一性较好，配置方便。使用脚本驱动，灵活性较好，改动困难。

实际中：在实际中，往往是脚本和数据并行来驱动。纯粹的数据驱动只为特定的游戏而存在，这是因为系统需求以及开发者的缘故。比如星际，魔兽，周到的系统分析，然后配上稳定的驱动程序，使得数据式角色驱动变得非常具有统一性，改动非常方便，但是这些角色，却不常出现在别的游戏中，这便是纯粹的数据驱动最大的弊病。脚本和数据并行的开发，开发脚本和数据并行驱动，是因为脚本的灵活性虽高，但大量配置，非常麻烦，而结合数据，就刚好解决配置和驱动复杂的问题。并行驱动，可以在游戏中，使用多种游戏角色动画的资源，比如曾经的游戏A是数据驱动，现在是游戏B是并行驱动，在游戏B中，可以游戏A的所有角色动画资源。在实际工作中采用并行驱动，并不是为了功能的强大，而是因为系统的兼容性以及衍生性可以大大提高。

角色数模的开发以及工作原理：
这么说吧，在角色数模的开发中，OO思路总是占主导位置。当角色的数字被对象化时，这个对象是不断在调用外面的VN触发器。

举个例子，在力量数模中。母值是20，而力量的当前值是40。那是因为外面的VN触发器被一些什么装备，技能做过一个触发器接口，当取得当前值时，接口被触发，然后按数模的母值+当前值规则去改变，最后得到最终结果40。

而数模部分的开发，在实时ARPG的准框架中如上所述。而在走OO实现的道路时，角色数模是关系状态数模，比如力量对生命的影响，生命对健康的影响，等等。关系状态都是以数模的VN触发器，以及数模工作规则在开发。这虽然有一定复杂性，但是思路上的清晰，可以大大降低关系数模部分的繁琐度。在OO中，数模分了很多很多对象，少的数十，多点上百，数千。当你看见上百条关系数模的框架时，不要嫌头大，太正常了。

角色物品，技能部分的开发以及工作原理：
消耗物品，像药水，使用以后影响数模。怎样使用，逻辑流程，包括空间流程，我在之前撰写过相关文档。而技能部分同样也是有前文档在介绍原理。
查找：深入分析物品系统，深入分析规则引擎

实际中：在实际制作中，物品和机能会大大依赖数模。几乎所有的关键数据都会来自数模。而数模对游戏影响是直接的，数模是通过VN触发器在影响游戏。

角色系统的开发时体系：
我考虑过使用配置文本来实现数模，还有机能，物品。但是配置的概念太高层了，比如使用关系数模，配置文本就不太好用了，在关系数模中少一个都不行。

最影响扩展和修改的地方：
角色使用分布式结构，可以随意拔插逻辑模块。
如：角色创建时，除了载入角色动画部分。其余地方全是VN触发器。
Void 角色创建（）
{
触发器1：（数模的创建）
触发器2：（技能的安排）
触发器3：（物品的处理）
触发器123随意拔插，整体性较强。比如新建一个数模模块时，直接注册一个触发器即可生效。
}

Over

我没有什么目的。我比较喜欢讨论。比较自主。在我眼里这肯定没什么问题。但是你们做过系统设计的，你们的意见不一样。

麻烦写一个批注，实在很懒，写两个字：可行。

批注写法：
提出疑问，或则表示一下想法，感觉有什么地方不妥，可以大大的发表一下意见。乐意展开话题来讨论。

没做过的我不会跟你讨论。浪费时间。

游戏之家站长

注：###### 后面为我写的内容，是根据我的以往的应用和时间来分析主题。

第一部分:

一，定义角色系统
在角色系统中，末端是角色动画系统，最前端则是角色的机能系统，角色的物品关系系统，角色系统的躯干部分则是数模系统。

划分原理：划分角色系统的末尾，前端，躯干时，是按照一贯的循序渐进开发原则来的。开发步骤是由末尾到躯干再到前端。因为图形引擎作为游戏引擎的基础层，而角色动画归属于图形范畴，所以角色系统在末端是角色的动画系统。然后在技能，物品系统中，几乎99%的数字操作都是基于数模系统来工作。所以角色的数模系统是作为躯干，提供给前端以基础去工作。

用形象方式来纵观整体，从角色系统的末端，再到最前端的机能，物品。相当易理解。

下面来分别阐述双极中的各个模块的工作原理。

一，角色动画系统
角色动画系统最简单的做法是使用数据驱动。数据驱动在概念上是这样的，角色进攻时，空闲时摇头晃脑，等等，这些动画使用一系列预先定义好的数据，然后在播放时通过程序对数据的处理，最后便形成了多种不同的动画效果。这就是数据驱动。
######（这个讲的是3D骨骼动画模型所具备的功能，模型文件是单个，但是他包含了很多角色的动作）
VB6 + TV3D的实例：
npc.Load "MODEL\name.mdl"                      '角色的模型
Pos.X = 100: Pos.Z = 100                       '角色行列坐标
npc.SetRotation 0, 90, 0                       '角色角度
Pos.Y = Land.GetHeight(Pos.X, Pos.Z)           '判断高低地形
npc.SetPosition BarneyPos.X, Pos.Y, Pos.Z      '角色摄像机上的坐标
npc.SetScale 1, 1, 1                           '角色尺寸
npc.SetAnimationID 1                           '角色动画编号
npc.PlayAnimation 30                           '角色动画速度
npc.SetMaterial 1                              '顶点光源

---------------------------------------------------------------------------------------------

角色动画系统第二种做法是使用脚本驱动。脚本驱动在概念上是，脚本本身具有播放动画的功能，然后脚本以流程方式来运行，将各种不同的动画全部子程序化。最后组合在一起时，通过不同的脚本子程序的工作，最后产生出角色的各种不同的动画效果。
######（这个脚本是操作由很多单张的连续动画图片构成的动画片，就是帧动画）

举例：爆炸动画脚本：VC6
TEXTURES 9
Animations\Expl\expl1.jpg > ExplA1
Animations\Expl\expl2.jpg > ExplA2
Animations\Expl\expl3.jpg > ExplA3
Animations\Expl\expl4.jpg > ExplA4
Animations\Expl\expl5.jpg > ExplA5
Animations\Expl\expl6.jpg > ExplA6
Animations\Expl\expl7.jpg > ExplA7
Animations\Expl\expl8.jpg > ExplA8
Animations\Expl\expl9.jpg > ExplA9
//
// Explosion2 effect
//
SHADER Explosion2
{
   Layer map1
   {   
       //
       // Texture Animation :
       // Syntax : anim [FramePerSecond] [Tex1] [Tex2] ... [TexN] [0]
       //
         anim 10 Explb1 Explb2 Explb3 Explb4 Explb5 Explb6 Explb7 Explb8 Explb9 [0]
blendFunc ONE ONE
         depthFunc NOWRITE
    }
}

---------------------------------------------------------------------------------------------
两种方式的优略比较：使用数据驱动的动画系统，因为配置和驱动的简单，在一些大型的多角色游戏中比较常见，比如即时战略，比如ARPG。使用数据驱动做出的角色系统统一性是非常好的。而使用脚本驱动的动画系统，因为配置和驱动比较专业，这种是非标准的专业，所以在统一性上并不如数据驱动。但是因为脚本驱动特定的纯程序的工作方式，这使得脚本驱动的角色系统在灵活性上很见长，比如角色可以脑袋飞起来在天上转360度，然后再掉落在角色身上，比如角色可以根据环境的条件，而产生特定的动作。

简单来总结：使用数据驱动，统一性较好，配置方便。使用脚本驱动，灵活性较好，改动困难。

######（数据驱动适合做角色动画，脚本驱动适合做效果动画，如果开发一个游戏两种驱动都要使用）

实际中：在实际中，往往是脚本和数据并行来驱动。纯粹的数据驱动只为特定的游戏而存在，这是因为系统需求以及开发者的缘故。比如星际，魔兽，周到的系统分析，然后配上稳定的驱动程序，使得数据式角色驱动变得非常具有统一性，改动非常方便，但是这些角色，却不常出现在别的游戏中，这便是纯粹的数据驱动最大的弊病。脚本和数据并行的开发，开发脚本和数据并行驱动，是因为脚本的灵活性虽高，但大量配置，非常麻烦，而结合数据，就刚好解决配置和驱动复杂的问题。并行驱动，可以在游戏中，使用多种游戏角色动画的资源，比如曾经的游戏A是数据驱动，现在是游戏B是并行驱动，在游戏B中，可以游戏A的所有角色动画资源。在实际工作中采用并行驱动，并不是为了功能的强大，而是因为系统的兼容性以及
衍生性可以大大提高。

######（早期星际用的是脚本驱动，魔兽用的是数据驱动，我的解释是2D游戏里用脚本驱动的多，3D游戏里数据驱动多）


--------------待续--------------

游戏之家站长

第二部分: 物品系统(因为时间关系, 文章是转载的, 应当是楼主要的分析)

我们先形象看一下物品。物品从游戏整体来看是以流的形式在运行。假如，物品掉落到场景中，那么物品就流入场景了。而物品被角色检起来，放进背包，这时候物品就流入角色的背包了。然后，物品如果被装备到角色的身体，这时候物品就流入角色的身上了。

以上述的物品流为例，来分析一下程序的实现。

从物品掉落到场景到物品被角色检起来
       运行机制上是物品在掉落到场景中以前，物品已经创建好了。物品中的关键数据，比如物品类型，物品的Portrait，物品的价格，等等，这些数据必须在之前就被创建好。然后物品在掉落时，可以是从箱子，桶，或则从死亡的角色身体上掉落。物品的掉落形式，是用Plane和屏蔽深度缓冲掉落的。值得说明的是，当物品掉落到场景时，物品在内部会触发一个事件，告诉规则系统，这时物品已经掉落到场景了。这时，物品在被角色检起来之前，物品会一直存在于场景中。而当物品被角色检起来时，在物品内部也会触发一个事件给规则系统，告诉规则系统，这时物品已经被某角色检起来了。

从物品被检起来再到角色的身体，然后再到场景
       当角色将物品检起以后。这时该物品就存在于一个角色的背包中了。你可以将背包理解成一个容器，但是我不建议你用游戏中那种形象的背包表示来理解容器，因为这个容器在这时是抽象的，只有在经过了GUI的表示以后，然后才会以形象的方式呈现出来。我们也是通过这种GUI来将物品装备到角色身上的。
       当物品从背包到被装备到角色身上，机理是和场景掉落同样的。都会触发一个事件给规则系统，告诉规则系统当前物品的流向，所处。而物品在功能和程序的实现上，也是在该事件中搞定的。

在了解了物品流向以后，我们来分析一下物品的使用。
       物品在使用上，建议你读一下那篇深入分析规则引擎。
       物品在使用上，主要是使用技能系统得运行机制。各种不同物品，有各种不同的使用方式。火球术法仗可以向一个区域发出面积性杀伤的火球术，飞弹法仗是向一个角色发射魔法飞弹，而药剂则是直接使用，不需要鼠标额外的点击。其实在物品使用上，是和技能一样的，分为，直接使用，必须指定另一个角色为目标来使用，或则必须指定某一个区域为目标来使用，等等，等等。建议去读一下那篇深入分析规则引擎，这篇文章对技能系统的实现分析是非常深入的。物品在使用的机制上则是完全的借鉴技能系统。

数模的架构：
数模在架构上，我采用队列分批计算。
举个例子，角色生命这个数模，是一个触发器的集合容器。角色当生命受到影响时，该数模会依次触发计算触发器集合容器中的那一大堆接口过的事件。
在生命数模中，有两个关键数值。生命数模的母模，和生命数模的变化模。母模的作用是，如果用Designer的传统思想来说，母模是存在于数据库中的数模。而变化数模，则是随游戏进行不断变化的数模。这两个数模都有各自得触发器集合容器，当数模发生变化，就会触发那些注册事件。
那么，数模系统是怎样工作的呢？
数模系统，是依靠母模来工作的，而数模的改变，是在触发事件中，拿程序来计算。当母模改变时，就全部刷新这些触发事件。而当数模的触发器容器，被增加或则减少事件时候，这些专用计算数模的触发事件，也会被全部刷新。这样就可以实现那种，当装备到角色身上时，角色数模受到影响，当装备被卸下时，角色数模的数值被还原。


物品的系统构架：
       物品的系统构架，详细来描述的话，是物品的数据构架到数据构架的驱动程序，它们之间的构架。
       物品的数据：物品的数据，前面大致说了一下。从总体来说分为，图片+配置数据。配置数据的内容，有很多属性，比如可以被交易，可以装备到身上（装备），只能饮用（药水）。

物品数据构架的驱动方式：
调用物品驱动时，配置数据作为参数传递给物品驱动程序。物品驱动程序从参数中，取得物品的相关属性，然后再有根据的运行。我举个例子，
假设有一个StandItemDriver函数。我们这样写即可。
StandInstItemDriver(“国王盔甲.ini”，角色A);
我的实现是放在核心系统的脚本中完成的。StandInstItemDriver，是一个专用的驱动可以装备物品的驱动程序，以函数的形式来使用。国王盔甲的说明信息，命名，和对于属性的影响，等等相关的配置信息，都存在于“国王盔甲.INI”这个文本文件中。具体的配置信息是根据物品驱动程序在处理。
如果这样写则不对，违反了制作上的思想
StandInstItemDriver(“生命回复药水.ini”，角色A);


物品的使用方式：
       物品在使用上，我是用的技能在代替物品的用途。比如一瓶毒药，可以向别人投掷过去，也可以通过自己饮用来伤害自己。如果向别人投掷过去，这时候就是使用技能库中的一个投掷技能来完成，这点是和技能的使用机制是一致的。如果是自己饮用，也是使用技能库中的一个技能来完成。像消耗品，生命药剂，魔法药剂，等等，在使用上都是采用这样的工作机制。总之，物品在使用上，都是使用的技能系统得工作机制在实现。

开发可装备的物品和数模构架：
       可装备的物品前面大致提了一下。可装备物品在驱动上主要是先获得物品的所属环境的事件，然后接获，然后在该事件中通过判断所属环境，来决定物品对于角色数模的影响。这整个的过程，都是在同一个物品的驱动中完成的，比如国王盔甲这个物品，对于数模的影响，就是在StandInstItemDriver中完成的。
       下面我来详细介绍一下驱动的具体结构和开发方式。
       因为我的核心规则是用Pascal脚本在实现，所以这里我暂时以Pascal为例。

       Unit StandInstItemDriver；

       Procedure OwnerChange(_OwnerID:Integer; _Obj:TObject);
       Begin
              Case _OwnerID of
                     场景：;
                     背包：;
                     身体：
                            Begin
                                   角色(_Obj).数模.A:= 角色(_Obj).数模.A+50;
                                   角色(_Obj).数模.B:= 角色(_Obj).数模.B+50;
                                   角色(_Obj).数模.C:= 角色(_Obj).数模.C+50;
                            End;
              End;
End;

       Begin
              TriggerTarget.OwnerChangeEvent:= OwnerChange;
              //读入数模
              IniFile.LoadFromFile(TriggerSource);
              //
              EnabledResident;
       End.

该脚本只是提供实现思路的构架。并非是实际环境中的物品驱动脚本。
在实际环境中的驱动是非常复杂的，涉及到很多数模的计算，和很多数模的触发器程序。

在物品驱动中，结合数模：
       在物品驱动中要结合数模。先要在物品驱动被启动时，注册一些数模的触发器。
       这样才能从真正的意义上实现那些属性数模的数值灵活化。
       因为我用文档来表达程序，尤其是像物品驱动结合数模这种程序，这种程序是架构比较复杂，实现起来并不复杂，可能几百行代码就可以将整体思路表达出来。

游戏之家站长

第三部分:

最影响扩展和修改的地方：
角色使用分布式结构，可以随意拔插逻辑模块。
如：角色创建时，除了载入角色动画部分。其余地方全是VN触发器。
Void 角色创建（）
{
触发器1：（数模的创建）
触发器2：（技能的安排）
触发器3：（物品的处理）
触发器123随意拔插，整体性较强。比如新建一个数模模块时，直接注册一个触发器即可生效。
}

######（这个触发器相当于游戏里的指针）
举例1：
MAP = 0        '空城
MAP = 1        '城市属于魏国
MAP = 2        '城市属于吴国
MAP = 3        '城市属于蜀国

举例2：
RES1=1(刀),RES1=2(枪)
RES2=1(大还丹),RES2=2(草药)
RES3=1(记录),RES3=2(读进度)

PSMOD=0        '不操作事件
PSMOD=1        '选择武器
PSMOD=2        '选择物品
PSMOD=3        '存读进度
IF PSMOD=1 AND RES1=1 THEN  拿刀
IF PSMOD=2 AND RES2=2 THEN  使用草药
IF PSMOD=3 AND RES3=1 THEN  记录游戏

举例3：
AI=INT(RND * 1000)
ENEMY = INT(RND * 3 + 1)
IF AI=1 AND ENEMY=1 THEN     '士兵
IF AI=2 AND ENEMY=2 THEN     '班长
IF AI=3 AND ENEMY=3 THEN     '连长

游戏之家站长

第四部分:

角色数模的开发以及工作原理：
这么说吧，在角色数模的开发中，OO思路总是占主导位置。当角色的数字被对象化时，这个对象是不断在
调用外面的VN触发器。

举个例子，在力量数模中。母值是20，而力量的当前值是40。那是因为外面的VN触发器被一些什么装备，
技能做过一个触发器接口，当取得当前值时，接口被触发，然后按数模的母值+当前值规则去改变，最后
得到最终结果40。

而数模部分的开发，在实时ARPG的准框架中如上所述。而在走OO实现的道路时，角色数模是关系状态数模，
比如力量对生命的影响，生命对健康的影响，等等。关系状态都是以数模的VN触发器，以及数模工作规则
在开发。这虽然有一定复杂性，但是思路上的清晰，可以大大降低关系数模部分的繁琐度。在OO中，数模
分了很多很多对象，少的数十，多点上百，数千。当你看见上百条关系数模的框架时，不要嫌头大，太正
常了。

######（你可以把角色的各种属性每一个做成一个类或模块来调用，但他们之间的关系要用公用变量连接好，数据处理部分还是比较多。）

角色系统的开发时体系：
我考虑过使用配置文本来实现数模，还有机能，物品。但是配置的概念太高层了，比如使用关系数模，配
置文本就不太好用了，在关系数模中少一个都不行。
######（配置文本比较适合地图编辑器， 机能，物品采用变量比较好）


注:以上回答的问题可能有不正确的地方,可以请开发过游戏的高手补充和修正, 谢谢

PassByYou

######（这个讲的是3D骨骼动画模型所具备的功能，模型文件是单个，但是他包含了很多角色的动作）
VB6 + TV3D的实例：
npc.Load "MODEL\name.mdl"                      '角色的模型
Pos.X = 100: Pos.Z = 100                       '角色行列坐标
npc.SetRotation 0, 90, 0                       '角色角度
Pos.Y = Land.GetHeight(Pos.X, Pos.Z)           '判断高低地形
npc.SetPosition BarneyPos.X, Pos.Y, Pos.Z      '角色摄像机上的坐标
npc.SetScale 1, 1, 1                           '角色尺寸
npc.SetAnimationID 1                           '角色动画编号
npc.PlayAnimation 30                           '角色动画速度
npc.SetMaterial 1                              '顶点光源

######（这个脚本是操作由很多单张的连续动画图片构成的动画片，就是帧动画）

举例：爆炸动画脚本：VC6
TEXTURES 9
Animations\Expl\expl1.jpg > ExplA1
Animations\Expl\expl2.jpg > ExplA2
Animations\Expl\expl3.jpg > ExplA3
Animations\Expl\expl4.jpg > ExplA4
Animations\Expl\expl5.jpg > ExplA5
Animations\Expl\expl6.jpg > ExplA6
Animations\Expl\expl7.jpg > ExplA7
Animations\Expl\expl8.jpg > ExplA8
Animations\Expl\expl9.jpg > ExplA9
//
// Explosion2 effect
//
SHADER Explosion2
{
   Layer map1
   {   
       //
       // Texture Animation :
       // Syntax : anim [FramePerSecond] [Tex1] [Tex2] ... [TexN] [0]
       //
         anim 10 Explb1 Explb2 Explb3 Explb4 Explb5 Explb6 Explb7 Explb8 Explb9 [0]
blendFunc ONE ONE
         depthFunc NOWRITE
    }
}

######（数据驱动适合做角色动画，脚本驱动适合做效果动画，如果开发一个游戏两种驱动都要使用）

######（早期星际用的是脚本驱动，魔兽用的是数据驱动，我的解释是2D游戏里用脚本驱动的多，3D游戏里数据驱动多）

######（这个触发器相当于游戏里的指针）
举例1：
MAP = 0        '空城
MAP = 1        '城市属于魏国
MAP = 2        '城市属于吴国
MAP = 3        '城市属于蜀国

举例2：
RES1=1(刀),RES1=2(枪)
RES2=1(大还丹),RES2=2(草药)
RES3=1(记录),RES3=2(读进度)

PSMOD=0        '不操作事件
PSMOD=1        '选择武器
PSMOD=2        '选择物品
PSMOD=3        '存读进度
IF PSMOD=1 AND RES1=1 THEN  拿刀
IF PSMOD=2 AND RES2=2 THEN  使用草药
IF PSMOD=3 AND RES3=1 THEN  记录游戏

举例3：
AI=INT(RND * 1000)
ENEMY = INT(RND * 3 + 1)
IF AI=1 AND ENEMY=1 THEN     '士兵
IF AI=2 AND ENEMY=2 THEN     '班长
IF AI=3 AND ENEMY=3 THEN     '连长

######（你可以把角色的各种属性每一个做成一个类或模块来调用，但他们之间的关系要用公用变量连接好，数据处理部分还是比较多。）

######（配置文本比较适合地图编辑器， 机能，物品采用变量比较好）

动画部分你的做法太程序化了。在配置和使用时，除了程序以外没有不喊头大。推荐在动画部分做法：程序事先做好，第三方designer直接拿配置文件或则工具来驱动动画。

实际中我的做法：脚本驱动+数据驱动。脚本部分比较复杂，大多人不会用，我为此专门做了一个builder工具。见下图。
初衷是避免涉及到复杂脚本。直接使用数据驱动。使用数据在实战中比脚本驱动来的有用。



在2D爆炸过程中，我指3D方面的制作，很多地方用的爆炸效果都2D爆炸。读你的shader和驱动代码，发现每帧爆炸都是一张纹理。用单张纹理切换坐标优于你不断切换纹理。可参看q3，hl2，及tv3d论坛中很多demo。

我的触发器原理，是这样的。

触发器引擎。
{
   在此触发引擎中所包含的若干个触发器事件接口。
}

数模1
{  
   注册触发事件到触发器引擎。
}

数模2
{  
   注册触发事件到触发器引擎。
}

角色创建函数
{
    读取角色模型。
    激活触发器引擎。（这时并不在这里直接指定自定义数模）
}

纵观总体，这样干简单实现了即插即用的灵活逻辑系统。

另外，回头我可以让你看看我的核心规则的实现代码。
我在高层逻辑层根本没写直接性的规则分辨之类的代码，规则判断部分全部放在局部处理。在中央部分只是几个接口。

总的来说，这种程序扩展较容易，可修改性较强。弊病是在开发过程中，会产生了一定的那种工程化特有的冗余代码，比如在几百个触发器的核心规则里面，调来去调去重复触发性比较大。