Поширені запитання¶
Що я можу зробити з Godot? Скільки це коштує? Які ліцензійні умови?¶
Godot — це відкрите та вільне програмне забезпечення, яке розповсюджується за умов дотримання затвердженої OSI ліцензії MIT. Це означає, що Godot — вільне, як «вільне висловлювання», і вільне, як «вільне пиво».
Коротко:
Ви можете вільно отримати Godot і користуватися ним для будь-яких потреб, особистих, некомерційних, комерційних або інших.
Ви можете модифікувати, поширювати і поєднувати Godot із іншими компонентами так, як цього забажаєте, для будь-якої мети, некомерційної або комерційної.
Весь вміст документації оприлюднено за умов дотримання дозвільної ліцензії Creative Commons Attribution 3.0 (CC-BY 3.0) за авторством "Juan Linietsky, Ariel Manzur та спільноти Godot Engine."
Логотипи та значки, як правило, знаходяться під однією ліцензією Creative Commons. Зауважте, що деякі сторонні бібліотеки, включені до вихідного коду Godot, можуть мати різні ліцензії.
Щоб отримати докладнішу інформацію, перегляньте файли COPYRIGHT.txt , а також LICENSE.txt і LOGO_LICENSE.txt в репозиторії Godot.
Також див. сторінку ліцензії на вебсайті Godot.
Які платформи підтримуються Godot?¶
Для редактора:
Windows
macOS
X11 (Linux, *BSD)
Android (експериментальний)
Для експорту ваших ігор:
Windows (і UWP)
macOS
X11 (Linux, *BSD)
Android
iOS
Інтернет
Передбачено підтримку створення 32-х та 64-х бітових виконуваних файлів, де це можливо, типовими є 64-х бітові.
Деякими користувачами повідомлялося про успішне збирання та використання Godot на заснованих на ARM системах із ядром Linux, зокрема на Raspberry Pi.
Також проводяться деякі неофіційні роботи третіх сторін над запуском збірок для деяких консолей, однак їх не включено в типові скрипти збірки або шаблони експорту.
Щоб дізнатись більше про це, перегляньте розділи про експортування та компілювання Godot самостійно.
Підтримку яких мов програмування передбачено у Godot?¶
Офіційно підтримуваними мовами для Godot є GDScript, Visual Scripting, C# і C++. Див. підкатегорії для кожної мови в розділі скриптинґ.
Якщо ви лише робите перші кроки з Godot або у розробці ігор загалом, - рекомендуємо мову GDScript для вивчення та використання, так як це рідна мова для Godot. Хоча скриптові мови програмування як правило менш продуктивні ніж низькорівневі в довгостроковій перспективі, для прототипування, розробки Мінімально Життєзданих Продуктів (MVPs) та фокусі на Time-To-Market (TTM), GDScript забезпечить швидкий, дружній та надійний спосіб для розробки ваших ігор.
Зауважте, що підтримка C# все ще відносно нова, і тому ви можете зіткнутися з деякими проблемами. Наше дружнє та працьовите співтовариство розробників завжди готове вирішувати нові проблеми, коли вони виникають, але оскільки це проєкт з відкритим вихідним кодом, ми рекомендуємо спочатку самостійно провести певну ретельну перевірку. Пошук безпосередньо в дискусіях у open issues є відмінним способом розпочати вирішення виниклих проблем.
Що стосується нових мов, можлива підтримка за допомогою стороннього коду з використанням можливостей GDNative / NativeScript / PluginScript. (Див. питання щодо додатків нижче.) Також ведуться роботи, наприклад, над неофіційними прив'язками Godot до Python і Nim.
Що таке GDScript і чому я повинен, це використовувати?¶
GDScript - це інтегрована у Godot скриптова мова. Її було створено з нуля з метою максимально розкрити потенціал Godot з мінімальною кількістю коду, що дозволяє як початківцям, так і досвідченим розробникам якнайшвидше зосередитися на сильних сторонах Godot. Якщо ви маєте досвід з мовами, схожими на Python, ви почуватимете себе як вдома. Приклади коду, історія та повний огляд можливостей, які пропонує вам GDScript знаходяться у розділі GDScript scripting guide <doc_gdscript>.
Є декілька причин використовувати GDScript: особливо, якщо ви створюєте прототип, знаходитесь в альфа/бета стадіях розробки вашого проєкту або не створюєте наступну гру AAA-класу. Проте, найбільш суттєвою причиною є загальне зменшення складності.
Першочерговый намір створення щільно інтегрованої скриптової мови для Godot був неоднозначним: по-перше, це зменшує кількість часу, необхідного, щоб розпочати роботу з Godot, надаючи розробникам швидкий спосіб доступу до двигуна з акцентом на продуктивність; по-друге, це зменшує загальне навантаження на технічне обслуговування, зменшує розмірність проблем, і дозволяє розробникам двигуна зосередитися на усуненні помилок і покращенні функцій, пов'язаних з ядром двигуна, а не витрачати багато часу, намагаючись отримати невеликий набір додаткових функцій, працюючих на великій кількості мов.
Оскільки Godot є проєктом з відкритим вихідним кодом, з самого початку було необхідно надавати перевагу більш інтегрованому і безшовний досвіду над залученням додаткових користувачів, підтримуючи знайоміші мови програмування, особливо якщо підтримка цих більш знайомих мов призведе до гіршого досвіду. Ми розуміємо, якщо ви хотіли б використовувати іншу мову в Godot (див. список підтримуваних варіантів вище). Тому, якщо ви ще не спробували GDScript, спробуйте його протягом трьох днів. Так само, як Godot, як тільки ви побачите, наскільки потужнию і швидкою стає ваша розробка, ми думаємо, GDScript виросте у ваших очах.
Більш детальну інформацію про те, як зручніше працювати з GDScript або динамічно типізованими мовами, можна знайти в посібнику GDScript: Вступ до мов динамічного типу.
Що мотивувало за створення GDScript?¶
На самому початку движок використовував для написання скриптів мову Lua. Lua швидка, але створення прив'язок до об'єктно-орієнтованої системи (за допомогою резервних копій) було складним та повільним і вимагало величезної кількості коду. Після деяких експериментів з Python, виявилося, що він також не зовсім підходить.
Основними причинами створення власної скриптової мови для Godot були:
У більшості віртуальних машин для скриптів немає хорошої підтримки потоків виконання, а Godot використовує потоки (Lua, Python, Squirrel, JS, AS та ін.).
У більшості скриптових віртуальних машин немає хорошої підтримки розширення класів, а адаптація до способу роботи Godot дуже неефективна (Lua, Python, JavaScript).
Багато існуючих мов мають жахливі інтерфейси для прив'язки до C++, що призводить до великої кількості коду, помилок, вузьких місць і загальної неефективності (Lua, Python, Squirrel, JS і т.д.). Ми хотіли зосередитися на великому рушії, а не на великій кількості інтеграцій.
Відсутність рідних векторних типів (vector3, matrix4 та ін.), що призводить до значного зниження продуктивності при використанні власних типів (Lua, Python, Squirrel, JS, AS та ін.).
Збирач сміття призводить до зупинки або надмірного використання пам'яті (Lua, Python, JavaScript, ActionScript та ін.).
Труднощі інтеграції з редактором коду для забезпечення завершення коду, редагування в реальному часі тощо (всі вони). Це добре підтримується GDScript.
GDScript був розроблений, щоб скоротити вищезазначені проблеми та багато іншого.
Який тип форматів 3D-моделей підтримує Godot?¶
Тим не менш, підтримка Collada у Godot хороша, будь ласка, використовуйте OpenCollada експортер для максимальної сумісності, якщо ви використовуєте Maya або 3DS Max. Якщо ви використовуєте Blender, подивіться на наш власний Better Collada Exporter.
Починаючи з Godot 3.0, glTF підтримується.
Підтримку FBX реалізовано за допомогою бібліотеки Open Asset Import. Однак FBX є патентованим, тому ми рекомендуємо використовувати інші формати, перелічені вище, які підходить для вашого робочого процесу.
Чи будуть [Пропрієтарні закриті SDK, такі як FMOD, GameWorks тощо] підтримуватися в Godot?¶
Мета Godot полягає у створенні вільного і з відкритим вихідним кодом, MIT ліцензованого двигуна, який є модульним і розширюваним. Спільнота розробників двигуна не планує підтримувати будь-які сторонні, приватні/з закритим вихідним кодом SDK, оскільки інтеграція з ними буде суперечити ідеалу Godot.
Тим не менш, оскільки він з відкритим джерелом, та модульний, ніщо не заважає вам або будь-кому іншому зацікавленому додавати ці бібліотеки в якості модуля та поширювати вашу гру за допомогою них як відкритого, так і закритого джерела.
Щоб дізнатись, як може бути надана підтримка вашого SDK, перегляньте запитання про плагіни вище.
Якщо ви знаєте стороннє SDK, яке не підтримується Godot, але при цьому надає вільну інтеграцію, та є з відкритим кодом, розгляньте можливість інтеграції самостійно. Godot не належить одній людині; він належить спільноті, і росте разом з амбіційними учасниками спільноти, такими, як ви.
Як встановити редактор Godot на мою систему (щоб була інтеграція з робочим столом)?¶
Оскільки насправді вам не потрібно встановлювати Godot у вашій системі, щоб запустити його, це означає, що інтеграція з робочим столом не виконується автоматично. Є два способи подолати це. Ви можете встановити Godot з Steam (всі платформи), Scoop (Windows), Homebrew (macOS), або Flathub (Linux). Тоді кроки необхідні для інтеграції з робочим столом будуть виконані автоматично.
Крім того, ви можете вручну зробити необхідні кроки:
Windows¶
Перемістіть виконуваний файл Godot у стабільне місце (тобто за межі теки Завантаження), щоб ви випадково не перемістили його та не зламали ярлик.
Клацніть правою кнопкою мишки виконуваний файл Godot і виберіть команду Створити ярлик.
Перемістити створений ярлик до
%LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. Це загальнодоступне для користувачів розташування ярликів, які з'являться в меню Пуск. Також можна закріпити Godot на панелі завдань, клацнувши правою кнопкою мишки виконуваний файл і вибравши Закріпити на панелі завдань.
macOS¶
Перетягніть витягнутий застосунок Godot до /Applications/Godot.app, а потім перетягніть її до Панелі, якщо хочете. Spotlight зможе знайти Godot, якщо він знаходиться в /Applications, або ~/Applications.
Linux¶
Перемістіть бінарний файл Godot у стабільне місце (тобто за межі теки Завантаження), щоб ви випадково не перемістили його та не зламали ярлик у.
Перейменуйте та перемістіть бінарний файл Godot у місце, на яке вказує змінна середовища
PATH. Як правило, це/usr/local/bin/godot, або/usr/bin/godot. Для цього потрібні права адміністратора, але це також дозволяє вам запустити Godot з термінала ввівшиgodot.Якщо ви не можете перемістити бінарний файл редактора Godot до захищеного місця, ви можете зберегти його десь у вашому домашньому каталозі та змінити рядок
Path=у файлі.desktop, наведеному нижче, щоб помістити повний абсолютний шлях до бінарного файлу Godot.
Збережіть цей файл .desktop до
$HOME/.local/share/applications/. Якщо у вас є права адміністратора, ви також можете зберегти файл.desktopдо/usr/local/share/applications, щоб зробити ярлик доступним для всіх користувачів.
Чи є редактор Godot портативним застосунком?¶
У своїй конфігурації за замовчуванням Godot є наполовину-портативним. Його виконуваний файл може працювати з будь-якого місця (включаючи місця, де не можна записувати) і ніколи не вимагає привілеїв адміністратора.
Однак файли конфігурації буде записано до користувацької конфігурації, або каталогу даних. Зазвичай це хороший підхід, але це означає, що файли конфігурації не будуть переноситися між комп'ютерами, якщо ви скопіюєте теку, що містить виконуваний файл Godot. Більше про це можна дізнатися з Шляхи до файлів у проектах Godot.
Якщо потрібна справжня портативність (наприклад, для використання на USB-накопичувачі), виконайте наступні кроки Автономний режим.
Чому Godot використовує Vulkan, або OpenGL, замість Direct3D?¶
Godot націлений, в першу чергу, на сумісність між різними платформами та відкриті стандарти. OpenGL та Vulkan - це технології, які одночасно відкриті та доступні на всіх (майже) платформах. Завдяки цьому проєкт, розроблений за допомогою Godot для Windows, буде працювати і на Linux, macOS та інших.
Оскільки над засобом обробки даних Godot працює лише декілька розробників, ми намагаємося мінімізувати кількість супроводжуваних модулів обробки. У надбудовах над модулями обробки використання єдиного програмного інтерфейсу для усіх платформ забезпечує вищу однорідність та зменшує кількість специфічних для платформ проблем.
У довгостроковій перспективі ми можемо розробити візуалізатор Direct3D 12 для Godot (в основному для Xbox), але Vulkan і OpenGL залишаться основними візуалізаторами на всіх платформах, включаючи Windows.
Чому Godot зберігає невеликий набір основних функцій?¶
Godot навмисно не включає функції, які можуть бути реалізовані додатками, якщо вони не використовуються дуже часто. Одним із прикладів може бути вдосконалена функціональність штучного інтелекту.
Є кілька причин для цього:
Обслуговування коду та можливі помилки. Кожен раз, коли ми доповнюємо Godot новим кодом, існуючі автори часто беруть на себе відповідальність за його підтримку. Деякі з них не завжди залишаються на місці після цього і це може ускладнити нам підтримку відповідного коду. Це може призвести до погано підтримуваних функцій із помилками, які нікому виправити. Крім того, "об'єм API", що потрібно протестувати та перевірити на наявність помилок, з часом збільшується.
Простота внеску. Зберігання основного коду малим та охайним робить його швидким та простим для розуміння. Це полегшує новим учасникам початок роботу з Godot, не вимагаючи від них надскладних зусиль.
Збереження малого розміру редактора. Не кожен має швидке підключення до Інтернету. Можливість завантажити редактор Godot, розпакувати його та запустити менш ніж за 5 хвилин, робить Godot доступнішим для розробників у всіх країнах.
Збереження малого розміру шаблонів експорту. Це безпосередньо впливає на розмір проєктів, експортованих разом з Godot. На мобільних та вебплатформах малий розмір файлів є пріоритетним, для забезпечення швидкої установки та завантаження на слабкі пристрої. Знову ж таки, є багато країн, де швидкісний Інтернет недоступний. До того ж у цих країнах часто діють суворі обмеження використання даних.
З наведених вище причин, ми стараємося вибирати те, що можемо прийняти як основну функціональність Godot. Ось чому ми прагнемо перенести деякі основні функції до офіційно підтримуваних доповнень у майбутніх версіях Godot. Що стосується бінарного розміру, то він залежить від того, що ви фактично використовуєте у своєму проєкті. (Ви можете скласти власні шаблони експорту з вимкненими невикористаними функціями, щоб оптимізувати розмір розповсюдження вашого проєкту.)
Як слід створювати активи для обробки різних роздільних здатностей та співвідношення сторін?¶
Це питання часто з'являється, ймовірно, це пов'язано з непорозумінням, створеною Apple, коли вони спочатку подвоїли роздільну здатність своїх пристроїв. Це змусило людей вважати, що однакові активи в різних роздільностях були гарною ідеєю, тому багато людей продовжували рухатись до цього шляху. Це спочатку спрацювало лише для пристроїв Apple, але потім було створено кілька пристроїв Android і Apple із різними роздільною здатністю та співвідношенням сторін, з дуже широким діапазоном розмірів та DPI.
Найпоширеніший і правильний спосіб досягти цього полягає в тому, щоб замість цього застосовувати єдину базову роздільну здатність для гри та обробляти лише різні співвідношення екрану. Це, в основному, потрібно для 2D, так як у 3D це просто питання осей камери (Camera XFov або YFov).
Виберіть єдину базову роздільну здатність для вашої гри. Навіть якщо є пристрої, які досягають 2K, та пристрої, які знижуються до 400p, звичайне апаратне масштабування на вашому пристрої буде забезпечувати її за невелику втрату або без втрати продуктивності. Найпоширеніші варіанти вибору - біля 1080p (1920x1080) або 720p (1280x720). Пам'ятайте, чим більша роздільна здатність, тим більші ваші активи, та тим більше пам'яті вони забирають, і довшим буде час для завантаження.
Використовуйте параметри розтяжки в Godot, 2D розтягування з підтримкою пропорції працює краще. Перевірте Multiple resolutions посібник про те, як це досягти.
Визначте мінімальну роздільну здатність, а потім вирішіть, чи потрібно вам, щоб ваша гра розтягувалася по вертикалі або по горизонталі для співвідношення сторін, або була в одному мінімальному співвідношенні, з відображенням чорних смуг по краях. Це також пояснюється у попередньому кроці.
Для користувацьких інтерфейсів використовуйте закріплення, щоб визначити, де елементи керування повинні залишатися, а де рухатися. Якщо користувацькі інтерфейси (UI) складніші, ознайомтеся з інформацією про контейнери (Containers).
І це все! Ваша гра повинна працювати в декількох роздільностях.
Якщо є бажання, щоб ваша гра також працювала на стародавніх пристроях із крихітними екранами (шириною менше 300 пікселів), ви можете скористатись експортом, щоб зменшити зображення, і встановити, які збірки використовуватимуться для певних розмірів екрана в App Store або Google Play.
Як я можу розширити Godot?¶
Як створювати плаґіни (додатки) до редактора Godot, перегляньте на Плаґіни редактора та інструментарій скриптів.
Також див. дописи в офіційному блозі за цими темами:
Ви також можете поглянути на реалізацію GDScript, модулів Godot, а також на неофіційну підтримку Python для Godot. Це було б хорошою початковою точкою для того, щоб побачити, як інша стороння бібліотека інтегрується з Godot.
Коли наступний реліз?¶
Коли він буде готовий! Додаткову інформацію дивіться в Коли наступний реліз?.
Я хотів би зробити свій внесок! З чого почати?¶
Чудово! Як проєкт з відкритим кодом, Godot процвітає від інновацій та амбіцій таких розробників, як ви.
Для початку вам потрібно ознайомитися з розділом проблеми <https://github.com/godotengine/godot/issues> _. Знайдіть проблему, яка вас зацікавила, потім перейдіть до Як внести свій вклад <https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md#contributing-pull-requests> _, щоб дізнатися як створити форк , модифікувати, і створити Pull Request (PR) з вашими змінами.
Чи можливо використовувати Godot для створення не ігрових застосунків?¶
Так! Godot має об'ємну вбудовану систему інтерфейсу користувача, і невеликий розмір, що робить його непоганою альтернативою для таких фреймворків, як Electron, чи Qt.
При створенні не ігрового застосунку не забудьте увімкнути low-processor mode в Параметрах Проєкту щоб зменшити використання CPU і GPU.
Тим не менш, ми не рекомендуємо використовувати Godot для створення мобільного застосунку, оскільки режим з низьким процесором поки не підтримується на мобільних платформах.
Загляньте в Material Maker і Pixelorama для прикладів застосунків із відкритим кодом, зроблених за допомогою Godot.
Чи можливо використовувати Godot як бібліотеку ?¶
У Godot інтегрований редактор. Ми рекомендуємо вам спробувати його, так як в далекій перспективі він збереже вам велику кількість вашого часу. Ми не плануємо випускати Godot в якості бібліотеки, оскільки це може зробити інші частини рушія заплутаними і зробити сам рушій незручним для використання.
Вам подобаються графічні бібліотеки ? Зверніть увагу на популярний графічний рушій. Пам'ятайте, що звичайні рушії зазвичай мають меншу спільноту у порівнянні з Godot. У зв'зку з цим у вас можуть виникнути проблеми з пошуком відповідей на ваші запитання.
Який набір інструментів користувальницького інтерфейсу використовує Godot?¶
Godot не використовує стандартний набір інструментів GUI, як GTK, Qt або wxWidgets. Натомість Godot використовує власний набір інструментів користувальницького інтерфейсу, відтворений за допомогою OpenGL ES або Vulkan. Цей набір інструментів представлений у вигляді вузлів керування, які використовуються для візуалізації редактора (який написаний на C++). Ці вузли управління також можуть бути використані в проєктах на будь-якій скриптовій мові, що підтримується Godot.
Цей спеціальний набір інструментів дає змогу отримати вигоду від апаратного прискорення та мати стабільний вигляд на всіх платформах. На додачу до цього, йому не доведеться мати справу із застереженнями щодо ліцензування LGPL, які поставляються з GTK або Qt. Нарешті, це означає, що Godot «їсть власну собачу їжу», оскільки сам редактор є одним із найскладніших користувачів системи інтерфейсу Godot.
Цей власний набір інструментів інтерфейсу користувача не можна використати, як бібліотеку, проте ви все ще можете використати Godot для створення не ігрових застосунків.
Чому Godot не використовує STL (Standard Template Library)?¶
Як і багато інших бібліотек (Qt як приклад), Godot не використовує STL. Ми вважаємо, що STL - це непогана бібліотека загального призначення, але до Godot ми мали особливі вимоги.
Шаблони STL створюють дуже великі символи, що призводить до величезних бінарних файлів. Натомість ми використовуємо кілька шаблонів із дуже короткими назвами.
Більшість наших контейнерів задовольняють особливі потреби, наприклад Vector, який використовує копіювання при записі, яке ми використовуємо для передачі даних, або систему RID, яка вимагає O (1) часу доступу для продуктивності. Аналогічно, наші реалізації хеш-карт призначені для безшовних інтеграції з внутрішніми типами двигунів.
В наші контейнери вбудована функція відстеження використання пам'яті, яка допомагає краще здійснювати контроль за використанням пам'яті.
Для великих масивів ми використовуємо пам'ять у вигляді пулів, які відображаються або на попередньо виділений буфер, або на віртуальну пам'ять.
Ми використовуємо наш власний тип String, так як надається STL є занадто простим і не має належної підтримки інтернаціоналізації.
Чому Godot не використовує винятки?¶
Ми вважаємо, що гри не повинні краш, незважаючи ні на що. Якщо трапиться несподівана ситуація, Godot видасть помилку (яку можна відстежити аж до скрипта), але потім спробує виправити її якомога витонченішою і продовжити роботу.
Крім того, виключення значно збільшують розмір довічного виконуваного файлу.
Чому Godot не нав'язує застосування RTTI?¶
Godot надає власну систему приведення типів, внутрішня реалізація якої передбачає можливість використання RTTI. Відключення RTTI в Godot означає досягнення значно меншого обсягу довічних виконуваних файлів ціною невеликої втрати продуктивності.
Чому Godot не примушує користувачів до впровадження DoD (дизайн, орієнтований на дані)?¶
Ми вважаємо, що поки Godot за рахунок внутрішніх ресурсів намагається якомога краще використовувати когерентність кеш для безлічі високопродуктивних завдань, більшість користувачів не потребують використання дата-орієнтованого дизайну (DoD).
DoD - це в основному оптимізація когерентності кеша, яка починає давати значне поліпшення продуктивності тільки при роботі з десятками тисяч об'єктів (які обробляються кожен кадр з невеликою зміною). Тобто, якщо ви переміщаєте кілька сотень спрайтів або ворогів на кадр, DoD не допоможе вам, і ви повинні розглянути інший підхід до оптимізації.
Переважна більшість ігор в цьому не мають потреби, і Godot надає зручних помічників, які підходять для більшості випадків.
Якщо необхідна гра, яка дійсно потребує обробки великої кількості об'єктів, ми рекомендуємо використовувати C ++ і GDNative для місць, де потрібна висока продуктивність, і GDScript (або C #) для іншої частини гри.
Як я можу підтримати розвиток Godot, або зробити свій внесок?¶
Хто працює над Godot? Як я можу зв'язатися з вами?¶
Дивіться відповідну сторінку на вебсайті Godot.