Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Тупик – это ситуация, когда игрок не может пройти дальше по игре из-за того, что он сделал что-то не так[179]. Вообразим игру, где есть ключ, который игрок может поднять и бросить где угодно, запертая дверь, которую открывает этот ключ, и колодец, который слишком глубок или слишком узок, чтобы в него спуститься. Игроку нужно отпереть дверь, чтобы перейти к следующей части игры, а ключ можно найти где-то поблизости. Но что, если игрок поднимет ключ и бросит его в колодец? Тогда он застрял. Он не может открыть дверь, он не может добраться до ключа, и он не может продолжить игру. Игроку нужно каким-то образом сбросить игровой мир, чтобы ключ вернулся в исходное положение.
Возможно, тут поможет смерть и перезапуск игры, но что, если объекты сохраняют свое положение после прохождения определенных контрольных точек? Возможно, перезагрузка игры с предыдущего сохранения вернет ключ в исходное положение (техника, известная как сэйв-скамминг[180]), но что делать, если в игре только один слот для сохранения и игра автоматически сохранилась сразу после того, как ключ упал в колодец? Тогда игрок действительно застрял, хотя он может даже не осознавать этого. Он может продолжать искать другой ключ, пока окончательно не заскучает или не разочаруется. Если он поймет, что произошло, и захочет продолжить играть, тогда ему придется проходить всю игру сначала. Скорее всего, игрок просто пойдет играть во что-то другое.
Эта ситуация может показаться странной, но во многих публикуемых играх невезучих игроков подстерегают такие сложности. Тупики представляют особую проблему для игр, где много системного, возникающего и процедурно генерируемого геймплея, хотя обычно существуют способы их устранения.
Тупики также могут быть приняты как неотъемлемая часть игрового процесса, особенно если игроку ясно, что он оказался в тупике. Огромные новые горизонты творческих возможностей открылись в этой области с появлением таких игр, как Spelunky, The Binding of Isaac и FTL: Faster Than Light, которые объединяют жанр roguelike с другими жанрами[181].
Не волнуйтесь, если вы не сможете обнаружить все эксплойты и тупики на этапе беты: иногда они прячутся прямо на виду, а иногда их очень нелегко найти. На поиск непростых, скрытых проблем у нас еще есть этап постпродакшена.
Стадия беты, концентрическая разработка и состояние игры
Готовясь к майлстоуну альфа-версии, мы прибегали к помощи стабов, теперь мы можем вновь обратиться к концентрическому методу, который я описал в главе 13, – но переключиться на концентрическую разработку может оказаться непросто. К сожалению, одна из традиций разработки игр заключается в том, что к майлстоуну бета-версии мы часто вводим контент в игру так быстро, как только можем, не заботясь о деталях так, как того рекомендует концентрический метод. Структурированность и дисциплина концентрического метода дают свободу творчеству, когда это действительно необходимо. В конце нам не придется сломя голову чинить все, что не работает, – у нас будет больше времени и сил, чтобы довести все до отличного качества. Если мы будем добавлять контент слишком быстро, то в итоге получим бета-версию с плохим ощущением игры, слишком сложную или слишком простую, глючную или сломанную игру. Поэтому я стараюсь работать в соответствии со старой пословицей: «Тише едешь – дальше будешь».
На стадии беты мы должны снова проверить состояние нашей игры точно так же, как делали это на стадии альфы. Сейчас крайне важно внимательно следить за техническими характеристиками игры. Если у нас низкая частота кадров, долгие загрузки, а освещение дает сбои, нужно устранить эти проблемы. Если у нас есть какие-либо серьезные проблемы с дизайном или особенно неприятные баги, за них тоже нужно немедленно браться. Вы не обязаны решить все эти проблемы к моменту достижения майлстоуна бета-версии, но у вас должен быть, по крайней мере, план их решения, чтобы вы могли приступить к нему сразу после майлстоуна. Игра с серьезными багами или низкой частотой кадров вряд ли добьется успеха.
Титры и атрибуции
Если вы последовали совету, который я дал вам в главе 5, вы постоянно вели список (а) атрибуций для любых найденных сторонних ассетов, которые использовали в своей игре, и (б) людей, которые работали над игрой, и что они сделали. Когда придет время создавать внутриигровые титры и атрибуции, вам будет значительно легче проделать эту работу. Если вы не вели такой список, вам, возможно, придется сильно напрячься, чтобы просмотреть весь контент игры, составляя списки тех, чью работу надо отметить. Некоторые приобретаемые пакеты ассетов не требуют атрибуции, поэтому внимательно проверьте информацию о лицензировании того, что вы приобрели.
При атрибуции сторонних ассетов остается открытым вопрос о том, должны ли вы перечислить используемые материалы или просто перечислить имена отдельных авторов, чьи работы вы использовали. Если в лицензии ассета указано, как оформляется атрибуция, внимательно соблюдайте указанные правила.
Вы должны включить в титры всех, кто внес свой вклад в создание игры, так что тщательно подумайте о том, кто работал над игрой, особенно на ранних стадиях разработки. Средства к существованию разработчиков игр во многом зависят от их резюме и портфолио – не создавайте коллегам лишних проблем, забывая добавить их в титры.
Испытание достижения майлстоуна беты
Гейм-дизайнерам обычно приходится принимать трудные решения, чтобы достичь майлстоуна бета-версии. Когда мы принимаем окончательные решения о масштабах нашей игры и ее контенте, увидеть лес за деревьями становится еще тяжелее. Тут может пригодиться некоторая сторонняя оценка, которая поможет нам определить приоритеты, – и такую оценку мы можем получить на обзоре майлстоуна, о котором мы совсем скоро поговорим.
Я должен быть честен с вами: несмотря на очень простое определение бета-версии – игра завершена! – границы беты, как и альфы, несколько размыты. Помимо тех уловок, которые разработчики игр могут использовать в альфа-версии (использование очень размытой разницы между фичами и контентом, как
