常見問題

Godot 可以做什麼？要花多少錢？授權條款是什麼？

Godot 是 由開放原始碼促進協會 (OSI) 所認可的 MIT 授權條款釋出。而這裡所指的 Free 就如同「言論自由」與「免費啤酒」的「Free」一樣。

簡單來說：

  • 你可以自由下載與使用 Godot，不管是為了什麼目的、是否是個人使用、非盈利或商業性，都可以自由使用。

  • 不論理由為何、不管有沒有商業目的，都可以根據需求自由修改、發佈、再發佈，或是重組 Godot。

這份文件所有內容都以寬鬆的創用CC—姓名標示 (CC-BY 3.0) 授權條款發佈，作者標示為「Juan Linietsky, Ariel Manzur 與 Godot Engine 社群」。

Logo 與圖示基本上也是用同一個創用 CC 條款授權。但請注意，Godot 原始碼所包含的一些第三方函式庫可能使用了不同的授權條款。

詳細資訊請參考 Godot 原始碼 Repository 中的 LOGO_LICENSE.txt。

另外，也請參考 Godot 網站上的授權條款頁面 (英文)。

Godot 支援哪些平台？

編輯器：

  • Windows

  • macOS

  • X11 (Linux, *BSD)

匯出遊戲：

  • Windows（與 UWP）

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • 網頁

根據情況，32 位元與 64 位元的執行檔都有支援，而預設使用 64 位元。

有些使用者也回報能成功在基於 ARM 的 Linux 系統上使用 Godot，如 Raspberry Pi。

另外，也有一些非官方的第三方組織成功匯出到遊戲主機平台上。但預設建置腳本以及匯出樣板中均未包含這些平台。

有關於匯出的詳細資訊請參考 匯出 與 自行編譯 Godot 。

Godot 支援哪些程式語言？

Godot 正式支援的語言有 GDScript、視覺腳本 (Visual Script)、C# 與 C++。請參考 撰寫腳本 章節中關於各個語言的子分類。

不論你是剛開始使用 Godot，或是剛開始進行遊戲開發，都推薦使用 GDScript，因為 GDScript 是 Godot 的原生語言。雖然腳本語言的效能遠比低階程式語言還低，但在原型設計 (Prototype)、最小可行產品 (MVP, Minimun Viable Product) 或是專注於上市時間 (TTM) 的開發上，GDScript 對於開發遊戲來說是一個快速友好、可靠的選擇。

請注意，C# 的支援仍然相對較新，因此在使用時可能會遇到一些問題。友好勤奮的開發社群隨時都準備好解決新遇到的問題。但由於 Godot 是開源專案，我們建議你先自己排解問題。不妨搜尋 未解決的 Issue 中的討論來排解疑難。

更多語言可以通過 GDNative / NativeScript / PluginScript 搭配第三方套件來支援。(詳細請參考下列關於外掛的問答。) 目前有些正在開發的非官方語言綁定專案如 Nim 。

GDScript 是什麼？為什麼要用 GDScript？

GDScript 是與 Godot 整合的腳本語言。是為了以最少的程式碼發揮 Godot 最大的潛能而從 0 打造的，同時也能讓不論新手或專業開發者都能儘可能快速地駕馭 Godot 優勢。若你曾經使用過如 Python 之類的語言，肯定也能快速上手 GDScript。請參考 GDScript 腳本編寫指南 取得範例程式碼、歷史、以及 GDScript 功能的完整簡介。

有很多使用 GDScript 的理由，尤其是在 Prototype 時、專案 Alpha/Beta 階段，或是還沒做好 3A 大作的階段。但最重要的理由就是 GDScript 能 降低整體的複雜度。

最開始會想從頭客製化一個與 Godot 深度整合的腳本語言主要有兩個原因：首先，自己做的語言做可以降低程式在 Godot 內的啟動與執行時間，能讓開發者更快上手引擎並專注於產品開發；再來，也能降低維護成本與避免遇到複雜問題，讓引擎開發者能專心找出 Bug 並提升引擎核心功能，而不是花一堆時間支援一大堆語言結果只獲得一小撮新功能。

由於 Godot 是一個開源專案，所以我們的首要考量是更好的整合性與無縫的體驗，而不是支援有名的程式語言來吸引使用者。尤其支援有名的語言卻可能讓使用體驗變得很糟糕。我們瞭解你會想在 Godot 裡使用其他語言 (請參考下方的支援選項列表)。但其實，如果你還沒試過 GDScript，請試著用用看 三天。就像 Godot，一旦瞭解到 GDScript 厲害到能讓開發變得更快速，你肯定會愛上 GDScript 的。

請參考 GDScript：動態語言簡介 一文瞭解如何熟悉 GDScript 或動態型別語言的資訊。

創造 GDScript 的動機是什麼？

剛開始我們是用 Python，但事後證明要把 Python 嵌入引擎有多困難。

為 Godot 建立一個客製化的腳本語言的主要原因：

  1. Godot 需要使用執行緒，但大部分腳本語言 VM 對執行緒的支援都很差。 (Lua, Python, Squirrel, JavaScript, ActionScript …等)。

  2. 大多數腳本語言 VM 都不太支援擴充類別 (Class-extending)，而要在 Godot 上用就會很沒效率。(Lua, Python, JavaScript)。

  3. 現存語言的 C++ 綁定界面都很可怕，會導致需要大量的程式碼、Bug、瓶頸、整體上來說變得很沒效率 (Lua, Python, Squirrel, JavaScript…等)。我們想要專心做出好用的引擎，而不是整合一堆東西。

  4. 沒有原生的 Vector 型別 (vector3, matrix4…等)，導致使用自定型別會大幅降低效能 (Lua, Python, Squirrel, JavaScript, ActionScript…等)。

  5. 記憶體回收行程 (Garbage Collector) 機制也導致了佔用或使用了大量不必要的記憶體。(Lua, Python, JavaScript, ActionScript…等)。

  6. 很難在程式碼編輯器中整合程式碼補全或即時編輯…等 (所有的語言都這樣)。而 GDScript 就支援得很好。

GDScript 被設計來解決上述所有的問題，甚至能做得更好。

Godot 支援什麼格式的 3D 模型？

Godot 通過 Better Collada Exporter。

自 Godot 3.0 版開始支援 glTF。

可以用 Open Asset Import Library 來支援 FBS。然而，由於 FBX 不是開源格式，如果狀況允許的話我們建議使用其他格式。

Godot 會支援 [自行帶入 FMOD, GameWorks 等閉源 SDK] 嗎？

Godot 的目標是要建立一個模組化且可擴充的自由開源 MIT 引擎。目前，引擎開發核心社群沒有計劃要支援任何第三方且閉源或專屬 (Proprietary) 的 SDK，因為整合這些 SDK 有違 Godot 的初衷。

但其實，因為 Godot 開放原始碼且模組化，所以任何有興趣的人都可以將這些函式庫做成模組，並隨著遊戲一起發佈，不論開源或閉源。

我們還是會告訴你你想要的 SDK 的支援程度，請參考下方關於外掛的問題。

如果你知道什麼 Godot 不支援但卻是自由且開放原始碼整合的第三方 SDK，你可以考慮自己整合。Godot 不屬於哪個人，而是屬於社群的，而這個社群會成長正是因為有想你一樣野心勃勃的社群貢獻者。

為什麼 Godot 要用 Vulkan 與 OpenGL 而不是 Direct3D？

Godot 的目標是提供跨平台相容性與優先使用開放標準。OpenGL 與 Vulkan 這兩種技術都是開放原始碼且 (幾乎) 可以在所有平台上使用。而得益於此一設計決定，使用 Godot 在 Windows 上開發的專案可以直接在 Linux, macOS 等平台上執行。

由於只有少數人在處理 Godot 的算繪引擎，我們希望能儘量減少工作，不要增加太多需要維護的算繪後端。因此，在所有平台上都使用相同的單一 API 可以讓我們保持更佳的一致性，並減少遇到平台特定的問題。

以長遠的眼光來看，未來我們可能會開發用於 Godot 的 Direct3D 12 算繪引擎 (主要是為了個 Xbox 用)，但在所有平台上，包含 Windows，預設的算繪引擎都會維持 Vulkan 與 OpenGL。

Why does Godot aim to keep its core feature set small?

Godot intentionally does not include features that can be implemented by add-ons unless they are used very often. One exemple of this would be advanced artificial intelligence functionality.

There are several reasons for this:

  • Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the reponsibility of maintaining it. Some contributors don't always stick around after getting their code merged, which can make it difficult for us to maintain the code in question. This can lead to poorly maintained features with bugs that are never fixed. On top of that, the "API surface" that needs to be tested and checked for regressions keeps increasing over time.

  • Ease of contribution. By keeping the codebase small and tidy, it can remain fast and easy to compile from source. This makes it easier for new contributors to get started with Godot, without requiring them to purchase high-end hardware.

  • Keeping the binary size small for the editor. Not everyone has a fast Internet connection. Ensuring that everyone can download the Godot editor, extract it and run it in less than 5 minutes makes Godot more accessible to developers in all countries.

  • Keeping the binary size small for export templates. This directly impacts the size of projects exported with Godot. On mobile and web platforms, keeping file sizes low is primordial to ensure fast installation and loading on underpowered devices. Again, there are many countries where high-speed Internet is not readily available. To add to this, strict data usage caps are often in effect in those countries.

For all the reasons above, we have to be selective of what we can accept as core functionality in Godot. This is why we are aiming to move some core functionality to officially supported add-ons in future versions of Godot. In terms of binary size, this also has the advance of making you pay only for what you actually use in your project. (In the meantime, you can compile custom export templates with unused features disabled to optimize the distribution size of your project.)

要怎麼做出能應付多種解析度與長寬比的素材呢？

這是一個很常見的問題，可能要感謝 Apple 公司，最開始 Apple 只是把設備的解析度變兩倍，讓大家以為可以直接在不同解析度下用同一個素材，所以許多人就一直這麼做。剛開始這方法在 Apple 的裝置上還行，但不久後就開始出現各種有不同解析度與長寬比的 Android 與 Apple 裝置，而且大小與 DPI 的差異還很大。

最常見且最恰當的做法就是不管這些，在遊戲中只使用一種的解析度，然後對不同的螢幕長寬比做處理。這主要是 2D 遊戲所需要做的，3D 遊戲中就只是相機的 XFov 或 YFov 的問題而已。

  1. 首先為遊戲選擇一個基本的解析度。就算有的裝置解析度高達 2K，有的則只有 400p，在裝置上做一般的硬體縮放幾乎不怎麼消耗效能。最好的選擇就是接近 1080p (1920x1080) 或 720p (1280x720) 其中一種。但要記得，解析度越高，素材的大小就越大，也就代表要佔用更多的記憶體以及需要更長的載入時間。

  2. 使用 Godot 的伸縮選項；2D 伸縮在保持長寬比的時候效果最佳。請參考 Multiple resolutions 教學來瞭解如何實現。

  3. 確保最小解析度並決定在不同的長寬比下是要讓遊戲垂直還是水平伸縮，還是要在螢幕旁邊顯示黑條。關於這點進一步的說明請參考 Multiple resolutions。

  4. 使用者界面則請使用 錨定 來判斷控制元件是要留在原位還是要移動。如果是比較複雜的 UI，建議您瞭解有關容器 (Container) 的內容。

就這樣！現在遊戲應該可以在不同解析度底下運作。

如果希望遊戲在只有小螢幕 (寬度小於 300 像素) 的上古裝置上也能運作，可以使用匯出選項來縮小圖片，並將該建置設為在 AppStore 或 GooglePlay 下特定的螢幕大小。

如何擴充 Godot？

如製作 Godot 編輯器外掛或是加上其他語言的支援等有關擴充 Godot 的內容，請參考 編輯器外掛 與工具腳本。

另外也請參考一下有關下列主題的官方部落格文章：

也可以看看 GDScript 的實作，GDScript 只是 Godot 的一個模組，就像 Godot 的 非官方 Python 支援 一樣。這是瞭解第三方函式庫要如何整合進 Godot 的一個好的開始。

下個版本什麼時候出？

準備好的時候就會出了！更多資訊請參考 :ref:`doc_release_policy_when_is_next_release_out ` 。

我想參與貢獻！要從哪裡開始？

水啦！作為一個開源專案，Godot 沒有像你這種創新且野心勃勃的開發者可不行。

可以先從 如何貢獻 指南來瞭解如何 Fork、修改，最後送出 Pull Request (PR)。

我有個大膽的想法可以給 Godot。該分享去哪裡？

雖然你可能對 Godot 有很多想法，例如某個會需要大改核心的想法，或是想要模仿某個遊戲引擎的想法，或是又有哪個希望能內建在編輯器裡的工作流程 (Workflow)。這些都很棒，而且我們也很感謝有這些上進的人們想要參與貢獻，但 Godot 的重點一直都專注於 解決 Bug 與找出問題 (英文)，以及與 Godot 核心成員對話。

Godot 社群中多數的開發者都對下列這些東西比較有興趣：

  • 使用 Godot 的體驗以及所遇到的問題 (這點比起增進 Godot 的想法還重要)。

  • 因使用者專案需求而希望能實作的功能。

  • 在學習過程中遇到的難以理解的概念。

  • 希望能在工作流程中改善的部分。

  • 需要更清楚的教學或是說明文件寫得很模糊的部分。

請不要覺得 Godot 不歡迎你的想法。反過來說，請試著先把這些想法當成是 Godot 的設計問題來重新表達，這樣開發者們以及社群就可以此作為實現依據。

設定使用者故事 (User Story) 是向社群說明你的 Idea 與問題的好方法。說明你正在嘗試什麼、希望獲得什麼結果、以及實際上得到了什麼。這樣子來描述問題與 Idea 就有助於讓整個社群都能專注於提升整體的開發者體驗。

加分項：最好能附上截圖、具體用了什麼數字、測試案例、或是範例專案（若可能的話）。

可以把 Godot 當作函式庫來用嗎？

Godot 是以使用編輯器為前提設計的。我們建議可以先試著用用編輯器，長期下來通常可以節省很多時間。目前沒有計劃要讓 Godot 能作為函式庫使用，因為這樣會讓引擎其他的功能變得很複雜，對一般的使用者來說難以使用。

若您是想用算繪引擎，建議改而使用其他正式的算繪引擎。請注意，算繪引擎的社群通常與 Godot 相比來得小。這樣會讓尋找問題答案變得比較困難。

Godot 怎麼不用 STL

如同其他的許多函式庫一樣（例如 Qt），Godot 沒有用到 STL (Standard Template Library，標準樣板庫)。雖然我們知道 STL 是一個很厲害的通用函式庫，但 Godot 有一些特殊需求。

  • STL 樣板會產生很大的符號 (Symbol)，進而讓偵錯用二進位檔的體積變大。我們用名稱很短並、少量的樣板來代替。

  • 大部分的容器都有特殊需求，例如 Vector 會需要使用寫入時複製 (Copy on Write) 來傳遞資料；或是 RID 系統為了效能需要 O(1) 的存取時間。還有其他類似狀況，如我們的雜湊表實作設計成能與引擎內部型別無縫整合。

  • 容器內建了記憶體追蹤，以改進記憶體使用狀況追蹤。

  • 在大型陣列中使用記憶體池，可以被映射到預分配緩衝區 (Preaoolocated Buffer) 或是虛擬記憶體。

  • 使用自定字串型別，而 STL 提供的字串太簡陋且缺乏完善的國際化支援。

Godot 怎麼不用例外 (Excaption)？

我們認為無論如何遊戲不應該 Crash。若發生了未預期的狀況，Godot 會輸出錯誤 (可以被追蹤回腳本)，但接著會儘可能地修復並繼續執行。

另外，例外功能會導致二進位執行檔的大小大幅增加。

Godot 怎麼不強制 RTTI？

Godot 提供了自己的型別轉換系統，其內部可以選擇是否要使用 RTTI (執行期型態訊息)。在 Godot 內禁用 RTTI 則代表能損失一點點效能來爭取更小的二進位檔案大小。

Godot 怎麼不強制使用者實作 DoD？

雖然 Godot 內部有儘可能地試著在很多吃效能的任務上都使用了快取一致性 (Cache Coherency) 機制，但我們認為多數使用者都不是真的有需要強制使用 DoD (Data oriented Design，資料導向設計)。

DoD 基本上就是一個快取一致性最佳化機制，只能讓處理成千上萬個物件 (每一幀都需要執行一些少量的修改) 時能讓效能有顯著提升。舉個例子，若每一幀都需要移動上百個 Sprite 或敵人時，DoD 就沒什麼用了，需要考慮另一種最佳化的方式。

絕大多數的遊戲都不需要 DoD。而且 Godot 對於大多數情況都提供了便利的工具來代替。

如果真的有遊戲需要處理這麼大量的物件，我們建議使用 C++ 與 GDNative 來處理吃效能的部分，剩下的部分則使用 GDScript (或 C#)。

要怎麼參與貢獻或支持 Godot 的開發呢？

請參考 參與貢獻的方法。

有誰在為 Godot 工作？如何聯絡？

請參考 Godot 網站 (英文) 上相應的頁面。