Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

Поширені запитання

Що я можу зробити з Godot? Скільки це коштує? Які ліцензійні умови?

Godot — це «безкоштовне програмне забезпечення з відкритим кодом». доступний під OSI-схваленим Ліцензія MIT. Це означає, що це безкоштовно, як у «свободі слова», так і у «безкоштовному пиві»

Коротко:

  • Ви можете вільно отримати Godot і користуватися ним для будь-яких потреб, особистих, некомерційних, комерційних або інших.

  • Ви можете модифікувати, поширювати і поєднувати Godot із іншими компонентами так, як цього забажаєте, для будь-якої мети, некомерційної або комерційної.

Весь вміст цієї супровідної документації публікується під ліцензією Creative Commons Attribution 3.0 (CC BY 3.0) із зазначенням авторства "Juan Linietsky, Ariel Manzur та спільнота Godot Engine."

Логотипи та значки, як правило, знаходяться під однією ліцензією Creative Commons. Зауважте, що деякі сторонні бібліотеки, включені до вихідного коду 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

  • Лінукс, *BSD

  • Android (експериментальний)

  • Web (експериментальний)

Для експорту ваших ігор:

  • Windows

  • macOS

  • Лінукс, *BSD

  • Android

  • iOS

  • Інтернет

Підтримуються як 32-, так і 64-розрядні двійкові файли, де це має сенс, причому за замовчуванням використовується 64-розрядність. Офіційні збірки macOS підтримують Apple Silicon нативно, а також x86_64.

Деякими користувачами повідомлялося про успішне збирання та використання Godot на заснованих на ARM системах із ядром Linux, зокрема на Raspberry Pi.

Щоб отримати інформацію про підтримку консолей, див. веб-сайт Godot <https://godotengine.org/consoles/>`__.

Більше про це дивіться в розділах про exporting і compiling Godot yourself.

Примітка

Godot 3 також підтримував Universal Windows Platform (UWP). Порт цієї платформи було вилучено у версії Godot 4 через відсутність підтримки, а також через те, що вона була застарілою для Microsoft. Він все ще доступний у поточному стабільному випуску Godot 3 для зацікавлених користувачів.

Підтримку яких мов програмування передбачено у Godot?

Офіційно підтримуваними мовами для Godot є GDScript, C# та C++. Дивіться підкатегорії для кожної мови у розділі scripting.

Якщо ви лише робите перші кроки з Godot або у розробці ігор загалом, - рекомендуємо мову GDScript для вивчення та використання, так як це рідна мова для Godot. Хоча скриптові мови програмування як правило менш продуктивні ніж низькорівневі в довгостроковій перспективі, для прототипування, розробки Мінімально Життєзданих Продуктів (MVPs) та фокусі на Time-To-Market (TTM), GDScript забезпечить швидкий, дружній та надійний спосіб для розробки ваших ігор.

Зверніть увагу, що підтримка C# все ще відносно нова, тому ви можете зіткнутися з деякими проблемами на цьому шляху. Підтримка C# також наразі відсутня на веб-платформі. Наша дружня і працьовита спільнота розробників завжди готова вирішувати нові проблеми по мірі їх виникнення, але оскільки це проект з відкритим вихідним кодом, ми рекомендуємо вам спочатку провести певну перевірку самостійно. Пошук в обговореннях відкритих питань - це чудовий спосіб розпочати пошук та усунення несправностей.

Що стосується нових мов, підтримка можлива через третіх осіб за допомогою GDExtensions. (Див. питання про плагіни нижче). Наразі ведеться робота, наприклад, над неофіційними прив'язками Godot до Python та Nim.

Що таке GDScript і чому я повинен, це використовувати?

GDScript - це інтегрована мова сценаріїв Godot. Вона була створена з нуля, щоб максимізувати потенціал Godot з найменшою кількістю коду, що дозволяє як початківцям, так і досвідченим розробникам використовувати сильні сторони Godot якнайшвидше. Якщо ви коли-небудь писали щось на мові Python, то ви відчуєте себе як вдома. Приклади та повний огляд можливостей GDScript можна знайти у GDScript scripting guide.

Існує кілька причин для використання GDScript, але найголовнішою є загальне зменшення складності.

Початковий намір створення тісно інтегрованої, користувацької мови сценаріїв для Godot був подвійним: по-перше, це скорочує час, необхідний для початку роботи з Godot, надаючи розробникам швидкий спосіб ознайомитися з рушієм, зосередившись на продуктивності; по-друге, це зменшує загальний тягар супроводу, зменшує розмірність проблем і дозволяє розробникам рушія зосередитися на виправленні помилок і покращенні функцій, пов'язаних з ядром рушія, замість того, щоб витрачати багато часу на спроби змусити невеликий набір додаткових функцій працювати на великому наборі мов.

Оскільки Godot є проектом з відкритим вихідним кодом, з самого початку було вкрай важливо віддати перевагу більш інтегрованому та бездоганному досвіду, а не залученню додаткових користувачів за допомогою підтримки більш знайомих мов програмування, особливо коли підтримка цих більш знайомих мов призведе до гіршого досвіду. Ми розуміємо, якщо ви віддасте перевагу використанню іншої мови в Godot (перегляньте список підтримуваних варіантів вище). З огляду на це, якщо ви не пробували GDScript, спробуйте його протягом трьох днів. Подібно до Godot, як тільки ви побачите, наскільки він потужний і наскільки швидким стає ваш розвиток, ми вважаємо, що GDScript підійде вам.

Більш детальну інформацію про те, як зручніше працювати з GDScript або динамічно типізованими мовами, можна знайти в посібнику GDScript: Вступ до мов динамічного типу.

Що мотивувало за створення GDScript?

На початку свого існування рушій використовував скриптову мову Lua. Lua може бути швидкою завдяки LuaJIT, але створення прив'язок до об'єктно-орієнтованої системи (за допомогою запасних варіантів) було складним і повільним і займало величезну кількість коду. Після деяких експериментів з Python, це також виявилося складним для вбудовування.

Основними причинами створення власної скриптової мови для Godot були:

  1. У більшості віртуальних машин для скриптів немає хорошої підтримки потоків виконання, а Godot використовує потоки (Lua, Python, Squirrel, JS, AS та ін.).

  2. У більшості скриптових віртуальних машин немає хорошої підтримки розширення класів, а адаптація до способу роботи Godot дуже неефективна (Lua, Python, JavaScript).

  3. Багато існуючих мов мають жахливі інтерфейси для зв'язування з C++, що призводить до великої кількості коду, помилок, вузьких місць і загальної неефективності (Lua, Python, Squirrel, JavaScript тощо). Ми хотіли зосередитися на хорошому движку, а не на великій кількості інтеграцій.

  4. Відсутність власних векторних типів (Vector3, Transform3D тощо), що призводить до значного зниження продуктивності при використанні користувацьких типів (Lua, Python, Squirrel, JavaScript, ActionScript тощо).

  5. Збирач сміття призводить до зупинки або надмірного використання пам'яті (Lua, Python, JavaScript, ActionScript та ін.).

  6. Складність інтеграції з редактором коду для забезпечення завершення коду, редагування в реальному часі тощо (всі).

GDScript був розроблений, щоб скоротити вищезазначені проблеми та багато іншого.

Яка мова програмування найшвидша?

У більшості ігор мова сценаріїв сама по собі не є причиною проблем з продуктивністю. Натомість продуктивність сповільнюється через неефективні алгоритми (які є повільними в усіх мовах), через продуктивність графічного процесора або звичайний код рушія C++, як-от фізика чи навігація. Усі мови, які підтримує Godot, достатньо швидкі для створення сценаріїв загального призначення. Вам слід вибрати мову на основі інших факторів, як-от простота використання, знайомство, підтримка платформи або мовні особливості.

Загалом продуктивність C# і GDScript знаходиться в межах одного порядку величини, а C++ швидший за обидва.

Порівнювати продуктивність GDScript із C# складно, оскільки C# може бути швидшим у деяких конкретних випадках. Сама мова C#, як правило, швидша, ніж GDScript, що означає, що C# може бути швидшим у ситуаціях з невеликою кількістю викликів коду механізму Godot. Однак C# може працювати повільніше, ніж GDScript, коли виконує багато викликів Godot API, через вартість маршалінгу. Продуктивність C# також може бути знижена через збирання сміття, яке відбувається у випадкові та непередбачувані моменти. Це може призвести до проблем із заїканням у складних проектах, і це стосується не лише Godot.

C++ із використанням GDExtension майже завжди буде швидшим, ніж C# або GDScript. Однак C++ менш простий у використанні, ніж C# або GDScript, і його розробка повільніша.

Ви також можете використовувати кілька мов в одному проекті за допомогою cross-language scripting або спільного використання GDExtension і мов сценаріїв. Майте на увазі, що це супроводжується власними ускладненнями.

Які формати 3D-моделей підтримує Godot?

Ви можете знайти детальну інформацію про підтримувані формати, як експортувати їх з вашого програмного забезпечення для 3D моделювання та як імпортувати їх для Godot у документації Імпортування 3D сцен.

Чи будуть [Пропрієтарні закриті SDK, такі як FMOD, GameWorks тощо] підтримуватися в Godot?

Метою Godot є створення вільного та відкритого рушія з ліцензією MIT, який є модульним та розширюваним. Спільнота розробників рушія не планує підтримувати будь-які сторонні, закриті/пропрієтарні SDK, оскільки інтеграція з ними суперечить принципам Godot.

Тим не менш, оскільки Godot є відкритим і модульним, ніщо не заважає вам або будь-кому іншому, хто зацікавлений, додати ці бібліотеки як модуль і постачати свою гру з ними, як з відкритим, так і з закритим вихідним кодом.

Щоб дізнатись, як може бути надана підтримка вашого SDK, перегляньте запитання про плагіни вище.

Якщо ви знаєте сторонній SDK, який не підтримується Godot, але пропонує безкоштовну інтеграцію з відкритим кодом, подумайте про те, щоб розпочати роботу над інтеграцією самостійно. Godot не належить одній людині; він належить спільноті, і він розвивається разом з амбітними учасниками спільноти, такими як ви.

Як я можу розширити Godot?

Як створювати плаґіни (додатки) до редактора Godot, перегляньте на EditorPlugins та інструментарій скриптів.

Також, дивіться офіційний блог про GDExtension, спосіб розробки власних розширень для Godot:

Ви також можете ознайомитися з реалізацією GDScript, модулями Godot, а також з інтеграцією фізичного рушія Jolt <https://github.com/godot-jolt/godot-jolt>`__ для Godot. Це буде гарною відправною точкою для ознайомлення з тим, як інтегрується з Godot інша бібліотека сторонніх розробників.

Як встановити редактор Godot на мою систему (щоб була інтеграція з робочим столом)?

Оскільки насправді вам не потрібно встановлювати Godot у вашій системі, щоб запустити його, це означає, що інтеграція з робочим столом не виконується автоматично. Є два способи подолати це. Ви можете встановити Godot з Steam (всі платформи), Scoop (Windows), Homebrew (macOS), або Flathub (Linux). Тоді кроки необхідні для інтеграції з робочим столом будуть виконані автоматично.

Крім того, ви можете вручну зробити необхідні кроки:

Windows

  • Перемістіть виконуваний файл Godot у стабільне місце (тобто за межі теки Завантаження), щоб ви випадково не перемістили його та не зламали ярлик.

  • Клацніть правою кнопкою мишки виконуваний файл Godot і виберіть команду Створити ярлик.

  • Перемістіть створений ярлик до %APPDATA%\Microsoft\Windows\Меню Пуск\Програми. Це загальне для всіх користувачів місце для ярликів, які з'являться у меню "Пуск". Ви також можете закріпити Godot на панелі завдань, клацнувши виконуваний файл правою кнопкою миші і вибравши Закріпити на панелі завдань.

macOS

Перетягніть витягнутий застосунок Godot до /Applications/Godot.app, а потім перетягніть її до Панелі, якщо хочете. Spotlight зможе знайти Godot, якщо він знаходиться в /Applications, або ~/Applications.

Linux

  • Перемістіть бінарний файл Godot у стабільне місце (тобто за межі теки Завантаження), щоб ви випадково не перемістили його та не зламали ярлик у.

  • Перейменуйте та перемістіть бінарний файл Godot у місце, на яке вказує змінна середовища PATH. Як правило, це /usr/local/bin/godot, або /usr/bin/godot. Для цього потрібні права адміністратора, але це також дозволяє вам run the Godot editor from a terminal ввівши godot.

    • Якщо ви не можете перемістити бінарний файл редактора Godot до захищеного місця, ви можете зберегти його десь у вашому домашньому каталозі та змінити рядок Path= у файлі .desktop, наведеному нижче, щоб помістити повний абсолютний шлях до бінарного файлу Godot.

  • Зберегти this .desktop file до $HOME/.local/share/applications/. If Якщо у вас є права адміністратора, ви також можете зберегти файл .desktop у /usr/local/share/applications, щоб зробити ярлик доступним для всіх користувачів.

Чи є редактор Godot портативним застосунком?

У своїй конфігурації за замовчуванням Godot є наполовину-портативним. Його виконуваний файл може працювати з будь-якого місця (включаючи місця, де не можна записувати) і ніколи не вимагає привілеїв адміністратора.

Однак файли конфігурації буде записано до користувацької конфігурації, або каталогу даних. Зазвичай це хороший підхід, але це означає, що файли конфігурації не будуть переноситися між комп'ютерами, якщо ви скопіюєте теку, що містить виконуваний файл Godot. Більше про це можна дізнатися з Шляхи до файлів у проектах Godot.

Якщо потрібна справжня портативна робота (наприклад, для використання на USB-накопичувачі), виконайте кроки в Автономний режим.

Чому Godot зберігає невеликий набір основних функцій?

Godot навмисно не включає функції, які можна реалізувати за допомогою доповнень, якщо вони не використовуються дуже часто. Одним із прикладів того, що не використовується часто, є розширені функції штучного інтелекту.

Є кілька причин для цього:

  • Супровід коду та виявлення помилок. Щоразу, коли ми приймаємо новий код до сховища Godot, існуючі дописувачі часто беруть на себе відповідальність за його супровід. Деякі дописувачі не завжди залишаються у сховищі після злиття коду, що може ускладнити нам підтримку відповідного коду. Це може призвести до поганої підтримки функцій з помилками, які ніколи не будуть виправлені. Крім того, "поверхня API", яку потрібно тестувати і перевіряти на регресії, з часом збільшується.

  • Простота внеску. Зберігання основного коду малим та охайним робить його швидким та простим для розуміння. Це полегшує новим учасникам початок роботу з Godot, не вимагаючи від них надскладних зусиль.

  • Збереження малого розміру редактора. Не кожен має швидке підключення до Інтернету. Можливість завантажити редактор Godot, розпакувати його та запустити менш ніж за 5 хвилин, робить Godot доступнішим для розробників у всіх країнах.

  • Зменшення розміру двійкових файлів для шаблонів експорту. Це безпосередньо впливає на розмір проектів, що експортуються за допомогою Godot. На мобільних і веб-платформах, щоб забезпечити швидке встановлення і завантаження на малопотужних пристроях, важливо зберігати малий розмір файлів. Знову ж таки, є багато країн, де високошвидкісний інтернет не завжди доступний. До того ж, у цих країнах часто діють суворі обмеження на використання даних.

З наведених вище причин, ми стараємося вибирати те, що можемо прийняти як основну функціональність Godot. Ось чому ми прагнемо перенести деякі основні функції до офіційно підтримуваних доповнень у майбутніх версіях Godot. Що стосується бінарного розміру, то він залежить від того, що ви фактично використовуєте у своєму проєкті. (Ви можете compile custom export templates with unused features disabled, щоб оптимізувати розмір розповсюдження вашого проєкту.)

Як слід створювати активи для обробки різних роздільних здатностей та співвідношення сторін?

Це питання часто з'являється, ймовірно, це пов'язано з непорозумінням, створеною Apple, коли вони спочатку подвоїли роздільну здатність своїх пристроїв. Це змусило людей вважати, що однакові активи в різних роздільностях були гарною ідеєю, тому багато людей продовжували рухатись до цього шляху. Це спочатку спрацювало лише для пристроїв Apple, але потім було створено кілька пристроїв Android і Apple із різними роздільною здатністю та співвідношенням сторін, з дуже широким діапазоном розмірів та DPI.

Найпоширеніший і найправильніший спосіб досягти цього - використовувати єдину базову роздільну здатність для гри і лише обробляти різні співвідношення сторін екрана. Це здебільшого потрібно для 2D, оскільки в 3D це просто питання вертикального або горизонтального FOV камери.

  1. Виберіть єдину базову роздільну здатність для вашої гри. Навіть якщо є пристрої з роздільною здатністю до 1440p і пристрої з роздільною здатністю до 400p, звичайне апаратне масштабування у вашому пристрої подбає про це з мінімальними витратами на продуктивність або взагалі без них. Найпоширеніші варіанти - близько 1080p (1920x1080) або 720p (1280x720). Майте на увазі, що чим вища роздільна здатність, тим більші ваші ресурси, тим більше пам'яті вони займають і тим довше завантажуються.

  2. Використовуйте параметри розтягування у Godot; найкраще працює розтягування елементів полотна зі збереженням співвідношення сторін. Про те, як цього досягти, див. підручник Кілька дозволів.

  3. Визначте мінімальну роздільну здатність, а потім вирішіть, чи бажаєте ви, щоб ваша гра розтягувалася вертикально чи горизонтально для різних пропорцій, чи існує одне співвідношення сторін і ви хочете, щоб натомість з’явилися чорні смуги. Це також пояснюється в Кілька дозволів.

  4. Для користувацьких інтерфейсів використовуйте anchoring, щоб визначити, де елементи керування повинні залишатися, а де рухатися. Якщо користувацькі інтерфейси (UI) складніші, ознайомтеся з інформацією про контейнери (Containers).

І це все! Ваша гра повинна працювати в декількох роздільностях.

Коли наступний реліз?

Коли він буде готовий! Додаткову інформацію дивіться в Коли наступний реліз?.

Яку версію Godot використовувати для нового проекту?

Ми рекомендуємо використовувати Godot 4.x для нових проектів, але залежно від набору функцій, який вам потрібен, може бути краще використовувати 3.x. Дивіться Яку версію використовувати для нового проекту? для отримання додаткової інформації.

Чи варто мені оновити свій проект, щоб використовувати нові версії Godot?

Деякі нові версії безпечніші для оновлення, ніж інші. Загалом, рішення про необхідність оновлення залежить від обставин вашого проекту. Докладнішу інформацію можна знайти на сторінці Чи потрібно оновлювати свій проект, щоб використовувати нові версії рушіїв?.

Чи варто мені використовувати засіб візуалізації Forward+, Mobile або Compatibility?

Ви можете знайти детальне порівняння рендерів у Огляд рендерерів.

Я хотів би зробити свій внесок! З чого почати?

Чудово! Як проект з відкритим вихідним кодом, Godot процвітає завдяки інноваціям та амбіціям таких розробників, як ви.

Найкращий спосіб почати долучатися до роботи з Godot - це користуватися ним і повідомляти про будь-які issues, з якими ви можете зіткнутися. Гарне повідомлення про ваду з чіткими кроками для її відтворення допоможе вашим колегам швидко та ефективно виправити ваду. Ви також можете повідомити про проблеми, які ви знайшли у онлайн документації.

Якщо ви відчуваєте, що готові подати свій перший PR, виберіть будь-яку проблему, яка резонує з вами, з одного з посилань вище і спробуйте виправити її. Вам потрібно буде навчитися компілювати рушій з вихідних кодів або створювати документацію. Вам також потрібно ознайомитися з Git'ом, системою контролю версій, яку використовують розробники Godot.

Ми пояснюємо, як працювати з вихідним кодом движка, як редагувати документацію та які інші способи зробити свій внесок є в нашому документація для учасників.

У мене є чудова ідея для Godot. Як я можу поділитися нею?

Ми завжди відкриті для пропозицій щодо покращення рушія. Відгуки користувачів є основною рушійною силою нашого процесу прийняття рішень, а обмеження, з якими ви можете зіткнутися під час роботи над своїм проектом, є для нас чудовим джерелом даних, коли ми розглядаємо можливість удосконалення рушія.

Якщо у вас виникли складнощі з використанням, або ви не можете знайти якусь функцію в поточній версії Godot, спробуйте обговорити це з нашою спільнотою. Там ви можете знайти й інші, можливо навіть кращі, варіанти вирішення свого питання. Окрім того ви зможете дізнатися, чи виникають подібні складнощі в іншим користувачів, і разом знайти оптимальне рішення.

Якщо ж у вас виникла чітка ідея для покращення рушія, то не соромтеся створити пропозицію. Старайтеся чітко і зрозуміло викласти свою проблему і варіанти її рішення — розглядаються лише дієві пропозиції. Це не обов'язково, але ми цінуємо бажання користувачів самостійно реалізовувати свої ідеї!

Якщо у вас є лише загальна ідею без конкретних деталей, то ви можете відкрити обговорення пропозиції. Так, в формі вільного спілкування, можна, що-завгодно обговорювати шукаючи рішення. Коли ж рішення буде знайдене, можна буде створити пропозицію покращення рушія.

Будь-ласка, прочитайте документ readme перед створенням пропозиції, щоб дізнатися більше про цей процес.

Чи можливо використовувати Godot для створення не ігрових застосунків?

Так! Godot має об'ємну вбудовану систему інтерфейсу користувача, і невеликий розмір, що робить його непоганою альтернативою для таких фреймворків, як Electron, чи Qt.

Див. Створення додатків для отримання додаткової інформації.

Чи можливо використовувати Godot як бібліотеку ?

Якщо ви хочете створити гру за допомогою Godot, пам’ятайте, що Godot розроблено для використання з його редактором. Ми рекомендуємо вам спробувати, оскільки це, найімовірніше, заощадить ваш час у довгостроковій перспективі.

Для більш спеціалізованих застосувань може бути доцільно розглянути використання Godot як бібліотеки. Починаючи з Godot 4.6, існує експериментальна підтримка використання Godot як статичної або спільної бібліотеки у вигляді LibGodot. Наразі це підтримується у Windows, macOS та Linux. Підтримка Android та iOS запланована на майбутній реліз.

Ви можете знайти приклади програм, що використовують Godot як бібліотеку, у репозиторії migeran/libgodot_project GitHub.

Який набір інструментів користувальницького інтерфейсу використовує Godot?

Godot не використовує стандартний набір інструментів GUI, такий як GTK, Qt або wxWidgets. Натомість Godot використовує власний набір інструментів інтерфейсу користувача, який завжди відтворюється за допомогою апаратного прискорення. Вбудованого програмного резервного копіювання немає, хоча можна використовувати зовнішні рішення, що емулюють графічні API на процесорі.

Цей інструментарій представлений у вигляді вузлів керування, які використовуються для рендерингу редактора (який написаний на C++). Ці вузли керування також можна використовувати в проектах з будь-якої мови сценаріїв, що підтримується Godot.

Цей спеціальний набір інструментів дає змогу отримати вигоду від апаратного прискорення та мати стабільний вигляд на всіх платформах. На додачу до цього, йому не доведеться мати справу із застереженнями щодо ліцензування LGPL, які поставляються з GTK або Qt. Нарешті, це означає, що Godot «їсть власну собачу їжу», оскільки сам редактор є одним із найскладніших користувачів системи інтерфейсу Godot.

Цей набір інструментів для створення користувацького інтерфейсу можна вбудовувати в інші програми (експериментально). Однак, кращим способом його використання є використання Godot для створення неігрових програм за допомогою редактора.

Чому Godot використовує систему збірки SCons?

Godot використовує систему збірки SCons. Найближчим часом не планується перехід на іншу систему збірки. Є багато причин, чому ми вибрали SCons замість інших альтернатив. Наприклад:

  • Godot можна скомпілювати для дюжини різних платформ: усіх платформ ПК, усіх мобільних платформ, багатьох консолей і WebAssembly.

  • Розробникам часто потрібно компілювати для кількох платформ одночасно або навіть для різних цілей однієї платформи. Вони не можуть дозволити собі щоразу перелаштовувати та перебудовувати проект. SCons може робити це без зайвих зусиль, не порушуючи збірки.

  • SCons ніколи не ламає збірку незалежно від кількості змін, конфігурацій, доповнень, видалень тощо.

  • Процес збирання Godot не простий. Частина файлів генеруються кодом (зв’язувачі), інші аналізуються (шейдери), ще інші потребують налаштування (modules). Для цього потрібна складна логіка, яку легше написати реальною мовою програмування (наприклад, Python), а не використовувати мову на основі макросів, призначену лише для створення.

  • Процес збирання Godot активно використовує інструменти крос-компіляції. Кожна платформа має певний процес виявлення, і всі вони повинні розглядатися як окремі випадки з написанням спеціального коду для кожного.

Будь ласка, постарайтеся хоча б трохи ознайомитися з SCons, якщо ви плануєте зібрати Godot самостійно.

Чому Godot не використовує STL (Standard Template Library)?

Як і багато інших бібліотек (наприклад, Qt), Godot не використовує STL (за деякими винятками, такими як примітиви потоків). Ми вважаємо, що STL є чудовою універсальною бібліотекою, але у нас були особливі вимоги до Godot.

  • Шаблони STL створюють дуже великі символи, що призводить до величезних бінарних файлів. Натомість ми використовуємо кілька шаблонів із дуже короткими назвами.

  • Більшість наших контейнерів задовольняють особливі потреби, наприклад Vector, який використовує копіювання при записі, яке ми використовуємо для передачі даних, або систему RID, яка вимагає O (1) часу доступу для продуктивності. Аналогічно, наші реалізації хеш-карт призначені для безшовних інтеграції з внутрішніми типами рушіїв.

  • В наші контейнери вбудована функція відстеження використання пам'яті, яка допомагає краще здійснювати контроль за використанням пам'яті.

  • Для великих масивів ми використовуємо пам'ять у вигляді пулів, які відображаються або на попередньо виділений буфер, або на віртуальну пам'ять.

  • Ми використовуємо наш власний тип String, так як надається STL є занадто простим і не має належної підтримки інтернаціоналізації.

Перегляньте Godot's container types для альтернатив.

Чому Godot не використовує винятки?

Ми вважаємо, що гри не повинні краш, незважаючи ні на що. Якщо трапиться несподівана ситуація, Godot видасть помилку (яку можна відстежити аж до скрипта), але потім спробує виправити її якомога витонченішою і продовжити роботу.

Крім того, винятки значно збільшують двійковий розмір виконуваного файлу і призводять до збільшення часу компіляції.

Чи використовує Godot ECS (Entity Component System)?

Godot не використовує ECS, натомість він покладається на спадкування. Хоча універсального кращого підходу не існує, ми виявили, що використання підходу на основі успадкування покращує зручність використання, але при цьому залишається достатньо швидким для більшості випадків використання.

Однак ніщо не заважає вам використовувати композицію у вашому проекті, створюючи дочірні вузли з окремими сценаріями. Потім ці вузли можна додавати та вилучати під час виконання, щоб динамічно додавати та вилучати поведінку.

Більше інформації про варіанти архітектури Godot можна знайти в цій статті.

Чому Godot не змушує користувачів впроваджувати DOD (Data-Oriented Design)?

Хоча всередині Godot намагається використовувати когерентність кешу якомога більше, ми вважаємо, що користувачів не потрібно змушувати використовувати методи DOD.

DOD - це здебільшого оптимізація когерентності кешу, яка може забезпечити значний приріст продуктивності лише при роботі з десятками тисяч об'єктів, які обробляються кожного кадру з невеликими змінами. Тобто, якщо ви переміщуєте кілька сотень спрайтів або ворогів за кадр, DOD не призведе до значного покращення продуктивності. У такому випадку варто розглянути інший підхід до оптимізації.

Переважна більшість ігор в цьому не мають потреби, і Godot надає зручних помічників, які підходять для більшості випадків.

Якщо гра має обробляти таку велику кількість об'єктів, ми рекомендуємо використовувати C++ та GDExtensions для завдань, що вимагають високої продуктивності, та GDScript (або C#) для решти гри.

Як я можу підтримати розвиток Godot, або зробити свій внесок?

Див. Як зробити внесок.

Хто працює над Godot? Як я можу зв'язатися з вами?

Дивіться відповідну сторінку на вебсайті Godot.