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

Що я можу зробити з 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)

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

  • 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 були:

  1. У більшості віртуальних машин для скриптів немає хорошої підтримки потоків виконання, а Godot використовує потоки (Lua, Python, Squirrel, JS, AS та ін.).
  2. У більшості скриптових віртуальних машин немає хорошої підтримки розширення класів, а адаптація до способу роботи Godot дуже неефективна (Lua, Python, JavaScript).
  3. Багато існуючих мов мають жахливі інтерфейси для прив'язки до C++, що призводить до великої кількості коду, помилок, вузьких місць і загальної неефективності (Lua, Python, Squirrel, JS і т.д.). Ми хотіли зосередитися на великому рушії, а не на великій кількості інтеграцій.
  4. Відсутність рідних векторних типів (vector3, matrix4 та ін.), що призводить до значного зниження продуктивності при використанні власних типів (Lua, Python, Squirrel, JS, AS та ін.).
  5. Збирач сміття призводить до зупинки або надмірного використання пам'яті (Lua, Python, JavaScript, ActionScript та ін.).
  6. Труднощі інтеграції з редактором коду для забезпечення завершення коду, редагування в реальному часі тощо (всі вони). Це добре підтримується 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 не належить одній людині; він належить спільноті, і росте разом з амбіційними учасниками спільноти, такими, як ви.

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

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

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

  1. Виберіть єдину базову роздільну здатність для вашої гри. Навіть якщо є пристрої, які досягають 2K, та пристрої, які знижуються до 400p, звичайне апаратне масштабування на вашому пристрої буде забезпечувати її за невелику втрату або без втрати продуктивності. Найпоширеніші варіанти вибору - біля 1080p (1920x1080) або 720p (1280x720). Пам'ятайте, чим більша роздільна здатність, тим більші ваші активи, та тим більше пам'яті вони забирають, і довшим буде час для завантаження.
  2. Використовуйте параметри розтяжки в Godot, 2D розтягування з підтримкою пропорції працює краще. Перевірте Multiple resolutions посібник про те, як це досягти.
  3. Визначте мінімальну роздільну здатність, а потім вирішіть, чи потрібно вам, щоб ваша гра розтягувалася по вертикалі або по горизонталі для співвідношення сторін, або була в одному мінімальному співвідношенні, з відображенням чорних смуг по краях. Це також пояснюється у попередньому кроці.
  4. Для користувацьких інтерфейсів використовуйте закріплення, щоб визначити, де елементи керування повинні залишатися, а де рухатися. Якщо користувацькі інтерфейси (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, наприклад, ті, які призводять до масивних змін ядра, якогось наслідування того, що робить інший ігровий движок, або реалізувати альтернативні робочі процеси, які ви хотіли б вмонтувати в редактор. Це здорово, і ми вдячні за те, що такі мотивовані люди хочуть внести свій внесок, але Godot завжди буде сфокусований на тому, що зазначено в дорожній карті, тема" усунення помилок і неполадок "знаходиться за цим посиланням <https://github.com/godotengine/godot/issues> _, також ви можете обговорити їх в цій темі з іншими учасниками спільноти .

Більшість розробників в спільноті Godot буде цікавіше дізнатися про такі речі, як:

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

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

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

Бонусні бали за висилання скріншотів, конкретних номерів, тестових прикладів або прикладних проектів (якщо це застосовується).

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

У 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.