В последнее время стараюсь раз в неделю скачать и посмотреть новую мобильную игру, и про себя отметил что у многих проектов плохо реализованы — отзывчивость интерфейса, микроанимации, пропущены логичные анимационные/звуковые вставки. Всё то что я давно про себя называю — второй слой разработки. Это не индустриальный термин, но на мой взгляд хорошо харектеризует то что происходит в разработке игр.

О чем будет в этой статье

Я хочу раскрыть на конкретных примерах следующие моменты:

1. Почему второй слой разработки?
2. Отзывчивость интерфейса
3. Микроанимации
4. Визуальная логика

Рассмотрим на примере в том числе и этого проекта

В прошлой статье — Разновидности координат используемые в GUI Unity3d я попытался кратко рассказать о разновидностях координат в Unity UI/RectTransform. Теперь хочется немножко осветить такую полезную для UI штуку как RectTransformUtility. Которая является одним из основных инструментов вычисления чего либо в UI по отношению к чему либо ещё.

Простая непростая задача

Есть задача — нужен компонент который анимированно убирает UI элемент за выбранный край экрана. Компоненту должно быть фиолетово где он находится иерархически, в каких местах стоят якоря, какой размер экрана, и в каком месте экрана он находится. Компонент должен уметь убирать объект в 4е стороны (вверх, вниз, влево, вправо) за заданное время.

Почему разновидности и сколько их?

Часто сталкиваюсь с тем, что люди просто не понимают как подвинуть объект в UI на какое то значение, и удивляются что результат зачастую непредсказуем. Или допустим как получить правильные координаты объекта в UI. Если мы через дебагер выведем обычную позицию объекта(position), то она будет сильно отличаться от той что мы видим в инспекторе у UI элемента, так что же мы там видим и как это работает? В итоге перебираются 100500 решений с форумов пока какое либо не подойдет. Хочу придать подобным процессам осмысленное движение.

Суть подвоха заключается в следующем — у обычного Transform есть потомок RectTransform который и отвечает за положение и многие вещи связанные с размером, скейлом и тд — элемента UI. И благодаря ему мы можем получить следующие варианты координат.

1. position
2. localPosition
3. anchoredPosition (есть еще anchoredPosition3D, но его не будем рассматривать отдельно, а будем считать что это подвид test.anchoredPosition

В первой части я рассуждал для чего прототипирование и в целом с чего начать
— Часть 1

В второй части немножко пробежались по ключевым классам
и архитектуре — Часть 2

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

Скриншоты про ракету в целом унылые, поэтому предлагаю посмотреть видео другого прототипа, который был собран за 2е недели вместе с графикой, и был заброшен в связи с тем что в жанре платформеры и так не протолкнуться. Это кстати одна из ключевых идей вокруг прототипа — собрать, посмотреть, не гавно ли это, нужно ли это? И честно забросить в корзину если вам ответы кажутся недостаточно убедительными. Но! Это не касается творческих проектов — иногда творчество бывает ради творчества ).

Итак видосик, смотреть надо на тексты расставленные по уровню, а не на геймплей ):

Для тех кто пропустил первую часть — Часть 1
Следующая часть — Часть 3

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

Итак, начинаем собирать всё в кучу

Так получилось что я часто делаю прототипы (как по работе, так и на личных проектах)
и хочу поделиться накопленным опытом. Хочется написать статью которую бы самому было интересно читать, и в первую очередь мне интересно чем руководствуется человек когда принимает то или иное решение в реализации проекта, как он начинает проект, зачастую начать — самое сложное.

Свежий пример который я хочу с вами рассмотреть — концепт казуальной головоломки, основанной на физике. Иногда я буду упоминать сверх очевидные вещи с целью развернуть тему для новичков.

Идея выглядит так

Часть 2
Часть 3

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

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

Необходимый функционал:

1. Любой класс может подписаться на любое событие (часто агрегаторы в юнити делают подписчиками конкретные Gameobject)
2. Должна быть исключена возможность двойной подписки конкретного экземпляра, на конкретное событие (в стандартных средствах за этим нужно следить самому)
3. Должен быть функционал как ручной отписки, так и автоматической, в случае удаления экземпляра/отключения монобеха (хочется подписаться и не париться что подписчик вдруг откинет копытца)
4. события должны уметь перекидывать данные/ссылки любой сложности (хочется в одну строку подписаться и получить весь комплект данных без заморочек)