Top
eventGameDevЗа кулисамиКонцепт артНовости

Кровь, пот и пострелизный геймдизайн

Поделиться

Статья основана на докладе Вадима Сиволапа с прошедшей Games Gathering 2019 Kiev

Меня зовут Вадим Сиволап. Я работаю в студии компании Plarium Kharkiv. В геймдеве уже более 9 лет, 6 из которых работаю геймдизайнером.

Многие думают, что основная работа геймдизайнера заключается в подготовке продукта к релизу. Хотя на самом деле, настоящие кровь, пот и слезы начинаются на этапе поддержки продукта. Я не раз наблюдал, как полные энтузиазма ребята, работающие над еще не выпущенной игрой, теряют фокус, как только проект выходит в hard launch. Они думают, что самое интересное позади и не знают как развивать проект и как принимать решения. Их продуктивность начинает падать.

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

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

Цель

Четко понимайте, зачем вы делаете эту фичу.

У каждой фичи, у каждого улучшения во free-to-play игре есть цель. За частую, она выражается в изменении того или иного KPI. Мы никогда не добавляем фичи ради фичи. Мы добавляем программы лояльности, чтобы поднимать ретеншн, делаем плановые задания, чтобы увеличить энгейджмент, добавляем стартер паки, чтобы поднять конверсию.

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

Озарение творца

Знайте об озарении творца и пользуйтесь им с умом.

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

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

Всегда разделяйте этап генерирования идей и их редактирования — это противоположные процессы.

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

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

Так вы оставляете только те идеи, которые помогут вам в достижении цели.

Хороший дизайн

Не забывайте где живет хороший дизайн. Не забывайте о трех столпах, на которых он стоит.

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

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

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

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

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

Системный дизайн

Любая игра — это целая система. Вписывайте фичу в систему.

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

Монетизация и live ops

Прорабатывайте монетизацию и продумывайте live ops активности на этапе дизайна.

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

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

Именно live ops на данный момент генерирует большую часть прибыли.

Под live ops я подразумеваю разные внутриигровые активности, такие как ивенты, турниры, события направленные на продвижение или промоушен нового функционала, разнообразные монетизационные ивенты.

Можем ли мы сделать турниры под новую функциональность? Какими они будут? На что они будут направлены? Какая у них будет продолжительность и периодичность? Специальные офферы будут доступны все время или будут запускаться по какой-то логике? Может быть нам нужны специальные предложения под турниры?

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

Подумайте о будущем

Думайте о будущем фичи и о будущем игры с ней.

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

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

Очевидное не очевидно

Убедитесь, что вас правильно поняли. Делайте все, чтобы ваши дизайн документы и макеты были юзерфрендли.

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

Если вам что-то понятно, это не значит, что понятно и другим. Это не значит, что все играли в те же игры, что и вы. Это не значит, что люди умеют читать ваши мысли. Не оставляете команде разработки возможность додумывать что-то за вас. Потому что все, что останется непонятым, так или иначе будет додумано и реализовано. Вот только как?

Чтобы избежать непонимания, используйте кликабельные прототипы. Можно просто взять скрины из игры и нарисовать там блоки, чтобы показать, что при клике на эту область, будет следующий скрин. Тем самым, вы покажете гендиректору/генпродюсеру как все будет выглядеть.

Чек-лист

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

  • В вашей игре есть квесты? Вам нужно с новой фичей добавить эти квесты?
  • У вас есть системы daily/weekly/monthly квестов? Вам нужно вписать новую фичу в эту систему?
  • В вашей игре есть ачивки? Вам нужно под новый функционал изготовить новые ачивки?
  • В игре есть айтомы/бустеры? Можно ли добавить какие-то ресурсы и сразу придумать как их монетизировать?
  • У вас есть турниры? Вам нужно их придумать?
  • Нужны ли отдельные промоушены по спичу?
  • Вы использовали все монетизационные инструменты, которые у вас есть в игре?
  • Нужно ли сделать отдельную новость или рассказ о том как работает функциональность в сообществах игры?
  • Нужна ли интеграция с какими-то внутренними инструментами компании? С админками и тд.
  • Вы поговорили с аналитиком? Продумали логирование фичи, чтобы впоследствии получить качественный аналитический отчет?
  • Вы презентовали фичу аналитику? Рассказали как она работает, чтобы он хорошо это понимал и сделал более развернутые, правильные и точные расчеты?

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

В чек-листе нашей команды первым пунктом стоит определение MVP (Minimal Viable Product) фичи. Проще говоря, что в этой фиче самое важное. Бывают случаи, когда команда разработки не успевает сделать все в релиз и предлагает выкинуть фичу, а продюсер говорит, что у них цели, бизнес, KPI и ее выкидывать нельзя.

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

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

С чек-листом есть один очень важный момент — нужно не забывать им пользоваться. Делая чек-лист, мы помогаем лучше работать в первую очередь себе: ничего не забывать и не размазывать релизы по нескольким спринтам.

Пройти путь 3D-Artist-а и найти себя в CG поможет курс MAYА WINTER ’20.
Старт 20 января. Welcome!

Статью подготовил Олег Мощенко.

Подписывайтесь на нас в Facebook, Telegram, Vkontakte, Pinterest.