貢献する方法

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

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

  • コミュニティの一員になりましょう。 Godotに貢献し、これを改善するための最善の方法は、単にエンジンを使用して、口コミ、ゲーム、ブログ投稿、チュートリアル、ビデオ、デモ、gamedevのクレジットまたはスプラッシュ画面で宣伝することです フリーソフトウェアイベント、Q&A、IRC、フォーラム、Discordなどのサポート。参加してください!ユーザーであり、支持者であることは、マーケティング予算がなく、そのため、より主流になるためにコミュニティに頼ることしかできない私たちの素晴らしいエンジンについての評判を広めるのに役立ちます。
  • ゲームを作りましょう。 Godotが関連するマーケットプレイヤーであることを新規ユーザー、特に業界全体に納得させるには、Godotで作成した素晴らしいゲームが必要であることは周知の事実です。 このエンジンには2Dと3Dの両方のゲームに多くの可能性があることがわかっていますが、その若さから、Godotに注目を集める大きなリリースはまだありません。 素晴らしいプロジェクトに取り組み続けてください。新しいゲームはゲーム開発市場での私たちの信頼を高めます!
  • Get involved in the engine's development. This can be by contributing code via pull requests, testing the development snapshots or directly the git master branch, report bugs or suggest enhancements on the issue tracker, improve the official documentation (both the class reference and tutorials) and its translations. The following sections will cover each of those "direct" ways of contributing to the engine.
  • 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.

コードの提供

The possibility to study, use, modify and redistribute modifications of the engine's source code are the fundamental rights that Godot's MIT license grants you, making it free and open source software.

そのため、誰もがGodotのソースコードを変更し、パッチ(すぐに適用できる方法で変更を説明するテキストファイル)の形で上流のプロジェクトにそれらの変更を送り返す権利があります。 いわゆる「プルリクエスト」(PR)、つまり、1つ以上のgitコミット(パッチ)をメイン開発ブランチに直接マージする提案を使用します。

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

  • 独自のコードは他の開発者によってレビューおよび改善され、アップストリームプロジェクトで直接維持されるため、新しいバージョンに移行するたびに独自の変更を再適用する必要はありません。 一方、変更は、プロジェクトだけでなく、すべてのユーザーにとって有益であるように十分に汎用的である必要があるため、責任が伴います。 そのため、場合によっては、変更があまりにも具体的である場合は、自分のプロジェクトのみに変更を保持することが適切な場合があります。
  • コミュニティ全体があなたの仕事の恩恵を受け、他の貢献者も同じように振る舞い、あなたに有益なコードを提供します。この執筆時点では、300人以上の開発者がエンジンにコード変更を投稿しています!

優れたコラボレーションと全体的な品質を確保するために、Godot開発者は、C++コード(インデント、括弧など)やgitおよびPRワークフローで使用するスタイルなど、コードの貢献に関するいくつかのルールを適用します。

A good place to start is by searching for issues tagged as junior jobs (or Hacktoberfest during October) on GitHub.

参考

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

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

テストとレポートの問題

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

開発バージョンのテスト

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

  • プラットフォームのコンパイルページの指示に従って、ソースからエンジンを自分でコンパイルします。
  • Test official pre-release binaries when they are announced (usually on the blog and other community platforms), such as alpha, beta and release candidate (RC) builds.
  • 開発ブランチの「信頼できる」非公式ビルドをテストします。 信頼できるプロバイダーをコミュニティメンバーに尋ねてください。 可能な限り、公式のバイナリを使用するか、自分でコンパイルして、バイナリの出所を確認するのが最善です。

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

GitHubで問題を提起する

Godotは、バグレポートと機能強化の提案にGitHubの課題追跡を使用します。そこで新規発行を開始するにはGitHubアカウントが必要で、「新規発行」ボタンをクリックします。

When you report a bug, you should keep in mind that the process is similar to an appointment with your doctor. You noticed symptoms that make you think that something might be wrong (the engine crashes, some features don't work as expected, etc.). It's the role of the bug triaging team and the developers to then help make the diagnosis of the issue you met, so that the actual cause of the bug can be identified and addressed.

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

  • オペレーティングシステム バグはシステム固有の場合があります。これは、ファイル管理、入力、ウィンドウ管理、オーディオなど、OS インターフェイスに関連するすべてのバグに特に関連します。
  • ハードウェア バグはハードウェア固有の場合があります。可能な場合は、ハードウェアに関する情報を含めるのが役立ちます。
  • Godotのバージョン これは必須です。いくつかの問題は現在の安定版リリースに関連しているかもしれませんが、開発ブランチでは修正されています。また、古いバージョンのGodotを使用していて、新しいバージョンで修正された既知の問題が発生している可能性もあるため、このことを最初から知っておくと、診断の迅速化に役立ちます。
  • バグを再現する方法 ほとんどの場合、バグは再現可能であり、すなわちいくつかの手順に従うことによって確実にそれらをトリガすることが可能です。誰もが問題を再現し、それを確認できるように、常にこれらの手順をできるだけ明確に記述してください。理想的には、この問題を箱から取り除くデモ プロジェクトを作成し、それを圧縮して問題に添付します (ドラッグアンドドロップでこれを行うことができます)。問題を再現するのは些細なことだと思っても、それを再現できる最小限のプロジェクトを追加することは大きな付加価値です。トラッカーには何千もの問題があり、開発者は各問題に少しの時間しかかからないように注意する必要があります。

「新規発行」ボタンをクリックすると、問題テンプレートがあらかじめ入力されたテキスト領域が表示されます。すべての問題が一貫性を保ち、必要な情報を提供するように、それに従ってください。

ドキュメントへの貢献

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

  • クラスリファレンス これは、GDScriptおよびその他のスクリプト言語に公開されている完全なGodot APIのドキュメントです。 オフラインで、Godotのコードエディタで直接、またはオンラインでGodot APIで参照できます。 クラス参照に貢献するには、Godotのgitリポジトリで doc/base/classes.xml を編集し、プルリクエストを行う必要があります。クラスリファレンスへの貢献を参照してください。
  • The tutorials and engine documentation and its translations. This is the part you are reading now, which is distributed in the HTML, PDF and EPUB formats. 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.