在unity中是使用json统一管理所有数据还是scriptableobject？

NoiseFloor

感觉使用scriptableobject可以轻松的管理资源的引用，而使用json的话灵活度更高，但是资源的引用都需要存储resources或者assetbundle的path，那么大家在商业项目中一般都是如何做的呢？

zt3ff3n

总结一下什么时候用什么格式的配置文件以及配置文件存放位置。
一般来说，游戏里的数据可以分为关系型数据和非关系型数据。
关系型数据通常都会为每一条数据设置一个索引，例如excel，方便配置人员和代码逻辑查找，同时也方便配置人员增删改，批量操作友好，适用于维护大量数据。当一个配置人员学会了excel的基本操作后，会发现excel就是为了集中处理大量数据而生的。这里我们不讨论数据库，那个是后端该管的东西。以下链接是个人的一点总结。
https://zd304.github.io/2020/03/21/excel-system/
非关系型数据通常是键值对方式存储，包括json、xml、ScriptableObject等，通常具有良好的可读性，适合配置全局唯一的数据。对比起excel，简单的全局唯一的配置更注重逻辑性和可读性，其中SciptableObject就是Unity一部分，甚至可以序列化资源引用。
再回答一下资源存放路径的问题。
Unity的Resources文件夹里面的资源，在打包时候会自动打到包体里，这样包体会变得很大，包体大会引起以下问题：第一，影响运营数据，玩家看到这么大的包体立马就失去了下载欲望；第二，某些平台不支持大于规定大小的包体，例如Google Play不支持超过100MB的包体。
解决以上问题，可以选择使用AssetBundle，或者Addressable，这里都简称AB吧。既然选择了AB，资源就可以不放到Resources了。我们可以创建一个叫Res的文件夹并列于Resources，资源全部放到Res里。
使用了AB，那么资源读取方式就分两种。第一，非运行时，也就是编辑器中，可以使用AssetDataBase.LoadAtPath来加载；二，运行时，应该先加载AB包，再加载AB包里面的资源，当然AB包你可以放在任意位置，比如CDN上、持久化目录里等等。
以上是本人项目中的做法，经过项目验证，希望有所帮助。

Baste

个人感觉，使用json或者自动生成技术，使用Excel配表很方便；而使用scriptableobject，如果数据复杂而且很多，感觉管理上比较麻烦，有可能会创建大量object，然后拖拽到很多面板上。

pc8888888

excel写表格，然后利用插件自动生成scriptobj，完美利用两者特性，程序策划各不耽误。scriptobj的优点实在是太多了，所以必须用。

xiaozongpeng

游戏表数据可以用Protobuf和Flatbuffer
只是每次修改都要导一次二进制文件，可读性不太行外其他都还挺好

RecursiveFrog

看情况，有可能两者协调一起用。
因为纯文本数据的配置文件再大撑死就几张图的内存容量，所以一开始我启动，我偏向全部加载到内存，通过一些自动生成手段存好内存结构。
scriptable object会直接存储关联asset的guid,bundle加载时会牵连到相关的bundle一并加载，利用这特点，一些表现挂钩的地方可利用来把相关资源一并预加载。由于关联了asset，所以这种用了也不能一把梭全加载。而且后端非unity后端，无法直接读取。所以仅适用部场景。
此外unity自带序列化反序列化机制，可能是出于对性能考虑。只对原始结构进行序列化，这意味着，有继承关系的结构，如果引用处存的是基类容器，容器内存的又是子类数据，就会有数据丢失的可能。要么得像Behaviour Designer那样绕着处理；要么，不用基类结构；要么自己做，自己搞一套出来。

redhat9i

不论是unity还是netjson库，都让我用起来感到痛苦。否则肯定是json。
另外问题应该是管理配置更贴切些

量子计算9

scriptableobject我也理解成一种和prefab一样模块化的内容，他不是为了管理数据，而是一种可以把prefab扩展的解决方案

APSchmidt

具体问题具体分析，不同的数据会有不同的需求
我自己搓老辐射那种带各种检定的对话树的时候就写了一个yaml（近似）的解析器，因为看中了yaml的可读性，还有不用像json那样一堆括号

unityloverz

我原本打算用Scriptable，并且还买了odin写了个很漂亮的编辑器，然则卵...企划大哥说这玩意太不方便了，我要用excel... 所以最终改成了 Excel -> Json -> MessagePack