贡献方式

Godot引擎是一个非盈利, 社区驱动的免费开源项目. 几乎所有的开发人员(不仅包括我们的首席开发人员Juan, 下面还有更多人员)都在 无偿 利用他们的空闲时间, 出于个人兴趣以及对创建一个质量卓越的自由引擎的热爱.

这意味着要发展壮大,Godot需要尽可能多的用户通过为引擎做出贡献而参与进来. 有许多方法可以为这样一个大项目做出贡献, 无论他们的技能是什么, 每个人都可以为引擎带来积极的一面:

  • 成为社区的一份子。为 Godot 做贡献并帮助它变得更好的最佳方式，就是使用这个引擎，并且在口头、游戏的致谢或启动界面、博客文章、教程、演示、游戏开发或开源大会等场合进行宣传，也可以在问答、论坛、贡献者聊天、Discord 等渠道帮忙回答问题。参与进来！成为用户并宣扬它，有助于宣传我们的强大引擎。它没有营销预算，因此只能一开社区使其变得更加主流。

  • 制作游戏. 为了说服新用户, 尤其是整个行业,Godot是相关市场的一个参与者, 我们需要使用Godot制作出色游戏已不是什么秘密. 我们知道该引擎在2D和3D游戏方面具有很大的潜力, 但是鉴于其年轻的年龄, 我们仍然缺乏吸引人们关注Godot的重要发行版本. 因此, 请继续从事出色的项目, 每款新游戏都会提高我们在游戏开发市场上的信誉！

  • 参与引擎的开发. 这可以通过拉取请求贡献代码, 测试开发快照或直接通过git master 分支, 在问题跟踪器上报告bug或建议改进, 改进官方文档(包括类参考和教程)及其翻译. 以下各节将介绍对引擎做贡献的所有这些 “直接” 方式.

  • 捐赠. Godot是一个非盈利项目, 但它可以从用户捐赠中受益. 除了服务器托管费用和活动宣传材料等日常开支外, 我们还会在必要时使用捐款来购买硬件(例如, 使用捐款购买一台Macbook Pro来开发Retina/HiDPI支持, 以及和macOS相关的其他功能). 最重要的是, 我们会使用捐款聘请全职开发引擎的核心开发人员. 即使月薪不高, 我们也需要稳定的捐款收入才能维持, 而目前为止, 全职开发对项目非常有益. 如果您想为该项目捐款, 请访问 我们的网站 了解详细信息.

贡献代码

学习, 使用, 修改和重新分发对引擎源代码修改的可能性是Godot的 MIT 许可授予您的基本权利, 使其成为 免费开源软件 .

因此, 每个人都有权修改 Godot 的源代码 , 并以补丁(描述预定更改的文本文件)的形式将这些修改发送回上游项目, 或者——用现代的工作流程——通过所谓的 “拉取请求”(PR), 直接请求将一个或多个Git commits(补丁)合并到主开发分支.

上游贡献代码更改有两大优势:

  • 你自己的代码将由其他开发人员审查和改进, 并将直接在上游项目中进一步维护, 因此你不必在每次迁移到新版本时重新应用自己的更改. 另一方面, 它也是一种责任, 因为你所做的更改必须足够通用才能对所有用户有益, 而不仅仅是对你的项目有益；因此, 在某些情况下, 如果更改过于具体, 则仅在你自己的项目中保留可能依然有用.

  • 整个社区都会从你的工作中受益, 其他贡献者也会以同样的方式, 贡献对你有益的代码. 在写这篇文章的时候, 已经有超过1000名开发者为引擎贡献了代码的修改!

为了确保良好的合作和整体质量,Godot的开发者对代码贡献实行一些规则, 例如关于C++代码的风格(缩进, 括号等)或Git和PR工作流程.

通过搜索 Github 中标记为 good first issue 的问题着手是个不错的办法。

参见

有关PR工作流程的技术细节在特定章节 拉取请求工作流程 中概述.

有关代码样式规范和用于实施它们的 clang-format 工具的详细信息，将在 代码风格规范 概述。

所有的拉动请求在被接受之前必须经过一个审查过程。根据修改的范围，负责引擎修改部分的维护者可能需要一些时间来提供他们的审查。我们重视所有的贡献者，并希望他们在此期间保持耐心，因为在像Godot这样的开源项目中，预计会有更多的贡献者来验证它们。

为了确保你的时间和精力不被浪费，建议在实施该想法并将其作为PR进行审查之前，先对其进行审查。为此，Godot有一个`提案系统 <https://github.com/godotengine/godot-proposals>`_ 。我们鼓励使用该系统来计划修改并与社区讨论。实施细节也可以在 Godot贡献者聊天 中与其他贡献者讨论。

备注

只有在进行增强或新功能的工作时，才需要提出建议，错误报告对于修复问题已经足够了。

测试和报告问题

对引擎做贡献的另一个好方法是测试开发版本或开发分支并报告问题. 报告在稳定版本中发现的问题也很有帮助, 这样就可以在开发分支和未来的维护版本中修复它们.

测试开发版本

为了帮助进行测试, 你有以下几种可能性:

  • 按照针对你的平台的 编译 页面中的说明, 自己从源代码编译引擎.

  • 在官方宣布预发布二进制文件时(通常在博客和其他社区平台上)测试, 如alpha,beta和候选(RC)构建版本.

  • 测试开发分支的“可信”非官方版本；请向社区成员询问可靠的提供商。尽可能使用官方的或自己编译的二进制文件，以确保二进制文件的来源可靠。

如前所述, 对于可能仍然存在于稳定版本中的潜在bug, 请务必留意, 特别是当使用引擎的某些特定功能时, 开发人员可能对其测试较少.

在GitHub上提交问题

Godot 使用 GitHub 的问题跟踪器来获取错误报告和改进建议。你需要一个 GitHub 帐户才能在那里开启新问题，然后点击 New issue（新问题）按钮。

报告错误时，请记住该过程类似于与预约医生。您注意到了症状，因而认为某些内容可能会有问题（引擎崩溃、某些功能无法正常工作等）。错误分类小组和开发人员的职责是帮助诊断您遇到的问题，以便找出并解决该错误的实际原因。

因此, 你应该始终问自己: 要提供什么相关信息, 以便其他Godot贡献者可以理解bug, 发现并希望修复该它. 以下是你应始终提供的一些最重要的信息:

  • 操作系统. 有时错误是系统特定的, 即它们仅在Windows上, 或仅在Linux上发生. 这对于与OS接口(如文件管理, 输入, 窗口管理, 音频等)相关的所有bug尤其相关.

  • 硬件. 有时错误是特定于硬件的, 即它们仅在某些处理器, 显卡等硬件上发生. 如果可以, 包含有关硬件的信息会很有帮助.

  • Godot 版本。这是必要信息。某些问题可能存在于当前稳定版本，但在开发分支中已修复，或者相反。你也可能还在使用过时的 Godot 版本，遇到了在后续版本中已经修复的已知问题，因此从一开始就知道这一点有助于加快诊断速度。

  • 如何重现 bug。在大多数情况下，bug 是可重现的，即可以通过遵循某些步骤切实地触发它们。请始终尽可能清楚地描述这些步骤，以便每个人都可以尝试重现问题并进行确认。如果条件允许，请制作一个可以立即重现此问题的演示项目，将其压缩并将其附加到问题中（你可以通过拖放操作完成此操作）。即使你认为该问题的重现方法非常简单，添加一个最小的项目来重现该问题也是很划算的。请记住，跟踪器中有成千上万的问题，开发人员专门用于处理某个问题的时间很有限。

点击 New issue 按钮时，应向你展示预先填写了我们的问题模板的文本区域。请尝试遵循它，以便所有问题保持一致并提供所需信息。

贡献文档

在 Godot 中有两个不同的资源会被称为“文档”：

  • 类参考。这是 Godot API 的完整文档，会暴露给 GDScript 和其他脚本语言。可以在离线状态下，直接在 Godot 的代码编辑器中查阅，也可以在 Godot API 在线查阅。要对类参考做出贡献，你需要编辑与类对应的 XML 文件，并创建拉取请求详情请参阅 为类参考手册贡献 和 类参考编写规范。

  • 教程和引擎文档及其翻译。这是您现在正在阅读的部分，它以 HTML 格式分发。它的内容是用 reStructured Text（rst）格式的纯文本文件生成的，您可以在 godot-docs GitHub 仓库上通过拉取请求来为其进行贡献。详情请参阅 文档规范。

贡献翻译

为了让每个人都能使用Godot, 包括那些可能更喜欢使用母语而不是英语资源的用户, 我们的社区帮助把Godot编辑器和它的文档翻译成多种语言.

详见 编辑器和文档本地化 .