[Перевод] Мобильный гейм-дизайн: итерация vs. планирование и опасности MVP
Всем гейм-дизайнерам, которые не занимаются планированием, я хотел бы сказать:
«Остановитесь! Вы опасны. Вы изматываете разработчиков. Вы напрасно тратите драгоценное время и ресурсы, которые можно было бы легко сэкономить, уделяя достаточно внимания планированию. Проектирование на скорую руку оборачивается задержками в общей разработке. Спешка втиснуть новые полусырые фичи аукнется вам в виде незапланированных расходов. Работайте нормально!»
Как же делается качественное планирование?
Как правило, мобильный гейм-дизайн делится на две базовые школы принципов разработки:
1. Итерация — заложить базовые механики, а затем итерировать до тех пор, пока не получится что-то стоящее; набросок проекта до его последующей разработки.
2. Планирование — тщательно продумать каждую фичу, каждое окно, все зависимости и взаимодействия между основными фичами еще до начала разработки.
Обычно адепты школы итерации — это выходцы из мира ПК, где народ привык продавать максимально интересные для пользователя игры в базовой комплектации за фиксированную одноразовую плату. У таких игр часто высокий показатель удержания игроков и низкая монетизация.
На мой взгляд, стало слишком много людей, которые чересчур увлеклись методом итерации. Эти люди возвели MVP (англ. minimum viable product — минимально жизнеспособный продукт) в статус культа и сделали метод MVP универсальным костылем и дешевой отговоркой для того, чтобы не особо тщательно продумывать все фичи. Сторонники MVP-подхода часто приводят аргументы вроде:
• «Мы просто можем проитерировать это потом.»
• «О монетизации подумаем позже, а пока нужно сделать интересно.»
К сожалению, нетехнические разработчики не понимают, что игровой код не резиновый. Это вам не пластмассовые блоки LEGO собирать. Игра — не пластилин, ее нельзя сильно перекроить без существенных последствий. Всё потому, что код (особенно игровой код с изрядным количество хардкода) относительно негибкий.
На этот счёт у меня довольно радикальная точка зрения: я считаю, что многие гейм-дизайнеры, которые используют метод итерации в мобильных free-to-play играх, просто опасны тем, что могут загубить своей ленью целые команды разработки.
В новой мантре для разработки мобильных игр речь должна идти не о MVP с акцентом на «минимум» для разработки жизнеспособного товара, а о чём-то бóльшем.
Закон Кима:
Разрабатывай Минимально Жизнеспособный Продукт с Максимально Жизнеспособным Планированием
Индустрия мобильных игр не по зубам людям, которые не желают вкладывать время и усилия в планирование своих проектов.
Сплошь и рядом я вижу следующие типы развития событий:
• В разработку отдают полусырые, недостаточно продуманные идеи.
• Многие разработчики в погоне за трендовыми и наиболее прибыльными гейм-дизайнами запихивают в уже существующие игры фичи, которые смотрятся там крайне нелепо.
• Недостаточно хорошо продумывается взаимодействие фич и их влияние друг на друга в игре.
Всем гейм-дизайнерам, которые попадают в эту категорию, я хотел бы сказать:
«Остановитесь! Вы опасны. Вы изматываете разработчиков. Вы напрасно тратите драгоценное время и ресурсы, которые можно было бы легко сэкономить, уделяя достаточно внимания планированию. Проектирование на скорую руку оборачивается задержками в общей разработке. Спешка втиснуть новые полусырые фичи аукнется вам в виде незапланированных расходов. Работайте нормально!»
Как же делается качественное планирование?
На самом деле, всё сводится к таким основным задачам:
1. UI. Убедитесь, что интерфейс поддерживает вашу фичу. Заранее делайте макеты основных окон.
2. Пользовательский поток. Прежде чем отдавать новую фичу в разработку, убедитесь, что в ней учтены и продуманы все окна и их сочетания в пользовательском потоке. Что за поток? Читайте здесь: Mobile UI and Game Design: Screens vs. Flows.
3. Пограничные случаи. Продумайте все основные пограничные случаи. Что это такое? Пограничные случаи — это игровые ситуации, которые находятся за рамками нормального потока геймплея, но их тоже нужно прорабатывать. Проверьте, что в пограничных случаях нет подводных камней.
4. Влияние на систему. Подумайте, как новая фича повлияет на баланс и экономику вашей игры. Как она отразится на других системах в вашей игре. А в разных частях интерфейса? Убедитесь, что нигде не будет противоречий.
5. Влияние на проект. Как новая фича повлияет на геймплей, проектные параметры и монетизацию? Если вы сходу добавите новую PvE-фичу в PvP-игру, это может привести к КАТАСТРОФЕ. Как это отразится на ожидаемой и фактической монетизации? (Подробнее здесь: Monetization-based Game Design: ARPDAU Contribution) Подумайте над этим!
Но всё же, бывают случаи, когда лучше использовать итеративный подход вместо планирования. Например, в экспериментах с новыми типами геймплея, если именно это является основной задачей и главным риском. Кроме того, смысл не в СВЕРХпланировании. Рассматривать перечисленные выше вопросы проектирования стоит настолько, насколько это необходимо для каждой конкретной фичи, типа игры, ваших целей и т.д. Именно ваш отдельно взятый случай будет определять ваше Максимально Жизнеспособное Планирование. Стандартного решения всех проблем не существует.
В зависимости от ситуации, более тщательного планирования, как правило, требуют такие типы игр:
• Более сложные — комплексные, многосистемные, с большим количеством взаимосвязей; здесь необходимо понимать, как новая фича повлияет на всё остальное в игре.
• Больше UI — тоже более сложные, но в плане большого количества окон;
• Мультисистемные — чем хардкорнее ваша игра, тем больше в ней систем.
В завершение:
• Надеюсь, эта публикация поможет кому-то из вас увеличить шансы на успех вашего продукта за счет планирования.
• Нужно понимать, когда ситуативно использовать планирование, а когда — итерацию.
• Используйте вышеупомянутые приемы для уменьшения итераций на продакшене; основная часть планирования должна выполняться на первых этапах разработки игры, когда стоимость изменений еще сравнительно небольшая.
