iKest
Ни разу не пользовался ассет-стором и оригинальные решения пишу сам. Но эти "клики мышкой" экономят вагон времени. Нет, если ты безработный, школьник или иной индивид с кучей свободного времени, чтобы писать элементарные функции руками каждый раз, когда они нужны - пожалуйста, а индустрия работает всё таки по-другому.
А для полного контроля над проектом можно вообще движком не пользоваться, писать всё кодом, или вообще сразу в машинном. Кто-то и землю до сих пор плугом копает, игнорируя комбайны и автоматику.
MLDS
Привет.
Кодировать в твоём проекте я не могу.
Но я делаю двумерный проект (клон метроидваний), с открытым кодом GDScript.
В моих архивах можно найти наброски ресурсов (тайлы), и их использование.
местный линк
Ankero
> Большая часть претензий к Unity или высосана из пальца, или ошибочна из-за
> того, что вы плохо разобрались в редакторе.
Но в чем именно я ошибаюсь ты говорить конечно же не будешь? И правда, аргумент в стиле "вы фсе врети" всегда был неоспорим.
А судя по этому:
Ankero
> Хочешь сделать реакцию на клик по какому-нибудь спрайту? Задавай ноду с
> границами и просчитывай координаты мышки, считывай инпут клика, соединяй всё
> это в метод и проверяй каждый фрейм
Ты даже основы движка godot не знаешь, но зато делаешь громкие выводы какой он плохой.
BEETON
У меня нет времени на срачи и расписывать всё по пунктам, просто ограничусь контр-аргументом. Судя по этому:
Game UI:
- Размер канваса в несколько раз больше размера границ игры. Приходится скроллиться туда-сюда постоянно.
Ты даже основы движка Unity не знаешь, зато делаешь громкие выводы, какой он плохой.
Ты не знаешь Юнити, я не знаю Годот, у обоих движков есть свои проблемы, так что просто не надо строить тут секты и пытаться убеждать людей, что "engine_name - идеальный вариант".
Ankero
> У меня нет времени на срачи и расписывать всё по пунктам
так я и думал. Ведь аргументом "ты ошибаешься и все высосал из пальца" можно победить любого в споре.
Ankero
> Ты даже основы движка Unity не знаешь, зато делаешь громкие выводы, какой он
> плохой.
Я опираюсь на опыт, который получил от работы в команде над большим коммерческим проектом. Может ты расскажешь нам как делать правильно?
BEETON
Я опираюсь на опыт, который получил от работы в команде над большим коммерческим проектом. Может ты расскажешь нам как делать правильно?
Ты работал над большим коммерческим проектом и ни разу не заглядывал в свойства канваса? Не знаешь, что кроме режима World Space есть еще Screen Space, который вписывает канвас в игровую камеру? Ой ля, не завидую я твоему большому коммерческому проекту, над ним такие спецы работают...
Ты не знаешь про команду ref, которой ресурс ищется в проекте, и поиск по проекту у тебя непредсказуемый (видимо, потому что с опечатками валишь и потом жалуешься, ой-ёй, поиск не работает), и 2D от 3D у него не отделено. В общем, как ты выше писал, общаться с такими "ололоперами" у меня желания нет.
slatazan
благодарю за возможность Ctrl+C/Ctrl+V научится чему то новому))
Почему все перешло в измерение чей движек больше и лучше???))
Как говорил мне учитель "Лучший инструмент тот которым ты умеешь пользоваться" остальное неважно))
Ankero
BEETON
усбагойтесь.
BEETON
ты многие аспекты отлично расписал, но есть моменты да. Есть кнопочка F, которая позиционирует объект по центру сцены.
Ещё что-то было, но это не принципиально.
Godot прост и его скорость и режим реалтайм дебагинга просто шедевр по сравнению даже с Java (хотя мне казалось удобнее уже просто не придумаешь).
Поэтому godot отлично подходит для быстрых прототипов.
Многие большие фирмы так работают. Вводят новую фичу (на основе идеи), смотрят как она сочетается или не сочетается, дорабатывается или частично изменяется геймплей (если это необходимо) и идёт частичное или полное утверждение в том, что: да - эта фича нам нужна или нет - сейчас эта фича тут не интересна и мы её отложим (уберём совсем).
Ежу понятно что Godot нехватает собственного магазина с Assets Store. И у него были проблемы с документацией, НО, он сразу позволил всем размещать свои проекты и учиться на чужом коде (а это тоже неплохой вариант). Сейчас документации вроде хватает, по крайней мере мне.
Ещё его огромный плюс в том, что он догмой работает по принципу React и Angular (это всё NodeJS). То есть мы разбиваем Замок на комнаты, комнаты на предметы в ней, предмет на шарики разбираем и можем этим всем управлять как снизу (через те же сигналы), так и сверху иерархии. В Юнити (это тоже есть, но оно там в другом виде, менее связанном друг с другом что ли)
в Unity удобнее работать именно команде, дизайнеров пустили в UI это открывает определенные двери, но нагружает художника дополнительными профессиями (ну у нас же все стараются делать больше и дешевле, ну как врачи например. Одна на больничном, значит берём целый чужой район на себя)
И есть UE, плюсом которого я считаю всё таки сеть. Ну и он если не сам уже настроен (в отличии от той же Unity), то имеет инструменты из коробки для многих вещей.
Однако, спорить какой из молотков лучше и удобнее - это всё ИМХО. Потому что без руки человека, молоток так и останется лишь деревянной палкой с железным клином.
Ankero
> Не знаешь, что кроме режима World Space есть еще Screen Space, который
> вписывает канвас в игровую камеру? Ой ля, не завидую я твоему большому
> коммерческому проекту, над ним такие спецы работают...
Ты вообще понимаешь разницу между World Space и Screen Space. Это разные режимы для разных вещей предназначены, юнити ты иксперт.
Дальше можешь не продолжать, я понял твой уровень, мне не интересно.
Salamandr
> в Unity удобнее работать именно команде, дизайнеров пустили в UI это открывает
> определенные двери
В годо это стало еще удобнее, с появлением возможности отключать в редакторе не нужные подсистемы. Можно оставить все связанное только с UI и художнику будет проще и испортить ничего не сможет.
Тема в архиве.