Spiiin's blog

Немного про прототипирование, плейтесты, итерации в разработке игр

Начитался книг по геймдизайну ("Искусство геймдизайна" Джесси Шелла, "Геймдизайн. Рецепты лучших" Тайнана Сильвестра, "Теория развлечений" Рэфа Костера), а также историй разработки ("Кровь, пот и пиксели" Джейсона Шрейера). Все они помимо прочего рассказывают о том, насколько сложно и долго делать хорошие игры.

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

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

- Меняются технологии, следствие чего поднимается планка качества игр и требуются изменения в подходах к разработке
Как пример - истории "Uncharted 4" и "Witcher 3" из “Крови, пота и пикселей“ - следующие игры серии масштабнее, сложнее и амбициознее предыдущих. Вполне может быть так, что для следующей игры нужны специалисты, разбирающиеся в следующем поколении технологии, а не той, на которой была сделана предыдущая игра.

- Часто очень сложно сказать по неготовой игре, интересной она получится или скучной
Проверять какие-либо гипотезы в незаконченной части игры сложно, а создавать полноценный контент просто ради проверки - дорого и долго. Пример с “Ведьмаком 3“ - проверка сценария романтической беседы Геральта с Йеннифер в саду в сумерках, вместо моделей персонажей были два уже готовых рыбака, вместо сада - “серые коробки”, а текст читал вслух сценарист. Как узнать, будет ли это смотреться с правильными декорациями, моделями и начитанным профессиональными актёрами текстом?

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

Прототипирование

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

В геймдизайне временное принятие некачественной работы в конечном итоге приводит к более качественной работе. Это ПАРАДОКС КАЧЕСТВА. Игры отличаются тем, что наиболее важным фактором, определяющим их качество, является количество итерационных циклов, через которые они проходят. Одержимость качеством на каждом этапе замедляет итерацию, что в конечном итоге ведет к ухудшению игры.

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

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

Я не встречал больших компаний (YMMV), в которых грамотно поставлено прототипирование, чаще всего “прототип” это: дизайн-документ + “питч”-презентация + наброски художественного стиля и сюжета проекта. Затем следует большое количество работы и проверка только уже почти готового продукта, вместо тестов черновых версий. Ну и дальше - выбрасывание того, что не работает. Возможно, это связано с тем, что в больших компаниях чаще создают игры “проверенных временем” жанров, в которых компания уже имеет некоторую экспертизу.

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

Как сконструировать игровой прототип за 7 дней - некоторые способы и работающие идеи для быстрого создания прототипов от авторов World of Goo. Конспект их правил и методов:

Быстрота - Это состояние разума. Быстрое прототипирование это нечто большее, чем полезный инструмент в пред-производстве - оно может стать образом жизни.

Ускоряйте циклы разработки (Больше времени != Больше качества) - всего несколько дней на тесты, до недели. Не было никакой взаимосвязи между потраченным на разработку временем и тем, насколько успешной игра стала в конечном итоге.

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

Соберите крутую команду и консультанта - мышление не менее важно, чем талант. В таком стиле разработки некогда учить инструмент или язык. (Кстати, консультант у них всё тот же Джесси Шелл, автор “Искусство геймдизайна”, что лишний раз подтверджает практичность его идей).

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

Обычный мозговой штурм не работает - нельзя заставить себя “думать по расписанию”. Иногда идеи приходят, когда лежишь в гамаке.
Hammock Driven Development - про этот метод есть отдельный хороший доклад Рича Хикки.

Скапливайте концепт-арты и музыку, чтобы создать эмоциональный настрой

Идея “Tower of Goo” пришла ко мне, когда я (зачем-то) слушал вступление к “Tango Apasionado” Астора Пьяццоллы, придя домой, и в моей голове возникло видение – небольшой городок в лучах заката, и все жители покидают свои дома, забирая с собой столы, стулья, и все, что могут унести, чтобы построить гигантскую башню в центре города. Я не знаю почему, но они очень хотели лезть выше и выше – но они были не очень хорошими инженерами-строителями, поэтому вы должны были им помогать.

Симулируйте игру в своей голове – Пред-прототипируйте прототип. Не выходит в голове - бумага, песок, пластилин или детские конструкторы в помощь.
Have Paper, Will Prototype - примеры прототипирования с помощью бумаги.
DYK: Hideo Kojima has built Metal Gear Solid with LEGO - создание уровней Metal Gear из кубиков Lego.

Разработка: Никто не знает, как ты это сделал, и никому до этого нет дела. Самая больная для меня, как программиста, часть. Всем плевать на ваши прекрасные навыки программирования. Надо делать не “правильно”, а быстро.
2012 - Ускорение написания кода - мои заметки о том, как писать код быстро и грязно.

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

Если что-то может занять слишком много времени, подделайте это. Это вообще очень полезный рецепт для разработки игр. Нам не важна корректная и точная симуляция, важно чтобы было весело и интересно. Не надо делать корректную систему освещения и затенения там, где вшитое в текстуру освещение будет выглядеть также. Не надо делать сложные сплайны с векторной графиков там, где подойдёт растягивающийся спрайт (World of Goo).

Сокращайте потери и "Знайте, когда стоит застрелить своего ребенка". Основная цель прототипа - он может быть неудачным, это нормально. 4F - Fail Faster - Follow the Fun - принимайте возможность неудачи, это помогает пойти на творческий риск! Если не получится одно, то получится другое, более того, вы станете опытнее благодаря неудаче. Принимая возможность неудачи, мы открываем дорогу эксперементированию.
Ну, и вообще - “Plan to throw one version away; you will, anyhow” (из Мифического Человекомесяца Фредерика Брукса)

Обильное оформление не спасет плохой гейм-дизайн (или "Вам не удастся сделать конфетку из дерьма"). Если игра будет скучное - её не спасёт ничто. Но в целом оформление имеет значение! Используйте добротный набор изображений, звуков и музыки.

Сложность концепции не обязательна для интересности “Экспериментальный” не значит “Запутанный”. Если все человечество на протяжении тысяч лет успешно развлекает себя вариациями на тему “мяч и плоская поверхность”, то мы, возможно, слишком уж сильно корячимся над всеми этими новомодными штучками для видеоигр. У игрока всегда должна быть простая и понятная ему цель.

Создайте чувство собственности, чтобы игроки возвращались назад. Здесь авторы отмечают, что самые реиграбельные игры включают аспекты сохранения того, что создал игрок. Это не накопленные им запасы, а возможность выразить себя через кастомизацию игры (“построй СВОЮ башню”, “создай СВОЙ дом”).

Делайте игру сочной!

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

В дополнение, правила прототипирования из книги Искусство Геймдизайна Джессси Шелла. Глава 8. Итерации делают игру лучше.

• Каждый прототип отвечает на конкретный вопрос.
• Забудьте о качестве. Максимально черновой и быстрый.
• Никаких привязанностей. Прототип делается на выброс.
• Расположите прототипы в порядке их важности.
• Совмещать прототипы эффективно. Если можно распараллелить, можно делать несколько прототипов одновременно.
• Делайте нецифровые прототипы. Можно создать бумажную версию, воспользоваться метрономом для отмеры “шагов” в игре реального времени.
• Вносите изменения максимально быстро. Автор рекомендует выбрать язык и движок со скриптами и поздним связыванием (Python, Scheme, Smalltalk, Javascript).
• Сначала сделайте игрушку. Мяч - это игрушка, но футбол - игра. Мяч интересен сам по себе, и позволяет играть в разные игры. Маленькая фигурка, которая бегает и прыгает - это игрушка, а Donkey Kong - игра. Город в GTA или уровень в Lemmings без действий игрока - это игрушка.
• Прототип не обязан быть интерактивным. Стиль анимации можно проверить интерактивным роликом - Prince of Percia: Sands of Time.
• Если возможно, делайте несколько итераций прототипирования.

прим. обновлено 02.09.2021
Ещё одно дополнение по прототипам, из книги Ernest Adams - Fundamentals of Game Design.
Список того, что скорее всего нужно прототипировать отдельно (от более раннего к более позднему):

• Техническое демо
• Игровая экономика (возможно на бумаге)
• Интерфейс и система управления
• Туториалы (или FTUE)

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

Прототип должен отвечать на чётко поставленный вопрос, чтобы его было проще создать и оценить. В качестве примеров, список различных прототипов игры Spore с описанием целей их создания:
http://www.spore.com/comm/prototypes

Во второй части книги (Game mechanics. Advanced Game Design) описывается графический язык Machinimations. К схемам, созданным на этом языке, можно подключить ботов, реализующих различные стратегии использования нод (случайные, паттернами, регулярное использование одной стратегии), чтобы протестировать таким образом прототип игровой экономики или баланс.

Путь от прототипа к результату

Несколько примеров трансформаций игр в ходе исследований (из книги "Геймдизайн. Рецепты лучших" Тайнана Сильвестера).

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

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

The Sims - начиналась как архитектурная игра. Изначально Уилл Райт не планировал помещать в дом семью. Игра была о строительстве и не более. Только добавив простого персонажа, Райт обнаружил, насколько сильно это понравилось игрокам. Райт следовал возможностям, которые он видел, и игра все больше и больше сосредоточивались на людях, и так до тех пор, пока они не стали ее центром. Он не планировал такой результат; он обнаружил его в процессе создания игры.

Legend of Zelda - Breath of the Wild - двухмерный прототип в стиле первой “Зельды”, созданный для теста механики.

Diablo - изначально была пошаговой.

Braid - доклад Jonathan Blow: Indie Prototyping с различными версиями прототипов игры, от самого первого в поисках идеи, к нескольким игровым, а также “пост-игровые”, в поисках способа применения найденной механики в других жанрах.

Магия итераций и плейтестов

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

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

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

Первые несколько тестов спустили нас с небес на землю, — говорит Дракманн. — Мы с Брюсом теперь их обожаем, потому что это позволяет посмотреть на то, что мы делаем, под новым углом. Ты получаешь от тестеров жесткую обратную связь, это обрубает тебе крылья. Дизайнерам часто тяжело смотреть, как люди проходят уровни, хочется буквально рвать на себе волосы. Да нет же, обернись, ну вон же ручка, да что ты делаешь-то? А помочь ты им не можешь.

Плейтесты со случайными игроками показывают такие факты, о которых мы не знали заранее. Без этой информации мы можем исправить только те проблемы, о которых нам УЖЕ было известно. Особенность человеческого мозга, что он начинает думать, что известные проблемы - это ВСЕ проблемы, которые есть в игре. Это когнитивное искажение мышления WYSIATI - “что ты видишь, то и есть”, описанное в книге "Думай медленно... решай быстро" Канемана Даниэля.

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

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

Бывает обратная ситуация, когда во время игры в очередной прототип, находится не неизвестная проблема, а фича игры, которая не была запланирована - серендипное открытие. Доклад про “открытие” геймплея Tetris - Game Design by Accidents.

Смирение позволяет принять то, как мало мы знаем. Так можно постичь не только маленькие берега понимания; смирение открывает перед нами непостижимые океаны неведения. Оно помогает нам поймать волну серендипности, когда мир пытается нас чему-то научить. Оно противостоит нашему природному заблуждению «что вижу, то и существует», делает нас наблюдательнее, вдумчивее и, возможно, даже немного мудрее. Нет человека глупее, чем тот, который считает, что знает все.

Закон Конвея

Игра, как и любой другой вид искусства, становятся отражением своих создателей.
The Legend of Zelda родилась из воспоминаний Сигеру Миямото о том, как он в детстве занимался спелеологией.
Сатоши Тэджири, разработавший Pokemon, любил коллекционировать насекомых.
Doom — из кампании в D&D Джона Ромеро и Джона Кармак, в которой демоны захватили вымышленный мир.
Uncharted 4 — это история про человека, который слишком много работает.
Мрачные сюжеты и развязки квестов Witcher 3 отражают переживания восточно-европейских народов после Второй Мировой.
Техническая точность в управлении самолётом WarThunder, скрывающаяся за казуальным управлением - результат увлечения разработчиков из Gaijin настоящими самолётами.

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

Мелвин Конвей сформулировал следствие этого наблюдения так - "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации". Не только результат, но и сам процесс производства тоже подчинён этому закону. Компания будет делать новые игры так же, как делала их до этого. Следом за Witcher 3, который уже был слишком большим по объёму, последует ещё больший Cyberpunk 2077, который просто добьёт разработчиков; После затянувшегося Uncharted 4 последует The Last of Us 2, который так же невозможно выпустить в обозримый срок.

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

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