Unity手游实战：从0开始SLG——Unity目录分布（Asset权限规划）

目录演变

Unity的工作目录在2018以后发生了比较大的变更，这跟Unity“减负”的计划有很大的关系。

Unity第一个版本的发布要追溯到2005年，距离现在也有了10几年了。在这么多年的迭代和演变的过程中，升级了很多的功能和规则，比如使用Animator来替代Animation，数字命名版号改为年份命名版号等，当然除了优化的部分之外，本身也在做越来越多的功能支持，甚至吸收很多外部优秀的插件，使得Unity本身越来越臃肿。“减负”无论是从官方的维护角度，还是用户的使用角度都是有必要的，因为如果功能是一体的，那么你就不得不将你用不到的部分也编译到你的发布代码里面。

当然其实你也可以使用代码裁切来剔除你不需要的库和代码，但这个使用场景有限定，并且也不能剔除Unity自身的代码库。

所以Unity的做法就是给核心部分“减负”，把所有能从核心库里剥离的功能都剥离出来，然后以“Packages”的方式进行引用。2018.3的空工程，目录结构如下所示：

可以看到，比对原来只有一个Assets目录来看，新的版本增加了一个Packages的目录，用来管理各种剥离的外部组件。

Packages

这个目录是2018新增的，Unity自动生成的Project是不能直接对这里进行管理和修改的。同时，Unity的引擎在工作目录里也是没法对它进行操作的，是一个只读的目录。

Assets

这是是Unity的主工作目录，这么多年一直都没变的，是Unity工作的基石。任何资源只有放在这个目录下才能被Unity识别和管理，不管你是纹理、模型、地形、声音、特效、代码、文本等等。也正是因为Unity的这个特性，项目的开发人员都必须基于这个目录去工作。因为所有目录的变动都会导致工程效果的变动，所有这个目录的规划就非常非常的重要。本篇文章讨论的也是这个目录的规划和布局。

Packages和Package Manager

前面说了，Packages是一个只读目录，那么如何去管理它呢？答案是Unity提供的一个Package Manager窗口。入口如下图：

打开之后，长这样：

左边是工程里已经引入的插件列表，前面的√表示是最新的，黑底的下箭头符号表示有最新的版本。这里要注意，你可以选择上面中间的按钮 Advanced然后勾选ShowPreviewPackages来让左边显示所有支持的package列表。如果工程尚未引用那么前面就是空的没有额外标识。

右边是插件的一些基本信息和操作。可以查看文档，变更日志，授权许可等，也可以查看历史版本、选择更新或者回退或者删除插件。

当我们选择安装了插件的时候，插件最终到哪里去了呢？来看下下面的截图，在Assets的平级目录里多了一个Packages目录

嗯打开看看。

嘿~就一个json格式的文件！

OK，再打开这个文件看下，里面长这样：

这里其实就是一个Json文件，记录了当前工程所引用的packages以及版本信息而已。那么真正的插件在哪里呢？

点开Assets平级的Library-->PackageCache里面长这样：

这里就是真正的package所存放的目录了。这个目录其实没有太多好规划的，目前来说都是定死的，除非你需要修改插件源码，但是除非必要，不然不建议修改，要不然等到插件升级的时候，你会痛不欲生。

这里要吐槽一个点：外国人可能不会想到中国人开发项目的复杂环境，2020年了，还是有很多公司是内外网隔离开发的，Package Manager只能在线更新，对于没有外网的同学，很惨。（当然也不是没有办法，外网建空工程下了按照规范修改了就好）

Assets目录规划

在讲目录规划之前，要讲一下大体的开发背景。

我没有制作过独立游戏，从业以来都是在实际项目里工作，所以对于独立游戏的目录规划没有什么经验。但是我觉得当工程涉及的人员和分工非常复杂的时候就有必要去做目录规划。

实际的Unity项目，一般都会有几种重要开发人员参与客户端工程的资源传递：策划、服务器、客户端、美术。（当然也会有QA参与工程的情况，比如有一些白盒测试，或者QA部门十分强大需要对客户端性能检测部分进行埋点的）。

那么人员结构一旦复杂了之后，对项目权限的划分就要做的精细，不然就会经常出现你的工程出现各种莫名其妙的错误，或者一个资源的问题理不清责任人，处于三不管的地带。策划、服务器、美术、和客户端几种开发人员对于Unity的熟悉程度差异也非常大，所以一套详细的目录规范和权限职责是保障有序开发的前提。

我们的项目目前几种开发人员都参与了客户端工程的内容提交。

• 策划需要将配置表数据输送到工程目录

• 服务端需要将协议提交到工程目录（Sproto需要C#的序列化和反序列化文件，服务器统一提交避免协议修改之后前后端协议不一致产生问题）

• 美术要将各种美术资源提交至工程目录。讲完背景之后，就来看看我们客户端目录的总览：

Unity本身会有一些固有目录，比如Resources、StreamingAssets、Editor、Plugins等等，另外每个不同的插件也都会有不同的使用目录，这些基本都是不需要规划的，最好也不要规划。那么剩下的就是每个工程自己独有的资源了。这里主要就是讲上面提到的不同人员的目录分工。

Arts

这个目录里存放的是美术的原件资源，也就是美术最基本的素材。比如UI的切图，Icon的资源，模型Fbx文件，场景贴图，材质球等。并且根据不同的类型存放在不同的目录下面。美术同学只有这个目录的写入权限（但是有整个工程的读取权限）。不过如果有些项目美术人员对Unity确实不熟悉，并且资源也确实不需要在Unity下工作的话，也可以通过外链方式管控（比如UI切图）。

Data

这个是工程的数据文件夹，主要存放策划编辑的表格数据，以及Lua脚本和一些散列的配置项。策划只有这个目录的写入权限。

Prefabs

这个目录是真正项目要用到的各种预制体文件，比如一个士兵，拿到Fbx之后，由工具生成特定的Prefab到指定目录，这里包含了各种资源，也是通过子目录来划分类别。这部分由客户端和各种工具共同维护。

Scripts

这个是客户端内部的代码文件，这里要注意的是ECSBattle和ECSBattleView两个目录。之前也有提到，我们的战斗是逻辑和表现分离的方式，所有的逻辑层可以在脱离表现层的情况下独立工作。ECSBattle就是逻辑层的必须代码，ECSBattleView是跟表现相关的部分。这里我们其实希望能从设计上将单局和外围的部分隔离出来，这样就可以防止改动外围的时候会动到核心。

执行监督

制定规范其实很容易，难的是如何保障规范的执行。理论上来说，美术资源是最难管控的，不仅仅是因为人员对软件的熟悉程度，也是因为美术资源是除了客户端代码之外，内容最多的部分了。并且美术分工的差异也非常大，特效、音效（和部分美术资源一起外包的）、地编、模型、动作甚至是Shader等等。所以必须要安排好接口人，写好工具，定时扫描检查问题。

 

下一篇，讲讲ECS战斗部分。