Вышел Godot 3.1

Годнота, жаль gdscript то ещё дерьмо (хотя к нему нужно просто привыкать), а native неудобное на Си особо не попишешь, но в остальном один из если не самый лучший из тех с которыми можно просто сесть и начат делать. Божественный интерфейс редактора. Годнота и нужно, даже несмотря на то что не использую его.

Нужно делать игру на движке, который падает на куче девайсов на целевой архитектуре, потому что так сказали анонимные «эксперты» с лора? Ясно, понятно....

2 года пользуюсь для своих личных поделок, ничего не падает, не ври. Но любители обновляться до свежих беток, когда разработка в самом разгаре - определенно должны страдать. Это каким же идиотом надо быть чтоб гнаться за фичами, когда уже определен стек технологий, намечены даты релиза и настроено окружение. Знаю 100500 факапов, когда разработчики обновлялись до свежайшей версии юнити и получали такие чудесные баги, что потом неделями восстанавливали рабочий процесс. Ты видимо как раз из таких мамкиных девелоперов.

Мне, кстати, тоже интересно было бы узнать, отчего Urho3D так непопулярен? Есть знающие люди, способные ответить на этот вопрос без мыла?

То есть оказывается мой телефон врет мне, что демо на этом движке падает на релизе 3.1 на графическом рендере.

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

То есть вы сами своим сообщением подтверждаете сырость этого движка и называете этот релиз беткой, раз этот движок падает на стабильном релизе.

А еще вы за глаза голословно утверждаете, что знаете как я веду процесс разработки. Ясно, понятно...

С трамвайными хамами я не дискуссии не веду. Всего хорошего вам.

Я так подозреваю для Androida Godot — это по любому beta.

Если ты и C++ не осилил, то в геймдеве тебе делать точно нечего.

Если я напишу игрушку целиком на C++, то к ней труднее будет делать моды.

Для этого есть такие хорошо интегрируемые в кресты скриптовые движки, как Lua, Angel Script etc.

Gdscript очень прост и удобен. Для игровой логики вполне достаточно! В зависимости от жанра игры, игровой логики там может быть всего 1% от разработки, а основная нагрузка ложится на художников, аниматоров, левел-дизайнеров, гейм-дизайнера, тестировщиков и т.д. Если каждый из этих разработчиков сможет подправить значения переменных в скриптах - разве это не главная цель скриптового языка? А все эти Lua, Angelscript - там ведь запутаешься с нагромождением скобок всех форм, попробуй одну не закрыть - и код поломан.

AngelScript — да, это почти C++, а в Lua то вы где много скобочек видели? И Lua, что называется, отраслевой стандарт.

ps. В GDScript, я так понимаю, как в Питоне, всё на отступах? Ну в Lua end-ы писать надо, не бог весь какое (по мне) усложнение (с отступами что-то случайно сломать тоже легко, если что). Ну и с ООП в Lua по другому — прототипы (хотя уж что, что, а сымитировать классы на прототипах — вообще не проблема)

Ой, я как вспомню конфиги оконного менеджера awesome, это же ад какой-то! Все возможные виды скобок, плюс ещё и обязательный отступ, да ещё и end до кучи! Комменты сливаются, когда на той же строке. Вобщем, читабельность сомнительная. А уж что-то поменять вообще проблематично, всё время думаешь какой формы скобки в какую строку, где закрыть... и всё равно потом обнаруживается синтаксическая ошибка. https://awesomewm.org/apidoc/sample files/rc.lua.html#

Ну если оконный менеджер действительно нужно конфигурировать кодом с кучей вложенных анонимных функций, то, наверное, лисп для него был бы лучшим выбором.

ну и да, наверное конфигурировать этот самый awesome вообще не зная синтаксиса lua (прочитал про комменты) — тот ещё квест. Обязательного отступа в lua нет.

Что не отменяет того факта, что этот самый awesome — отличный пример того, как не надо использовать lua в своих проектах (что называется ­— в закладки).

ps. Возвращаясь к GameDev, не знаю, как там с Ухом (Urho’м) но гляньте, что-ли, на игры на LÖVE или INSTEAD — никакого ада там нет.

Нужно делать игру на движке, который падает на куче девайсов на целевой архитектуре

Надо всё-таки прежде чем лить желчь, озвучивать, какая именно целевая архитектура имелась в виду. Потому, что android — это linux, но весьма нестандартный, и под «онтопиком» на этом сайте обычно понимают что-то другое. А поскольку вы это не сделали, ваш оппонент предположил, что вы используете сырые беты, откуда же он мог понять что вы используете десктопный (по факту) движок для мобильной разработки.

Простой пример астероидов на lua для LÖVE. С созданием объекта игры.

Да, различие между точкой (для, что называется, статических методов) и двоеточием для вызова методов, работающих с конкретным объектом слегка непривычно. А так — очень простой язык.

Кому нужны навороченные «батарейки» — https://luarocks.org/

Если кому не хватает структур данных из python standard library — Penlight

ну и т.д.

Как с поддержкой lua в у[р]хе, ещё раз, не знаю, надо будет его на эту тему потрогать.

Дефолтный кофиг awesome — лютое вырвиглазное УГ, нельзя так писать на Lua.

основная проблема Urho3D это то, что разработчики считают его законченным и добавлять в него ничего не нужно. Исправлять ограничения тоже не нужно. И вообще ничего не нужно кроме переработки системы сборки и переписывания на очередной диалект C++, ну или очередной дискасс на тему выкинуть ли что-нибудь типа физики или скриптоты или оставить. У разрабов нет ни времени ни желания работать над фичами или улучшением существующих. Сейчас я не могу советовать использовать Urho3D так как трудностей с ассет пайплайном будет слишком много. Если хочется чего-нибудь минималистичного для очередного тетриса лучше взять что-то более живое или набрать свое из имеющихся либ под C++. Просто объём работ по доведению урхи до ума сопоставим с написанием своего такого же или собрать из готовых либ/фреймворков.

с ассет пайплайном будет слишком много Конкретнее

Конкретнее

Лень объяснять. Попробуй и узнаешь. Самое простое объяснение - нет этого пайплайна. Особенно задолбешься с персонажами. Если тетрис делать или там совсем простые гоночки, то может получиться. Как где ассеты более сложные - уйдет вагон времени чтобы сделать так, чтобы можно было одной кнопкой ассет в добавить. Слишком много ограничений, которых больше нигде нет. Например максимум 64 кости на меш в GLES2. И натыкаешься на такое по 100 раз на дню. В больших движках или даже Godot'е это всё очень прозрачно работает - экспортнул и опа, готово можно тыкаться. В Urho3D всё будешь делать руками или писать сам, постоянно натыкаясь на грабли. Это чаще всего сразу же убивает желание людей хоть какое-то дело иметь с Urho. Вторая поблема с костями и если работаешь в Max, она тебя не коснется. С Блендером понятие «вперед» для кости будет отсутствовать и быть по рандому. Делать ручную анимацию для костей проблематично. Также есть проблемы с IK (оно там как бы есть, но никто работать его не заставлял, кроме разработчика). В общем если тебе норм и так, то бери Ogre3D, там только рендер, зато более продвинутый. И те же тетрисы гонять будет попроще. Есть даже недофизика (можно прикрутить тот же Bullet или ODE для полноценной физики). Статус будет как с урхой, просто будет легче фиксить и будет лучше понимание как и что делать и без дурацких ограничений. Ну или идти на большой движок типа UE4, где таких проблем нет и можно везде залезть и все поправить (правда распространять код нельзя). Плюс этих движков в том, что они живые, а Urho3D, увы, мертвечина.

В 4й версии Godot станет единственным серьезным свободным движком.

Бред не неси.

Хороший пост.

Мои 5 копеек (все ИМХО): UE4 если под мобильные платформы - ну очень жирный. Если C++, и нужно 3D (и скажем board game) и crossplatform (ну почти) то альтернатив Ogre3D не вижу.

Для 2D - cocos2d-x наше все. Хотя они ударились в Cocos Creator, поскольку главный китаец заявил что игры на javaScript - это «новый голубой океан», поэтому собственно cocos2d-x сейчас пилит в основном один человек.

Автор Urho покинул пост руководителя проекта, так что пациент скорее мертв, чем жив. А жаль. Кстати где-то были тесты, что в 2D Urho по производительности рвет все остальное в разы.

P.S. В сабже смотрю можно GDNative - не знаю насколько это просто и есть ли подводные камни.

Я повозюкавшись решил, что патчить двиг проще чем возиться с GDNative. Так как инфраструктуры для GDNative нету, их под платформы никто не собирает, соответственно код гниет очень быстро и на платформах не работает. Если бы хоть базовый набор плагинов тестировани хотя бы на собираемость вместе с движком, то можно было бы хотеть фичи «которые не нужны ненужнистам» пихать в GDNative, и тогда и фича есть и ненужнисты довольны, а так код в GDNative считай выкинут - и лишней возни с поддержкой больше, и с доками не очень, и API не все продето, и баги. Проще просто модули для движка делать. Не берут PR - похеру, пущай лежит мне так проще и тестировать и в дереве все пилить полегче. Если начнут тесты гонять - тогда может быть GDNative меня и заинтересует.

Спасибо за инфу.

А для 2D с урхой вообще связываться не вижу смысла - и движков вагон всяких разных, в которых ассет пайплайн разворачивается мнгновенно и от старта до прототипа пара дней. И не уверен я что Urho в 2D быстрее - рендер там тот же, просто камера в ортонормальном виде. Но там дело не в тормозах рендера, а в том, что для 2D там практически ничего не сделно для облегчения жизни юзеру, то есть проблемы там те же. Но 2D и само проще в плане ассетов, тут не шибко трудно руками все сделать, вон в кокосе народ все руками делает и ничего (на youtube смотрел, сам не трогал). Может и зайдет кому. Вот физику придется всю руками делать (в смысле Box2D продет as is) но этим вряд ли кого удивишь. Godot в этом плане балует, но 2Dшников он не радует тем, что жирный, баги вылезают, и ненужного много. А они привыкли лопатой, и в движке очень много ненужных ручек, они пугаются.

Надо кстати самому потестить как там дела с андроидом, а то пока народ потестит годы могут пройти. Хочу понять допилили GLES2 или нет еще, да багов порепортить.

Ага, нашел ссылку (сравнивали unity c ue и с urho):

https://forums.unrealengine.com/development-discussion/rendering/34185-render...

ну тема 3-летней давности, я бы перепроверил. Даже если рвет за счет батчинга одинаковых прямоугольников, то вряд ли разница будет видна на реальных данных. С другой стороны сравнивать движок, позиционирующий себя как AAA для 3D, с поделием одного человека, тоже для 3D, на 2D тестах - не вижу смысла. Нету недостатка в легко ковыряемых 2D-движках, там небось лямы спрайтов на 200fps уже давно можно. Но зачем это 5-е колесо телеге - я не знаю. У 2D-шников свой хардкорный мир, им такое непонятно будет. Задрочить UE-разрабов на 2D-батчинг вроде получилось и тема была не зря, но мне проверять реально лень.

100,000 sprites: 45 fps

Тесты уровня null. Вот в /gd делали тест моай: сделал тест - 2d сцену с 10k текстурированных объектов в цепочке, где каждый объект это родитель cледующего. Вращаю и двигаю (по разным анимационным кривым) 1й, 2й и 8й объекты. Меньше 60fps не падает на intel-встройке.

Хотелось бы такие же тесты на godot и unity.

Там ещё и Battle for Wesnoth на него перетаскивают постепенно https://twitter.com/Wesnoth/status/1107303301828141057