游戏开发架构中的数据与元数据.docx

游戏开发架构中的数据与元数据 从2012年4月开始，一直都在开发一款平板电脑上的实时战略类游戏，开发平台是当下比较流行的 Unity3D，网络传输部分基于 uLink。是我自己的第一个 Unity3D 项目，在架构上下了不少功夫，项目相对比较复杂，作为架构师和主要的开发者（技术团队一共3个人，其他两个经验都比较少），工作量着实不小，开发过程还是相当痛苦的，相对应的收获也很不少。 目前项目的技术部分基本上算是告一段落，下一步更多的是市场和运营的工作，我的重心也会向服务器管理的部分转移，计划陆续把项目中的心得体会在这里用文字的形式保留一下。 数据 其实广义的说，与计算机相关的所有的信息，包括代码，可执行文件，网络数据包，一切的一切都是数据，取决于从什么方向来看，比如说，源代码是编译器的输入数据，相应的可执行文件则是编译器的输出数据；从操作系统的角度来看，可执行文件就变成了输入数据。 元数据 元数据简单的说就是关于数据的数据，听上去可能比较抽象，其实并没有什么特别之处，例如关系式数据库中数据库的模式就是一种典型的元数据，定义了数据表的内容格式，包含哪些列，各自的数据类型及取值的约束，索引的定义等等，表中存储的内容是数据，模式就是数据的数据，也就是元数据。 数据与元数据的关系 对于软件系统来说，元数据往往是输入数据的一部分，而数据则是输出数据。元数据会影响系统对待数据的方式，此外元数据和数据往往是一对多的关系。 这里的输入输出并不是绝对的，比较复杂的系统往往会有多重体现，例如：可能会提供元数据的编辑工具（例如游戏中提供了地图编辑的功能），则对于工具来说，元数据就成了输出数据。 另外，大部分情况下，数据即是输入也是输出的，例如对文本编辑器来说，对文本文件既会读取，也会写入。 架构与元数据的关系 个人体会，架构的核心功能就是对元数据的定义、解析，和执行，只能以一种方式运行的代码不能称之为架构，必然要根据具体的元数据（广义上也包含构建于架构之上的逻辑代码）来执行不同的逻辑规则。 架构中的元数据并不仅限于类似数据库模式或者页面模板这种具体的形式，也包括比较抽象的形式，例如对于实现类中特定方法的定义等等，像是 Ruby on Rails，或是 Django 这类大量基于惯例的架构就更是大量定义这种抽象类型的元数据，有些甚至可以称之为元数据的元数据。 领域专属语言，则是这种关系达到最大程度的结果：软件系统 = 架构 + 元数据 游戏开发架构中的数据与元数据 终于进入正题，下面就以我们的游戏中各个兵种的定制系统为例，具体解释一下。 游戏中玩家只负责划线指挥位置的移动，各个单位的运行逻辑是类似 AI 的方式，会根据当前自身的状态，玩家的命令，周边的环境以及敌军、友军的具体情况产生行动。游戏的可玩性很大程度上来自于各个兵种的设计，例如远程攻击的能力，近战的攻防能力，攻击速度；特殊兵种的独特技能，例如忍者在运动时可以隐身，医生可以恢复周围友军的生命值等等。为了达到更大的多样性，每个单位还可以叠加特殊设定，简单的可能是数值的加成，复杂的则可以提供额外的特殊技能。 策划提出的要求是能在不需重新编译的情况下调整参数，例如各兵种的移动速度，加成的数值等等，似乎要求不高，也很容易实现。然而游戏开发中的不确定因素其实很大，往往会做大量的修改，如果用常规的方式，逐一实现功能，来来回回的修改恐怕会带来相当大的工作量。 原型版本中实现的相对简单，自己写了第一个版本，基于行为树的模型，实现了基本的攻击逻辑，后来让另一个程序员接手，加了不少功能，又改了若干次需求，后来复杂性失控了，出现很多问题，经常行为就不对了，最明显的就是敌我双方非常友好的转来转去，就是不动手。 本想凑合着先改改用着，策划说是不行了，必须彻底修好，而且好多新技能还没加，旧的代码是不可能支持了。最后还是花了近两个月的时间，把这部分彻底重写了一遍，基本上提供了一个小型的领域专属语言。策划通过 Json 的形式，利用系统支持的底层组件，可以自由定义兵种，加入新的技能、装备，效果相当不错。这些 Json 格式的元数据保存在单独的目录中，不需要重新编译的情况下可以自由修改。 面向元数据开发的优点 技术与策划分工明确 最重要的一点就是把各工种的责任划分的比较清晰，技术负责实现架构和各个子模块，策划负责通过提供元数据的方式进行具体的设计与定制。 通过简单的培训，和基本完整的文档，我们的策划写了上百个 Json 文件，把所有的技能、装备都实现了一遍，有些自定义的技能达到了相当复杂的程度。整个过程中我的角色都是技术支持，前期答疑、做些示例，后期主要是调试，增加一些新的组件。双方都很满意，策划可以自己实现想要的效果，我也可以集中精力在可重用的工作上。 之前看到过有些项目里修改一个简单的参数都必须由程序员负责，有些“乐于助人”的