组织Unity项目的最佳实践

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

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

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

虽然没有固定的文件夹结构，但以下两个部分展示了您可能如何设置 Unity 项目的示例。这些结构都是基于按资产类型拆分项目。

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

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

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

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

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

空文件夹可能会在版本控制中造成问题，因此请尽量只为您真正需要的内容创建文件夹。在 Git 和 Perforce 中，空文件夹默认情况下会被忽略。如果设置了这样的项目文件夹，并且有人尝试提交它们，实际上不会成功，直到在文件夹中放置了某些内容。

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

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

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

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

虽然 .meta 文件是自动生成的，但它包含了与之关联的文件的很多信息。这对于具有导入设置的素材是常见的，例如纹理、网格、音频剪辑等。当您更改这些文件的导入设置时，更改会写入 .meta 文件（而不是素材文件）。这就是为什么您将 .meta 文件提交到您的代码库中——以便每个人都使用相同的文件设置。

达成标准并不止于项目文件夹结构。为所有游戏素材设定特定的命名标准可以使团队在处理彼此的文件时更轻松。

尽管没有明确的 GameObjects 命名标准，但请考虑上面的表格。

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

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

最佳实践是尽可能将工作分解为 Prefabs，并利用嵌套 Prefabs 的强大功能。如果您需要稍后进行更改，可以更改 Prefab，而不是场景，以避免与其他正在处理该场景的人员发生冲突。在版本控制下进行差异比较时，Prefab 更改通常更易于阅读。

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

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

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

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

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

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

编码标准同样保持您团队的工作一致，这使得开发人员更容易在项目的不同领域之间切换。同样，这里没有固定的规则。您需要决定什么对您的团队最好——但一旦您决定了，请确保坚持下去。

作为一个例子，命名空间可以更精确地组织您的代码。它们允许您在项目内部分离模块，并避免与第三方资产的类名冲突。

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

也建议使用标准头部。在您的代码模板中包含标准头部可以帮助您记录类的目的、创建日期，甚至是谁创建的；本质上，所有可能在项目的漫长历史中轻易丢失的信息，即使在使用版本控制时。

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

• Windows:C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/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 方法。

在您的脚本模板中使用以下脚本示例中的头部。这样，任何新脚本都将创建一个显示其日期、创建者和原始所属项目的头部。这对于在未来的项目中重用代码非常有用。