Проводили ли вы анализ элементов на экране и дальнейшую оптимизацию? Если да, то какие подходы или инструменты использовали?
Если вопрос о том, как мы отслеживаем (и отслеживаем ли вообще) степень оптимизации 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 и т.д.). В мобильном проекте смысла в этом немного, трудозатраты просто не окупятся.
Про автоматизацию. Я пробовал решения из ассетстора, и мне показалось, что игра не стоит свеч. Финальный результат получается хуже и при этом все равно требует ручной доводки. Так что все на этом проекте все экраны собираются в движке вручную.
Про визуализацию. Если бы свободных рук было побольше, я бы наверное заморочился и создал интерактивный "стенд", как минимум для отдельных фич, на котором их можно было бы пощупать в как-бы-финальном качестве до сборки в движке. Я вижу в этом ценность и думаю, что качество новых фичей бы от этого выиграло.
При этом вот конкретно на анимации в Фигме я бы тратить время не стал. Трудоемкость высокая, а выхлоп маленький, да и возможности Фигмы в этом плане очень ограничены. Проще собрать превьюху конкретного (сложного) эффекта в AfterEffects или AdobeAnimate.
Рад, что информация была полезна! По вопросам, с удовольствием отвечу:
Каких-то значительных сложностей не возникло. В целом, по моим ощущениям Фигма намного понятнее и интуитивнее Фотошопа. Единственное узкое место, которое я вижу - векторность Фигмы. То есть если бы наш интерфейс был сильно более художественным, мне бы пришлось намного больше элементов создавать в фотошопе и потом переносить в Фигму в виде растровых изображений. Процесс переноса всех экранов в нашем случае занял месяцев пять. Но тут нужно учитывать, что этим занимался один дизайнер в промежутках между основными задачами.
Да, все так как вы описали. Нарисовали в Фигме - "схлопнули" в минимальное количество слоев - минимизировали размер под 9-slice (если это возможно) - выгрузили в png - загрузили в Юнити - настроили, добавили в атлас. В больших студиях переносом макетов в движок занимается отдельный человек, в нашем случае и дизайнер и верстальщик это одно и то же лицо.
С появлением Фигмы сильно сократилось кол-во лишних спрайтов в движке и кол-во лишних телодвижений в приципе. Ты всегда точно знаешь, используется ли какой-то конкретный элемент где-то еще. Можешь найти все его инстансы и соотнести с тем, что есть в движке. Я бы сказал, что для верстальщика жизнь облегчилась.
Вообще, огромным плюсм Фигмы я бы назвал прозрачность процесса производства экранов. Любой человек в команде может открыть артборд и получить полную информацию, которая ему нужна. Например, кодеры могут увидеть все возможные состояния элементов, верстальщики - все размеры и отступы, художники - какого формата картинки где используются, геймдизайнеры - как фича работает и т.д.
Я бы сказал, что в Юнити все довольно хорошо с адаптивным дизайном. Ну, с учетом того, что в играх нет возможности динамически поменять ориентацию экрана (т.е. в процессе игры нельзя перевернуть экран и с портретной ориентации перейти на ландшафтную).
Адаптивности добиваемся только теми средствами, что дает Юнити "из коробки", ничего дополнительно не писали. Canvas Scaler'а, "якорения" элементов, size fitter'а и лэйаутов вполне хватает. Даже на ПК удалось перенести все экраны с минимальными корректировками верстки.
Самой проблемной (для меня, по крайней мере) частью была работа с safe area. Если у девайса есть челка или врезанная камера, он информацию об этом передает Юнити, чтобы она делала соответствующий отступ и ничего под ними не отрисовыавала. Но на каких-то девайсах инфа об отступах указана производителем корректно, а на каких-то нет. И поэтому внутри зоопарка андроид устройств постоянно попадались те, на которых функциональные элементы интерфейса залезают под камеру или скругления углов. Очень бесит, но как с этим бороться, я так и не придумал (кроме больших отступов).
Да, теперь все экраны и состояния элементов находятся на одном большом артборде. Кроме того, нейминг экранов и элементов в Фигме и в Юните совпадают, так что в материалах очень легко ориентироваться. Ну и наличие полноценных компонентов позволяет легко менять какие-то повторяющиеся элементы (те же кнопки из примера).
Ребята из Пиксоника писали статью о своем опыте перехода из Фотошопа на Фигму в War Robots, там более детально тема раскрыта.
Поскольку у нас в студии кто рисует, тот и верстает в Юнити, то я просто не использовал те элементы, которые не мог повторить в движке. То есть
Для теней - используется тянущийся спрайт тени нужной степени размытости, которому потом в движке назначается нужные прозрачность и цвет.
Блюр как динамическая сущность не применяется вовсе. Вместо это приходится использовать другие приемы - например, всяческие затемнения либо прозрачность.
Все элементы на которых есть режимы наложения схлопываются в один без наложений.
Пайплайн вкратце следующий: все элементы из Фигмы "схлопывались" в минимальное количество слоев, по возможности приводились под "тянущийся" (9-slice) формат и выгружались из Фигмы в виде png. Затем в таком виде загружались в Юнити и там уже добавлялись в атлас и настраивались.
Есть плагин для автоматиической конвертации дизайнов из Фигмы в Юнити. Но результат его работы конечно хуже, чем результат ручной переноски.
В «причины» я бы добавил еще один пункт: связанность переходов и сущностей. Не всегда это актуально, но иногда приходится добавлять анимацию, чтобы переход с одного экрана на другой выглядел переходом из одной комнаты в другую через дверь, а не однокадровой дизориентирующей телепортацией. Плюс сюда же можно привести классические примеры типа «тапнул — ресурсы списались, цифра поменялась» VS «тапнул — ресурсы мигнули, счетчик открутился».
Еще я не очень согласен с тем, что делать сразу в движке хуже, чем делать сначала превьюху в сторонней проге. ИМХО, если человек может собрать все в Unity, то нафига ему дублировать работу еще где-то? В том же After Effect вы пройдете все те же этапы (определение идеи, нарезка графики, настройка таймингов), которые потом придется повторить в движке. И не всегда их можно сделать идентичными, особенно если человек, который делал превьюху, не очень хорошо представляет ограничения движка.
Судя по задаче, которую ты описываешь, в твоем случае как раз достаточно будет неинтерактивного (или минимально интерактивного) прототипа, сделанного с помощью обычных «дизайнерских» инструментов для прототипирования.
Считается, что Principle помощнее конкурентов в плане анимаций и интерактивности, за это Ом его и выбрал. Но Principle (как и Sketch, который тоже хорош) доступен только для маководов.
Все прототипы по ссылке — из портфолио Ома, а у него вся команда работает только в Principle. Думаю, и интересующий тебя пример сделан в нём же.
Присоединяюсь к когорте тупого быдла. Я, честно признаюсь, не в состоянии оценить узкоспециализированные посты автора про LLTR (судя по косвенным признакам, они действительно стОящие). Но. Мне всегда казалось, что один из признаков высокого интеллекта у человека — умение четко оформлять свои мысли и доносить информацию. Если, конечно, он хочет это сделать. А если не хочет — к чему тогда вообще что-то постить?
Если автор хотел донести до сообщества некую информацию о себе или о «колонии», то выбрал, на мой взгляд, неудачный стиль и формат.
Если это художественный текст из разряда «мир, в котором мне хотелось бы жить», то стоит однозначнее это обозначить.
Если автор хотел поговорить о своей болезни, то почему бы не сделать это прямо? К чему эти заигрывания с темой в каждом посте? И уж если ему действительно жить осталось лишь несколько месяцев и ничего нельзя изменить, не лучше ли рассказать сообществу эту историю вместо туманной притчи о некоей колонии?
Не все хотят рвануть в исландское автономное поселение, не все работают с LLTR, но все сталкивались или еще столкнутся с болезнями и смертью. Лично мне бы любой чужой опыт из этой области мог бы помочь в критический момент.
Стиль и любовь автора к туманным ответам на прямые вопросы наводят на мысль, что это некий своеобразный перформанс и его физическое здоровье находится вне смертельной опасности.
Интересно было бы более подробно почитать про определение ЦА для проектов и как описание условной Ирины превращается в кейс для дизайнера. Вообще, какая аналитика минимально необходима для определения ЦА, или обычно свою ЦА просто описывает владелец проекта, и все пляшут от его видения?
Ну… всегда сложно что-то сказать, не зная конкретики проекта. Но основных мысли возникает три:
Вы, насколько я понял, выступаете для дизайнера заказчиком, правильно? И многое зависит от вашей формулировки задачи. Если просто прислать простыню с рефами и сказать «сделай как тут», то на выходе, конечно, будет копипаста. А если сформулировать задачу как «сделай что-то наподобие этого и вот этого, а палитру давай попробуем взять примерно как тут», то получится уже что-то свое. Как и везде, тут работает принцип «Copy. Transform. Combine». Кроме того, всегда можно завернуть явно скопированные с рефов элементы на этапе приемки работы.
Вторая мысль: уж если у вас есть дизайнер, то он вполне может выполнить бОльшую часть работы за вас. Собрать релевантные рефы, сформулировать предложения и варианты, накидать пару экранов в выбранной стилистике и т.д.
Ну и последнее: звучит крамольно, не всегда имеет смысл стремиться к чему-то «своему» и «уникальному». Да, от больших проектов пользователь ожидает индивидуальности, но если речь идет о небольшом казуальном проекте для мобилок, часто выгоднее взять какую-то распространенную и простую стилистику, к которой пользователь уже привык. Посмотрите на приложения студии Ketchapp, к примеру. Это не треш, это рыночная стратегия )
Я бы в таком случае посоветовал налегать на референсы.
Чтобы определить, где какие элементы должны быть, какого размера, как их расположить и т.д. — найдите игры, похожие (функционально) на ваш проекты и подсмотрите, как это сделано у них. Отметьте вещи, которые вам нравятся и которые хочется перенять. И не бойтесь «плагиата» — в результате вы все равно все переделаете под себя, зато так у вас появится платформа для старта.
По поводу стиля — опять же, смотрите на сторы. Какие проекты популярны и какие нравится визуально лично вам? Наберите себе реф-лист. Если после этого ситуация не прояснится — покажите рефы знакомым и друзьям, которые более-менее похожи на вашу целевую аудиторию, они наверняка смогут подкинуть идей и мнений для начала.
Вообще, если по визуалу нет даже общего понимания (хотя бы того, какой сеттинг у игры), то, на мой взгляд, на него можно спокойно забивать до какого-то этапа.
1) Заглушечные иконки я обычно беру с thenounproject.com, там всегда есть из чего выбрать или, как минимум, набраться идей.
2) По серому в мокапах лично у меня нет каких-то четко выделенных правил. В целом, главное, чтобы элементы читались и было не слишком контрастно. Если есть сомнения, я бы посоветовал найти мокапы, которые нравятся визуально, и с них пипеткой набирать палитры. Ну и быть последовательным — фоны всегда одного цвета, кнопки другого, иконки третьего и т.п.
Если тема интересна, могу предложить почитать вот эту статью, там я чуть детальнее описал свою логику работы с мокапами.
16.6K юзеров в одной группе и 6.5K в другой
Привет!
Если вопрос о том, как мы отслеживаем (и отслеживаем ли вообще) степень оптимизации 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 и т.д.). В мобильном проекте смысла в этом немного, трудозатраты просто не окупятся.
Отличные вопросы!
Про автоматизацию. Я пробовал решения из ассетстора, и мне показалось, что игра не стоит свеч. Финальный результат получается хуже и при этом все равно требует ручной доводки. Так что все на этом проекте все экраны собираются в движке вручную.
Про визуализацию. Если бы свободных рук было побольше, я бы наверное заморочился и создал интерактивный "стенд", как минимум для отдельных фич, на котором их можно было бы пощупать в как-бы-финальном качестве до сборки в движке. Я вижу в этом ценность и думаю, что качество новых фичей бы от этого выиграло.
При этом вот конкретно на анимации в Фигме я бы тратить время не стал. Трудоемкость высокая, а выхлоп маленький, да и возможности Фигмы в этом плане очень ограничены. Проще собрать превьюху конкретного (сложного) эффекта в AfterEffects или AdobeAnimate.
Рад, что информация была полезна! По вопросам, с удовольствием отвечу:
Каких-то значительных сложностей не возникло. В целом, по моим ощущениям Фигма намного понятнее и интуитивнее Фотошопа. Единственное узкое место, которое я вижу - векторность Фигмы. То есть если бы наш интерфейс был сильно более художественным, мне бы пришлось намного больше элементов создавать в фотошопе и потом переносить в Фигму в виде растровых изображений. Процесс переноса всех экранов в нашем случае занял месяцев пять. Но тут нужно учитывать, что этим занимался один дизайнер в промежутках между основными задачами.
Да, все так как вы описали. Нарисовали в Фигме - "схлопнули" в минимальное количество слоев - минимизировали размер под 9-slice (если это возможно) - выгрузили в png - загрузили в Юнити - настроили, добавили в атлас. В больших студиях переносом макетов в движок занимается отдельный человек, в нашем случае и дизайнер и верстальщик это одно и то же лицо.
С появлением Фигмы сильно сократилось кол-во лишних спрайтов в движке и кол-во лишних телодвижений в приципе. Ты всегда точно знаешь, используется ли какой-то конкретный элемент где-то еще. Можешь найти все его инстансы и соотнести с тем, что есть в движке. Я бы сказал, что для верстальщика жизнь облегчилась.
Вообще, огромным плюсм Фигмы я бы назвал прозрачность процесса производства экранов. Любой человек в команде может открыть артборд и получить полную информацию, которая ему нужна. Например, кодеры могут увидеть все возможные состояния элементов, верстальщики - все размеры и отступы, художники - какого формата картинки где используются, геймдизайнеры - как фича работает и т.д.
Я бы сказал, что в Юнити все довольно хорошо с адаптивным дизайном. Ну, с учетом того, что в играх нет возможности динамически поменять ориентацию экрана (т.е. в процессе игры нельзя перевернуть экран и с портретной ориентации перейти на ландшафтную).
Адаптивности добиваемся только теми средствами, что дает Юнити "из коробки", ничего дополнительно не писали. Canvas Scaler'а, "якорения" элементов, size fitter'а и лэйаутов вполне хватает. Даже на ПК удалось перенести все экраны с минимальными корректировками верстки.
Самой проблемной (для меня, по крайней мере) частью была работа с safe area. Если у девайса есть челка или врезанная камера, он информацию об этом передает Юнити, чтобы она делала соответствующий отступ и ничего под ними не отрисовыавала. Но на каких-то девайсах инфа об отступах указана производителем корректно, а на каких-то нет. И поэтому внутри зоопарка андроид устройств постоянно попадались те, на которых функциональные элементы интерфейса залезают под камеру или скругления углов. Очень бесит, но как с этим бороться, я так и не придумал (кроме больших отступов).
Да, теперь все экраны и состояния элементов находятся на одном большом артборде. Кроме того, нейминг экранов и элементов в Фигме и в Юните совпадают, так что в материалах очень легко ориентироваться. Ну и наличие полноценных компонентов позволяет легко менять какие-то повторяющиеся элементы (те же кнопки из примера).
Ребята из Пиксоника писали статью о своем опыте перехода из Фотошопа на Фигму в War Robots, там более детально тема раскрыта.
Поскольку у нас в студии кто рисует, тот и верстает в Юнити, то я просто не использовал те элементы, которые не мог повторить в движке. То есть
Для теней - используется тянущийся спрайт тени нужной степени размытости, которому потом в движке назначается нужные прозрачность и цвет.
Блюр как динамическая сущность не применяется вовсе. Вместо это приходится использовать другие приемы - например, всяческие затемнения либо прозрачность.
Все элементы на которых есть режимы наложения схлопываются в один без наложений.
Пайплайн вкратце следующий: все элементы из Фигмы "схлопывались" в минимальное количество слоев, по возможности приводились под "тянущийся" (9-slice) формат и выгружались из Фигмы в виде png. Затем в таком виде загружались в Юнити и там уже добавлялись в атлас и настраивались.
Есть плагин для автоматиической конвертации дизайнов из Фигмы в Юнити. Но результат его работы конечно хуже, чем результат ручной переноски.
Перенес комментарий в ответ
Перенес комментарий в ответ
Хорошо написано, но к сожалению у меня не заработало. Девайс появляется в списке симулятора, но на этом все.
Если вдруг кто-то еще, как и я, пришел просто в поиске работающих на версии Юнити 2021+ device definitions для 14-х айфонов, то вот эти (https://gist.github.com/mrcarriere/049596740fb52907edf68712d2818df0) запустились из коробки.
Еще я не очень согласен с тем, что делать сразу в движке хуже, чем делать сначала превьюху в сторонней проге. ИМХО, если человек может собрать все в Unity, то нафига ему дублировать работу еще где-то? В том же After Effect вы пройдете все те же этапы (определение идеи, нарезка графики, настройка таймингов), которые потом придется повторить в движке. И не всегда их можно сделать идентичными, особенно если человек, который делал превьюху, не очень хорошо представляет ограничения движка.
Судя по задаче, которую ты описываешь, в твоем случае как раз достаточно будет неинтерактивного (или минимально интерактивного) прототипа, сделанного с помощью обычных «дизайнерских» инструментов для прототипирования.
Считается, что Principle помощнее конкурентов в плане анимаций и интерактивности, за это Ом его и выбрал. Но Principle (как и Sketch, который тоже хорош) доступен только для маководов.
Все прототипы по ссылке — из портфолио Ома, а у него вся команда работает только в Principle. Думаю, и интересующий тебя пример сделан в нём же.
Она свежая (2018 год), сфокусирована на играх (в первую очередь ПК и консоли) и написана для геймдизайнеров и UI/UX специалистов.
А еще там в конце есть длиннющий и абсолютно бесценный список полезных тематических статей и книг.
Если автор хотел донести до сообщества некую информацию о себе или о «колонии», то выбрал, на мой взгляд, неудачный стиль и формат.
Если это художественный текст из разряда «мир, в котором мне хотелось бы жить», то стоит однозначнее это обозначить.
Если автор хотел поговорить о своей болезни, то почему бы не сделать это прямо? К чему эти заигрывания с темой в каждом посте? И уж если ему действительно жить осталось лишь несколько месяцев и ничего нельзя изменить, не лучше ли рассказать сообществу эту историю вместо туманной притчи о некоей колонии?
Не все хотят рвануть в исландское автономное поселение, не все работают с LLTR, но все сталкивались или еще столкнутся с болезнями и смертью. Лично мне бы любой чужой опыт из этой области мог бы помочь в критический момент.
Стиль и любовь автора к туманным ответам на прямые вопросы наводят на мысль, что это некий своеобразный перформанс и его физическое здоровье находится вне смертельной опасности.
Вы, насколько я понял, выступаете для дизайнера заказчиком, правильно? И многое зависит от вашей формулировки задачи. Если просто прислать простыню с рефами и сказать «сделай как тут», то на выходе, конечно, будет копипаста. А если сформулировать задачу как «сделай что-то наподобие этого и вот этого, а палитру давай попробуем взять примерно как тут», то получится уже что-то свое. Как и везде, тут работает принцип «Copy. Transform. Combine». Кроме того, всегда можно завернуть явно скопированные с рефов элементы на этапе приемки работы.
Вторая мысль: уж если у вас есть дизайнер, то он вполне может выполнить бОльшую часть работы за вас. Собрать релевантные рефы, сформулировать предложения и варианты, накидать пару экранов в выбранной стилистике и т.д.
Ну и последнее: звучит крамольно, не всегда имеет смысл стремиться к чему-то «своему» и «уникальному». Да, от больших проектов пользователь ожидает индивидуальности, но если речь идет о небольшом казуальном проекте для мобилок, часто выгоднее взять какую-то распространенную и простую стилистику, к которой пользователь уже привык. Посмотрите на приложения студии Ketchapp, к примеру. Это не треш, это рыночная стратегия )
Чтобы определить, где какие элементы должны быть, какого размера, как их расположить и т.д. — найдите игры, похожие (функционально) на ваш проекты и подсмотрите, как это сделано у них. Отметьте вещи, которые вам нравятся и которые хочется перенять. И не бойтесь «плагиата» — в результате вы все равно все переделаете под себя, зато так у вас появится платформа для старта.
По поводу стиля — опять же, смотрите на сторы. Какие проекты популярны и какие нравится визуально лично вам? Наберите себе реф-лист. Если после этого ситуация не прояснится — покажите рефы знакомым и друзьям, которые более-менее похожи на вашу целевую аудиторию, они наверняка смогут подкинуть идей и мнений для начала.
Вообще, если по визуалу нет даже общего понимания (хотя бы того, какой сеттинг у игры), то, на мой взгляд, на него можно спокойно забивать до какого-то этапа.
1) Заглушечные иконки я обычно беру с thenounproject.com, там всегда есть из чего выбрать или, как минимум, набраться идей.
2) По серому в мокапах лично у меня нет каких-то четко выделенных правил. В целом, главное, чтобы элементы читались и было не слишком контрастно. Если есть сомнения, я бы посоветовал найти мокапы, которые нравятся визуально, и с них пипеткой набирать палитры. Ну и быть последовательным — фоны всегда одного цвета, кнопки другого, иконки третьего и т.п.
Если тема интересна, могу предложить почитать вот эту статью, там я чуть детальнее описал свою логику работы с мокапами.