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

Що я можу зробити з 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-класу. Проте, найбільш суттєвою причиною є загальне зменшення складності.

The original intent of creating a tightly integrated, custom scripting language for Godot was two-fold: first, it reduces the amount of time necessary to get up and running with Godot, giving developers a rapid way of exposing themselves to the engine with a focus on productivity; second, it reduces the overall burden of maintenance, attenuates the dimensionality of issues, and allows the developers of the engine to focus on squashing bugs and improving features related to the engine core–rather than spending a lot of time trying to get a small set of incremental features working across a large set of languages.

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

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

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

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

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

  1. Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
  2. Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
  3. Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.
  4. No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
  5. Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).
  6. Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.

GDScript was designed to curtail the issues above, and more.

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

Godot supports Collada via the OpenCollada exporter (Maya, 3DSMax). If you are using Blender, take a look at our own 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.

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

Awesome! As an open-source project, Godot thrives off of the innovation and ambition of developers like you.

The first place to get started is in the issues. Find an issue that resonates with you, then proceed to the How to Contribute guide to learn how to fork, modify, and submit a Pull Request (PR) with your changes.

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

It might be tempting to want to bring ideas to Godot, like ones that result in massive core changes, some sort of mimicry of what another game engine does, or alternative workflows that you’d like built into the editor. These are great, and we are thankful to have such motivated people want to contribute, but Godot’s focus is and always will be the core functionality as outlined in the Roadmap, squashing bugs and addressing issues, and conversations between Godot community members.

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

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

Please don’t feel like your ideas for Godot are unwelcome. Instead, try to reformulate them as a problem first, so developers and the community have a functional foundation to ground your ideas on.

A good way to approach sharing your ideas and problems with the community is as a set of user stories. Explain what you are trying to do, what behavior you expect to happen, and then what behavior actually happened. Framing problems and ideas this way will help the whole community stay focused on improving developer experiences as a whole.

Bonus points for bringing screenshots, concrete numbers, test cases, or example projects (if applicable).

Why does Godot not use STL (Standard Template Library)

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

  • STL templates create very large symbols, which results in huge debug binaries. We use few templates with very short names instead.
  • Most of our containers cater to special needs, like Vector, which uses copy on write and we use to pass data around, or the RID system, which requires O(1) access time for performance. Likewise, our hash map implementations are designed to integrate seamlessly with internal engine types.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • For large arrays, we use pooled memory, which can be mapped to either a preallocated buffer or virtual memory.
  • We use our custom String type, as the one provided by STL is too basic and lacks proper internationalization support.

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

We believe games should not crash, no matter what. If an unexpected situation happens, Godot will print an error (which can be traced even to script), but then it will try to recover as gracefully as possible and keep going.

Additionally, exceptions significantly increase binary size for the executable.

Why does Godot not enforce RTTI?

Godot provides its own type-casting system, which can optionally use RTTI internally. Disabling RTTI in Godot means considerably smaller binary sizes can be achieved, at a little performance cost.

Why does Godot not force users to implement DoD (Data oriented Design)?

While Godot internally for a lot of the heavy performance tasks attempts to use cache coherency as well as possible, we believe most users don’t really need to be forced to use DoD practices.

DoD is mostly a cache coherency optimization that can only gain you significant performance improvements when dealing with dozens of thousands of objects (which are processed every frame with little modification). As in, if you are moving a few hundred sprites or enemies per frame, DoD won’t help you, and you should consider a different approach to optimization.

The vast majority of games do not need this and Godot provides handy helpers to do the job for most cases when you do.

If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.

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

Див. Способи участі у розробці.

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

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