В командах разработки игр, а особенно в инди-командах, зачастую царит хаос взаимодействия. Это может происходить по разным причинам, но чаще всего из-за неполного понимания границ ответственности. И если в крупных компаниях и студиях это ещё как-то стараются исправлять, то в инди-командах горизонтальная иерархия управления совсем размывает границы ответственности и непонятно, кто вообще должен разруливать ситуацию. Ведь ВСЕ управляют ВСЕМ. Подобные проблемы часто приводят к увеличению сроков разработки, конфликтам, выгоранию и, в целом, к гибели проекта.

В этой статье, я хотел бы обратить внимание на одну из самых распространенных проблем во взаимодействии между программистами и художниками. И, учитывая 10 летний опыт в геймдеве, как в инди командах, так и проектах на сотни человек, обозначить, как можно избавиться от проблемы, или хотя бы свести к минимуму ее влияние. Также в конце статьи вы можете найти список вопросов, ответы на которые помогут улучшить коммуникацию между отделами с самого старта проекта.

Дисклеймер

Я понимаю, что инди - это истории про нескольких специалистов в одном лице, и в случае, если в одном лице собрались и художник и программист, то проблемы взаимодействия не может существовать в принципе. По крайней мере, если у человека нет раздвоения личности.

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

Понимание проблемы - первый шаг к ее решению

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

Кейс плохого разделения ответственности 1

п: Мне не нравится, как выглядит персонаж, добавь ему повязку на руку.
х: Зачем?
п: Ну так же плохо смотрится!
х: Ннееет, все отлично!
п: *Ничего не отлично! Ужасно смотрится. Ко мне не прислушиваются, проект становится мне не интересен. Моя эффективность падает, и если это повторится еще пару раз, я вообще забью на проект*

Кейс плохого разделения ответственности 2

х: Давай воткнем анимацию на каждом виджете!
п: Не, так не пойдет. Устройства не вывезут, нагрузка слишком большая, виджетов слишком много.
х: Ну можно же что-то придумать. Подшаманить там, чтобы все получилось. Просто это очень круто будет - анимация на каждом виджете!
п: Нет! Устройства не вывезут, понимаешь? Нужно либо отказываться от анимаций, либо от слабых устройств, которых большинство у нашей ЦА.
х: *Ну вот. И сколько моих решений не пройдет в игру, я же художник, я хочу сделать как можно красивее, а никто даже не пытается идти на встречу! Наверное, работа с этими людьми была не лучшим решением, меня и мое мнение здесь не уважают*
п: *Попытки залезть в мою работу отнимают у меня силы. Если человек не разбирается в теме, зачем настаивать? Я бы рад сделать все красиво, но ничего не могу поделать с ограничениями. Мне не нравится работать с такими людьми”.

Из примеров выше, мы видим, как один специалист пытается поставить свои условия для работы другого, что, при непонимании специфики, приводит к конфликтам. Чтобы уменьшить напряжение, нужно во-первых, проявить уважение и дать  себе осознать, что оппонент - специалист, эксперт, и лучше разбирается в своем вопросе. Да, вы можете дать аргументированный фидбек, но не настаивать на том, что вы, якобы, лучше понимаете, что делать второму специалисту, а он вообще-то неуч неопытный. Проявление уважения и доверие - залог успеха, однако, не всегда удается достичь взаимопонимания на этой почве. Если чувствуете, что уважение не взаимно, то лучше расстаться с человеком, иначе такие отношения станут бомбой замедленного действия, и ваш проект рискует умереть от развала команды на не начальной стадии готовности, а гораздо позднее. От чего и в депрессию недолго впасть, и вообще игрострой забросить.

Зоны ответственности

Для того, чтобы решить проблему, важно, чтобы каждый понимал зону своей ответственности. А еще лучше, чтобы понимал и ключевые пункты из зоны ответственности специалистов других направлений в команде. Поэтому, обозначим их прямо сейчас.

Что делают программисты

Программисты, или вернее сказать разработчики, пишут код, работают с движком, интегрируют тот же арт, созданный художниками непосредственно в проект, в игру. Кроме логики игры, всеми силами пытаются создать визуализацию, максимально похожую на то, что задумали художники. Это порой непростой процесс в техническом плане, и часто присутствуют какие-то ограничения, которые иногда можно обойти, а иногда приходится мириться с ситуацией и менять концепт. Плюс, реализация некоторых визуальных решений настолько сложные, что могут занять месяцы на реализацию, что порой слишком дорого, и приходится также менять концепт.

Что делают художники

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

Техническая составляющая художникам от программистов

Для того, чтобы конфликтных ситуаций стало меньше, нужно также чтобы каждая сторона понимала некоторые принципы работы противоположной стороны.

Возьмем программистов. Они работают с движком, пишут код, знают все тонкости работы девайсов, какие ограничения есть, как под эти ограничения можно подстроить ту или иную фичу, сколько это займет времени. Знают какие исходники, в каком формате им нужны, чтобы правильно встроить в движок, в каком разрешении. И поверьте мне, художники, что если разработчик говорит, что что-то не подойдет технически, то это это точно не подойдет. Тут следует сказать “но есть одно НО”, потому что, если какое-то решение не подойдет — не значит, что нужно просто сдаться и принять что есть. Логическим и наиболее эффективным решением будет диалог в формате “давай подумаем, как мы можем получить похожий результат, чего нам это будет стоить, взвесим плюсы и минусы и примем совместное решение”. Таким образом, пример диалога между художником и программистом выше, может превратиться в:

х: Давай воткнем анимацию на каждом виджете!
п: Не, так не пойдет. Устройства не вывезут, нагрузка слишком большая.
х: Совсем ничего нельзя сделать? Как нагрузку уменьшить?
п: Можно анимировать только появление и исчезновение иконки аватара, или анимировать другие, более простые части виджета, чтобы громоздкая спайн-анимация не болталась внутри виджета - это тяжело для просчетов.
х: Что ж, появление и исчезновение тоже подходят, лучше чем просто статика, давай так и сделаем. Что подготовить? 
п: Мне нужны…

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

Художественная составляющая программистам от художников

То же работает и в обратную сторону. Разработчик-программист должен понимать, что художник знает все о графике на проекте: установленная стилистика, установленная палитра цветов, различные правила композиции кадра, правила анимации (если это еще и аниматор, конечно), как верно отрисовать пропорции, под каким углом, как дополнить или упростить картинку, как поставить свет и много еще чего, что связано с ответами на вопрос “как должна выглядеть картинка”. Художники щепетильно относятся к своей работе, поэтому хотят, чтобы картинка в игре в итоге вышла точно такой, как это было изображено на концепте или макете, это тоже важно понимать. Я знаю множество программистов, которые лепят из исходников “на глазок”, а художники потом ругаются и просят переделать, программисты не понимают этого и на этой почве также возникают разные конфликты. Просто примите это как данное, художник не просто так просит сделать точное расположение элементов, это важно для него, и это также стоит уважать. Возвращаясь к диалогам выше, переделать разговор художника и программиста в диалог здорового человека:

п: Мне не нравится, как выглядит персонаж, добавь ему повязку на руку.
х: Зачем?
п: Ну, на руке пусто как-то, тебе не кажется?
х: Ннееет, все отлично! Здесь же будет анимация, и если эту повязку приделать - непонятно как анимировать, и вообще каша получится на сгибе.
п: Хм.. Похоже что так. Давай, когда персонажа заанимируем, посмотрим, может действительно там все ок.

Взаимопонимание и уважение к границам ответственности приводит к отсутствию конфликта и напряженности на ровном месте. Работа идет слаженно и эффективно.

Общие правила эффективного взаимодействия:

После того, как мы поговорили о базовом принципе взаимодействия, предлагаю перейти к более производственному вопросу. Программист в любом случае будет взаимодействовать с художниками прямо, или опосредованно (через менеджера), но будет. И им не избежать спорных моментов. Чтобы уменьшить количество таких моментов, есть ряд вопросов, на которые необходимо ответить ВМЕСТЕ еще В НАЧАЛЕ проекта, и обязательно зафиксировать ответы. Да, они могут измениться по ходу работы, однако основной вектор останется неизменным, что сэкономит силы в будущем. Вот шпаргалка с вопросами:

1. Какой стиль арт материалов в проекте (3D, 2D, стилизованная графика, или реализм, может что-то более комбинированное и нетривиальное). От этого зависит выбор ассетов и настроек проекта в технической части. Можно прикреплять референсы.

2. Каким образом будет реализована анимация (скелетная, спайн, покадровая) - выбор накладывает разные ограничения в техническом плане. Можно и комбинировать, в таком случае ограничений может быть как меньше, так и больше.

3. Планируются ли какие-то частицы в пользовательском интерфейсе? Монетки? Фейерверки? Интересует все.

4. Какого рода анимации планируются в пользовательском интерфейсе. Это могут быть простые условные анимации вроде Bounce (увеличение-уменьшение), Fade (исчезновение-появление) и подобные, а могут быть включены и Spine анимации, например.

5. В каком референсном разрешении работаете на проекте. То есть разрешение, которое является эталонным и в нем все должно выглядеть идеально.

6. Какое разрешение максимально широкое и максимально высокое. Есть экраны с разным соотношением сторон и адаптивную верстку никто не отменял. Этот вопрос важен как программисту, так и художнику.

7. Как художнику изображать макеты интерфейса в трех разрешениях: референсном, максимально высоком и максимально широком. Это важно для разработчика, который будет верстать интерфейс.

8. В каком разрешении готовите спрайты/текстуры. Обычно, после определения референсного разрешения, определяется максимальное разрешение под выбранное соотношение сторон и от него отталкиваются. Но имейте ввиду, что если одна из сторон немного выходит за рамки Power Of Two разрешения (например картинка 2080х1280 по стороне 2080 выходит немного за рамки 2048), то лучше уменьшить картинку до 2048, сохранив пропорции.

9. Все на проекте должны понимать, как работают слайсинг спрайты. Особенно художники. Вот тут пример описания для Unity, но это работает и для других движков

10. Какими инструментами пользуетесь для создания макетов. Макеты могут быть как и просто собранные в png, но есть и более мощные инструменты вроде Figma.

11. По каким правилам будет раскладываться нарезка спрайтов, как группироваться. Группировки бывают по месту использования, по типу. Тут нужно смотреть на оптимизацию, программист должен знать, каким способом лучше сгруппировать спрайты, и он может подсказать, как это сделать художнику.

12. Определитесь с правилами наименования ассетов. От себя добавлю, что удобно именовать набором ключевиков маленькими буквами с нижним подчеркиванием. Например: button_close, button_highlighter_circle, это позволит легко найти ассет в проекте и понятно, где он примерно должен располагаться. Поверьте, сэкономит кучу времени.

На этом все, если есть какие-то дополнения - пишите, обязательно добавлю.