貢献する方法

Godot Engineは、非営利のコミュニティ主導の無料のオープンソースプロジェクトです。 ほとんどすべての開発者(ただし、主任開発者のJuan、詳細は下記)は、個人的な興味から、そして非常に優れた品質のlibreエンジンを作成するために、自由時間に無償で取り組んでいます。

これは、Godotが成功するためには、エンジンに貢献して関与するためにできるだけ多くのユーザーが必要であることを意味します。 このような大きなプロジェクトに貢献するには、スキルセットに関係なく、誰もがエンジンに前向きなものをもたらすことができるようにする多くの方法があります:

  • Be part of the community. The best way to contribute to Godot and help it become ever better is simply to use the engine and promote it by word-of-mouth, in the credits or splash screen of your games, blog posts, tutorials, videos, demos, gamedev or free software events, support on the Q&A, forums, Contributors Chat, Discord, etc. Participate! Being a user and advocate helps spread the word about our great engine, which has no marketing budget and can therefore only rely on its community to become more mainstream.

  • ゲームを作りましょう。 Godotが関連するマーケットプレイヤーであることを新規ユーザー、特に業界全体に納得させるには、Godotで作成した素晴らしいゲームが必要であることは周知の事実です。 このエンジンには2Dと3Dの両方のゲームに多くの可能性があることがわかっていますが、その若さから、Godotに注目を集める大きなリリースはまだありません。 素晴らしいプロジェクトに取り組み続けてください。新しいゲームはゲーム開発市場での私たちの信頼を高めます!

  • エンジンの開発に参加してください。 これは、プルリクエストを介してコードを提供し、開発スナップショットをテストするか、git master ブランチを直接テストするか、バグを報告するか、課題追跡システム(issue tracker)の機能強化を提案するか、公式ドキュメント(クラスリファレンスとチュートリアルの両方)とその翻訳を改善することで可能です。以下のセクションでは、エンジンに貢献するこれらの「直接的な」方法のそれぞれについて説明します。

  • Donate. Godot is a non-profit project, but it can still benefit from user donations for many things. Apart from usual expenses such as hosting costs or promotional material on events, we also use donation money to acquire hardware when necessary (e.g. we used donation money to buy a MacBook Pro to implement Retina/HiDPI support and various other macOS-related features). Most importantly, we also used donation money to hire core developers so they can work full-time on the engine. Even with a low monthly wage, we need a steady donation income to continue doing this, which has been very beneficial to the project so far. So if you want to donate some money to the project, check our website for details.

コードの提供

エンジンのソースコードの変更を調査、使用、変更、および再配布が出来る可能性は、Godotの MIT ライセンスが付与する基本的な権利であり、Godotは自由なオープンソースソフトウェア になります。

As such, everyone is entitled to modify Godot's source code, and send those modifications back to the upstream project in the form of a patch (a text file describing the changes in a ready-to-apply manner) or - in the modern workflow that we use - via a so-called "pull request" (PR), i.e. a proposal to directly merge one or more Git commits (patches) into the main development branch.

コードの変更をアップストリームに提供するには、次の 2 つの大きな利点があります:

  • 独自のコードは他の開発者によってレビューおよび改善され、アップストリームプロジェクトで直接維持されるため、新しいバージョンに移行するたびに独自の変更を再適用する必要はありません。 一方、変更は、プロジェクトだけでなく、すべてのユーザーにとって有益であるように十分に汎用的である必要があるため、責任が伴います。 そのため、場合によっては、変更があまりにも具体的である場合は、自分のプロジェクトのみに変更を保持することが適切な場合があります。

  • The whole community will benefit from your work, and other contributors will behave the same way, contributing code that will be beneficial to you. At the time of this writing, more than 1000 developers have contributed code changes to the engine!

To ensure good collaboration and overall quality, the Godot developers enforce some rules for code contributions, for example regarding the style to use in the C++ code (indentation, brackets, etc.) or the Git and PR workflow.

A good place to start is by searching for issues tagged as good first issue on GitHub.

参考

PR ワークフローに関する技術的な詳細については、対応するセクションで概説されています プルリクエスト・ワークフロー。

コードスタイルガイドラインと、それらを適用するために使用される clang-format ツールの詳細については、コードスタイルガイドラインで説明されています。

All pull requests must go through a review process before being accepted. Depending on the scope of the changes, it may take some time for a maintainer responsible for the modified part of the engine to provide their review. We value all of our contributors and ask them to be patient in the meantime, as it is expected that in an open source project like Godot, there is going to be way more contributions than people validating them.

To make sure that your time and efforts aren't wasted, it is recommended to vet the idea first before implementing it and putting it for a review as a PR. To that end, Godot has a proposal system. Its usage is encouraged to plan changes and discuss them with the community. Implementation details can also be discussed with other contributors on the Godot Contributors Chat.

注釈

Proposals are only required when working on an enhancement or a new feature. Bug reports are sufficient for fixing issues.

テストとレポートの問題

エンジンに貢献するもう1つの優れた方法は、開発リリースまたは開発ブランチをテストし、問題を報告することです。また、安定したリリースで発見された問題を報告して、開発ブランチや将来のメンテナンスリリースで修正できるようにすることも役立ちます。

開発バージョンのテスト

テストを支援するために、いくつかの可能性があります:

  • プラットフォームのコンパイルページの指示に従って、ソースからエンジンを自分でコンパイルします。

  • アルファ版、ベータ版、リリース候補(RC)ビルドなど、公式のプレリリースバイナリを(通常はブログや他のコミュニティプラットフォームで)発表されたらテストします。

  • 開発ブランチの「信頼できる」非公式ビルドをテストします。 信頼できるプロバイダーをコミュニティメンバーに尋ねてください。 可能な限り、公式のバイナリを使用するか、自分でコンパイルして、バイナリの出所を確認するのが最善です。

前述のように、特に開発者によるテストが少なくなる可能性のあるエンジンのニッチな機能を使用する場合は、安定したリリースにまだ存在する可能性のあるバグに目を離さないようにしておくと便利です。

GitHubで問題を提起する

Godot uses GitHub's issue tracker for bug reports and enhancement suggestions. You will need a GitHub account to be able to open a new issue there, and click on the New issue button.

バグを報告する場合、プロセスは医師との約束に似ていることに留意する必要があります。何かが間違っている可能性があると思わせる*症状*に気づきました(エンジンがクラッシュしたり、一部の機能が期待どおりに動作しないなど)というようにです。バグの実際の原因を特定して対処できるように、遭遇した問題の診断を支援するのはバグトリアージングチームと開発者の役割です。

したがって、他のGodotの貢献者がバグを理解し、バグを特定し、うまくいけば修正できるように、関連する情報は何かを常に自問する必要があります。常に提供する必要がある最も重要な情報の一部を次に指定します:

  • オペレーティングシステム バグはシステム固有の場合があります。これは、ファイル管理、入力、ウィンドウ管理、オーディオなど、OS インターフェイスに関連するすべてのバグに特に関連します。

  • ハードウェア バグはハードウェア固有の場合があります。可能な場合は、ハードウェアに関する情報を含めるのが役立ちます。

  • Godot version. This is a must-have. Some issues might be relevant in the current stable release, but fixed in the development branch, or the other way around. You might also be using an obsolete version of Godot and experiencing a known issue fixed in a later version, so knowing this from the start helps to speed up the diagnosis.

  • How to reproduce the bug. In the majority of cases, bugs are reproducible, i.e. it is possible to trigger them reliably by following some steps. Please always describe those steps as clearly as possible, so that everyone can try to reproduce the issue and confirm it. Ideally, make a demo project that reproduces this issue out of the box, zip it and attach it to the issue (you can do this by drag and drop). Even if you think that the issue is trivial to reproduce, adding a minimal project that lets everyone reproduce it is a big added value. You have to keep in mind that there are thousands of issues in the tracker, and developers can only dedicate little time to each issue.

When you click the New issue button, you should be presented with a text area prefilled with our issue template. Please try to follow it so that all issues are consistent and provide the required information.

ドキュメントへの貢献

Godotには、「ドキュメント」と呼ばれる2つの別個のリソースがあります:

  • The class reference. This is the documentation for the complete Godot API as exposed to GDScript and the other scripting languages. It can be consulted offline, directly in Godot's code editor, or online at Godot API. To contribute to the class reference, you have to edit the XML file corresponding to the class and make a pull request. See Contributing to the class reference and Class reference writing guidelines for more details.

  • The tutorials and engine documentation and its translations. This is the part you are reading now, which is distributed in the HTML format. Its contents are generated from plain text files in the reStructured Text (rst) format, to which you can contribute via pull requests on the godot-docs GitHub repository. See ドキュメントへの貢献 for more details.

Contributing translations

To make Godot accessible to everyone, including users who may prefer resources in their native language instead of English, our community helps translate both the Godot editor and its documentation in many languages.

See Editor and docs localization for more details.