貢献する方法

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

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

  • コミュニティの一員になりましょう。 Godotに貢献し、これを改善するための最善の方法は、単にエンジンを使用して、口コミ、ゲーム、ブログ投稿、チュートリアル、ビデオ、デモ、gamedevのクレジットまたはスプラッシュ画面で宣伝することです フリーソフトウェアイベント、Q&A、IRC、フォーラム、Discordなどのサポート。参加してください!ユーザーであり、支持者であることは、マーケティング予算がなく、そのため、より主流になるためにコミュニティに頼ることしかできない私たちの素晴らしいエンジンについての評判を広めるのに役立ちます。
  • ゲームを作りましょう。 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.

開始するのに適した場所は、junior jobs <https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+label%3A%22junior+job%22>`_(または `Hacktoberfest 10月の時点)というタグの付いた課題をGitHubで検索することです。

参考

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

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

テストとレポートの問題

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

開発バージョンのテスト

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

  • プラットフォームのコンパイルページの指示に従って、ソースからエンジンを自分でコンパイルします。
  • アルファ版、ベータ版、リリース候補(RC)ビルドなど、公式のプレリリースバイナリを(通常はブログや他のコミュニティプラットフォームで)発表されたらテストします。
  • 開発ブランチの「信頼できる」非公式ビルドをテストします。 信頼できるプロバイダーをコミュニティメンバーに尋ねてください。 可能な限り、公式のバイナリを使用するか、自分でコンパイルして、バイナリの出所を確認するのが最善です。

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

GitHubで問題を提起する

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

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

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

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

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

ドキュメントへの貢献

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 doc/base/classes.xml in Godot's Git repository, and make a pull request. See クラスリファレンスへの貢献 for more details.
  • チュートリアルとエンジンのドキュメントとその翻訳。 これは、HTML、PDF、およびEPUB形式で配布されている、あなたが今読んでいる部分です。その内容はreStructured Text(rst)形式のプレーンテキストファイルから生成され、godot-docs GitHubリポジトリのプルリクエストを介して貢献できます。ドキュメントのガイドライン を参照してください。