Иногда эксплойт привносит в игру нечто хорошее, а если для его использования нужны значительная сноровка и навыки, то эксплойты вовсе не вредят дизайну. Например, глитчи, которые позволяют игроку срезать путь через уровень, горячо любимы спидранерами. А неожиданное преимущество в киберспортивной игре, которое на первый взгляд кажется эксплойтом, может быть воспринято сообществом игроков как законная фича игры[178]
. Возможно, вы создаете экспериментальную игру или игру, в которой сообщается о лазейках, и эксплойты в вашей игре преднамеренны. Однако для большинства типов игр, особенно тех, которые связаны с соревнованием против системы игры или против других игроков, от эксплойтов надо избавляться. Принятие решений по подобным вопросам – часть творческой работы гейм-дизайнера.Тупик – это ситуация, когда игрок не может пройти дальше по игре из-за того, что он сделал что-то не так[179]
. Вообразим игру, где есть ключ, который игрок может поднять и бросить где угодно, запертая дверь, которую открывает этот ключ, и колодец, который слишком глубок или слишком узок, чтобы в него спуститься. Игроку нужно отпереть дверь, чтобы перейти к следующей части игры, а ключ можно найти где-то поблизости. Но что, если игрок поднимет ключ и бросит его в колодец? Тогда он застрял. Он не может открыть дверь, он не может добраться до ключа, и он не может продолжить игру. Игроку нужно каким-то образом сбросить игровой мир, чтобы ключ вернулся в исходное положение.Возможно, тут поможет смерть и перезапуск игры, но что, если объекты сохраняют свое положение после прохождения определенных контрольных точек? Возможно, перезагрузка игры с предыдущего сохранения вернет ключ в исходное положение (техника, известная как сэйв-скамминг[180]
), но что делать, если в игре только один слот для сохранения и игра автоматически сохранилась сразу после того, как ключ упал в колодец? Тогда игрок действительно застрял, хотя он может даже не осознавать этого. Он может продолжать искать другой ключ, пока окончательно не заскучает или не разочаруется. Если он поймет, что произошло, и захочет продолжить играть, тогда ему придется проходить всю игру сначала. Скорее всего, игрок просто пойдет играть во что-то другое.Эта ситуация может показаться странной, но во многих публикуемых играх невезучих игроков подстерегают такие сложности. Тупики представляют особую проблему для игр, где много системного, возникающего и процедурно генерируемого геймплея, хотя обычно существуют способы их устранения.
Тупики также могут быть приняты как неотъемлемая часть игрового процесса, особенно если игроку ясно, что он оказался в тупике. Огромные новые горизонты творческих возможностей открылись в этой области с появлением таких игр, как
Не волнуйтесь, если вы не сможете обнаружить все эксплойты и тупики на этапе беты: иногда они прячутся прямо на виду, а иногда их очень нелегко найти. На поиск непростых, скрытых проблем у нас еще есть этап постпродакшена.
Стадия беты, концентрическая разработка и состояние игры
Готовясь к майлстоуну альфа-версии, мы прибегали к помощи стабов, теперь мы можем вновь обратиться к концентрическому методу, который я описал в главе 13, – но переключиться на концентрическую разработку может оказаться непросто. К сожалению, одна из традиций разработки игр заключается в том, что к майлстоуну бета-версии мы часто вводим контент в игру так быстро, как только можем, не заботясь о деталях так, как того рекомендует концентрический метод. Структурированность и дисциплина концентрического метода дают свободу творчеству, когда это действительно необходимо. В конце нам не придется сломя голову чинить все, что не работает, – у нас будет больше времени и сил, чтобы довести все до отличного качества. Если мы будем добавлять контент слишком быстро, то в итоге получим бета-версию с плохим ощущением игры, слишком сложную или слишком простую, глючную или сломанную игру. Поэтому я стараюсь работать в соответствии со старой пословицей: «Тише едешь – дальше будешь».
На стадии беты мы должны снова проверить состояние нашей игры точно так же, как делали это на стадии альфы. Сейчас крайне важно внимательно следить за техническими характеристиками игры. Если у нас низкая частота кадров, долгие загрузки, а освещение дает сбои, нужно устранить эти проблемы. Если у нас есть какие-либо серьезные проблемы с дизайном или особенно неприятные баги, за них тоже нужно немедленно браться. Вы не обязаны решить все эти проблемы к моменту достижения майлстоуна бета-версии, но у вас должен быть, по крайней мере, план их решения, чтобы вы могли приступить к нему сразу после майлстоуна. Игра с серьезными багами или низкой частотой кадров вряд ли добьется успеха.
Титры и атрибуции