-
大部分数据都是在Excel里填写生成的
-
最原始的数据方式，代码数据
-
txt文本数据文本是一种常用的数据表形式，例如用.Json，Xml，Csv为扩展名的文件，里面全是字符串形式的文本，包括数字在内也都以字符串的形式存在，在当程序读取这些字符串内容后将它们转化为相应的数据类型，整数，浮点数，文本，数组。
-
比特流数据，数据比特流是一种稍微底层点的数据表现形式，他是将数据转化为二进制形式存放在文件里，然后程序通过读取二进制文件，按一定的规则将其转化为所需要的数据。它比起文本形式的数据文件，比特流数据文件特点是，占用的空间更加小，读取速度更快，但缺点也同时存在，通用性差，无法直观和任意的修改。
为什么会更加小，二进制比特流在存储数字时，会直接用二进制形式存储，比如，txt文本中23345是“23345”这个字符串，占用了5个字符，每个字符2个字节，就用了10个字节，而二进制比特流则在存储时可以直接使用二个字节(short)存储’23345‘这个数字，所以数据比特流形式的数据存储文件更加小。一个以文本形式的txt文件来建立的10MB的数据文件，转化为2进制格式后，可以压缩到几百KB甚至几十KB。
以比特流形式作为协议的标准很多。比如最近比较流行的，Google protobuf，还有MessagePack。
-
最简单的就是直接将Excel里的数据复制黏贴到文本文件作为游戏数据。
-
有比较简单的直接Excel手动另存为导出CSV，就有了CSV的一个规范。
-
例如使用Shell或Bat(window批处理)设计自动化流程操作，在Mac或Windows下执行我们编写的批处理文件就能自动一步步地执行我们规则的操作步骤。
-
通过特定语言写自动化程序的，比如C#从Excel中读取数据后写入特定文件，会使用.Net库，或者其他第三方库来取得Excel里的数据，再将数据以自己希望的格式输出到文件中。
-
很多同学还使用Jenkins来强化自动化流水线。Jenkins可以认为是一个电脑中待命的程序，它有自己的本地站点，可以通过网页的形式，添加我们需要执行的操作或程序命令，还可以设置运行的时间和次数，每次运行结束都会有失败和成功的信息显示，还会有很多错误的日志记录在里面。
当然Jenkins也不是万能的，并不是说一定要使用它，我们也可以有自己的流水线制作途径。Jenkins只是多了一个可视化的Web页面，它同样需要借助特定的语言，比如Shell或C#或Python或Ruby等来编写我们需要的操作过程，甚至这些语言的组合起来的操作流程也是很常见的。如果这些你都不太熟悉，还可以使用Unity3D的菜单栏编辑功能，实现点击菜单栏按钮后执行一套相关程序，也是种不错的选择。
-
一键转化Excel到其他格式是一个比较人性化的工具，不需要人工手动去转化，通过工具就能搞定，只要数值策划按照你们双方约定的规则就行。这能大大提高数值策划与程序的协调性，一个系统，一个模块，需要什么数值，什么类型的数值，数据表建立的流程，在你们约定的填表规则上，建立，读取，转化，变得轻而易举。这种在规则下，大家都遵守同一规则，减少了沟通时间以及沟通的障碍，彼此能默契的合作，是多么高效和舒心。
-
在程序命令中预留几个参数，这个参数是指向某个需要导出的文件的，以及需要导出sheet。那么在命令行里，执行这个程序并且后面跟上参与就能导出数据。
-
可以增加一个Excel表，表里面填有具体要导出哪些Excel文件里的哪个sheet，这些sheet的数据导出后的文件名是什么，以及生成文件后，文件应该转移到哪个文件夹中去。这样策划就可以自行定制，我们需要用哪些Excel里的哪些sheet，可以自行增删改，可以完全自给自足了。策划设计人员完全能够主导所有数据的导出工作和转移工作都了。
-
让字段名字与程序对应的规则。用程序生成一群变量定义与每个数据表字段名对应，将每个要导出的sheet里的头行的列名作为变量名字写入程序变量定义中，以方便程序在读取数据表时，列名与数据表对齐，无形中校验做好了。
到这里，我们有了自动化和一键转化XXX的工具，省去了不少人力，并且加入了规则，让策划设计人员完全可以自己控制Excel数据表的操作，又加入了检查校验和修复的功能，让程序员在数据表衔接部分也得到了很好的检查和校验作用。这个方案可以供大家参考，许多大项目大公司都采用这样的方式，安全又稳定。
-
用整数形式获取就会像这样的样式存在
string content = GetTextString(12)这种形式，看起来不是很美观，对于其他程序员来说，或者我们过了几周再回头来看时，我们怎么知道12代表什么？只能猜，这个12可能是某个字符串。随着代码的增多文字量的增多，对应数字Key也增多，我们很难识别这句话是代表什么，调试起来会很麻烦。一个项目一般会有10-30万行代码，到处都是这种形式的字符串获取方式，任何人看起来都会崩溃。维护性太差，校验检查难度太大，效率太低。
-
如果用字符串形式获取
string content = GetTextString(“FightWin”)这种形式，会好些吗？看起来似乎好了些，至少我知道了我获取的大概是什么内容的字符串。不过任然有问题，你用一个字符串去获取另一个字符串，那岂不是双份内存，GC垃圾回收的消耗也会同时增加。原本只需要存储一个字符串就够了，现在要存两个，就因为用了键值字符串去获取内容字符串。
-
既要用简洁的数字去代表文字，又要让键值看起来形象。我们策略是生成一个类，用变量的形式去记录文字的ID，在文字表生成数据表，同时生成数据定义类，使用变量去代表数字。我们依然在表里填字符串对应字符串，比如上面提到的”BattleSceneFightAllianceWin” 对应”联盟战胜利了”，在导出xls数据文件时，生成一个类文件，专门把Key值按次序写进类中当变量。如下
Class TextKey { public const BattleSceneFightAllianceWin = 1; public const BattleSceneFightAllianceLose = 2; }再把“联盟战胜利了”这种文本数据按次序，依次写入数据文件。这样就可以一一对应了。也就是，第一个变量对应第一个文字，第二个变量对应第二个文字。获取文本的方式改为了
string content = GetTextString(TextKey.BattleSceneFightAllianceWin)这时文本数据的排列是如下
联盟战胜利了 联盟战失败了 …而程序变量生成后为如下：
Class TextKey { BattleSceneFightAllianceWin = 1; BattleSceneFightAllianceLose = 2; }文字与变量的数字依次对应，既解决了用数字做Key不够形象的问题，又解决了字符串做Key太多冗余的问题。
-
假如把所有表都集中起来成一个表，那么游戏在加载数据表就需要一次集中使用CPU去处理，导致游戏有时会卡顿现象，不合理。我们需要让游戏表现的尽可能的顺畅。所以分散读取比较可取，各个表数据都自己管自己读取吧，这样就CPU就分散开来了，不会一下子对CPU的需求量很大。而且在读取数据表时，要按需读取，而不是一开始就初始化，这样的话跟集中在一起就没有区别了。至于预读取，其实和提前集中读取没有区别，关键是如何利用空挡时间进行预读取。比如在Loading等待时读取一部分数据，这样在等待时也不会浪费CPU。