我对Unity和其他（非虚幻C ++）游戏引擎非常有经验。我在基于C ++的引擎中管理了多个项目，但过去使用Unity，我在每个项目文件夹中使用了一个可交付项目。目前，我有3个几乎没有相关的多平台项目，这些项目共享相同的第三方库，一些常用代码，以及视觉资源中的一些重叠。一个是预发布游戏，另一个是客户端项目，另一个是内部原型。
目前，我将这些全部保存在同一个Unity项目中（包含Assets和ProjectSettings）。现在，为了保留构建设置，我按项目缓存这些文件：
EditorBuildSettings.asset
ProjectSettings.asset
我喜欢monorepo接近，我已经将它从单独的团队广泛用于有数十人的初创公司。当您考虑进行更改时，您可以轻松地搜索和编译它所使用的任何地方。您被迫在正确的泛化级别编写代码，并且在一个项目中修复可以使同一个仓库中的所有项目受益。但是，我不知道Unity是否喜欢这种方法。
我以前见过人们建议使用子模块，或者在Unity项目中使用符号链接目录。我在诊断具有子模块依赖性的错误方面遇到了不好的经历。我对复杂的符号链接设置持谨慎态度，因为我目前使用3台机器（一台macOS，两台Windows）来构建和测试多种类型的硬件，并且承包商偶尔会使用我的回购。
那么为我的所有建筑项目提供一个大项目文件夹的缺点是什么？我关注的两个方面是：
1）资源文件夹在出厂时可能会在项目之间不必要地共享。
2）具有意外影响的第三方库。目前，我打算用每个项目的编译标志处理这些。
答案 0 :(得分：0)
我刚才问了一个类似的问题，并没有找到满意的解决方案，所以我创建了一个名为Link & Sync的插件。我的大多数插件都是预编译的DLL，它们使用post-build命令将自己复制到Unity中心项目的Plugins文件夹中。然后，当我制作一个新游戏项目时，我可以复制插件文件夹，包括Link＆amp;同步，并使用它在游戏中的插件文件夹和中央项目之间创建链接。然后每当我在中央项目中重新编译我的一个插件时，我都可以通过按下按钮来同步更改。
Pro版本还提供了选项，可以在需要同步更改时自动通知您，或者只是自动同步更改。我倾向于坚持通知模式。它还支持双向同步，以防您想要修改游戏项目中的链接内容并将其同步回中心项，而不是每次都打开中心项。
答案 1 :(得分：0)
除了你提到的资源问题之外，需要考虑的一个方面是Unity每次重新获得焦点时都会重建你的代码库，虽然这通常比任何类型的c ++重新编译/链接快得多，但是大型项目会慢慢变得更多使用您添加的每个脚本刷新更加缓慢，因此请考虑到这一点。
然而，你已经提出了一些有效的观点，为了保持一个“上帝”项目，除了不同的构建设置（以及上述资源管理），没有任何硬性理由不使用它，如果适合你。
就资源而言，一件事情一无所获：资产/资源文件夹中的资源将始终包含在您的构建中（统一假设您将在运行时加载这些资源），但您可以保留项目特定的资源不要在运行时在Assets下的任何其他文件夹中加载 - 只有在选择用于构建的任何场景中静态引用它们时，它们才会与您的构建链接（我相信这包括在当前设置为任何场景中使用的预制件）包含在构建中） - 牢记这一点可能会削减您的资产管理工作。
我在项目之间共享了很多脚本，我对它进行排序的方式是进行脚本假装脚本是本地的，但是每个更改都有一个版本增量和一行解释前端的变化该文件（并不总是更大的文件=更新的版本）
如果我发现更改很重要，我将其复制到给定插件的repo中，如果不是，我等到当前项目不太活跃并整理来自所有活动项目的最新更改集，将这些更改传播到repo并传播它们回来（但我会在有时间的时候做，很少在中期生产以避免意外后果）。虽然这是一个严重的浪费时间，但它限制了我在尝试替代方法（即子模块）时遇到的破坏，因为从一个项目的角度来看，有时改变节点是完全合理的，可能会对使用相同代码的另一个项目产生负面影响
根据你所说的（共享一些资源的三个项目），我可能会像你现在一样把它作为一个项目。