Меня ничем не расстраивают, я именно ими и занимаюсь, и видимо местный токсичный народ меня неправильно понял, что если бы я не занимался играми, то хотел бы заниматься разработкой софтом для анимаций/3д
Нужны канешн ), просто про деревья обычно спрашивают на собеде всякие штуки которые давным давно читал в учебнике, плюс придираются к формулировкам. А вакансия вообще про UI ), где большую часть времени надо старые префабы переделывать.
По теме статьи — генерация контента очень прикольная и интересная тема ), результат у автора на первый взгляд ничошный такой.
Если движение от точки А до точки Б, можно использовать глобальные координаты. Так как у нас нет привязки к конкретному элементу UI и смещению относительно него. Может возникать вопрос в взаимной отрисовке сцены и UI. Фишки — элементы сцены, они должны изначально рисоваться под UI, потом поверх. Для этого канвас должен быть Camera Type c своим слоем сортировки, потом меняем фишкам, сортировку на UI и вуаля они уже кучкуются на панельку.
Идея с органическими формами и отсылкой к вагнерам — прикольная, подпилить визуал и будет норм. Сейчас всё слишком пластиковое, плюс детали сливаются на малых формах.
А насчёт геймплея — стреляющими тачками никого не удивить, на позапрошлом девгаме видел 3 концепта на эту тему, причём все были занудными.
ЗЫ насчёт бликов и тд, попробуй рефлекшен пробы добавить
Тогда не сработает, ибо layout компоненты переписывают все манипуляции с рект трансформами, навскидку можно предложить вешать layout element на скрываемый объект, включать игнорирование layout и потом активировать скрытие за экраном, тогда сработает. Но скорее всего будет глючить ибо освободится место в layout group и все элементы сместятся.
Вообще все анимирование layout group сложная история, там в итоге придется писать кучу костылей, поэтому большинство анимированных списков в играх — это самописная история без использование layout.
Там наверху тэг Unity. Соответственно речь об этом. Как фреймворк работает вне Unity — отдельная песня. Теперь зайдем с другой стороны — можете ли вы утверждать что ваш фреймворк быстрее нативного ECS и даст результат лучше чем DOTS в целом?
Все реализации кроме нативной не дадут того прироста производительности, и по факту являются надстройкой над монобехом. А реализация скиллов всегда строится на системе предикатов, её не избежать как в ECS так и в других парадигмах, и нормальная система в целом атомарна и даёт возможность создавать предикаты геймдизайнерам. Просто описанную автором систему можно оспорить и покритиковать. И скажем так, более композитные решения будут более удачны, но это не аргумент в целом за использование ECS, и их можно также легко решить в ООП.
Мне понравилось выступление на конференции Юнити, и там чел сказал что проверяет SRP очень просто, он задаёт вопрос — что делает этот класс? Если ответ содержит в себе список функционала, то вывод очевиден ).
современные языки поддерживают много парадигм, плюс на выбор есть тонны архитектурных паттернов и тд. Для геймдева отлично подходят — композиция, ECS, событийная и реактивные модели. Это помимо ООП здорового человека (без фанатизма). Который тоже хорош. В любом проекте есть комбинация подходов, и это нормально. Я к тому что нормальный ООП до сих пор хорош и решает большинство вопросов.
По теме статьи — генерация контента очень прикольная и интересная тема ), результат у автора на первый взгляд ничошный такой.
Теперь должно работать, если нужно передать какую то специфичную камеру, а не главную, то надо еще чуток расширить метод.
А насчёт геймплея — стреляющими тачками никого не удивить, на позапрошлом девгаме видел 3 концепта на эту тему, причём все были занудными.
ЗЫ насчёт бликов и тд, попробуй рефлекшен пробы добавить
Вообще все анимирование layout group сложная история, там в итоге придется писать кучу костылей, поэтому большинство анимированных списков в играх — это самописная история без использование layout.
:) если вам нравится парадигма ECS это не означает что большинству она проще и удобней. Кстати я так понимаю есть ECS фреймворк леопотам? )
Один вопрос — зачем? Поведение перемещения это отдельный функционал, рубка леса отдельный функционал, зачем тут
Как мне видится — правильнее в поведении рубки, определять что мы закончили рубить по разным причинам, и запускать следующее поведение.
Но на мой взгляд главное без глупого фанатизма.