组织 Unity 项目的最佳实践

尽管没有单一的方法来组织 Unity 项目，但这里有一些关键建议：

• 记录您的命名约定和文件夹结构。样式指南和/或项目模板使文件更容易定位和组织。选择适合您团队的方法，并确保每个人都同意。
• 与您的命名约定保持一致。不要偏离您选择的风格指南或模板。如果您确实需要修改命名规则，请一次性解析并重命名受影响的资产。如果更改影响大量文件，请考虑使用脚本自动更新。
• 文件和文件夹名称中不要使用空格。Unity 的命令行工具在处理包含空格的路径名时存在问题。使用 CamelCase 代替空格。
• 单独的测试或沙盒区域。为非生产场景和实验创建一个单独的文件夹。带有用户名的子文件夹可以按团队成员划分您的工作区域。
• 避免在根级别设置额外的文件夹。一般来说，将内容文件存储在 Assets 文件夹中。除非绝对必要，否则不要在项目的根级别创建其他文件夹。
• 将您的内部资产与第三方资产分开。如果您使用来自 Asset Store 或其他插件的资产，那么它们很可能有自己的项目结构。将您自己的资产分开保管。

注意：如果您发现自己正在修改项目的第三方资产或插件，那么版本控制可以帮助您获取该插件的最新更新。一旦导入更新，您可以查看差异以查看您的修改可能被覆盖的地方，然后重新实现它们。

虽然没有设置文件夹结构，但以下两部分展示了如何设置 Unity 项目的示例。这两种结构都是基于按资产类型划分项目。

资产类型手册页 更详细地描述了最常见的资产。您可以在组织文件夹结构时使用模板或学习项目来获取更多灵感。虽然您不受这些文件夹名称的限制，但它们可以为您提供一个良好的起点。

如果你从 Unity Hub 下载其中一个模板或入门项目，你会注意到子文件夹是按资产类型分开的。根据所选的模板，您应该会看到代表几种常见资产的子文件夹。

从一开始就定义强大的项目结构可以帮助您避免以后出现版本控制问题。如果将资产从一个文件夹移动到另一个文件夹，许多 VCS 会认为这只是删除一个文件并添加另一个文件，而不是移动文件。这会丢失原始文件的历史记录。

Plastic SCM 可以处理 Unity 内的文件移动并保存任何已移动文件的历史记录。但是，必须在编辑器中移动文件，以便 .meta 文件与资产文件一起移动。

一旦您决定了项目的文件夹结构，请使用编辑器脚本重复使用模板并为所有项目创建相同的文件夹结构。当它被放置在编辑器文件夹中时，下面的脚本将在资产中创建与“PROJECT_NAME”变量匹配的根文件夹。这样做可以使您自己的工作与第三方软件包分开。

空文件夹可能会在版本控制中产生问题，因此请尽量只创建真正需要的文件夹。使用 Git 和 Perforce 时，默认会忽略空文件夹。如果设置了这样的项目文件夹并且有人试图提交它们，那么直到将某些内容放入文件夹中后它才会真正起作用。

注意：一个常见的解决方法是将“.keep”文件放在一个空文件夹中。这足以将文件夹提交到存储库。

塑料 SCM 可以处理空文件夹。Plastic SCM 将目录视为实体，每个目录都附有自己的版本历史记录。

这是在使用 Unity 时需要牢记的一点。Unity 为项目中的每个文件（包括文件夹）生成一个 .meta 文件。使用 Git 和 Perforce，用户可以轻松提交空文件夹的 .meta 文件，但文件夹本身不会受到版本控制。当另一个用户获得最新更改时，其机器上不存在的文件夹将会有一个 .meta 文件，然后 Unity 将删除该 .meta 文件。Plastic SCM 通过将空文件夹纳入版本控制来完全避免这个问题。

Unity 为项目内的每个其他文件生成一个 .meta 文件，虽然通常不建议在版本控制中包含自动生成的文件，但 .meta 文件略有不同。应在Version Control窗口中打开可见元文件模式（除非您使用内置的 Plastic SCM 或 Perforce 模式）。

虽然 .meta 文件是自动生成的，但它包含了大量与其关联文件的信息。对于具有导入设置的资产（例如纹理、网格、音频剪辑等）来说，这种情况很常见。当您更改这些文件的导入设置时，更改将写入 .meta 文件（而不是资产文件）。这就是将 .meta 文件提交到存储库的原因 - 以便每个人都使用相同的文件设置。

就标准达成的一致并不止于项目文件夹结构。为所有游戏资产设置特定的命名标准可以让您的团队更轻松地处理彼此的文件中。

虽然没有针对 GameObjects 的明确命名标准，但请考虑上面的表格。

单一、大型的 Unity 场景并不利于协作。将您的关卡划分为几个较小的场景，以便艺术家和设计师可以在单个关卡上顺利协作，同时最大限度地降低发生冲突的风险。

在运行时，您的项目可以使用 SceneManager 通过 LoadSceneAsync 传递 LoadSceneMode.Additive 参数模式来添加场景。

最佳做法是尽可能将工作分解为预制件，并利用嵌套预制件的强大功能。如果您稍后需要进行更改，您可以更改预制件而不是其所在的场景，以避免与在场景中工作的其他人发生冲突。在版本控制下进行差异比较时，预制更改通常更容易读取。

如果最终遇到场景冲突，Unity 还具有内置的 YAML（一种人类可读的数据序列化语言）工具，可用于合并场景和预制件。有关更多信息，请参阅 Unity 文档中的 智能合并 。

预设允许您自定义检查器 (Inspector) 中任何内容的默认状态。通过创建 预设 ，您可以复制所选组件或资产的设置，将其保存为自己的资产，然后稍后将相同的设置应用于其他项目。

使用预设来强制执行标准或将合理的默认值应用于新资产。它们可以帮助确保整个团队的标准一致，以便常常被忽视的设置不会影响项目的性能。

单击组件右上角的 预设图标 。要将预设保存为资产，请单击将 当前预设保存到...， 然后选择其中一个可用预设来加载一组值。

以下是使用预设的一些其他便捷方法：

• 使用默认值创建一个 GameObject：将 预设资产 拖放到 层次结构 中，以创建一个具有包含预设值的相应组件的新 游戏对象 。
• 将特定类型与预设关联：在 预设管理器 （项目设置 > 预设管理器）中，为每种类型指定一个或多个预设。创建新组件时将默认采用指定的预设值。
• 专家提示：为每种类型创建多个预设，并依靠过滤器通过名称关联正确的预设。
• 保存并加载管理器设置：使用 管理器窗口 的预设，以便可以重复使用这些设置。例如，如果您计划重新应用相同的标签和图层或物理设置，预设可以减少下一个项目的设置时间。

编码标准同样可以保持团队工作的一致性，这使得开发人员更容易在项目的不同领域之间切换。再说一遍，这里没有一成不变的规则。您需要决定什么对您的团队最有利——但是一旦您做出了决定，一定要坚持下去。

举例来说，命名空间可以更精确地组织您的代码。它们允许您分离项目内的模块，并避免与第三方资产发生冲突（类名可能会重复）。

注意：在代码中使用命名空间时，请按命名空间分解文件夹结构以便更好地组织。

还建议使用标准标题。在代码模板中包含标准标题有助于记录类的用途、创建日期甚至创建者；本质上，即使使用版本控制，所有这些信息也可能很容易在项目的漫长历史中丢失。

每当您在项目中创建新的 MonoBehaviour 时，Unity 都会使用脚本模板来读取。每次创建新脚本或着色器时，Unity 都会使用存储在 %EDITOR_PATH%\Data\Resources\ScriptTemplates 中的模板：

• Windows 10。C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac：/Applications/Hub/Editor/[版本]/Unity/Unity.app/Contents/Resources/ScriptTemplates

默认的 MonoBehaviour 模板 是这样的：81-C# Script-NewBehaviourScript.cs.txt

还有着色器、其他行为脚本和程序集定义的模板。

对于 项目特定的脚本模板，创建一个 Assets/ScriptTemplates 文件夹，并将脚本模板复制到此文件夹中以覆盖默认值。

您还可以直接修改所有项目的默认脚本模板，但在进行任何更改之前请确保备份原始模板。Unity每个版本都有自己的模板文件夹，因此当更新到新版本时，需要再次替换模板。下面的代码示例展示了原始 81-C# Script-NewBehaviourScript.cs.txt 文件的样子。

在下面的例子中，有两个可能有用的关键字：

• #SCRIPTNAME# 表示输入的文件名，或者默认文件名（例如，NewBehaviourScript）。
• #NOTRIM# 确保括号包含一行空格。

您可以使用自己的关键字并将其替换为编辑器脚本来实现 OnWillCreateAsset方法。

在脚本模板中使用以下脚本示例中的标题。这样，任何新脚本都会带有一个标题，其中显示其日期、创建者、以及其最初所属的项目。这对于在未来的项目中重复使用代码很有用。