Часто задаваемые вопросы

На что способен Godot? Сколько он стоит? Каковы условия лицензирования?

Godot - это свободное программное обеспечение с открытым исходным кодом <https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D0%BE%D0%B5_%D0%B8_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5>`_, доступное по одобренной OSI <https://opensource.org/licenses/MIT>`_ лицензии MIT. Это означает, что движок бесплатен и его использование ничем не ограничено.

Вкратце:

  • Вы можете бесплатно скачивать и использовать Godot для любых целей: личных, некоммерческих, коммерческих или иных (но не зловредствуйте).

  • Вы можете свободно изменять, распространять и пересобирать Godot по любой причине, как не коммерчески, так и коммерчески.

Все содержимое этой сопроводительной документации опубликовано под разрешительной лицензией Creative Commons Attribution 3.0 (CC-BY 3.0) с указанием авторства "Хуан Линецкий, Ариэль Манзур и сообщество Godot Engine."

Логотипы и иконки также находятся под лицензией Creative Commons. Заметьте, что сторонние библиотеки, включённые в исходный код Godot, могут иметь другие лицензии.

Для полной информации, смотрите COPYRIGHT.txt а также LICENSE.txt и LOGO_LICENSE.txt в репозитории Godot.

Также смотрите страницу лицензии официального сайта Godot.

Какие платформы поддерживаются Godot?

Для редактора:

  • Windows

  • MacOS

  • X11 (Linux, *BSD)

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

  • Windows OS (и UWP OS)

  • MacOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • Веб

Поддерживается создание как 32-х, так и 64-х битных исполняемых файлов (для платформ, где это возможно); по умолчанию создаются 64-х битные файлы.

Некоторые пользователи также сообщают о сборке и использовании Godot для систем на базе ARM с Linux, таких как Raspberry Pi.

Ведутся работы (вне основного проекта Godot) по запуску на игровых консолях, но в стандартные скрипты сборки и шаблоны экспорта такие расширения не входят.

Более подробная информация есть в разделах экспорт и как собрать Godot.

Какие языки программирования поддерживаются в Godot?

Официально поддерживаемые языки для Godot это GDScript, Visual Scripting, C# и C++. Смотрите подкатегории для каждого языка в секции Скриптинг.

Если вы только начинаете разбираться с Godot или с разработкой игр в целом, то рекомендуем изучить язык GDScript, поскольку он является родным языком для Godot. Как правило, в долгосрочной перспективе скриптовые языки программирования менее эффективны, чем языки низкого уровня, но для прототипирования, создания минимально жизнеспособных продуктов (minimum viable product, MVP) и уменьшения времени выхода на рынок (Time-To-Market, TTM) GDScript предоставляет достаточно быстрый, дружественный и действенный путь разработки.

Обратите внимание, что поддержка C# это довольно новая функция и по пути вы можете столкнуться с некоторыми проблемами. Наше дружелюбное и трудолюбивое сообщество всегда готово решать новые проблемы по мере их возникновения, но поскольку это проект с открытым исходным кодом, то мы рекомендуем сначала выполнить некоторую должную осмотрительность. Поиск в обсуждениях на open issues (Открытые вопросы) это отличный способ приступить к решению возникших проблем.

Что касается новых языков, поддержка возможна с использованием возможностей сторонних решений GDNative / NativeScript / PluginScript. (См. вопрос о плагинах ниже.) В настоящее время работа ведётся полным ходом, например, есть неофициальные привязки Godot к Python и Nim.

Что такое GDScript и зачем мне его использовать?

GDScript — это интегрированный язык скриптов Godot. Он был построен с нуля, чтобы максимизировать потенциал Godot в наименьшем количестве кода, предоставляя как начинающим, так и опытным разработчикам возможность максимально быстро использовать преимущества Godot. Если вы когда-нибудь писали что-то на языке, подобном Python, то вы почувствуете себя как дома. Для примеров, истории и полного обзора возможностей, которые предлагает GDScript, ознакомьтесь с Руководством по созданию скриптов GDScript.

There are several reasons to use GDScript--especially when you are prototyping, in alpha/beta stages of your project, or are not creating the next AAA title--but the most salient reason is the overall reduction of complexity.

Первоначальная цель создания тесно интегрированного пользовательского языка сценариев для 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, 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 поддерживается через Open Asset Import library. Однако FBX является проприетарным, поэтому мы рекомендуем использовать другие форматы, перечисленные выше, если они подходят для вашего рабочего процесса.

Будет ли [Закрытый SDK такой как FMOD, GameWorks, и т.д.] поддерживаться в Godot?

Целью Godot является создание бесплатного и открытого движка с лицензией MIT, который является модульным и расширяемым. Сообщество разработчиков движка не планирует поддерживать сторонние SDK с закрытым исходным кодом/проприетарные SDK, поскольку интеграция с ними будет противоречить идеалу Godot.

Тем не менее, поскольку Godot является открытым и модульным, ничто не мешает вам или кому-либо еще заинтересоваться добавлением этих библиотек в качестве модуля и распространять вашу игру используя его в качестве открытого или закрытого источника.

Чтобы узнать, как еще можно обеспечить поддержку вашего SDK, прочтите в вопросах о плагинах выше.

Если вы знаете стороннее SDK, которое не поддерживается Godot, но при этом бесплатное и с открытым исходным кодом, тогда вы можете начать работу по интеграции самостоятельно. Godot не принадлежит одному человеку; он принадлежит сообществу, растет вместе с амбициозными участниками сообщества, такими как Вы.

Почему Godot использует Vulkan или OpenGL вместо Direct 3D?

Прежде всего, Godot стремится к совместности перекрёстных платформ и открытых стандартов. OpenGl и Vulkan - технологии, открытые и доступные на всех (почти) платформах. Благодаря этому дизайнерскому решению, проект, созданный с Godot на Windows также пойдёт на Linux, macOS и др.

Поскольку над модулем рендеринга Godot работает всего несколько человек, мы бы предпочли, чтобы у вас было меньше серверных модулей рендеринга. Кроме того, использование единого API на всех платформах позволяет добиться большей согласованности с меньшим количеством проблем, связанных с платформой.

В будущем, возможно, мы разработаем для Godot рендерер Direct3D 12 (в основном для Xbox), однако Vulkan и OpenGL по умолчанию останутся основными графическими отрисовщиками для всех платформ, включая Windows.

Почему Godot стремится сохранить свой набор основных функций маленьким?

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

На это есть несколько причин:

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

  • Легкость вклада. Сохраняя небольшую и аккуратную кодовую базу, ее можно быстро и легко компилировать из исходного кода. Это облегчает новым участникам начало работы с Godot, не требуя от них покупки высокопроизводительного оборудования.

  • Сохранение небольшого размера двоичного файла для редактора. Не у всех есть быстрое подключение к Интернету. Обеспечение того, чтобы каждый мог загрузить редактор Godot, извлечь его и запустить менее чем за 5 минут, делает Godot более доступным для разработчиков во всех странах.

  • Сохранение небольшого двоичного размера для шаблонов экспорта. Это напрямую влияет на размер проектов, экспортируемых с помощью Godot. На мобильных и веб-платформах сохранение небольшого размера файлов имеет первостепенное значение для обеспечения быстрой установки и загрузки на устройствах с недостаточной мощностью. Опять же, есть много стран, где высокоскоростной Интернет недоступен. Вдобавок к этому в этих странах часто действуют строгие ограничения на использование данных.

По всем вышеперечисленным причинам мы должны выбирать, что мы можем принять в качестве основных функций в Godot. Вот почему мы стремимся перенести некоторые основные функции в официально поддерживаемые надстройки в будущих версиях Godot. Что касается двоичного размера, это также имеет то преимущество, что вы платите только за то, что вы действительно используете в своем проекте. (А пока вы можете: ref: компилировать пользовательские шаблоны экспорта с отключенными неиспользуемыми функциями <doc_optimizing_for_size>, чтобы оптимизировать размер дистрибутива вашего проекта.)

Как создавать ресурсы под множество разрешений и соотношений сторон дисплея?

Этот вопрос возникает часто, и это, вероятно, благодаря недопониманию, созданному Apple, когда они изначально удвоили разрешение своих устройств. Это заставляло людей думать, что иметь одинаковые ассеты в разных разрешениях было хорошей идеей, поэтому многие продолжали идти по этому пути. Это работало до определенного момента и только для устройств Apple, но затем было создано несколько устройств Android и Apple с различными разрешениями и соотношениями сторон с очень широким диапазоном размеров и DPI.

Самый распространенный и правильный способ достичь этого - использовать одно базовое разрешение для игры и управлять только различными пропорциями экрана. В основном, это нужно для 2D, так как в 3D это просто вопрос угла обзора камеры по осям X и Y (Camera XFov/YFov).

  1. Выберите одно базовое разрешение для своей игры. Даже если есть устройства, которые поднимаются до 2K и устройства, которые опускаются до 400p, обычное аппаратное масштабирование на вашем устройстве позаботится об этом практически без затрат. Наиболее распространенные варианты - либо около 1080p (1920x1080), либо 720p (1280x720). Имейте в виду, что чем выше разрешение, тем больше ваши ассеты, больше памяти они будут занимать и больше времени им потребуется для загрузки.

  2. Используйте параметры растяжения в Godot; 2D растяжение при сохранении пропорций работает лучше всего. Посмотрите учебник: Multiple resolutions о том, как этого добиться.

  3. Определите минимальное разрешение, а затем примите решение, хотите ли вы, чтобы ваша игра растягивалась вертикально или горизонтально для разных соотношений сторон или была в одном минимальном разрешении, с отображением черных шкал прогресса по краям. Это также объясняется на предыдущем шаге.

  4. Для пользовательских интерфейсов используйте закрепление, чтобы определить, где элементы управления должны оставаться и перемещаться. Если пользовательские интерфейсы являются очень сложными, подумайте о том, как использовать контейнеры.

И всё! Ваша игра будет работать в нескольких разрешениях.

Если вы хотите сделать игру пригодной к работе на старых устройствах с маленькими экранами (меньше чем 300 пикселей в ширину), вы можете использовать опцию экспорта для сжатия картинок и настроить проект на использование необходимых разрешений экрана в App Store или Google Play.

Как я могу расширить Godot?

Для расширения Godot, например, для создания плагинов редактора Godot или добавления поддержки дополнительных языков, взгляните на Редактор плагинов и инструментальные скрипты (tool скрипты).

Также смотрите сообщения в официальном блоге по этим темам:

Вы также можете взглянуть на реализацию GDScript, модули Godot, а также на неофициальную поддержку Python для Godot. Это было бы хорошей отправной точкой, чтобы увидеть, как другая сторонняя библиотека интегрируется с Godot.

Когда выйдет следующий релиз Godot?

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

Я хочу внести свой вклад! С чего мне начать?

Это потрясающе! Проект с открытым исходным кодом, Godot процветает за счет инноваций и амбиций таких разработчиков, как вы.

Для начала вам нужно ознакомиться с разделом проблемы. Найдите проблему, которая вас заинтересовала, затем перейдите к Как внести свой вклад, чтобы узнать как создать форк, модифицировать, и создать Pull Request (PR) с вашими изменениями.

У меня есть отличная идея для Godot. Как я могу поделиться ей?

Может возникнуть соблазн привнести некоторые идеи в Godot, например, те, которые приводят к массивным изменениям ядра, какому-то подражанию тому, что делает другой игровой движок, или реализовать альтернативные рабочие процессы, которые вы хотели бы встроить в редактор. Это здорово, и мы благодарны за то, что такие мотивированные люди хотят внести свой вклад, но Godot всегда будет сфокусирован на том, что указано в дорожной карте, тема „устранение ошибок и неполадок“ находится по этой ссылке, также вы можете обсудить их в этой теме с другими участниками сообщества.

Большинству разработчиков в сообществе Godot будет интереснее узнать о таких вещах, как:

  • Ваш опыт использования данного программного обеспечения и возникающие у вас проблемы (нас волнует это гораздо больше, чем идеи об улучшениях).

  • Возможности, которые вы бы хотели видеть реализованными, потому что они нужны вам в вашем проекте.

  • Концепции, которые было сложно понять в процессе изучения программы.

  • Части вашего рабочего процесса, которые вы хотели бы видеть оптимизированными.

  • Части, где вам не хватает понятных уроков или документация недостаточно понятная.

Пожалуйста, не думайте, что ваши идеи для Godot не приветствуются. Вместо этого в первую очередь попробуйте сформулировать их как проблему, чтобы разработчики и сообщество имели какую-то основу для обсуждения.

Хороший способ подхода к обмену идеями и проблемами с сообществом — это набор пользовательских историй. Объясните, что вы пытаетесь сделать, какое поведение вы ожидаете, а затем, какое поведение на самом деле произошло. Описание круга проблем и идей таким образом поможет всему сообществу сосредоточиться на улучшении опыта разработчиков в целом.

Плюс в карму за предоставление скриншотов, конкретных значений, тестовых случаев или проектов-примеров (если возможно).

Можно ли использовать Godot для создания не игровых приложений?

Да! Godot обладает обширной встроенной системой пользовательского интерфейса, а небольшой размер дистрибутива может сделать его подходящей альтернативой таким фреймворкам, как Electron или Qt.

При создании неигрового приложения не забудьте включить low-processor mode в настройках проекта, чтобы уменьшить использование центрального и графического процессоров.

Это значит, что мы бы не рекомендовали использовать Godot для создания мобильного приложения, поскольку режим с низким использованием процессора еще не поддерживается на мобильных платформах.

Загляните в Material Maker <https://github.com/RodZill4/material-maker> __ и Pixelorama <https://github.com/Orama-Interactive/Pixelorama> __ для примеров приложений с открытым исходным кодом, созданных с помощью Годо.

Можно ли использовать Godot как библиотеку?

Godot предназначен для использования с его редактором. Мы рекомендуем вам попробовать, так как это, скорее всего, сэкономит вам время в долгосрочной перспективе. Нет никаких планов использовать Godot в качестве библиотеки, поскольку это сделало бы остальную часть движка более запутанной и трудной для использования обычными пользователями.

Если вы хотите использовать библиотеку рендеринга, рассмотрите возможность использования установленного движка рендеринга. Имейте в виду, что движки рендеринга обычно имеют меньшие сообщества по сравнению с Godot. Это затруднит поиск ответов на ваши вопросы.

Какой инструментарий пользовательского интерфейса использует Godot?

Godot не использует стандартный набор инструментов :abbr: ГИП (графический интерфейс пользователя), наподобие GTK, Qt или wxWidgets. Вместо этого Godot использует собственный набор инструментов пользовательского интерфейса, созданный с помощью OpenGL ES или Vulkan. Этот инструментарий представлен в виде узлов управления, которые используются для визуализации редактора (написанного на C++). Эти узлы управления также можно использовать в проектах на любом языке сценариев, поддерживаемом Godot.

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

Этот собственный набор инструментов пользовательского интерфейса нельзя использовать в качестве библиотеки, но вы все равно можете использовать Godot для создания неигровых приложений с помощью редактора.

Why does Godot not use 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.