Play all audios:
На этой неделе компания Pixonic в своем блоге продолжила публикацию итогов (по сути, конспектов) обучающих семинаров, которые она проводит для собственных сотрудников. Теперь ознакомиться с
ними можно и на наших страницах.
Роли, в целом, зависят от динамики расширения проекта и команды. У вас может быть небольшая команда, где гейм-дизайнер выполняет задачи продюссера, PM'а и аналитика — все в одном. Или у вас
может быть команда побольше, в которой эти функции распределены между разными людьми. Главное правильно понимать, какие функции нужны на каждом этапе развития проекта, и как они
совмещаются/распределяются при масштабировании команды.
Ниже приведено обобщение схожих для нескольких проектных команд Pixonic черт. Посмотрите, а как бы вы сформулировали зоны ответственности внутри своих команд?
Нужно определить свои сильные и слабые стороны. Слабые стороны закрываются наймом профессионалов.
Если PM хочет стать продюсером, ему нужно учиться игровому дизайну, если гейм-диз хочет стать продюсером, ему нужно учиться управлению.
Продюсер следит за тем, чтобы все вышеперечисленное функционировало и члены команды правильно взаимодействовали (в т.ч. продюсер контролирует контролеров).
Если продюсер видит проблемы, то либо решает их, либо своевременно сообщает о (возможной) проблеме своему руководителю, добиваясь выработки совместного решения.
При работе над игрой в стадии постпродакшн в вашем арсенале есть, грубо говоря, три инструмента:
Доработка (Улучшение/Исправление/Изменение)
Исправление, переделка чего-то уже имеющегося в игре. Например, изменение/добавление туториала, упрощение UI, перекройка баланса, фикс багов.
Перед запуском любой игры командой аналитики совместно с продюсером выставляются параметры, которым она должна соответствовать: Retention, ARPU, NPU, LTV и т.д.
Если после запуска показатели плохие — дается время на доработку игры, чтобы достичь требуемых показателей. Новые фичи в игру не вводятся! Если не получается доработать основу — игра
закрывается. Ведь если основа проекта не работает, то наслоение на нее чего-то нового вряд ли спасет положение. (Как и не поможет надстройка дополнительного этажа зданию, у которого плохой и
разваливающийся фундамент)
Введение новых фичей (Интенсивное развитие)
Внедрение в игру новых механик, функционала. Например, кланы, клановые войны, система событий, рейтинг, механика крафта/рыбалки/прокачки/чего_угодно_нового.
При разработке и вводе каждой фичи совместно с аналитиками определяется, насколько и какой параметр должен быть увеличен. Иногда в качестве KPI ставятся такие показатели как reviews, или
кол-во взаимодействия с механикой на игрока в день и т.п.
Если фича не достигает целевого показателя — она дорабатывается, новые фичи в игру не вводятся. Если фича после 2-3 переделок все равно не работает, то либо фича не нужна в игре, либо на
проекте плохой гейм-дизайн.
Добавление контента (Экстенсивное развитие)
Добавление контента на основе уже имеющегося функционала. Например, добавление новых квест-паков, событий, оружия и т.п.
Если вы вводите в игру новый контент, то это делается на основе данных по уже имеющемуся контенту. Совместно с аналитиками нужно понять, какие варианты товаров (квест-паков, оружия, эвентов,
акций и т.п.) показали себя лучше всего, понять причины этого и создавать контент со схожими характеристиками. Таким образом, среднее качество игрового контента на проекте будет повышаться
(а не ухудшаться или стоять на месте).
Если при разработке проекта дизайнерские решения принимаются, исходя из опыта, то в постпродакшене разработка должна ориентироваться на объективные данные, которые получаются, в первую
очередь, благодаря аналитике. Т.е. при разработке вы делали игру, исходя из гипотез о том, как игрок будет воспринимать игру, в постпродакшене вы проверяете, насколько ваши гипотезы
оказались верны. И под влиянием новой информации вы производите корректировку уже имеющегося или запланированного дизайна игры. И этот процесс итеративный:
Предыдущие публикации по теме: