Neofit писал(а):Так, а Годот сколько человек разрабатывает? Мне показалось что один.
Скорее всего ты про
Хуана, он типа как
Тон, но для
Godot. То есть руководит и программит, пишет и принимает решения. При этом он написал большую часть кода, а после успеха на
патреон стал нанимать себе оплачиваемых помощников; до этого только открытая помощь принималась. Сейчас есть как-минимум два оплачиваемых программиста и ещё гдквест набился в доработку документации.
Neofit писал(а):И как у него с производительностью? По графике и процессорным рассчетам?
С производительностью всё неоднозначно, в
2д всё отлично, а в
3д сейчас (третья версия) появилась куча технологий, но красивая картинка ощутимо напрягает систему. К примеру, сложно получить на обычной системе более 30фпс в фуллHD, если ты используешь риалтайм
AO и
GI.
Сам
GScript по производительности примерно рядом с чистым
Python. Есть возможность подключить и сам
Python. А можно и
C++ или
C#, и более специфичные вещи, и ты получишь соответственное ускорение. Самый быстрый показатель сейчас вроде бы у языка
D.
Для 2д движок очень хорош. А в целом с BGE сравнивать особо смысла нет, в первую очередь по причине паблишинга, с этим у
BGE всё никак от слова — очень сложно. Да, паблишить можно и на
BGE,
Дима (
Кива) и его несколько изданных на
Steam игр — вам в пример, но в целом всё будет сложно и печально. И костыльно.
У
Godot своя философия построения игр на базе сцен, сигналов и иерархической зависимости; система достаточно интересная и отчасти удобная. С ним проще доделать первую приличную игру, чем с
BGE. А с
BGE проще получить первую интерактивную реакцию, если вы уже знакомы с
Blender. Чуть-чуть проще, да то всё относительно и смотря в чём.
Кстати. Когда только познакомился с #
Godot, то дико бесило, что про него не пишут простым языком. Вот попробую сравнить с #
BGE на парочке примеров. Так сказать, для 'самых маленьких'.
Простой пример. Как сделать объект с простой анимацией, вроде вращения или покачивания.
BGE. Берём кубик, ставим ключи анимации. Заходим в брики и делаем цепочку:
Always >
And >
Action (выбрали сделанную анимацию, указали диапазон и прочие параметры).
Godot. Берём нод (Sprite или MeshInstance, или это может быть готовый ресурс/сцена). Входим в режим установки ключей (в дерево сцены нужно добавить нод AnimationPlayer, выбрать его и создать в нём новую анимацию), cтавим инстансу ключи на его свойства (плейеру ставим активацию при загрузке и цикличность).
Теперь, если вы ставили ключи на вращение, то у вас есть вращающийся кубик и там, и там. Или кубик двигающийся по ключевым точкам. Всё хорошо. Всё примерно одинаковой сложности. Плюс в
Godot вы можете создать из этой сцены ресурс и добавлять его в нужные сцены, и его анимация, скрипты и прочее будет уже внутри него, и работать так, как если бы вы запустили эту сцену отдельно в
Godot. Этот момент сильно упрощает организацию сцен, что называется, — мышкой.
Теперь более сложный момент. Допустим реакция на мышку над объектом.
BGE. Меняем в нашей цепочке
Always на
MouseOver. Всё. По дефолту у нас и так создаётся Static объект, так что физика и raycasting будут работать (кстати, это можно и из скрипта делать). Кубик закрутится, когда мы наведём мышку на него.
Godot. Нам уже придётся познать скрипты и сигналы. Полезные новичкам подробности под катом, а вывод после него.
- Спойлер
- VisualScript использовать для простых задач можно, некоторые вещи в нём интересно сделаны; но всё же не рекомендую, так как по большому счёту, это просто визуальная и достаточно неудобная обёртка для возможностей GDScript, немножко изменённая, но не так как хотелось бы и в целом лучше сразу идти в GDSсript. Вот этим путём и пойдём.
GDSсript так устроен, что когда вы пишите новый скрипт, то тем самым расширяете функционал уже существующих классов объектов. К примеру Sprite или Camera. При этом, если вы делаете расширение класса который входит в другой класс, то есть имеет родителя, то вы автоматом получаете и возможности родительского класса. Так что если вам чего-то не хватает, то возьмите от класса повыше в иерархии или сделайте себе новый экземпляр другого класса прямо здесь. Но продолжим. Мы делаем реакцию на мышку над кубиком.
Сделаем сцену, где будет такая иерархия нодов:
- Код: Выделить всё
(root)
- Node >
- Camera
- AnimationPlayer
- RigidBody(static) >
- CollisionShape(куб)>
- MeshInstance(куб)
Скрипт можно повесить на любой нод (в Godot всё добавляемое в сцену называется нодами, а не объектами как в Blender). То, куда мы повесили скрипт вообще не принципиально и влияет только на удобство обращения к нужным нодам, их функциям, методам и свойствам.
Скрипт будет такой:
- Код: Выделить всё
extends Node
var player # это переменная, она будет доступна во всех функциях далее
func _ready():
player = get_node('/root/Node/AnimationPlayer') # получаем нод плейера из дерева сцены по указанному пути
func _on_RigidBody_mouse_entered():
player.get_animation('New Anim').set_loop(true) # получаем анимацию по имени и ставим бесконечный цикл
player.play('New Anim', -1, 1.0, false) # запускаем анимацию
func _on_RigidBody_mouse_exited():
player.get_animation('New Anim').set_loop(false) # выключаем цикл
player.stop() # остановили анимацию
Теперь такой момент, у нас в скрипте (расширении класса Node) есть три функции:
_ready — это резервированное имя метода, который активируется в момент, когда после запуска проекта наш нод и все его потомки/чайлды добавились в дерево сцены, т.е. готовы к работе с ними. Резервов такого рода несколько, например _process(), _physics_process() и другие, но эти вы будете использовать чаще всего. В BGE такого вообще нет, потому по началу будет немного непривычно, но это быстро пройдёт.
_on_RigidBody_mouse_entered(), _on_RigidBody_mouse_exited() — с этими интереснее, так как если мы их просто напишем сами, то ничего не заработает. В Godot есть такая штука как сигналы, они есть у каждого нода и находятся в своём отдельном свитке. Любой сигнал можно подключать как функцию в скрипт на любом ноде. Просто берём 'Connect' и выбираем нужный _нод_со_скриптом_ в открывшейся форме выбора. В данном случае я использовал два сигнала, когда курсор мышки заходит в/над RigidBody и когда покидает его. Оба два просто подключил к нашему скрипту/расширению выбрав нод с ним. Функции появляются в скрипте автоматически и мы можем добавлять в их 'тело', что нам требуется. В данном случае управление анимацией.
Таким образом, самый простой способ сделать аналог
MouseOver из
BGE в
Godot:
Добавить
RigidBody,
ColisionShape,
MeshInstance (грубо говоря, собрать свой аналог объекта
BGE, с мешем и физикой). Повесить скрипт на кого-то из них и подключить в этот скрипт сигналы по детекту мышки из
RigidBody, с помощью которых управлять анимацией.
Этот простой пример уже показывает, что в
Godot очень большая функциональная раздробленность и зачастую, что бы добраться до какой-то фичи, нужно попутно задействовать ещё 2-3. В принципе в
BGE тоже ситуация не далеко ушла, если смотреть на скриптинг, разница только в том, что в
BGE нет такого разнообразия типов объектов в дереве сцены и идёт связка брики-скрипты. А в
Godot связка ноды-расширения(классов). В
BGE мы добавим брик-сенсор для
raycast и будем хитить объект, а в
Godot добавим нод
raycast и будем делать тоже самое (правда довольно мудрёно). Плюс в
BGE есть и более комплексные решения, как в примере с
MouseOver. А в
Godot всё несколько более низкоуровнево и даже
VS, который вроде как создан для новичков, но ставит им высокую планку вхождения. Такая вот ситуация.
При этом у
Godot есть такие специализированные ноды, про которые
BGEшникам лишь мечтать. Например, есть класс
Control, где в том числе есть табы, контейнеры, скролл, меню, есть готовые кнопки и так далее... вам осталось только научиться этим управлять.
Но самое главное, что в
BGE проект — набор файлов и скриптов.
А в
Godot проект, это именно проект. Со всеми сопутствующими плюшками.
Az есмь.
.
