參與貢獻的方法

Godot Engine 是非盈利、由社群驅動、自由且開放原始碼的專案。幾乎所有 (除了開發負責人 Juan,詳見下方) 開發人員都是利用空閒時間,抱持想製作高品質自由引擎的熱情所 無償 開發的。

這表示,若 Godot 想成長茁壯,則需要儘量有多一點的人參與為 Godot 引擎貢獻。有許多方法可以參與這種大小專案的貢獻,因此,無論是有什麼技能的人,幾乎都能為 Godot 帶來正面改進:

  • 成為社群的一部分。 要參與貢獻 Godot,並讓 Godot 變得更好的最簡單的方法就是親自使用 Godot 並到處宣傳,不論是在遊戲的製作人員名單內、部落格、教學、影片、Demo 版遊戲、遊戲開發或自由軟體活動、支援與 Q&A、IRC、討論區、Discord …等,一起參加就對了!由於 Godot 沒有行銷預算,幾乎都仰賴與社群來讓 Godot 擠進主流市場,因此如果你能成為 Godot 的使用者與支持者將有助於讓 Godot 這個優秀的遊戲引擎更佳流行。

  • 製作遊戲。 大家都知道,在 Godot 所參與的這整個產業中,要說服新使用者的方法就是使用 Godot 來製作優質的遊戲。我們知道,Godot 不論是在 2D 還是 3D 遊戲上都有龐大的潛能,但由於 Godot 還很新,因此我們還沒有足夠大型的遊戲來吸引大家的注意。因此,請繼續製作優質的遊戲,每製作一個遊戲就能更提升 Godot 在遊戲開發市場上的名聲!

  • 參與引擎的開發。 可以通過 Pull Request、測試引擎的開發快照或 Git 的 master 分支、回報 Bug 或在 Issue Tracker 上提供改進的建議、或是改進官方說明文件 (類別參考文件與教學) 與其翻譯來參與引擎開發。接下來的段落會討論各種「直接」參與貢獻引擎的方法。

  • 捐款。 Godot 是一個非營利性專案,但通過使用者的捐款,Godot 依然能在許多方面獲益。除了如伺服器託管費用與在活動上用到的宣傳材料等一般性開支外,我們也會在需要的時候使用收到的捐款來購買硬體 (如,我們曾使用捐款買一台 MacBook Pro 來實作 Retina/HiDPI 支援與其他 macOS 相關的功能)。最重要的是,我們也會使用收到的捐款聘請核心開發者來讓他們全職為 Godot 工作。即使月薪低,我們還是需要穩定的捐款收入才能繼續這麼做,而到目前為止專案也此獲得了許多好處。因此,如果你也想捐款給 Godot,請參考 我們的網站

參與貢獻程式碼

學習、使用、修改與重新發佈對 Godot 原始碼的修改,是 Godot 的 MIT 授權條款提供給你的基礎權利,因此 Godot 也是 自由與開放原始碼軟體 <https://zh.wikipedia.org/zh-tw/%E8%87%AA%E7%94%B1%E5%8F%8A%E5%BC%80%E6%94%BE%E6%BA%90%E4%BB%A3%E7%A0%81%E8%BD%AF%E4%BB%B6>

也因如此,人人都能修改 Godot 的原始碼 ,並以修正檔 (一種描述如何直接套用修改的文字檔) 或所謂的「Pull Request (PR)」這種我們所用的現代工作流程來將這些修改送回上流專案,如,可以提議將一個或多個 Git Commit (修正檔) 合併回主要開發分支上。

向上游專案貢獻程式碼修改有兩大好處:

  • 所撰寫的程式碼會經過其他開發者的審閱與改進,接著會進一步直接在上游專案中被維護,因此接下來每次更新到新版本後就不需要再重新套用這些修改。另一方面,由於這個改動不能只對你自己的專案有利而已,還必須要讓一般的使用者都能從中獲益,因此這也是一種責任。所以,如果這些改動只適用於你的專案的話,則這些情況就應該只將改動保持在自己的專案裡就好了。

  • 整個社群都能得益於你的行動,而其他參與貢獻者也一樣,他們所貢獻的程式碼也能讓你獲益。在這篇文章撰寫時,已有超過 1000 位開發人員為 Godot 貢獻了程式碼修改!

為了確保大家能順利地協作以及程式碼整體的品質,Godot 開發人員必須遵守一些程式碼貢獻的規則,如一些關於 C++ 的程式碼樣式 (縮排、分號…等) 與 Git 及 PR 工作流程。

在 GitHub 上搜尋有 junior jobs (或十月時的 Hacktoberfest) 標籤的 Issue 是個不錯的開始。

也參考

有關 PR 工作流程的技術性細節,將在 Pull Request 工作流程 中詳細說明。

有關程式碼樣式的方針與用來強制套用這些樣式的 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.

測試與回報問題

另一種參與貢獻 Godot 的好方法就是測試開發版本或是開發分支,並回報問題。回報在穩定版上發現的問題也不錯,這樣這些問題就能在開發分支與未來的維護版本中被修復。

測試開發版本

若要協助測試,則有幾種方法:

  • 自行從原始碼編譯,請參考各個平台的 編譯 頁中的說明。

  • 測試官方公告的預覽版本 (通常會在部落格或其他社群平台公告),如 Alpha 版、Beta 版與 RC (Release Candidate, 候選) 版。

  • 測試開發分支的「可信」非官方版本;請向社群成員詢問可靠的提供者。雖然,我們建議儘量使用官方發佈的版本或自行編譯,以確認二進位文件是否可靠。

就像剛才說的,如果能幫忙留意未來可能持續存在的 Bug 也很有幫助,特別某些只有少數開發者協助測試的功能。

在 GitHub 上提出 Issue

Godot 使用 GitHub 的 Issue Tracker 來處理 Bug 回報與改進建議。要開啟新 Issue 會需要持有 GitHub 帳號,並點擊「New Issue」按鈕。

在回報 Bug 時,請記得要使用與向醫生預約相同的流程。首先會先遇到某個感覺不對的 症狀 (如 Godot 當機、某些功能的運作不如預期…等),接著,Bug 分級小組與開發人員的工作,就是負責診斷所遇到的問題,這樣一來便能找出造成 Bug 的真正原因。

接著請問問自己該提供什麼樣的資訊來讓其他 Godot 貢獻者能瞭解這個 Bug、定位出 Bug 並對其進行修復。下列為一些每次都必須提供的重要資訊:

  • 作業系統: 有的 Bug 只出現在某些作業系統上,如,某些 Bug 可能只發生在 Windows 上,或是只發生在 Linux 上…等。特別與作業系統介面相關的 Bug,如檔案管理、輸入、視窗管理、音訊…等。

  • 硬體。 某些 Bug 只發生在特定硬體上。如,某些 Bug 只發生在特定的處理器、顯示卡…等。如果可以的話,能提供硬體資訊將很有幫助。

  • Godot 版本。 這項資訊一定要有。某些問題只發生在目前的穩定版本上,而開發分支上已經修正或在開發分支上有其他問題。也有可能你正在用的是舊版本,而遇到的問題是已知 Bug,因此如果能一開始就提供版本號的話將有助於加快診斷速度。

  • 如何重現 Bug。 在大多數的情況下,Bug 都是可重現的。即,依照某些步驟就一定會觸發該 Bug。請一定要儘可能地描述清楚這些步驟,這樣一來所有想重現該 Bug 的人都能對其進行確認。理想情況下,最好能製作一個能直接重現該 Bug 的 Demo 專案,然後壓縮該專案並附加到 Issue 上 (可以通過拖放來附加檔案)。即使你認為該 Bug 很難重現,如果能加上能重現該 Bug 的最小專案也很有幫助。但請記得,在 Issue Tracker 上有數千個 Bug,而對每個 Issue 來說,開發人員都只有一定的時間來處理。

點擊「New Issue」後,應該可以看到一個已經填好 Issue 樣板的文字輸入框。請依照該 Issue 樣板,來讓所有的 Issue 都保持一貫性,並提供必要的資訊。

參與貢獻說明文件

在 Godot 中,所謂的「說明文件」有兩種不同的東西:

  • 類別參考文件。 類別參考文件是 Godot 暴露給 GDScript 與其他腳本語言的完整 Godot API。該參考文件可以離線瀏覽,也可以直接在 Godot 的程式編輯器內瀏覽,或是在 Godot API 上線上瀏覽。如果想參與貢獻類別參考文件,則必須編輯 Godot Git 儲存庫中的 doc/base/classes.xml ,並建立 Pull Request。詳情請參考 參與貢獻類別參照文件

  • 教學與引擎說明文件及其翻譯。 也就是你目前正在閱讀的部分。這些教學與說明文件有 HTML 版、PDF 版與 EPUB 版。教學與說明文件的內容是從以 reStructured Text (rst) 格式的純文字檔所產生而來的,而你也可以通過在 godot-docs GitHub 版本庫中開啟 Pull Request 來參與貢獻。詳情請參考 說明文件方針

參與貢獻翻譯

為了要讓包含母語不是英語在內的所有人都能使用 Godot,我們的社群也協助將 Godot 編輯器與其說明文件翻譯為其他許多語言。

詳情請參考 本地化編輯器與說明文件