Если мы говорим об интерфейсах в игре, то это всегда вопрос скорее в ресурсах разработки. В общей системе разработки сталкрафта гуишкам отводится далеко не первое место, поэтому дизайнить мы можем что угодно, но стараемся дизайнить то, что точно смогут реализовать и ввести. Именно поэтому мы потратили часть времени не на разработку, непосредственно, гуишек, а на новую систему верстки, чтобы кодеры тратили меньше времени на гуишки. Но это время все еще есть и благодаря новой системе распределяется иначе.
Интерфейс состоит из двух частей: непосредственно, визуала и логики.
Визуал мы экспортируем прямиком из фигмы в игру уже адаптивным.
Я не буду сейчас расписывать, сколько времени требуется дизайнеру, чтобы родить интерфейс и документацию к нему для отдела разработки, но можете поискать треды на тему тултипов, например, я там кидал скриншоты из фигмы. Это месяцы работы, буквально. Чтобы полностью охватить и проработать механизм отображения характеристик предметов, нужно очень плотно постараться и внимательно проработать все детали.
Остается логика и совместимость со старой системой интерфейсов.
Разберем на примере трех проектов: Тултипы, Экран смерти и ПДА.
1) Тултипы - это, казалось бы, минорное изменение внешнего вида тултипов (когда наводишь мышку на предмет и какие-то штуки показываются о предмете). Но принцип отдела дизайна - не заниматься простым редизайном, а, когда это возможно, улучшать пользовательский опыт взаимодействия с интерфейсом.
Перенести дизайн тултипа в игру любым из методов стоит 3 дня разработки программиста.
Но дьявол кроется в деталях.
Мало перенести дизайн, надо создать такую структуру и логику данных в коде, чтобы система могла дорабатываться с точки зрения введения новых параметров предметов и т.д.
А теперь вспомните сколько характеристик у нашей брони, оружия. Как много у нас типов предметов (разные типы брони, оружия, расходников, ресурсов и т.д.) и у всего этого есть свои подтипы характеристик. Добавляем сверху статусы предметов (персональный, бартерный и т.д.). Над всем этим надо подумать. Причем подумать специально обученному человеку, который понимает, как работает сталкрафт изнутри. Затем нужно реализовать эту логику таким образом, чтобы ничего не сломать и не переусложнить, упростив дальнейшую разработку.
А на это всё нужно время. Не так много, как кажется. Мои эстимейты - три-четыре недели любого нашего программиста (за такие слова на публику меня в офисе порешают) и можно отдавать на тесты. Но эти недели еще нужно найти, а ресурс разработчиков ограничен, поэтому это всегда вопрос приоритетов и компромиссов.
2) Экран смерти
Тут почти так же, как и с тултипами, но несколько иначе. Сам дизайн верстается так же мега-быстро, но мы ведь не хотим просто редизайнить гуишку, добавив красивые уголки. Мы хотим изменить пользовательский опыт, предоставив ему максимум информации об убийце и содействующих, а это реализация целого комплекса логики по сбору/хранению данных и их визуализации в этом интерфейсе, что так же требует времени на подумать у кодера, на что мы, как дизайнеры, никак повлиять не можем.
3) ПДА
А вот тут всё совершенно иначе.
Мало того, что пда необходимо задизайнить и это уже тратится время дизайнеров, но не об этом.
ПДА - это на самом деле огромный кусок кода, связанный между собой, к тому же трудно поддерживаемый.
И вот если экран смерти это интерфейс “в вакууме”, т.е. его изменение не сильно затронет остальные участки кода. то на пда завязана половина интерфейсов в игре. И тут нужно потратить просто гигатонну времени разработчиков, чтобы осмыслить реализацию и реализовать, даже без учета времени на дизайн.
И вот у разработчиков всегда стоит выбор приоритетов. Компромисс. Готовы ли мы отдать программиста Х минимум на полгода, чтобы он реализовал такой большой интерфейс или же есть более важные задачи?
Мы не ААА компания, чтобы позволить себе огромные штаты сотрудников под каждый целевой отдел. Но проблема даже не столько в финансах, хотя в них тоже. Проблема еще и в масштабируемости.
Мало нанять программиста. Его нужно долго обучать (все это время он будет работать, что называется, в минус).
А обучают у нас топ-тир программисты, которые тратят на это свое время и не занимаются чем-то альтернативно полезным. А затем этого программиста надо контролировать, ревьювить код. А ведь остальные программисты тоже никуда не делись. Это уже вопросы масштабируемости менеджмента, потому что так растут все отделы. И вот тут, по-моему мнению, ключевая проблема. Мало кто хочет быть менеджером, это неблагодарная работа, хотя и крайне важная. Но менеджера отдела программистов нельзя взять из воздуха, даже со стороны нельзя нанять, потому что ключевые навыки менеджера, а именно знание сильных и слабых сторон конкретных членов команды, знание кодовой базы сталкрафта и умение распределять все это дело воспитываются годами варки внутри команды.
В конце концов нужно просто смириться, что нельзя сделать всё и сразу и стараться искать разумные компромиссы. Если кодеры не тратят время на гуишку, то значит, они тратят свое время на что-то более важное. (например, на победу над читерами)
