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

Що я можу зробити з 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: An introduction to dynamic languages.

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

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

  1. У більшості віртуальних машин для скриптів немає хорошої підтримки потоків виконання, а Godot використовує потоки (Lua, Python, Squirrel, JS, AS та ін.).
  2. У більшості скриптових віртуальних машин немає хорошої підтримки розширення класів, а адаптація до способу роботи Godot дуже неефективна (Lua, Python, JS).
  3. Багато існуючих мов мають жахливі інтерфейси для прив’язки до C++, що призводить до великої кількості коду, помилок, вузьких місць і загальної неефективності (Lua, Python, Squirrel, JS і т.д.). Ми хотіли зосередитися на великому рушії, а не на великій кількості інтеграцій.
  4. Немає рідних векторних типів (vector3, matrix4 та ін.), що призводить до значного зниження продуктивності при використанні власних типів (Lua, Python, Squirrel, JS, AS та ін.).
  5. Збирач сміття призводить до зупинки або надмірного використання пам’яті (Lua, Python, JS, AS та ін.).
  6. Труднощі інтеграції з редактором коду для забезпечення завершення коду, редагування в реальному часі тощо (всі вони). Це добре підтримується GDScript.

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

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

Godot підтримує Collada через експортера OpenCollada (Maya, 3DSMax).

Якщо ви використовуєте Blender, погляньте на наш власний Better Collada Exporter.

Починаючи з Godot 3.0, glTF підтримується.

FBX SDK розповсюджується відповідно до обмежувальних умов ліцензування, які не сумісні з відкритою ліцензією наданою Godot. Незважаючи на це, підтримка 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.

Most developers in the Godot community will be more interested to learn about things like:

  • Ваші враження від користування програмним забезпеченням і проблеми, з якими ви зіткнулися (ми переймаємося цим набагато більше за ідеї щодо поліпшення програмного забезпечення).
  • Можливості, які б ви хотіли бачити реалізованими, оскільки вони потрібні для вашого проекту.
  • Поняття, які було важко зрозуміти під час вивчення програмного забезпечення.
  • Частини вашого робочого процесу, які б ви хотіли оптимізувати.
  • Parts where you missed clear tutorials or where the documentation wasn’t clear.

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.

Why does Godot not use exceptions?

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