C# Unity游戏开发——Excel中的数据是如何到游戏中的（四）2018.4.3更新

2022-10-16 21:45:53

本帖是延续的：C# Unity游戏开发——Excel中的数据是如何到游戏中的（三）

前言

最近项目不算太忙，终于有时间更新博客了。关于数据处理这个主题前面的（一）（二）（三）基本上算是一个完整的静态数据处理方案了。

不过前几篇发布的时候是2015年，比较早了，随着这几年技术不断积累和进步，其实已经有更好的方案来处理数据了，不过对于前端存储的那几个M的数据，多点少点其实影响也不大。

但是也不能就这样算了，毕竟技术的变化日新月异，还是要保持持续学习的心态。

虽然简单但却不易忽视

对于游戏中静态数据的处理，单纯的对于整个程序项目来说其实只是很小的一部分。写个读写工具，打个包，压个缩，加个密其实对于很

多程序来说也不是难事。但是，我又要说但是了。但是，根据博主的个人经验来说，数据对于游戏的业务逻辑是非常底层的“逻辑”，对于

后期的开发起到了一个基础的作用。主要体现在两个方面:

1.业务逻辑角度的数据结构化。

　　这点很关键，策划想要把自己大脑里的游戏玩法用数据表示出来，而这个表示过程其实是需要程序配合的，因为不可能每个策划

　　都那么牛逼，然而现实情况也确实如此。因此，这部分要做的事就是，用数据抽象的思维把策划描述的游戏世界表示出来，最终

　　体现就是“表格”。这些数据，其实就是游戏业务逻辑的“骨架”，后续的开发都是围绕着数据来做的，或者说被数据“支配”的。

2.程序结构的设计。

　　第一条说过了，“后续的开发都是围绕着数据来做的”，那么这些数据的使用频率必然会很高。那么，问题来了，如何设计这部分的程序结构会使开发效率和运行效率最优？单纯的创建一个类，把所有数据查询的方法都放里面？还是根据第一条抽象出来的“实体类”来组织数据，然后对数据做一些预处理，例如游戏运行先进行分类然后放到内存中等待使用？

　　显然，后者更加高效，这也“静态数据处理虽然简单，但是也不容忽视”的理由。

最新的方案

前面也说了，技术是不断在变化的，我们也需要快速适应。之前的方案确实用了很长时间，也没什么问题。但是自己撸的代码总有几个疑问？这是最好的方案吗？和最好的方案差距有多大？

带着这几个问题，在最近2年所做的项目中也对这方面做了一些工作：1，在最近的项目中使用了ScriptableObject的方式。2,开始了一个protobuf方式处理数据的开源项目。

说起来惭愧，其实结果影响并不算很大，下面把这部分总结一下。

方案一 : 使用Unity的ScriptableObject。

　　做法就是每个表格生成的数据类都直接或者间接的继承自ScriptableObject类，打包的时候直接把所有表数据都生成一个对应类型的.asset文件。然后建一个总的Map类来存放所有asset的引用，当然这个Map类也必须继承自ScriptableObject，也生成对应的.asset文件。最终打包的时候，只打这个Map类的.asset文件，Unity会自动识别里面的依赖关系，将所有数据打包进bundle。

实体类Hero

using UnityEngine;

public class Hero : ScriptableObject

{

    public string name;

    public string level;

}

Map类

using UnityEngine;

using System.Collections.Generic;

public class Map : ScriptableObject

{

    public List<Hero> heroList = new List<Hero>();

}

最终在使用的时候也很方便：

                AssetBundle bundle = AssetBundle.LoadFromFile(Application.streamingAssetsPath + "/constance");

                Map m_Constance = bundle.LoadAsset("constance") as Map;

这种方式对Unity3D非常友好，使用起来也非常方便，但是缺点也是有的，下面来总结一下：

优点：

　　可以和预制产生依赖，prefab如果依赖了asset打包的时候也会打进去，减少了查找操作。

　　可以直接用Unity API操作asset。省去了一部分序列化反序列化代码。

　　可以直接用AssetBundle.LoadAsset() as Map;加载，省去了之前的反序列化代码。

　　在Unty中选中asset可以直接在Inpector中看到数据。

缺点：

　　生成asset的时候会有大量的文件操作，速度慢。

还有两个指标就是运行速度和存储空间。由于影响不大，没有做进一步测试。

存储空间的话，我这里有个参考：6个Excel文件占用的pc上的磁盘空间是112k，最终打成AssetBundle是31k。

方案二 : 使用protobuf

　　这种做法主要是通过google提供的protobuf来序列化和反序列化数据，并且使用protoc生成目标语言的代码。工作流程如下图所示。

　　把做法分成几部分来说：

　　　　操作1，读取excel数据描述信息，通过excel数据描述信息生成.proto文件。

　　　　操作2，使用protoc命令行生成本地代码，也就是你制作工具使用的语言代码。

　　　　操作3，创建本地代码的类的实例。

　　　　操作4，读取excel数据，并且将内容赋值给“操作3”创建的实例，最终使用protobuf API序列化。

　　　　操作5，生成目标平台的代码。

　　最终生成的二进制文件（.bytes）和目标代码会和程序一同发布，使用生成的目标代码解析生成的二进制数据。

　　具体代码就不贴出了，下面是本人对方案二开启的一个开源项目，用的是java+netbean8.2,目前已经完成大部分内容。

　　有兴趣的同学可以看一下。我会一直更新。

　　https://github.com/superbig/proto-packer

最后

　　如果你在游戏开发的静态数据处理方面还在犹豫，建议是：如果项目小可是试试ScriptableObject方式，应使用起来确实要方便一些。当然你也需要忍受数据导出时候的频繁的IO操作（当然其实你也可以开发一个增量导出的工具）。

如果项目大，数据很多还是老老实实用protobuf，空间占用少，速度快。或者自己写。

码农公寓

相关文章