对游戏引擎开辟者和保护职员来讲，货分若何高效、享开便利、源软低本钱地停止引擎保护，擎开让引擎能够也许也许也许也许也许也许获得疾速优化和功效更新，发中并使其构建体系能够也许也许也许也许也许也许兼容多个开辟平台和东西，货分是享开一个亘古稳定的困难。

在GDC2023中，源软来自网易游戏《星战前夕：无烬银河（EVE Echoes）》团队的擎开引擎法式师KK分享了他们是若何借助开源软件，对自研引擎NeoX做和游戏开辟适配的发中针对性优化，并获得杰出成果的货分。

以下为报告摘选（按照英文报告翻译清算）：

大师好，享开明天我分享的源软主题是《开源软件在引擎开辟中的赞助》。本次分享分为两局部，擎开第一局部是发中若何操纵开源软件来优化传统引擎；此中的首要内容是咱们若何将引擎迁徙至开源构建体系 Bazel。操纵Bazel，咱们明显削减了构建时候，晋升了开辟效力。

第二局部，我还会分享咱们在这进程中学到的若何更好的与开源社区协作的履历。

经由进程此次分享，我但愿能向你们展现开源东西长短常壮大的。它们能够也许也许也许也许也许也许极大的晋升游戏引擎的开辟效力。更首要的是，在一些情况下，开源软件几近是不可或缺的。由于开源的特征使得咱们能够也许也许也许也许也许对东西本身停止点窜，从而知足咱们在游戏开辟中碰着的特别而庞杂的须要。

先先容下背景，我来自《星战前夕：无烬银河（EVE Echoes）》团队。这是一款科幻背景太空游戏，由网易和 CCP Games 协作研发，游戏开辟用的是网易的自研引擎NeoX。网易旗下多个爆款游戏也操纵了NeoX 引擎开辟，如《嫡以后》《第五品德》等等。NeoX引擎在网易有着悠长而胜利的汗青，可是就像良多其余具有着较长汗青的代码堆栈一样，NeoX也不免背负着一些“手艺债”。游戏行业手艺日月牙异，为了与时俱进，星战前夕团队自客岁起头逐步的更新迭代引擎。


一、为甚么操纵开源软件Bazel来优化传统引擎

起首，咱们要做的便是优化构建时候。

NeoX 是一个功效丰硕的跨平台游戏开辟引擎，但随之而来的是绝对较长的构建时候。举例来讲，在装备六核 Core i7 处置器的 Windows 上，咱们引擎的完整构建时候为 27 分钟。而在 4 核 Core i7的Macbook Pro 上编译iOS版本时则是 24分钟。安卓平台的构建时候也差未几。若是咱们更新一些与衬着相干的代码，增量构建时候约为 14 分钟。

设想一下，一个简略的衬着器变动须要 14 分钟能力看到成果，这极大地影响着咱们的开辟效力。是以，在大范围重构代码之前，咱们但愿起首优化构建时候。

和庞杂的引擎比拟，《星战前夕：无烬银河》具有一个绝对较小的开辟团队，咱们不自力的子团队来担任差别的方针平台，是以咱们但愿新的构建体系能够也许也许也许也许也许也许在一切的平台上使命。

面对的挑衅

以下是咱们所面对的挑衅。《星战前夕: 无烬银河》的首要方针平台是 iOS 和Android，同时咱们的主力开辟平台为Windows；由于 EVE Echoes是一款 MMORPG游戏，咱们还须要在办事器端，也便是Linux平台上，编译局部引擎代码，比方焦点的战役逻辑。也便是说，咱们有 iOS 、Android、Windows、Linux四个差别的方针平台。

为了构建iOS操纵，咱们须要操纵macOS体系，这也是咱们的首要安卓构建平台。加上Windows和Linux，咱们有三个差别的host平台。

游戏开辟经常长短常庞杂的，是以咱们须要Xcode、Android Studio和Visual Studio等集成开辟情况供给的调试和阐发东西，是以新的构建体系须要能够也许也许也许也许也许也许与各类集成开辟情况（IDE）停止集成，其天生的二进制文件必须能够也许也许也许也许也许在这些IDE 中停止调试和机能阐发。

编程说话方面，咱们首要操纵了C++，引擎操纵了局部java代码用于与Android体系交互。一样，咱们也有用于iOS集成的 Objective C代码。


咱们须要一个新的构建体系，能够也许也许也许也许也许也许兼容三个操纵体系、面向四个方针平台构建咱们的引擎，能够也许也许也许也许也许也许与多种IDE集成，并撑持咱们操纵的三种编程说话。

最首要的是，构建体系须要能够也许也许也许也许也许也许撑持长途缓存或长途履行，从而削减构建时候。斟酌到上面的一切条件，这仿佛是一个不能够也许也许也许实现的使命。

开源构建东西 Bazel

但颠末一番研讨以后，咱们发了然由Google 开源的构建体系 Bazel。Bazel网站首页上写着：构建和测试 Java、C++、Android、iOS、Go 和其余各类说话平台，能够也许也许也许也许也许在Windows、macOS 和Linux 上运转。这个东西几近就像是为咱们量身定做的。


现实上也是如斯，借助Bazel的长途缓存，咱们胜利地将 Windows 平台的完整构建时候从 27 分钟降到 4 分钟。由于更快的SSD， iOS 和 Android 的完整构建时候乃至能够也许也许也许也许也许进一步延长到了 2.5 分钟，这对咱们的延续集成使命（CI jobs) 有着明显赞助。另外，长途履行能够也许也许也许也许也许有用地削减增量构建时候，一样以对render的点窜为例，面向iOS平台的构建时候从 14 分钟削减到了4 分钟。值得一提的是，这个构建是由3台mac mini所构成的“编译集群”实现的。若是咱们向这个“集群”中增加更多的装备，咱们还能进一步进步增量构建的效力。

另外一方面，斟酌到如斯庞杂的操纵场景，你能够也许也许也许也许也许设想到，再优异的开源东西都很难做到间接开箱即用，是以，在接上去的分享中，我将先容咱们迁徙至Bazel的完整路程。

二、若何将引擎迁徙至开源软件 Bazel

在此之前，让我扼要先容一下 Bazel 的使命道理。

Bazel 的使命道理

在 Bazel 名目中，咱们操纵名为 BUILD 或BUILD.Bazel 的文件来描写构建方针。


这是一个用于构建一个小型数学库的构建文件。

cc_library表现这是一个C或C++库的构建方针。

咱们将其名字设置为“math”，其余构建方针若是想要链接这个库，能够也许也许也许也许也许经由进程在其deps属性增加这个“math”库。

hdrs属性包罗一切的头文件。

srcs属性包罗一切的源码文件。

这个“math” 库本身也有一个依靠，也便是“portable”，用于处置跨平台开辟逻辑。


大局部人更熟习CMake，这是与之对应的CMakeList.txt文件，大师能够也许也许也许也许也许将其和Bazel的BUILD文件停止对照。

BUILD 文件操纵的说话为一种Python方言：Starlark 。Bazel 的构建文件的怪异的处所在于它是申明式的，咱们不能在BUILD文件中操纵号令式号令。

Bazel如许设想首要是为了保障构建的“可反复性”，即对不异的输出，一直会获得不异的输出成果。这是Bazel能够也许也许也许也许也许也许准确缓存你的构建成果的一个首要条件。比方，若是构建进程依靠于 “date” 号令，即便操纵不异的输出文件，每次构建的成果也会差别，而如许 Bazel 就没法为你缓存成果。


Bazel 的另外一个怪异功效是 Sandbox 机制。为了诠释这一点，假定咱们的名目中有多个容器的实现。咱们界说了两个 cc_library，一个是 hashmap， 一个是 set。咱们对它们别离界说，以便能够也许也许也许也许也许最大限制地削减增量构建时候。


在编译 hashmap 时，Bazel 不会间接在源目次下停止编译，而是先成立一个 sandbox 目次，将 hashmap 头文件和源文件链接到该目次，而后在 sandbox 目次下停止编译。

这么做能够也许也许也许也许也许避免代码不测include未列出的头文件，对准确的增量构建很是首要，特别是在触及长途缓存时。

比方，若是咱们不谨慎在了hashmap.cpp中include了set.h，并操纵了此中的一些函数，在有sandbox机制的情况下，编译会失利由于在sandbox中找不到set.h。若是不sandbox机制则编译会胜利，但当将来set.h停止更新时，构建体系不晓得hashmap须要被从头编译，从而能够也许也许也许致使毛病的构建成果。

以上便是咱们今朝所须要领会的对 Bazel 的信息。

构建体系迁徙到 Bazel

以下是咱们将构建体系迁徙到 Bazel 的打算。

• 起首，咱们成立一切的构建文件，以便能够也许也许也许也许也许操纵 Bazel 构建咱们的引擎。
• 接着测验考试将 Bazel 与咱们正在操纵的一切三个集成开辟情况集成。
• 最初，搭建长途办事器用于长途缓存和履行。
  

在操纵 Bazel 之前，咱们操纵 CMake 天生原生的 Visual Studio、Xcode 和Android Studio工程来构建咱们的引擎。咱们首要操纵 Conan 来办理第三方库依靠。咱们的方针是在不影响开辟进度的情况下，将构建体系从 CMake 无缝迁徙到 Bazel。


咱们从依靠树的底层节点起头。下图是咱们引擎外部依靠树的简化版本。顶部是名为 client 的可履行方针。它依靠于其余库，如“world”和“render”。

在依靠树的底部是通用的utility lib （通用东西库）和 portable lib （可移植库）。由于它们不更多的外部依靠项，以是能够也许也许也许也许也许轻松的在 Bazel 中构建。


咱们先编写portable的构建文件并操纵Bazel对其停止编译。


在咱们操纵 Bazel 胜利构建 portable 以后，咱们须要许可CMake 名目中的其余方针能够也许也许也许也许也许也许链接它。

这里要用到 CMake 的"IMPORTED" 库。咱们能够也许也许也许也许也许在 CMake 名目中导入 Bazel 天生的二进制文件。如许一来，CMake 名目中的其余库便能够也许也许也许也许也许链接到它。

咱们还但愿在 CMake 名目中主动触发 Bazel 构建。在这里咱们操纵add_custom_target，即界说一个自界说方针，当这个方针被构建时会触发bazel build号令来触发 Bazel 构建。咱们设置IMPORTED库portable依靠于这个自界说方针portable_bazel_build，如许每当咱们须要import portable时，相干的bazel构建号令就会被履行。


此刻咱们能够也许也许也许也许也许在 Bazel 中构建 “Portable” 并胜利链接到 CMake 名目中。咱们须要做的便是自下而上反复这个进程，直到全部引擎都能够也许也许也许也许也许操纵Bazel停止编译。


迁徙流程表示图

在现实中，咱们碰着的第一个题目现实上是来自 Conan ，而不是 Bazel 本身。

操纵Bazel构建时，咱们一样须要第三方依靠。现实上咱们能够也许也许也许也许也许操纵Bazel间接从源码编译一切的第三方依靠办理， Bazel也很是合适这类形式。可是咱们不太多时候为咱们一切的依靠项编写 Bazel 构建文件。另外，NeoX 引擎团队已在操纵 Conan 办理一切第三方依靠项和进级了，咱们不但愿破费额定的时候零丁保护第三方依靠，是以咱们须要实现 Bazel 和 Conan 的集成。


幸亏 Conan 供给了 Bazel 的构建天生器（Conan Bazel Generator）。和 CMake一样，Bazel也撑持操纵cc_import 导入预编译的lib。


Conan 的 Bazel 构建天生器使命道理是如许的。起首其从 Conan 设置装备摆设文件中读取一切依靠项。接着从办事器下载一切须要的库，并将它们保管在磁盘上。而后天生器会为一切的第三方库主动天生对应的BUILD文件。如许你便能够也许也许也许也许也许在Bazel工程中操纵它们了。


可怜的是 Bazel 构建天生器在那时还处于实验阶段，没法为咱们的某些依靠准确天生BUILD文件。

若是 Conan 不是开源软件，咱们就须要软件供给商来处置这个题目。斟酌到同时操纵 Conan 和 Bazel 并不是一个罕见的须要，咱们能够也许也许也许须要期待很长一段时候这个题目能力被处置，或底子不会被修复。即便是在最好的情况下，咱们的全部迁徙进度也会遭到影响。

幸亏 Conan 是一个开源东西，以是咱们能够也许也许也许也许也许自行修复 bug。

比方，咱们碰着的此中一个详细题目是，在导入 DLL 库时，咱们须要设置另外一个名为“interface_library”的属性。


增加起来其实很轻易，以是咱们为此成立了一个归并要求（Pull Request，下文简称PR)。

咱们还修复了另外一个lib 文件途径剖析相干的题目。

在修复了 Bazel 构建天生器以后，迁徙使命停顿顺遂。咱们碰着的大大都题目都与引擎本身有关。两个月后，咱们获得了第一个完整操纵 Bazel 构建的引擎。

将 Bazel 集成到集成开辟情况

此刻咱们须要将 Bazel 集成到集成开辟情况中。

针对 Visual Studio名目，咱们操纵了开源东西 Lavender 。Lavender 会天生一个包罗一切源文件和编译器参数的 Visual Studio 名目。但构建现实上是经由进程挪用 Bazel 号令实现的。这是 Lavender 天生的 Visual Studio 名目文件。名目依然是用 Bazel 构建的，可是 Visual Studio 能够也许也许也许也许也许也许准确获得源代码和天生的库的地位，便能够也许也许也许也许也许对库停止debug和阐发。


咱们还供给了一切预处置器界说和头文件搜刮途径，使得 Code Intelligence 能够也许也许也许也许也许一般使命。


可怜的是，Lavender 已不再保护，并且还存在一些 bug。比方在某些情况下，Code Intelligence 会没法一般使命。不过分享停止到这里，我信任有的观众能够也许也许也许已猜到了，由于 Lavender 是开源的，咱们能够也许也许也许也许也许本身修复这些 bug。

现实上，对Code Intelligence的bug原堆栈已有一个PR。以是咱们成立了一个 fork （小我名目分支） ，归并了对应分支的内容。另外，咱们还停止了一些细小更新，比方按照 Bazel 名目条理布局，在 Visual Studio 中响应构造文件夹布局。颠末点窜后，咱们处置了 Lavender 的题目。这是 Lavender 天生的 Visual Studio 名目。


对Xcode 名目也有近似的东西，叫做 Tulsi。它的使命道理和 Lavender近似。在Tulsi天生的 Xcode 工程中，编译仿照照旧是经由进程 Bazel 实现的。值得一提的是Tulsi比来被另外一个更壮大的东西rules_xcodeproj替代了，不过咱们今朝依然在操纵Tulsi。

咱们在 Xcode 上碰着的独一题目是对长途编译库的调试。这个我在讲到长途履行时，会详细会商。

Bazel 在 Android Studio 中的使命体例略有差别。谷歌和 IntelliJ 协作保护一个开源的 IntelliJ Bazel 插件。这个插件许可咱们在一切 IntelliJ 集成开辟情况中导入 Bazel 名目，包含 Android Studio。使命道理简略间接。

咱们也碰着了和Xcode近似的长途编译库调试题目，并用近似体例处置了。

长途缓存和履行

此刻，咱们已能够也许也许也许也许也许在 Bazel 中构建引擎并操纵集成情况对其停止调试。最初一个要切磋的题目是长途缓存和履行。

对长途缓存和长途履行，我感觉 Bazel 的开源战略是很伶俐的。谷歌不间接开源一个Bazel远端办事器，我以为这是由于谷歌外部操纵的Bazel办事器操纵了大批谷歌外部的根本架构，是以很难间接开源。即便谷歌做到了，这个办事器对绝大局部Bazel用户来讲也太庞杂了。

谷歌的战略是开源长途 API。Bazel 操纵此 API 与长途办事器通讯来实现长途缓存和履行。每小我都能够也许也许也许也许也许操纵此 API 成立本身的长途办事器。

我小我以为这是一个很是胜利的战略，今朝已有良多长途办事器实现了，并且良多都是开源的。当咱们测验考试给名目增加长途缓存时，只用了很短的时候内就胜利操纵 bazel-remote 搭建了一个仅缓存办事器。

另外一方面，别的的构建体系也都起头操纵 Bazel 长途 API，也就象征着这些构建体系都能够也许也许也许也许也许操纵长途 API 与肆意这些长途办事器停止对话。


Bazel 的长途 API 很是简练。API 和谈基于 gRPC，文档也很是详细。现实上我须要删除大批正文能力做成上面的截图。


Bazel 长途API 今朝首要供给的办事包含：用于接管履行要求的履行办事（Execution)，用于存储构建操纵成果的缓存办事（action) 。请注重，它不存储构建天生的现实输出文件（artifacts），只是保管对它们的援用。

输出文件和输出文件一路存储在内容可寻址存储（Content-addressable storage  (CAS) ）中。


每一个文件都经由进程择要（digest）来援用。择要由文件的哈希值和文件巨细（以字节为单位）构成。


若是设置了长途办事器，在测验考试构建方针时，Bazel 客户端（Client) 会先扣问操纵缓存办事（Action Cache Service） 是不是已有缓存。若是有，Bazel 客户端会按照缓存中的文件援用，测验考试从内容可寻址存储中下载缓存的成果。若是缓存丧失或下载失利，Bazel 客户端会将一切输出文件上传到内容可寻址存储中，而后要求长途履行构建方针。


履行办事将从内容可寻址存储中获得一切输出文件，履行构建号令，再将一切天生的成果上传到内容可寻址存储，将操纵成果上传到操纵缓存办事办事，而后将成果前往给 Bazel 客户端。

最初，Bazel 客户端在内容可寻址存储下载一切输出文件。

长途办事器也能够也许也许也许也许也许挑选只实现 ActionCache 办事和 ContentAddressCache 办事，咱们就会获得一个只供给缓存功效的办事器，这类情况下，由 Bazel 客户端担任构建方针并上传成果。

正如我后面提到的，咱们在很是短的时候内就实现了缓存办事器的安排。咱们用的是 bazel-remote，是用 Go 说话编写的缓存办事器。

经由进程操纵长途缓存，构建进程中的大局部时候能够也许也许也许也许也许被节流上去，特别是争对延续集成的主动化使命。比方咱们的 clang-tidy 均匀查抄时候从约莫 40 分钟延长到 7 分钟。但咱们依然但愿经由进程长途履行，进一步削减增量构建时候。

长途履行的安排要更庞杂一些。对缓存，咱们只须要一个办事器来供给构建时代天生的一切输出成果，并不在意这些要求履行在甚么样的平台上。

对长途履行，咱们则必须须要存眷这些操纵地点的履行平台。咱们须要在差别的平台上操纵长途使命器（remote workers）来履行这些操纵（actions），这也就象征着，咱们须要一个能够也许也许也许也许也许同时撑持 MacOS、Windows 和 Linux 的长途办事器。

大大都 Bazel 用户都来自互联网行业，而 Linux 是今朝互联网开辟情况中最常用的体系。是以，今朝大大都长途办事器都撑持 Linux。由于 MacOS 平台也经常用于构建 IOS 操纵法式，是以有的长途办事器也撑持 MacOS 。但对 Window 平台，咱们就不那末荣幸了。Bazel 在 Windows 上的操纵绝对未几，长途履行则被操纵得更少了。


咱们测验考试了操纵 Buildbarn，一个用 Go 说话编写的开源长途办事器。

Buildbarn 的一个长处是，它能够也许也许也许也许也许撑持多品种型的使命器。它在 Linux 上操纵基于 FUSE（Filesystem in Userspace） 的使命器，在 MacOS 上则是基于  NFSv4（Network File System version 4）的使命器。二者都操纵的是假造文件体系（VFS）。

基于VFS的使命器都有一个很大的上风：只抓取编译现实须要读取的源文件。这是甚么意义呢？假定咱们有如许一个数学库，另有一个名为“render.cpp”的编译单位，这个编译单位对数学库有依靠，但它只须要include matrix.h。当咱们操纵基于假造文件体系的长途使命器时，望文生义，使命器会为该编译举措天生一个假造文件体系，现实上不会从内容可寻址存储中下载任何文件。只要在编译器须要真正翻开文件时，VFS 才会从内容可寻址贮存中（ Content-addressable storage ）获得对应文件。

如许一来，长途履行使命器能够也许也许也许也许也许大大削减设置编译操纵的一切输出文件所需的时候。若是不 VFS，履行编译操纵的使命器须要获得一切能够也许也许也许被用作源代码的文件。这也便是Buildbarn 撑持的第三种使命器：本地使命器（native worker）。可是当处置像 NeoX 如许的大型工程时，每一个编译操纵都须要破费大批时候来下载一切的输出文件，长途办事器计划就不太现实了。

可怜的是，Buildbarn 在 Windows 上并不基于VFS的使命器。Windows本身有一个很不错的 VFS API 叫 ProjFS。微软用其实现了GitVFS 。但由于 Windows 不是 Web 行业开辟中最常用的构建情况，是以Buildbarn 在 Windows 上不响应的可用实现。

荣幸的是，Buildbarn 是个开源东西。由于它撑持多种使命器，它有一个很是简练了然的 API，用于使命器和使命调剂器之间的交互。正如长途 API 一样，这个API 也是基于 gRPC 和谈，并且有很是标准的文档。它只要 210 行 Protobuf 编码、一个Service、一个长途挪用和谈（RPC）、和四个信息界说（message）。这象征着咱们能够也许也许也许也许也许本身搭建一个自界说的使命器。


今朝市道上存在撑持 Windows 的贸易化长途构建办事，咱们也信任它们能够也许也许也许也许也许供给很好的办事，可是到这个阶段，咱们更偏向于操纵开源软件，由于咱们能够也许也许也许也许也许点窜开源软件，知足咱们的任何须要。是以咱们决议构建本身的Windows使命器。

咱们外部经常用 Python 编程，以是这个使命器也是用 Python 构建的。咱们的初版使命器并不实现 VFS，而是进修了另外一个Bazel办事器Buildfarm对输出目次停止缓存，如许就不必每次都从头下载全部输出树（tree）了。咱们最初用 2840 行 Python 代码搭建了一个使命器，不包含正文、空行、和测试。固然这个计划还不够完善。究竟结果在初次构建名目时，仍是须要破费一些时候来获得大批源文件的。可是，操纵这个使命器来加速构建对咱们来讲完整充足了。

若是你们感乐趣的话，能够也许也许也许也许也许看看这个堆栈：//github.com/kkpattern/bb-remote-execution-py

三、对开源东西

咱们正在操纵更多的开源东西来帮咱们开辟引擎。

比方，咱们操纵 clang-format 来主动格局化引擎代码；操纵AddressSanitizer（ASan）来检测内存拜候毛病。这两个东西都来自LLVM。咱们的大局部的延续集成管线都是在Kubernetes 集群运转的。咱们也大批操纵 Jenkins 停止延续集成。咱们有良多外部办事都是用 FastAPI 构建的。

本次分享的重点，并不是为了先容某个特定的开源软件，由于差别名目的须要差别，须要的东西也差别。咱们更想经由进程分享咱们的名目履历，向大师展现开源软件对游戏开辟的赞助，并情愿去测验考试操纵开源软件。

在我打仗这个名目之前，咱们在和开源社区协作方面并不太多履历。固然咱们操纵了良多开源库和开源东西，但咱们之前并未更多的到场到开源社区当中。在此次履历中，咱们也学到了良多若何跟开源社区彼此协作的履历，以是咱们想跟大师分享一下，但愿能够也许也许也许也许也许赞助大师更好地融入开源社区。

敢于发问。常言道“不笨拙的题目，只要笨拙的谜底。”须要别人为本身解答迷惑是再一般不过的使命。良多开源软件都有特地面向新人的邮件列表或slack频道等，若是你对一个开源软件有任何题目都能够也许也许也许也许也许安心的在这些处所停止发问。

题目不很快获得答复长短常罕见的，这不代表社区不接待你。良多人都是抽出本身使命以外的时候来扶植开源社区，他们能够也许也许也许不充足的时候实时的回覆你的题目，这长短常一般的。若是你的一个题目不获得谜底，请不要泄气，同时在你有了新的题目时也不要踌躇。

不要错过任何摸索开源东西的机遇，良多开源软件能够也许也许也许没法完善的知足你的须要，或没法做到开箱即用。但开源象征着你能够也许也许也许也许也许随时更新点窜东西以知足你的须要。是以，当一个东西没法知足的你的须要时，没关系多看看他的源码和实现，也许你能为他增加新的功效。

最初，在修复了毛病或实现新功效后，记得也要为社区做出回馈，现实上这么做对你本身也是大有好处的。很多开源东西都在不时更新，某些更新能够也许也许也许会粉碎你所增加的新功效。若是你将该功效进献回开源社区，增加上一些单位测试（Unit test），就会大大削减该功效在将来的更新中被粉碎的机率。不管若何，为开源社区进献资本老是一件功德。当你成立了基于某个名目的 fork，开辟了不错的新功效，请尽能够测验考试将该功效回馈给社区。

和你的题目一样，你提交的PR能够也许也许也许也没法被实时review和合入。一样不要泄气。若是你其实没法将代码公然到开源社区，能够也许也许也许也许也许试着在名目内成立一个管线，按期（如天天）抓取最新的下游代码，并将它归并到你的外部 fork 里，而后履行这个管线，看看是不是能经由进程你的外部测试。如许一来，若是下游代码的更新致使你的代码没法运转，就能够够立即晓得。你乃至能够也许也许也许也许也许操纵“git bisect”之类的东西来找出详细是哪些代码的变革致使代码没法运转。而后你能够也许也许也许也许也许实时向下游名目反应你的题目，如许他们就能够够鄙人一个版本之前停止修复。如许做有益于你的 fork 在将来的更新。

以上便是明天分享的内容。但愿本次分享能够也许也许也许也许也许让大师感遭到开源东西的壮大，并领会到它们对使命流起到的关头感化。你能够也许也许也许也许也许经由进程点窜开源东西，来知足各类百般的特别须要。若是你已在操纵一些开源东西，记得要多在社区内互动，多题目目和成立 Pull Request 。在开源东西变得愈来愈壮大的同时，让你的名目也不时优化。

在分享的最初，我想感激全部《星战前夕：无烬银河》团队，感激他们在全部路程中的耐烦、撑持和倡议。

我还想感激 NeoX 引擎团队为咱们供给的可贵倡议。

最初，我还要感激开源社区。不这些了不得的开源社区，咱们也没法实现这项艰难的使命。

相干浏览：

【GDC2023干货分享】挪动平台上的软光栅遮挡剔除计划
【GDC2023干货分享】立异的用户获得形式——直播引流摸索


原文：//mp.weixin.qq.com/s/L1oEZhCWeIUpIAwh7YHVLA