Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

常見問題

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

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

簡單來說:

  • 你可以自由下載與使用 Godot,並可用於個人、非盈利或商業性等任何目的。

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

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

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

For full details, look at the COPYRIGHT.txt as well as the LICENSE.txt and LOGO_LICENSE.txt files in the Godot repository.

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

Godot 支援哪些平台?

編輯器:

  • Windows

  • macOS

  • Linux, *BSD

  • Android (實驗性)

  • 網頁 (實驗性)

匯出遊戲:

  • Windows

  • macOS

  • Linux, *BSD

  • Android

  • iOS

  • Web

預設使用 64 位元,依情況可同時支援 32 位元與 64 位元的執行檔。

部分使用者也在基於 ARM 的 Linux 系統上成功使用 Godot,如 Raspberry Pi。

由於遊戲主機製造商施加的許可條款,Godot 團隊無法提供開源的主機匯出專案。但是無論使用哪種引擎,在主機上發行遊戲始終是一項繁重的工作。更多相關內容見 Godot 支援的主控台應用程式

有關匯出遊戲的詳細資訊請參考 匯出自行編譯 Godot 章節。

備註

Godot 3 also had support for Universal Windows Platform (UWP). This platform port was removed in Godot 4 due to lack of maintenance, and it being deprecated by Microsoft. It is still available in the current stable release of Godot 3 for interested users.

Godot 支援哪些程式語言?

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

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

Note that C# support is still relatively new, and as such, you may encounter some issues along the way. C# support is also currently missing on the web platform. Our friendly and hard-working development community is always ready to tackle new problems as they arise, but since this is an open source project, we recommend that you first do some due diligence yourself. Searching through discussions on open issues is a great way to start your troubleshooting.

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

GDScript 是什麼?為什麼要用 GDScript?

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

使用 GDScript 有不少原因——尤其是在進行原型設計、在專案的 alpha/beta 階段、或者專案非 3A 大作——但最大的優勢就是整體 複雜度降低

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

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

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

創造 GDScript 的動機是什麼?

剛開始我們是用 Lua 腳本語言。Lua 很快,但如果要 (使用 Fallback) 綁定物件導向系統,就變得很複雜而且很慢,也需要寫大量的程式碼。後來我們也試了 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. No native vector types (Vector3, Transform3D, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

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

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

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

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

你可以在 匯入 3D 場景 文件中找到有關支援的格式、如何從 3D 建模軟體匯出以及如何匯入 Godot 的詳細資訊。

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

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

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

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

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

如何擴充 Godot?

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

另外,可以看看官方的部落格文章,瞭解 GDExtension ,一種為Godot開發原生擴充的方法:

You can also take a look at the GDScript implementation, the Godot modules, as well as the Jolt physics engine integration for Godot. This would be a good starting point to see how another third-party library integrates with Godot.

如何在我的作業系統上安裝 Godot 編輯器(進行桌面整合)?

Godot 實際並不需要在你的作業系統上安裝就能執行,因此不會自動進行桌面整合。解決方式有兩種。您可以透過`Steam <https://store.steampowered.com/app/404790/Godot_Engine/>`__ (全平台)、Scoop (Windows)、Homebrew <https://brew.sh/>`__(macOS)、`Flathub (Linux)來安裝 Godot。 這樣就會自動執行桌面整合所需的步驟。

另外您也可以手動執行安裝程式會幫您執行的步驟:

Windows

  • 將 Godot 可執行檔案移動到一個穩定的位置(即在您的下載資料夾以外),這樣您就不會不小心移動導致破壞快捷啟動方式。

  • 右鍵點擊 Godot 可執行檔案,選擇 建立快捷方式

  • 將建立的快捷方式移動到``%LOCALAPPDATA%MicrosoftWindowsStart MenuPrograms``。 這是針對使用者的快捷方式存放位置,會顯示在開始選單中。 你也可以將Godot固定在工作列上,按右鍵可執行文件並選擇固定至工作列即可。

macOS

將解壓出的Godot應用拖拽至``/Applications/Godot.app``,如果需要的話還可以再拖到Dock欄上。 只要Godot在``/Applications``或``~/Applications``中,“聚焦”就能找到它。

Linux

  • 移動 Godot 二進制檔至穩定的位置(也就是您的下載資料夾之外),這樣的話之後您就可以避免不小心移動它並破壞捷徑。

  • 重新命名並移動Godot二進制檔至在``PATH``環境變數中出現的位置。通常是``/usr/local/bin/godot``或``/usr/bin/godot``。需要以系統管理員的權限執行該操作,不過這同時允許您在終端機 <doc_command_line_tutorial>`中輸入``godot``以 :ref:`執行 Godot 編輯器。

    • 如果無法將 Godot 編輯器二進制檔移動到受保護的位置,您可以將該二進制檔保存在主目錄中的某個位置,並修改下方連結的 ``.desktop``檔中的``Path=``行以包含 Godot 二進位檔的完整 絕對 路徑。

  • 儲存該 .desktop 檔案 <https://raw.githubusercontent.com/godotengine/godot/3.x/misc/dist/linux/org.godotengine.Godot.desktop>`__ 至``$HOME/.local/share/applications/。如果有系統管理員權限,您也可以儲存 ``.desktop``檔至/usr/local/share/applications``讓所有使用者可以使用該捷徑。

Godot 編輯器是個免安裝軟體嗎?

在預設設定中,Godot是*半可攜式的*。其執行檔可以從任何位置(包括不可寫入的位置)執行並且無需系統管理員權限。

然而設定檔案將被寫入至使用者設定或資料目錄。這通常是好的方法,但這意味著如果您複製含有Godot執行檔的資料夾,設定檔案將無法被攜帶至不同的機器。請參閱 Godot 專案中的檔路徑 以獲得更多資訊。

如果需要*是*可攜式的操作(例如於随身碟上使用),請依循 自包含模式 中的步驟操作。

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

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

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

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

為什麼Godot致力於保持小型的核心功能集?

Godot故意不包括可以由附加元件實作的功能,除非它們經常使用。例如進階人工智慧功能。

這有幾個原因:

  • 程式碼維護和 bug 的介面。 每次我們接受 Godot 儲存庫中的新程式碼時,現有的貢獻者通常會承擔維護它的責任。一些貢獻者在合併程式碼後不一定會堅持下去,這有可能讓我們難以維護有問題的程式碼,以致於功能維護不善,並出現從未修復的錯誤。最重要的是,需要測試和檢查退步的“API介面”隨著時間的推移而不斷增加。

  • 易於貢獻。,藉由保持程式碼庫小而整潔可以使編譯原始程式碼快速且容易。這使得新的貢獻者更容易開始使用Godot,而無需購買高級的硬體。

  • **為編輯器保持較小的二進位檔大小。**並非每個人都有快速的網路連線。確保每個人都可以在不到5分鐘的時間內下載Godot編輯器、解壓縮並執行它,將使所有國家的開發人員都可以更輕鬆地存取Godot。

  • 為匯出範本保持較小的二進位檔大小。 這直接影響 Godot 匯出專案的大小。在移動裝置和 Web 平臺上,保持較小的檔案大小對於確保在功率不足的裝置上快速安裝和載入至關重要。相同的,在許多國家中高速網路並不容易獲得。進一步來說,通常這些國家有嚴格的資料使用上限。

由於上述所有原因,我們必須選擇我們所可以接受的以作為Godot的核心功能。這就是為什麼我們的目標是將一些核心功能移動到Godot未來版本中官方支援的附加元件。就二進位檔大小而言,這也讓該檔案只需包含您實際使用的功能。(同時,您可以 :ref:`編譯禁用未使用功能的自定義匯出範本<doc_optimizing_for_size>`以優化專案的發行大小。)

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

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

The most common and proper way to achieve this is to, instead, use a single base resolution for the game and only handle different screen aspect ratios. This is mostly needed for 2D, as in 3D, it's just a matter of camera vertical or horizontal FOV.

  1. Choose a single base resolution for your game. Even if there are devices that go up to 1440p and devices that go down to 400p, regular hardware scaling in your device will take care of this at little or no performance cost. The most common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in mind the higher the resolution, the larger your assets, the more memory they will take and the longer the time it will take for loading.

  2. Use the stretch options in Godot; canvas items stretching while keeping aspect ratios works best. Check the 多解析度 tutorial on how to achieve this.

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

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

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

Godot 的下一個版本什麼時候發行?

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

新專案應該使用哪個版本的 Godot?

我們建議在新專案中使用 Godot 4.x,但是取決於你所需的功能,也許使用 3.x 更好。具體可參閱 GDScript是什麼?為什麼我要用它?

是否需要將我的專案升級到Godot的新版本?

新版本在某些方面更安全。一般來說,是否升級取決於你的專案環境。詳見 我應該把專案升級到新版本的引擎嗎?

我想參與貢獻!要從哪裡開始?

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

開始為 Godot 做出貢獻的最佳方式是使用它並報告你可能遇到的任何 問題 。一份帶有清晰重現步驟的好 bug 報告可以幫助其他貢獻者快速有效地修復 bug。你也可以在 線上文件 中報告你發現的問題。

如果您準備提交您的第一個 PR,請從上面的連結之一中選擇您感興趣的任何一個問題,並嘗試解決它。您將需要學習如何從原始程式碼編譯引擎,或如何建構文件。您還需要熟悉 Git,這是 Godot 開發人員使用的版本控制系統。

我們在 貢獻者文件 中解釋了如何使用引擎原始程式碼、如何編輯文件以及其他形式的貢獻方式。

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

我們一直在尋找關於如何改進引擎的建議。使用者的回饋是我們決策過程背後的主要驅動力,你在為自己的專案工作時可能遇到的限制是我們在考慮如何增強引擎時的重要依據。

如果您遇到可用性問題,或者目前版本的 Godot 缺少一項功能,請首先與我們的 社區 討論。社區成員可能會提出其他更好的方法來實作期望的結果。您可以瞭解其他使用者是否遇到過同樣的問題,並一起找出一個好的解決方案。

如果你對引擎有一個明確的改進想法,請隨意打開一個 提案 issue 。在描述您的問題和建議的解決方案時,儘量具體和明確——只有可行的建議才會被考慮。這不是必須的,但如果您想自己實作它,我們會非常感激!

如果你只有一個大致的想法,沒有具體的細節,你可以開啟一個 提案討論。討論可以包含您想要的任何內容,並允許自由形式的討論以尋求解決方案。一旦找到了一個解決方案,就可以打開提案 issue。

在建立提案之前,請閱讀 讀我檔案,以瞭解有關該過程的更多資訊。

是否能用 Godot 建立非遊戲應用?

是的!Godot 具有廣泛的內建 UI 系統,輕量化的特色可以使它成為 Electron 或 Qt 等框架的替代品。

當建立一個非遊戲的應用程式時,確保在專案設定中啟用 節能處理器模式 以減少CPU和GPU佔用。

請查看 `Material Maker<https://github.com/RodZill4/material-maker>`__Pixelorama<https://github.com/Orama-Interactive/Pixelorama> __ 瞭解用 Godot 製作的開源應用的例子。

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

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

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

Godot 使用的使用者界面工具包是什麽?

Godot 沒有像 GTK 、 Qt 和 wxWidgets 那樣使用標準 :abbr:`GUI (圖形使用者界面)`工具包。相反, Godot 使用的是自行開發的使用者界面工具包,使用 OpenGL ES 或 Vulkan 進行渲染。該工具包用於渲染編輯器( C++ 編寫),以控制元件節點的形式公開。這些控制節點也可用於 Godot 支援的任意腳本語言專案。

這個定制的工具包使它能獲益於硬體加速,並在全平臺上擁有一致的外觀。 最重要的是,它不必處理GTK或Qt所帶來的LGPL許可注意事項。 最後,這意味著Godot在“自產自用”,因為編輯器本身就是Godot UI系統中最複雜的用例之一。

這個自定義UI工具包:ref:不能作為一個庫使用<doc_faq_use_godot_as_library>,但你仍然可以:ref:通過使用Godot編輯器來建立非遊戲應用程式<doc_faq_non_game_applications>

為什麼 Godot 使用 SCons 建構系統?

Godot 使用 SCons 建構系統。近期沒有改用其他建構系統的計畫。我們選擇 SCons 而不是其他建構系統的原因有很多,例如:

  • Godot 可以編譯到數十種不同的平台上:所有 PC 平台、所有行動平台、各種遊戲主機以及 WebAssembly。

  • 許多開發人員通常都需要 同時 為數個平台進行編譯,甚至需要為相同平台的不同架構進行編譯。這些開發人員可沒精力每次都為專案重新設定並重新建置。SCons 則可以輕鬆完成這項工作,且不會破壞建置的過程。

  • 不論做了多少的更改、設定、新增、移除…等,SCons 永遠都不會 把建置中斷。使用 SCons 是,需要清理並重新建置的機率比你被雷劈的機率還要低。

  • Godot 的建置過程可不簡單。有許多檔案是由程式產生的 (Binder),有些檔案是經過解析的 (Shader),還有一些檔案是用來提供客製化的 (外掛程式)。這個建置過程會需要複雜的邏輯,而使用真正的程式語言 (如 Python) 會簡單得多,因此不適合用那些用來建置、基於巨集的語言。

  • Godot 的建置過程會使用到大量交叉編譯的工具。各個平台都有特定的偵測過程,而這些過程都必須要通過撰寫特定的程式碼來作為各種特殊情況處理。

所以,如果你想自己建置 Godot 的話,請儘量保持開放的態度,並至少稍微熟悉一下 SCons。

為什麼Godot不使用STL(Standard Template Library)?

Like many other libraries (Qt as an example), Godot does not make use of STL (with a few exceptions such as threading primitives). We believe STL is a great general-purpose library, but we had special requirements for Godot.

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

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

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

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

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

Godot 怎麼不用例外 (Exception)?

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

Additionally, exceptions significantly increase the binary size for the executable and result in increased compile times.

Godot使用 ECS(實體元件系統)嗎?

Godot不使用 ECS 而是依賴於繼承。雖然沒有一種普遍的更好的方法,我們發現使用繼承的效率已經可以滿足於絕大多數使用場景。

也就是說,沒有什麼能阻止你在專案中通過使用腳本建立子節點來使用組合。這些節點可以在隨後的運作時中新增和刪除,以實作動態新增和刪除。

可以在 這篇文章 中找到更多有關 Godot 設計抉擇的資訊。

為什麼 Godot 不強制使用者實作 DOD(面向資料設計)?

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

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

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

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

要怎麼參與貢獻或支援 Godot 的開發呢?

請參考 參與貢獻的方法

有誰在為 Godot 工作?如何聯路?

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