QiKi，源代码之光，sea_bug也可以进来玩玩，你们做过系统

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

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

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

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

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

神秘的猫

这是虾米...

策划写给美术看的程序技术类文章？

PassByYou

确实是写给非程序读的，非程序需要程序的意见。单靠我的说服，希望还显得不够，需要专业老程序的批注和肯定。

一片苦心。望狠批。

baickl

...

ixnehc

数模是什么,VN触发器是什么?有什么这方面的资料吗?

neelkey

上联：惊天地
下联：泣鬼神
横批：反正人类看不懂

PassByYou

我的错，我来解释一下。

数模是什么,VN触发器是什么?有什么这方面的资料吗?

数模就是个改变时可以触发事件出去的数字引擎
vn触发器，是一对多触发器。这种触发器是实现类似消息钩子被多挂的功能

rhett

PassByYou: Re: ReiKi，源代码之光，sea_bug也可以进来玩玩，你们做过系统设计的，进来批一下我的角色系统分析...

我的错，我来解释一下。



数模就是个改变时可以触发事件出去的数字引擎
vn触发器，是一对多触发器。这种触发器是实现类似消息钩子被多挂的功能

我自认为对角色系统有一定了解,可以对楼主说的看了两遍才有点感觉
你对专业术语的应用已到登峰造极的水准,强!你要是写论文,水平比国内99%的博士都强了

你对角色动画系统分类说的很好,对于大部分的MMORPG来说,如WOW,角色动画采用就是数据驱动,因为对动画的需求没有那么复杂。不少ＦＰＳ游戏里的角色动画用到了脚本驱动，通过对身体各个部件动作的组合来形成最终形态各异的动作，当然用数据驱动也能够完成这个工作，但是不是那么灵活．
　　　
建议楼主用更简单易懂的语言来表达，你的想法很好，但也要让我们更容易理解：）

源代码之光

从后面的帖子看到了VN的解释，呵呵，你把各个系统，比如技能系统，装备系统之间的通讯理解复杂了，要尽量减少各个系统之间的交流途径，如果按照你那个触发器的设定，随着设计规模的扩大，触发器可能会爆炸。所以，每个系统之间尽量简单。

congy

没有什么不可行的，不过建议你把系统分层，哪里属于底层接口，哪里属于上层概念，要分清楚，各个层次内部之间的功能要定义清楚。层次分清楚，层次内部结构划分清楚了，用数据驱动还是脚本驱动只是使用方式的问题了。