数据结构，就是使游戏中所有数据按照预定的设计进行计算并使之达成预期结果的规范。而游戏中大部分的数据，比如一个角色在10级的时候生命值是多少（包含装备影响）、击杀一个怪物后会得到哪些道具等，这些看似简单的问题实则涉及程序的算法和数据的调用。下面会对数据结构进行介绍。

游戏数据分类

所有游戏中涉及的数据都可分为两类——静态数据和动态数据。

静态数据是指最基本的保持稳定的数据。比如1级的角色对应的基础最大生命值，它是不会因为任何事件的变化而发生变化的，哪怕角色升级到了2级，那也只是对应的基础生命值变为了2级的数据，原来1级的数据是没有任何变化的。

动态数据则是指常常变化并且会受到事件影响和影响事件的数据。比如角色的当前生命值，在战斗中它是时时刻刻会被计算的数据，当角色的当前生命值小于等于0时会触发角色死亡事件。动态数据在某些条件下会调用到静态数据，而静态数据则不会受到动态数据的影响。

数值策划的一项非常重要的工作任务就是制定和维护静态数据的结构，填充和维护静态数据。所以我们一定要非常了解游戏的数据结构。

前后端数据结构

在实际工作中，我们会考虑到程序的架构来设计相应的数据结构。前面的章节也介绍过了程序分为前端和后端，而我们的数据也分为前端数据和后端数据。

在早期的端游时代，策划要分别维护前端数据和后端数据，最为头疼的是同一系统给前端的数据和后端的数据是有一定交集的两个集合，这给策划带来了巨大的维护成本。后来随着程序设计的发展，大部分游戏的数据也不需要再一式两份，策划也减少了维护过程可能出错的概率。

虽然数据只需要维护一份，但是这并不代表我们就可以不分前端数据和后端数据。只有了解程序的实现机制，你才可能做出切合实际的实现方案。否则你就算想得再怎么好，程序也会默默地回复你一句：这个功能无法实现。

一般来说，后端数据以运算动态数据和产出资源为主，而前端数据则以显示为主。比如掉落数据，前端一般是不会用到的，因为前端不会计算掉落的物品，全部由后端程序算好之后通过通信发送给前端。那么在游戏中看到怪物的掉落预览又是怎么实现的呢？这其实是策划又配置了一份数据给前端显示，其并不是掉落数据。

表格和配置文件

策划在日常工作中几乎100%使用Excel来维护数据（不要用WPS什么的）。而程序本身是通过读取配置文件来获取数据的。这就涉及从Excel到配置文件的转换问题。

目前笔者了解到的主流配置文件主要有3种形式：CSV数据、XML、JSON。

CSV数据

如果你遇到这种格式的配置文件，那真是太幸运了。因为这是Excel自带的格式，策划只需要将表格保存为这样的格式就可以供程序调用了。

XML

XML是一种可扩展标记语言，是标准通用标识语言的子集，它是一种用于标记电子文件使其具有结构性的标记语言。其结构如图3-2所示。

3-2-1

在这里强烈建议让项目组的程序员提供专门的转化数据的工具，其实也花费不了他们太多时间，这样策划只需要学习使用方法就可以了。不建议策划自己去找工具转化数据，因为程序员在做转化工具的同时会根据项目自身的特性来做一定的特殊处理，而现有开源的工具都是对定制格式的XML进行处理的，未必适合你的项目。

拿到工具之后建议策划自己多测试几次，出现问题可以让程序员立即解决，以免后期因为工具出问题而导致重大工作失误，这将会给项目带来巨大的损失。

JSON

JSON是一种轻量级的数据交换格式。它是基于ECMAScript的一个子集。JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C、C++、C＃、Java、JavaScript、Perl、Python等）。这些特性使JSON成为理想的数据交换语言，易于阅读和编写，同时也易于机器解析和生成（一般用于提升网络传输速率）。其结构如图3-3-1所示。

3-3-1

JSON可以说是目前使用率最高的配置文件格式，转换工具也很成熟。策划只需掌握工具的使用方法即可。

配置文件路径和多版本维护

我们通过工具就可以把表格变为配置文件，之后就要把它放到程序指定的路径下面，这样程序才能读取这个配置文件，使数据最终在游戏中得以体现。配置文件的路径由于项目不同差异会非常大，笔者在这里也无法给出一致的答案。不过大家也不用担心这个问题，不管是前端程序还是后端程序，这个路径的位置都是不会变化的。所以在实际工作过程中，只要记住它就可以了。

版本维护

多版本维护是一个令版本策划都非常头疼的问题。由于不同的版本内容所对应的配置文件也会有很大差异，所以如何管理不同版本的配置文件其实是非常烦琐的工作。在这里给大家提几点建议和意见，会对大家有所帮助。

做好记录

大家上学的时候都会做一件事就是记笔记，笔记可以记录某个时间点的某些事情。我们维护版本的时候也需要记录一些由于版本不同而进行了维护的数据笔记。

此外一定要注意与“母版本”的对应情况，分支版本其实都是对“母版本”的不同映射。一旦“母版本”更新了，我们一定要注意对应更新相应版本。

比如当前“母版本”的程序版本编号为1.1.0，发行范围为国内大陆，发行平台为iOS。那我们的内部数据版本编号就应该是1.1.0_大陆_ios。我们可以根据不同程序版本、发行范围和发行平台得到不同的数据版本编号。

差异化更新

我们可以根据各个版本和“母版本”差异情况来更新，没必要全部整体更新，这样带来的工作量较大并且没有太大意义。比如有的游戏，iOS版本可能会给一些安卓版本没有的礼包，那我们大可把道具都统一为一个配置文件，只在投放对应的表格中做出差异即可。这样一来，道具的编号也可以涵盖所有的版本，避免出现不同版本相同道具编号对应的不是同一道具的情况。

留意文件大小

维护好版本后千万把配置文件的大小都记录一下，这样可以发现一些不当操作导致配置文件的容量发生变化的错误。游戏的配置文件的大小一般都在几十兆以下，一旦超出这个范围就应当留意是否出现了问题。