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

Семинары Pixonic - команда и роли в проекте

Роли, в целом, зависят от динамики расширения проекта и команды. У вас может быть небольшая команда, где гейм-дизайнер выполняет задачи продюссера, PM'а и аналитика — все в одном. Или у вас может быть команда побольше, в которой эти функции распределены между разными людьми. Главное правильно понимать, какие функции нужны на каждом этапе развития проекта, и как они совмещаются/распределяются при масштабировании команды.

Ниже приведено обобщение схожих для нескольких проектных команд Pixonic черт. Посмотрите, а как бы вы сформулировали зоны ответственности внутри своих команд?

Часть [1/2] — Команда и роли в проекте

Роли в проекте

  • Продюсер — отвечает за сроки, бюджет, KPI, команду (найм\увольнение), концепт игры\баланс , организацию работы проекта.
  • Гейм-дизайнер отвечает за гейм-дизайн, UI, баланс, сюжет, фичи игры, концепт и тд.
  • PM — отвечает за сроки, бюджет и команду (найм\увольнение).

Нужно определить свои сильные и слабые стороны. Слабые стороны закрываются наймом профессионалов.

Если PM хочет стать продюсером, ему нужно учиться игровому дизайну, если гейм-диз хочет стать продюсером, ему нужно учиться управлению.

Состав проектной команды и ответственность

  1. Арт — Арт лид\арт директор + исполнители (+UI); 
  2. Код — тех лид\тех дир + исполнители; 
  3. QA — QA Lead+ исполнители (входит качество перевода); 
  4. Support\community\переводы; 
  5. Все остальное — маркетинг\аналитика предоставляется компанией; 
  6. Продюсер в ответе за все*! 

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

Как происходит рост проекта

  1. Развивающийся проект с переизбытком должен быть обеспечен задачами от гейм-дизайнеров (менеджеров); 
  2. Если команда разработчиков (+QA) не успевает* выполнять эти задачи, то команду надо увеличить; 
  3. Если не успевает команда по арту — надо увеличивать ее; 
  4. Если не хватает задач, то необходимо увеличивать количество** гейм-дизайнеров (менеджеров); 
  5. Далее пункт 1. 

*Речь про сроки. Если команда в принципе не способна выдать необходимое качество (за счет приемлемого увеличения сроков), то ее не расширяют, а “реструктуризируют”. **Профессионализм дизайнеров заключается в постановке целесообразных и продуманных задач (с грамотным ТЗ). 

Продюсер следит за тем, чтобы все вышеперечисленное функционировало и члены команды правильно взаимодействовали (в т.ч. продюсер контролирует контролеров).

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

Часть [2/2] — Постпродакшн: доработка, новые фичи и контент

При работе над игрой в стадии постпродакшн в вашем арсенале есть, грубо говоря, три инструмента:

  • Доработка;
  • Введение новых фичей;
  • Добавление контента.

Доработка (Улучшение/Исправление/Изменение)

JuozH65CLlBp_La0zsHYlw

Исправление, переделка чего-то уже имеющегося в игре. Например, изменение/добавление туториала, упрощение UI, перекройка баланса, фикс багов.

Перед запуском любой игры командой аналитики совместно с продюсером выставляются параметры, которым она должна соответствовать: Retention, ARPU, NPU, LTV и т.д.

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

Введение новых фичей (Интенсивное развитие)

DZavFTnZ_OVjHkjCfEY2OA

Внедрение в игру новых механик, функционала. Например, кланы, клановые войны, система событий, рейтинг, механика крафта/рыбалки/прокачки/чего_угодно_нового.

При разработке и вводе каждой фичи совместно с аналитиками определяется, насколько и какой параметр должен быть увеличен. Иногда в качестве KPI ставятся такие показатели как reviews, или кол-во взаимодействия с механикой на игрока в день и т.п.

Если фича не достигает целевого показателя — она дорабатывается, новые фичи в игру не вводятся. Если фича после 2-3 переделок все равно не работает, то либо фича не нужна в игре, либо на проекте плохой гейм-дизайн.

Добавление контента (Экстенсивное развитие)

Four puppets, holding in hands a puzzle

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

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

Мораль

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

-d5jciRH2NxW3hKvRB8r5A

Предыдущие публикации по теме:

Теги:

Комментарии

Оставлять комментарии могут только зарегистрированные пользователи.
×