Комментарии 19
Вы ограничивали как-то дизайнеров в фигме? Например, был ли запрет на использование эффектов, векторных элементов? Как потом переносили тени, блюр и прочие вещи в движок? Какой вообще был пайплайн по импорту пнг/векторов из фигмы в проект?
Поскольку у нас в студии кто рисует, тот и верстает в Юнити, то я просто не использовал те элементы, которые не мог повторить в движке. То есть
Для теней - используется тянущийся спрайт тени нужной степени размытости, которому потом в движке назначается нужные прозрачность и цвет.
Блюр как динамическая сущность не применяется вовсе. Вместо это приходится использовать другие приемы - например, всяческие затемнения либо прозрачность.
Все элементы на которых есть режимы наложения схлопываются в один без наложений.
Пайплайн вкратце следующий: все элементы из Фигмы "схлопывались" в минимальное количество слоев, по возможности приводились под "тянущийся" (9-slice) формат и выгружались из Фигмы в виде png. Затем в таком виде загружались в Юнити и там уже добавлялись в атлас и настраивались.
Есть плагин для автоматиической конвертации дизайнов из Фигмы в Юнити. Но результат его работы конечно хуже, чем результат ручной переноски.
Не хватает в выводах про удобство работы с Фигма и навели ли порядок в файлах. Стали ли процессы добавления нового контента удобнее и быстрее?
Да, теперь все экраны и состояния элементов находятся на одном большом артборде. Кроме того, нейминг экранов и элементов в Фигме и в Юните совпадают, так что в материалах очень легко ориентироваться. Ну и наличие полноценных компонентов позволяет легко менять какие-то повторяющиеся элементы (те же кнопки из примера).
Ребята из Пиксоника писали статью о своем опыте перехода из Фотошопа на Фигму в War Robots, там более детально тема раскрыта.
Главное в UI - чтобы было понятно, что это за 500% с картинки. Мне вот непонятно.
Как обстоят дела с адаптивным дизайном в юнити? Используете Canvas Scaler, Horisonal/VerticalLayout? Или код для адаптивности сами писали? Я говорю даже не о портретной/ландскейп, а просто о корректном отображении в одном аспекте. Например, ширина 800 и 2000.
Я бы сказал, что в Юнити все довольно хорошо с адаптивным дизайном. Ну, с учетом того, что в играх нет возможности динамически поменять ориентацию экрана (т.е. в процессе игры нельзя перевернуть экран и с портретной ориентации перейти на ландшафтную).
Адаптивности добиваемся только теми средствами, что дает Юнити "из коробки", ничего дополнительно не писали. Canvas Scaler'а, "якорения" элементов, size fitter'а и лэйаутов вполне хватает. Даже на ПК удалось перенести все экраны с минимальными корректировками верстки.
Самой проблемной (для меня, по крайней мере) частью была работа с safe area. Если у девайса есть челка или врезанная камера, он информацию об этом передает Юнити, чтобы она делала соответствующий отступ и ничего под ними не отрисовыавала. Но на каких-то девайсах инфа об отступах указана производителем корректно, а на каких-то нет. И поэтому внутри зоопарка андроид устройств постоянно попадались те, на которых функциональные элементы интерфейса залезают под камеру или скругления углов. Очень бесит, но как с этим бороться, я так и не придумал (кроме больших отступов).
Есть еще вариант добавить пользовательские настройки или сопоставлением SystemInfo.deviceModel с полным списком устройств и их челочности - но это еще список над составить или найти.
Рад, что информация была полезна! По вопросам, с удовольствием отвечу:
Каких-то значительных сложностей не возникло. В целом, по моим ощущениям Фигма намного понятнее и интуитивнее Фотошопа. Единственное узкое место, которое я вижу - векторность Фигмы. То есть если бы наш интерфейс был сильно более художественным, мне бы пришлось намного больше элементов создавать в фотошопе и потом переносить в Фигму в виде растровых изображений. Процесс переноса всех экранов в нашем случае занял месяцев пять. Но тут нужно учитывать, что этим занимался один дизайнер в промежутках между основными задачами.
Да, все так как вы описали. Нарисовали в Фигме - "схлопнули" в минимальное количество слоев - минимизировали размер под 9-slice (если это возможно) - выгрузили в png - загрузили в Юнити - настроили, добавили в атлас. В больших студиях переносом макетов в движок занимается отдельный человек, в нашем случае и дизайнер и верстальщик это одно и то же лицо.
С появлением Фигмы сильно сократилось кол-во лишних спрайтов в движке и кол-во лишних телодвижений в приципе. Ты всегда точно знаешь, используется ли какой-то конкретный элемент где-то еще. Можешь найти все его инстансы и соотнести с тем, что есть в движке. Я бы сказал, что для верстальщика жизнь облегчилась.
Вообще, огромным плюсм Фигмы я бы назвал прозрачность процесса производства экранов. Любой человек в команде может открыть артборд и получить полную информацию, которая ему нужна. Например, кодеры могут увидеть все возможные состояния элементов, верстальщики - все размеры и отступы, художники - какого формата картинки где используются, геймдизайнеры - как фича работает и т.д.
Были ли попытки автоматизировать импорт из фигмы в unity для ускорения процесса верстки за счёт готовых для экспорта экранов в фигме или всё полностью версталось?
Настраивали систему для визуализации всех переходов в фигме для возможности прокликать все экраны и возможно настроить там же анимации?
Отличные вопросы!
Про автоматизацию. Я пробовал решения из ассетстора, и мне показалось, что игра не стоит свеч. Финальный результат получается хуже и при этом все равно требует ручной доводки. Так что все на этом проекте все экраны собираются в движке вручную.
Про визуализацию. Если бы свободных рук было побольше, я бы наверное заморочился и создал интерактивный "стенд", как минимум для отдельных фич, на котором их можно было бы пощупать в как-бы-финальном качестве до сборки в движке. Я вижу в этом ценность и думаю, что качество новых фичей бы от этого выиграло.
При этом вот конкретно на анимации в Фигме я бы тратить время не стал. Трудоемкость высокая, а выхлоп маленький, да и возможности Фигмы в этом плане очень ограничены. Проще собрать превьюху конкретного (сложного) эффекта в AfterEffects или AdobeAnimate.
Перенес комментарий в ответ
Перенес комментарий в ответ
Спасибо, что поделились опытом. У меня возникли следующие вопросы, буду рад, если сможете ответить)
1. Проводили ли вы анализ элементов на экране и дальнейшую оптимизацию? Если да, то какие подходы или инструменты использовали?
2. Проводили ли тесты на вайерфреймах или сразу утверждали концепцию и тестировали уже после отрисовки?
3. Насколько я понял в данном проекте недиегетический интерфейс, возникали ли вопросы о переходе каких-то элементов в диегетический фоормат из-за расширения тех.возможностей? Или у вас всё было строго зафиксировано на уровне предыдущего дизайна?
Привет!
Проводили ли вы анализ элементов на экране и дальнейшую оптимизацию? Если да, то какие подходы или инструменты использовали?
Если вопрос о том, как мы отслеживаем (и отслеживаем ли вообще) степень оптимизации UI, то могу честно сказать что у нас это сделано на довольно базовом уровне. Просадить FPS в игре за счет чисто интерфейсных элементов достаточно сложно, тут нужно постараться. Обычно если на экране нет большого количества 3D объектов, то даже старые мобильные устройства без проблем переваривают большое количество draw call'ов (80+ на кадр) без просадок. Естественно, мы стараемся до таких цифр не доходить. Но получается не всегда )
А вот интерфейс в бою это отдельная тема. Там всегда наблюдается дефицит ресурсов, и экономия каждой лишней отрисовки в UI оправдана. Поэтому оптимизацией интерфейса "по-серьезному" мы занимаемся только тут: разбиваем канвасы, считаем draw call'ы, не используем юнити аниматор, максимально ужимаем количество слоев и т.д. Есть хорошая статья от ребят из Banzai Games.
Понять, что вот тут что-то не так, помогает три "инструмента" (в порядке очередности):
Здравый смысл. Если при заходе на экран на средних девайсах игра заметно дергается и подтормаживает, то тут явно что-то нечисто.
Rendering Statistics window. Проще всего получить базовое представление о том, что происходит с рендером на экране, открыв это окошко. Обычно на этом этапе становится понятно, в чем заключается проблема.
Для более детальной инфоррации запускаем unity profiler. В нем можно максимально детально посомтреть, что и как батчится (и почему не батчится) и откуда на экране берется данное количество draw call'ов. Об использовании профайлера есть хорошее руководство, ну либо см. официальную документацию от Unity.
Проводили ли тесты на вайерфреймах или сразу утверждали концепцию и тестировали уже после отрисовки?
В студии у нас следующий пайплайн:
Геймдизайнеры формируют ТЗ на фичу. Она может быть как чисто словесной, так и с визуальными материалами (рефы, файрмреймы).
Когда ТЗ закончено, приходит UI/UX дизайнер, отсматривает внимательно запрос, задает уточняющие вопросы.
Дальше обычно дизайнер предоставляет несколько вариантов визуализации. Поскольку у нас интерсфейс уже устаканившийся, то превью я собираю сразу из готовых существующих элементов, добавляя к ним новые, если требуется. Т.е. утверждение UI/UX фичи идет уже на превьюхах условно-финального качества, но без всех состояний элементов и с заглушками вместо арта.
После пары итераций, когда превью утверждены, они финализируются (добавляются состояния, дорисовываются недостающие элементы, делается превью анимаций, если они есть).
Все это дело нарезается и собирается в движке.
После того как экраны собраны и подключены, мы плейтестим фичу внутри студии. Обычно на этом моменте как раз становятся понятны косяки и необходимые коррективы. Несмотря на то что на доработки всегда выделено время, в особо запущенных случаях мы бывало промахивались настолько, что фичу приходилось откладывать на один-два релиза либо вообще отменять.
После релиза фичи смотрим на ее метрики и сравниваем с ожидаемыми (которые прописаны заранее ГД), собираем фидбэк игроков. Бывает, что вот тут приходит осознание, что что-то не работает или работает плохо, и тогда фиксы вносятся в планы.
Насколько я понял в данном проекте недиегетический интерфейс, возникали ли вопросы о переходе каких-то элементов в диегетический фоормат из-за расширения тех.возможностей? Или у вас всё было строго зафиксировано на уровне предыдущего дизайна?
Нет, таких вопросов не возникало. Диегетический интерфейс это не самоцель, он не лучше недегиетического "по дефолту". Я это вижу так: если в конкретной игре важно максимальное погружение игрока в мир, то тогда, возможно стоит заморочиться с встраиванием интерфейсных элементов внутрь игрового мира (см. Pip-Boy в Fallout, HUD в Metro: Exodus, весь GUI Dead Space и т.д.). В мобильном проекте смысла в этом немного, трудозатраты просто не окупятся.
Какое количество пользователей было в тестируемых группах?
Редизайн игрового интерфейса. Как, а главное зачем?