Unity 项目结构/云构建/Github 操作

Unity Project Structure / Cloud Build / Github Action

我目前正在处理多个共享大量预制件、脚本等的 Unity 项目。 这些或多或少是具有相同基础的多个“迷你游戏”。 我目前正在一个网站上通过 WebGL 展示这些游戏,该网站从我将文件上传到的 Azure Blob 存储请求数据文件(wasm、数据等)。 此上传是通过我为团队中的各种开发人员设置的单独页面进行的。 问题如下:

出于这些考虑,我想将此过程自动化。到目前为止,我的想法是使用 Unity Cloud Build(因为我们已经拥有 Unity plus 和 Teams advanced)或使用 Github Actions 并通过 Git 存储库对其进行源代码控制。

我对这两个选项的问题是:

我遇到的最后一个问题是,正如开头所说,所有“游戏”都在同一个 Unity 项目中,以便更容易和更快地开发下一个游戏(每周)并使用源代码控制我不想每次都构建所有游戏,而是 select 我想构建哪个游戏(云构建/github 操作)。

所以我的问题特别是:

也许有更多经验的人可以帮助我!

干杯

Is Cloud Build / Github Action feasible for my needs

是的,Cloud Build 在这里绝对是一个不错的选择。您也可以使用 Unity 的版本控制(Plastic SCM) to make it easier to work together, you can set triggers on Plastic SCM (after merge/before merge/after code review...etc..) or if you still prefer Github you can still Github actions。如果您想要自动构建(无需通过 Unity 的仪表板手动启动它,您可以在构建配置中将自动构建选项设置为 true,这将在存储库时启动云构建已更新或您选择要构建的分支。

如果您查看下面的选项,您会发现有很多自动化选项。

How would I control which games to build and deploy and which not (I thought of a triggered build on master/main branch commit and then checking which files have changed and getting the according "game" for those files)

你可以有多个分支,每个分支代表一个小游戏。您可以在特定分支上触发云构建。 例如,这是我及时设置的与 Plastic SCM 相关联的 Cloud Build 的基本配置。你可以看到选项“分支”,在我的例子中我使用了一个名为 QA 的分支,但你可以使用 minigame1 或任何游戏名称。

How much faster / slower would a cloud build solution be compared to a local building option (The devs have quite the machines (i7-10xxx, i9-11xxx + rtx 30xx and m.2 ssds)

这个不能这么定,要看你的游戏有多大。您可以选择是要干净构建还是正常构建,显然干净构建会花费更多时间,因为它将清除所有本地 files/cache.

如果您对如何设置有任何疑问,请告诉我,根据您所说的内容,我假设您知道如何设置,只是询问可能的设置。

参考资料: Using GitHub with Unity Cloud Build Plastic SCM Cloud build