Геймдизайн

Повышение квалификации дизайнеров

Geoff Ellenor

Около недели назад в Париже мы с несколькими гейм- и левел-дизайнерами обсуждали подходы к работе. Мы прошлись по многим темам, пока однажды за ужином не пришли к любопытной истине: Умение быть дизайнером в основном зависит от количества проделанного дизайна.

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

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

Дело не в стаже

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

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

Пусть это будет удобное нам число. "Чтобы новичок стал хорошим левел-дизайнером, ему нужно выполнить сто циклов производства." А теперь посчитайте, сколько времени потребуется вашей студии для 100 циклов производства.

Я не буду показывать пальцем на некоторые "авральные плантации", но! все мы с готовностью нанимаем бывших сотрудников авральных плантаций, потому что знаем, что за два года на [плантации А] дизайнер прошёл сотни циклов производства.

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

Удобный инструментарий провоцирует рост

Я большой поклонник повышения эффективности работы левел-дизайнеров за счёт готовых систем и гибких структур данных. Я хочу ускорить производство, но не только ради экономии времени (и денег).

Инструменты могут ускорить или замедлить цикл производства. Значит, дизайн в вашей команде (и отдел дизайна) развивается со скоростью, зависящей от технической процедуры - от того, насколько инструментарий позволяет дизайнерам работать над самим качеством игрового процесса, а не заниматься "манипулированием разрозненных наборов данных ради сборки и тестирования версии".

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

В больших командах развиваются не все

С увеличением масштабов игр в поколении 360/PS3 коллективы разработчиков стали очень большими. Разрастающиеся коллективы часто становятся специализированными ради удобства управления производством - то есть, как только у проекта появляется цельное видение, время нанять много людей и приступить к Глобальному Плану.

Увы, специализация и недостаток дизайнерской автономности со временем снижают продуктивность каждого отдельного дизайнера. Дизайнеры, которым не достаётся делать много дизайна и работать с разнообразными системами, не растут над собой - они застревают.

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

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

Без скрипта́ не выловишь и рыбку из пруда

Отписка: я вовсе не хороший программист. У меня нет профильного образования - я просто нахватался VB Script и C+, потому что с помощью них можно делать клёвые вещи, и потому что однажды был вынужден ими воспользоваться.

И всё же я думаю, что каждому дизайнеру следует уметь программировать на начальном уровне, а также что инструменты для дизайнеров должны поддерживать такую возможность. Я обожаю дизайнеров, которые могут испробовать свои идеи, не привлекая опытного программиста. Мне кажется, это одно из преимуществ использования Unreal 4 и прототипирования в Юнити.

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

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

Оригинал в свободном доступе.Вы также можете прочитать и прокомментировать в Гугл-документе, а на Человеческих переводах - сравнить с оригиналом.