Войти
Игровая индустрияФорумСобытия

Godot Engine получил $250K Epic Megagrant! (4 стр)

Страницы: 1 2 3 4 5 Следующая »
#45
7:47, 5 фев. 2020

pavlopiy
> GDScript - прекрасный легкий для чтения и написания язык, особенно если нравится Python like языки
тогда почему было просто не использовать питон? ну вот нафига изобретать очередной велосипед, под который никто никогда ничего не писал и не напишет? нафига пользователю учить язык, который гарантированно нигде больше не понадобится? а стоило использовать любой существующий скриптовый язык и вуаля — сразу вагон уже выполненной для него работы в виде кучи готовых библиотек, интерпретаторов, оптимизаторов, jit-компиляторов и чего только можно. единственная причина, по которой можно простить использование велосипедного скриптового языка — это если он был заложен в проэкт ещё до популяризации нормальных виртуальных машин для интерпретируемых языков, то есть где-то до 2000-2005 года. после этого причин нет от слова "вообще".


#46
7:58, 5 фев. 2020
тогда почему было просто не использовать питон?

На эту тему есть разъяснения в документации

https://docs.godotengine.org/ru/latest/getting_started/scripting/… .html#history

История

In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.

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

Godot встраивает скрипты в узлы. Большинство языков не предназначены для этого.
Godot использует несколько встроенных типов данных для 2D и 3D математики. Скриптовые языки не предоставляют такого функционала, поэтому привязывать их неэффективно.
Godot очень активно использует потоки для считывания и инициализации данных из сети или с диска. Скриптовые интерпретаторы популярных языков не очень хорошо дружат с этим.
Godot уже имеет модель управления памятью для ресурсов, а большинство скриптовых языков предоставляют свою собственную модель, что приводит к двойной работе и множеству багов.
Код привязки всегда неряшливый и приводит к некоторым ошибкам, неожиданным багам и, как правило, низкой поддержке.
Результатом этих рассуждений является GDScript. Язык и интерпретатор для GDScript оказался меньше чем код привязки для Lua и Squirrel, имея при этом такую же функциональность. Со временем наличие встроенного языка оказалось огромным преимуществом.

#47
8:12, 5 фев. 2020

pavlopiy
изобретать свой велосипед, потому что им не понравился синтаксис байндингов существующих языков? серьёзно? это ж просто смехотворно — вместо того, чтобы сделать промежуточный слой, который бы создавал байндинги так, как им нравится, они сели писать велик. ну ё-моё, совершенно типичная нубская ошибка, которая ещё _никогда_ к добру не приводила.

#48
10:09, 5 фев. 2020

Suslik
> вместо того, чтобы сделать промежуточный слой, который бы создавал байндинги
> так, как им нравится, они сели писать велик.
Вот-вот. Запретили лучше бы все языки кроме С++, а то понасоздавали костылей всяких...

#49
10:33, 5 фев. 2020

Обьясните для тех кто  в танке - в чем смысл скриптов?

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

1. он вроде должен вообще уметь программировать
2. он должен знать один из популярных распространненых скриптов языков(луа,питон) или в худшем случае выучить новый, который кроме как в каком то конкретном движке больше не используется

Если он ничего незнает, то программист должен написать для него скрипт, в котором уже будет функция move(), где геймдизайнер может какие нить коэффицентики поменять, что то сложить вычесть и тем самым изменить поведение.

И почему не реализуется язык более высокого уровня, типа как тут:

+ Показать

#50
(Правка: 10:51) 10:50, 5 фев. 2020

forwhile

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

func get_input():
    velocity = Vector2()
    if Input.is_action_pressed('right'):
        velocity.x += 1
    if Input.is_action_pressed('left'):
        velocity.x -= 1
    if Input.is_action_pressed('down'):
        velocity.y += 1
    if Input.is_action_pressed('up'):
        velocity.y -= 1
    velocity = velocity.normalized() * speed

куда еще более выше уровнем, есть событие "if Input.is_action_pressed('right')"  есть что сделать по событию " velocity.x += 1" события программист может делать конечно и свои собственные как то "is_player_dead" и т.п. :)

#51
10:50, 5 фев. 2020

forwhile
> И почему не реализуется язык более высокого уровня, типа как тут:
Реализуется. Очень просто. Заходишь на гит, качаешь сорсы и пишешь реализацию.

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

#52
10:53, 5 фев. 2020

forwhile
ко всему прочему Godot еще предоставляет Визуальное программрованеие

Что такое Визуальное Программирование

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

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

С устранением недоразумений остается вопрос, каково практическое применения Визуального Программирования.

Наиболее распространенные варианты использования следующие:

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

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

#53
11:19, 5 фев. 2020

Suslik
>
> изобретать свой велосипед, потому что им не понравился синтаксис байндингов
> существующих языков? серьёзно?

Ну они кстати правы - я всегда смотрел на это мракобесие, которое надо сотворить, чтобы получить Луа в своем С++ проекте, с недоумением. И главное зачем, если твой код все-равно выполняется в потусторонней виртуальной машине которая не знает что существуют "классы". Мне вообще-то в скриптовом языке нужен весь энвайронмент, потому что я не буду писать

DoScript(x, y)
{
  x = sin(x);
  y = cos(x + 1.111);
}

Я буду писать что-то такое

DoScript(x, y)
{
  x = sin(TreeObjectsArray[ID].getMyGoodSinus() + Moon.Weather(g_timeOfDay));
  y = MapPosition.y + MapZoom.get() + Character.getVelocityY();
}

Сферический код в вакууме без внешних условий нужен один раз в два лет.

#54
11:37, 5 фев. 2020

Godot рулит

#55
20:04, 27 апр. 2020

Suslik
> вот серьёзно, кстати. эпики ведь сами на этом собаку съели, когда долго и
> мучительно отходили от своего убогого unreal script.
И таки собираются вернутся обратно https://wccftech.com/intermediate-script-language-unreal-engine-4/
Даже наняли разработчиков одного из скриптов для ассет стора.

Suslik
> тогда почему было просто не использовать питон?
Да это фейл. Было бы круто прототипировать на питоне.

#56
(Правка: 15:37) 15:37, 28 апр. 2020

qGrin
> Да это фейл. Было бы круто прототипировать на питоне
Это ведь уже ооочень давно есть. О чем спор? не нравится нонэйм язык - не пиши. Тут, в отличие от юнити или анрила, есть выбор.

#57
15:42, 28 апр. 2020

mega_otetz (father)
> Godot рулит

Ох... ну не знаю, сырой он еще очень имхо (v. 3.2.1 stable)

Я вот купился на декларируемую фичу, из-за которой я его в принципе рассматривал:

- GDNative script (по сути С/С++ в виде shared library (so/dll)) - но на деле оказался какой-то
адовый капец, сколько ухищрений надо чтобы просто подключить функцию типа "hello world".
В итоге как-то запустилось, но в логе рандомно возникающая ошибка. Практически нет
документации, и в репе (вообще!) нет работающего примера на эту тему. Как они вообще эту
фичу тестируют? И да - у них проблемы с типом double (!!!) - т.е. официально такого типа у них нет.

Но даже допустим, если бы вдруг меня устраивал их GDScript, подобное и с другими
(нужными мне) фичами, например GUI темы - на деле здорово, но я два дня пытался просто
поменять цвета и отступы у встроенной. Неудачно.

Ну и т.д. - чуть копнешь глубже - очень много затыков.

Я понимаю, опен-сорс, молодой движок, неустоявшееся API - но по факту - на нем
делать что-то серьёзнее 2D платформера не получится.
При этом, они вроде как (в v.4) на вулкан замахнулись - значит сломают еще что-нибудь.

#58
20:47, 28 апр. 2020

rcsim
> я два дня пытался просто
> поменять цвета и отступы у встроенной. Неудачно.
rcsim
> по факту - на нем
> делать что-то серьёзнее 2D платформера не получится
Спасибо за икспертное мнение.rcsim

> При этом, они вроде как (в v.4) на вулкан замахнулись - значит сломают еще
> что-нибудь.
Непременно, ведь причинно-следственная связь налицо.

#59
22:37, 28 апр. 2020

> > я два дня пытался просто
> > поменять цвета и отступы у встроенной. Неудачно.
BEETON
> Спасибо за икспертное мнение.rcsim

У тебя есть опыт - продемонстрируй. Конкретно padding для treeview items.
Ну и конкретно как сменить хотя-бы цветовую палитру для всей темы.

BEETON
> При этом, они вроде как (в v.4) на вулкан замахнулись - значит сломают еще
> что-нибудь.
> Непременно, ведь причинно-следственная связь налицо.

Именно так. Я здесь авторов цитировал кстати.

Страницы: 1 2 3 4 5 Следующая »
Игровая индустрияФорумСобытия