Как ладить со своей командой?

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

Как определить свое место в команде?

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

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

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

Ну и в-третьих, хороший геймдизайнер обладает глубоким пониманием своей целевой аудитории, “чувством игрока”, и принимая решения по проекту основывается не только на своих собственных впечатлениях, но в большей степени на том, как то или иное решение отразится на игроке. Здесь в ход идет и психология, и игровой опыт, и опыт анализа конкурентов и похожих проектов. Такой подход как правило не входит в область компетенции других членов команды, и поэтому они не всегда могут принять взвешенное с точки зрения ГД решение. Что уж тут говорить, даже меня не перестает удивлять моя целевая аудитория, которая показывает огромное количество переходов по одной совершенно невзрачной иконке, и гораздо меньшее по другой, более красивой и красочной и привлекательной в моем понимании.

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

1, Нужен бизнес план и четкие сроки.

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

• Найдите все возможные геймдев мероприятия и конкурсы, которые будут проходить в будущем, во время разработки проекта. Ознакомьтесь с требованиями организаций к разработчикам и их играм. Составьте список итераций работы над проектом: к каким датам нужны играбельные демо версии проекта, чтобы успеть принять участие в выставке, или конкурсе.
• Определите дату окончания работы над проектом, объясните, что планируете делать с проектом далее (выложить на сайте, опубликовать в мобильных сторах, выложить на Steam Greenlight, и так далее и так далее). Нужно также упомянуть, как вы собираетесь рекламировать и продвигать проект.
• Обрисуйте перспективы, которые ждут команду в случае успеха проекта. Поиск инвесторов? Работа над следующим проектом? Коммерческая работа?

2. Независимая разработка - это работа.

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

3. Планирование работы.

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

Данный пункт снова относится к мотивации команды и к обеспечению их достижимыми целями. Это как в играх: если на сточасовой геймплей у игрока будет всего одна единственная задача, то игрок очень быстро соскучится и играть перестанет. Здесь то же самое: если единственная задача - это выпустить игру, то ощущение от работы превращается в ночной кошмар, от которого никак невозможно проснуться, словно ты дрейфуешь в океане в полном штиле, а на горизонте нигде не видно суши и хочется опустить руки и утонуть, чтобы все это наконец закончилось. Для планирования и постановки задач очень удобно использовать сервис-трекер типа unfuddle, или бесплатный и легкий вариант — trello.

• Нужно разбить всю работу над проектом на большие этапы, которые в свою очередь нужно разбить на маленькие группы задач, и так далее. Глубина этой системы зависит от сложности вашего проекта. Например, самыми крупными этапами разработки проекта могут быть “собрать прототип”, “собрать альфа версию” и т.д., а самыми мелкими - “собрать работающую версию с такой-то игровой механикой к такому-то числу”, “добавить игровой магазин”, “собрать один игровой город, полностью наполненный контентом”. А уже внутрь этих мелких групп класть отдельные задачи по интерфейсам, сюжету, арту и программингу.
• Советуйтесь с членами команды насчет сроков выполнения каждой отдельной задачи, фиксируйте названное количество часов, прибавляя к нему запас в 20-30%. Требуйте выполнения задач в установленный срок, потому что если ваши товарищи будут постоянно фейлить сроки, то ни о каких достижимых этапах речи быть не может, и после очередных новостей о том, что вы ничего не успели сделать команда быстро повесит носы.
• Самое важное в этом планировании - это сделать так, чтобы каждую 1-2 недели у команды была хотя бы одна достижимая цель, которая будет общей маленькой победой. В таком случае, когда вы работаете и видите, как ваш проект меняется на глазах - это очень мотивирует работать дальше.

4. Подводите итоги, стройте планы.

Раз в 1-2 недели собирайте всю команду в общем голосовом чате (или в живую, если вы работаете на коммерческой основе в общем офисе), и рассказывайте что было сделано за этот период времени каждым членом команды, какую важность эта работа несет для проекта, отмечайте успехи, благодарите. Даже если кто-то работал над долгой и сложной задачей, которая до сих пор не завершена - узнайте, что уже было сделано и сколько осталось по задаче работы. Если вы будете устраивать такие планерки постоянно, то каждый отдел будет в курсе работы всех остальных и будет иметь представление о том, на каком этапе развития находится игра и будут лучше понимать, какую роль их собственные задачи играют в разработке проекта. Также на подобных собраниях рассказывайте о планах на следующий временной отрезок, и о том, как запланированные задачи повлияют на дальнейшую разработку проекта.