1го июня 2018 в Steam вышла Football, Tactics & Glory – пошаговая стратегия в футбольном мире, которую никто не ждал. Фанаты футбольных игр считали ее слишком странной. Фанаты пошаговых игр считали, что спортивные игры – не для них.

Несмотря на это, игра продалась довольно хорошо. Рейтинг на Steam –  90%. Многие игроки пишут, что FTG – лучшая игра, которую они играли. Автор обзоров стратегических игр на Rock Paper Shotgun, Tim Stone, написал отличный обзор и сказал, что для него это лучшая игра года:

My Game of the Year by a country mile, Football: Tactics & Glory is what happens when coding talent collides with subject matter passion and a gin-clear creative vision.

 Tim Stone (Rock Paper Shotgun)

Да и в целом, на переполненном рынке футбольных игр, на котором балом правят FIFA и Football Manager, наша игра заняла свое почетное место. После релиза мы множество раз попадали в списки лучших футбольных игр. В частности, The Guardian поставил нас в подобный список.

В этой статье я расскажу о своем стиле мышления при дизайне игр на примере FTG. Здесь не будет секретных механик или новых знаний. Цель статьи – показать как мы, в Creoteam, дизайним наши игры.

Что важнее: интересная механика или видение?

Через два месяца прототипирования Football, Tactics & Glory, играть было довольно увлекательно. Да, были шероховатости, предстояло еще много работы, но уже тогда мы устраивали увлекательные соревнования, играя друг против друга. Цель прототипа была достигнута – мы нашли уникальную и очень увлекательную механику матча.

Но был нюанс – матчи длились 40-60 минут. Хотя согласно видению они должны длиться не более 15 минут.

Что же делать? Варианты:

1. Сказать себе: “Отходим от изначального видения: теперь мы считаем, что матчи должны длиться 40-60 минут.”
2. Решить, что цель прототипа не достигнута и искать правильные механики далее.

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

Второй вариант – неприятный. Он сулит продолжение борьбы с неизвестностью и неопределенностью.

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

В итоге мы пересмотрели баланс матча и вырезали сомнительную механику, которая значительно удлиняла матч и в целом выглядела проблемной для будущей разработки. Матчи стали длиться 7-12 минут. При этом, сохранилась тактическая глубина и разнообразие игровых ситуаций.

В результате мы добились общей аддиктивности и увлекательности всей игры в целом. Как и должно было быть согласно видению.

ВЫВОДЫ

1) У игры должно быть видение. Команда должна знать, какую игру она делает.

2) При разработке каждой новой механики нужно проверять, соответствует ли она видению.

Можно ли сделать прототип интересным без графики и мета-игры?

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

Что можно подумать о ситуации? Вот, например, мои мысли:

1. В игре не хватает графики и анимаций. Вот когда мы их добавим, появится и динамика. А так, все нормально, можно заканчивать работу над прототипом.
2. В игре не хватает мета-игры, которая бы связала прокачку футболистов и их игру на поле. Вот когда мы ее добавим, матчи будут увлекательными. А пока, все нормально. Можно заканчивать работу над прототипом.
3. Механика недоработана. Нужно продолжать работу над прототипом: искать, что с механиками не так.

О третьем варианте не хочется думать, его не хочется принимать. Но именно его и нужно принять.

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

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

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

ВЫВОДЫ

1) Если цель прототипа – найти увлекательные механики, то такой прототип должен цеплять.

2) Нельзя продолжать разработку, если увлекательность прототипа под сомнением.

Можно ли задизайнить сложные увлекательные механики с первого раза?

У нас была увлекательная игра в Раннем доступе Steam, опытная команда, живое коммюнити, хороший гейм-дизайнер. По ходу разработки мы решили добавить новый слой механик.

Как можно подойти к их разработке? Два варианта:

1) Подход уверенного в себе гейм-дизайнера:

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

2) Подход “ленивого” гейм-дизайнера:

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

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

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

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

ВЫВОДЫ

1) Хорошая идея не приходит первой.

2) Второй вариант механики всегда будет более интересный и более продуманный, чем первый.

Насколько простым должно быть начало игры?

Мы – опытные разработчики, поэтому знаем, что игрокам нужно в начале кампании давать что-то попроще.

Итак, сила команд в нашей игре варьируется от 1 до 10. Какую силу выдать игроку, чтобы у него было пространство для развития, и при этом он не был самым слабым?

Логично, что для начала игры достаточно игроку выдать силу 2, а первым противникам –  силу 1. Протестировали. Играется очень просто. Если мы, разработчики, выигрываем каждый матч со счетом 5:0, то игроки смогут в любом случае выигрывать хоть с минимальным счетом.

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

“Но ведь куда больше? Сейчас противники значительно слабее игрока, а если сделать их еще более слабыми, это будет смехотворно!”, – так мы думали. Но, все же, для более простого входа игроков в игру ввели понятие команды “нулевого уровня”.

Только установив первому противнику силу 0, мы увидели, что игроки легче входят в игру и получают больше удовольствия.

В каждой своей игре я по несколько раз наступал на эти грабли. Каждый раз я думал, что поступаю достаточно разумно, делая начало кампании простым. Но всегда оказывалось, что нужно было сделать начало еще проще, а потом – еще проще, а потом – настолько проще, что мне самому это казалось дебильным.

ВЫВОДЫ

Недостаточно сделать начало игры простым.

Нужно его сделать дебильно простым.

Что делать, если не получается решить геймплейную проблему?

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

Просто смасштабировать стадион, чтобы он влез в экран – невозможно, так как футболисты на нем будут очень маленькие. Ими будет невозможно управлять. Вот, как бы это выглядело:

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

Первая пришедшая к нам идея – это показать 2D поле, на котором игрок фишками играет в футбол, а когда происходят интересные ситуации, мы бы показывали специально подготовленные анимации происходящего.

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

Мы были в тупике. Казалось, что решения для нашей проблемы не существует. Футбольное поле уместить на экране нельзя, а показывать отдельно механику, отдельно анимации – было плохо.

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

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

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

Не могу сосчитать, сколько раз мне казалось, что нужно сдаваться: решения не существует. Но если я не сдавался, решение почти всегда находилось.

ВЫВОДЫ

Когда встречаешь геймплейную проблему, она всегда кажется нерешаемой.

Но у любой задачи есть решение.

Эта механика – стандарт жанра. Мы обязаны ее добавить. Верно?

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

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

Первая мысль, которая приходит в голову: “Зачем ломать то, что и так работает?” Но действительно ли механика экономики реального мира подходит нашей игре?

В итоге я пришел к другому типу экономики, в котором деньги никуда не уходят, пока игрок не нажмет кнопку “Купить”.

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

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

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

В Portal – наше оружие не стреляет, а ставит порталы. Игра World of Tanks показала, что шутеры могут быть медленными. Splatoon показал, что шутеры могут быть не жестокими. В SUPERHOT вы перемещаетесь одновременно с ходом времени. В каждом из этих случаев был изменен аспект жанра, который казался незыблемым.

Поэтому, каждый раз, когда я ввожу в игру механику, которая считается стандартной в играх жанра, я задаю себе вопросы: “Должен ли я оставить механику в ее привычном виде? Могу ли я заменить ее чем-то более интересным или более подходящим нашей игре?”

ВЫВОДЫ

Ставьте под сомнение устоявшиеся механики.

Эта фича нам ничего не стоит. Давай добавим ее в игру?

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

И вот, игроки попросили добавить магазин атрибутики.

С точки зрения кода добавить эту возможность несложно. Игрок платит определенную сумму денег и получает бонус от улучшенного здания. Графику рисовать не нужно.

Но при добавлении каждой новой механики меня волнует такой вопрос: какие интересные стратегические решения будет принимать игрок с магазином атрибутики? Что это привнесет в игру?

Ведь по большому счету, механика улучшения клубного магазина сводится к тому, чтобы потратить какую-то сумму денег, а потом клуб автоматически будет получать небольшие суммы. В этом нет стратегии или какого-то сложного выбора. Игрок будет думать так: если в игре есть магазин атрибутики – его строить нужно. Желательно пораньше, чтобы он пораньше окупился.

Подобные механики приносят удовольствие благодаря ощущению прогресса. Но мы в первую очередь делаем стратегию, поэтому хотим, чтобы игра была реиграбельной после 100 и 1000 часов игры.

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

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

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

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

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

Я вполне понимаю, что чем больше в игре разных, даже слабо полезных возможностей, тем более дорогой может ощущаться игра. Например, развитие своей виллы в Assassin’s Creed 2 не особо нужно, но наличие такой механики создает ощущение большей глубины контента.

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

ВЫВОДЫ

1) У каждой игровой возможности есть не только стоимость внедрения, но и стоимость поддержки.

2) Не добавляйте в игру механики, которые не несут геймплейной ценности, лишь потому, что так принято в других играх или потому, что это “ничего не стоит”.

Кто в команде главный по придумыванию идей?

Начиная с 2005го года я всегда являюсь главным и единственным дизайнером игр, над которыми работаю. Это позволяет мне рассказывать о своей работе с гордостью.

Но есть проблема. Постоянно кто-то из команды пытается позариться на мое величие.

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

А Саша увидел что-то в другой игре, и хочет такое же в нашей. Говорит, что вот недавно поиграл в Heroes of Might and Magic 3, и ему понравилось, что там есть автоатака, если противник перемещается рядом. Хотелось бы такое и в нашей футбольной игре.

Что ответил бы им Великий Игровой Дизайнер?

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

Как мыслят обычные дизайнеры?

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

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

А в примерах выше, я принял идеи команды.

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

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

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

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

Нередко можно увидеть, что когда известный игровой дизайнер сменил команду, его новая игра сильно уступает по качеству предыдущей. Потому что команда явно или неявно влияет на игровой дизайн.

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

ВЫВОДЫ

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

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

А что, если команда настаивает на внедрении плохих идей?

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

Это действительно интересная идея, но в рамках текущих механик, развития ИИ, соответствия метафорам реального мира и т.д. она по моему мнению не имеет права на попадание в игру.

Но команда настаивала. Споры стали жаркими.

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

Но кто решает, какие идеи хорошие? Кто в итоге отвечает за удовольствие от игровых механик? Кого будут обвинять, если игра окажется скучной? Игрового дизайнера. Значит он и должен быть тем человеком, который принимает последнее решение о том, какие механики будут в игре, а каких – не будет.

Споры на эту тему “неэффективных” игровых навыков были ожесточенными. Хуже всего то, что мне так и не удалось убедить коллег в том, что так дизайнить игру нельзя.

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

В итоге, эти “неэффективные” навыки мы так и не добавили.

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

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

ВЫВОДЫ

1) За итоговый дизайн должен отвечать один человек.

2) Об этом нужно договориться перед стартом разработки игры.

Послесловие

Здесь я собрал все выводы в один список:

• У игры должно быть видение. Команда должна знать, какую игру она делает.

• При разработке каждой новой механики нужно проверять, соответствует ли она видению.

• Если цель прототипа – найти увлекательные механики, то такой прототип должен цеплять.

• Нельзя продолжать разработку, если увлекательность прототипа под сомнением.

• Хорошая идея не приходит первой.

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

• Недостаточно сделать начало игры простым. Нужно его сделать дебильно простым.

• Когда встречаешь геймплейную проблему, она всегда кажется нерешаемой. Но у любой задачи есть решение.

• Ставьте под сомнение устоявшиеся механики.

• У каждой игровой возможности есть не только стоимость внедрения, но и стоимость поддержки.

• Не добавляйте в игру механики, которые не несут геймплейной ценности, лишь потому, что так принято в других играх или потому, что это “ничего не стоит”.

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

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

• За итоговый дизайн должен отвечать один человек. Об этом нужно договориться перед стартом разработки игры.

Следовать этим правилам непросто. Ведь по большому счету, они говорят о том, что нужно принимать сложные решения, изобретать то, чего раньше не было, не сдаваться, преодолевать лень своего мозга.

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

 

Отличных вам игр и успехов в разработке!

Дополнительные ссылки

• Видео и презентация этого доклада с конференции Games Gathering 2018.
• Небольшое видео (7 минут) о том, чем мы вдохновлялись при создании пошаговой механики Football, Tactics & Glory.
• Подкаст “Как делают игры” про нашу игру.
• Статья о том, как мы прошли Greenlight, не попав даже в топ-100