Нужно ли, чтобы игрок знал о каждом изменении состояния? Не обязательно. Некоторые изменения состояний лучше оставить скрытыми. Но есть и такие, о которых сообщать игроку очень важно. Обязательно следуйте правилу: если два объекта ведут себя одинаково, они должны выглядеть одинаково. Если они ведут себя по-разному, выглядеть они должны тоже по-разному.
Объекты в видеоиграх, особенно те, которые представляют собой персонажей с развитым искусственным интеллектом, имеют столько свойств и состояний, что геймдизайнер может легко в них запутаться. Будет полезным составить блок-схему состояний для каждого свойства, чтобы вы могли лучше понять, какие состояния связаны между собой и что является катализатором их изменений. С точки зрения программирования состояние каждого свойства может быть представлено в виде «механизма состояний», это поможет держать под контролем столь сложные системы и в дальнейшем облегчит процесс исправления ошибок. Рис. 12.12 – это простая диаграмма для свойства «движения» привидения в
Круг, обозначенный как «в клетке», – это изначальное состояние привидения (двойной круг часто используется для отображения стартовой позиции). Каждая стрелка показывает возможные изменения состояния вместе с событиями, которые провоцируют эти изменения. Диаграммы вроде этой очень полезны, когда нужно описать сложное поведение в игре. Они заставляют вас обдумать абсолютно все, что может произойти с объектом и что провоцирует эти события. Перенося эти изменения состояний в компьютерный код, вы автоматически запрещаете любые переходы между состояниями, которые противоречат ей (например, «В клетке» → «Синий»), что помогает избавиться от сбивающих с толку ошибок. Эти схемы могут быть довольно сложными и иногда иерархичными. Например, вполне возможно, что в алгоритме настоящего Пак-Мана есть несколько субсостояний «Преследовать Пак-Мана», такие как «Найти Пак-Мана», «На хвосте у Пак-Мана», «Двигаться через тоннель» и т. д.
Вы сами должны решать, какими будут свойства и состояния каждого объекта. Часто одни и те же вещи можно реализовать несколькими способами. Например, в покере руки игрока можно определить как зону для игрового пространства, в которой находятся пять объектов в виде карт. А можно назвать объектом сами руки игрока, а карты – пятью их свойствами. Как и в случае со всеми остальными аспектами геймдизайна, «правильным» способом мышления здесь будет тот, который больше всего подходит в данный момент конкретно вам.
Игры, заставляющие держать в голове слишком много состояний (слишком много игровых фигур, слишком много свойств у каждого персонажа), могут запутать игроков. В главе 13 мы рассмотрим различные техники оптимизации количества состояний, с которыми сталкивается игрок. Если вы представите свою игру как набор свойств с изменяющимися состояниями, вы откроете для себя много интересного, в этом вам поможет призма 28.
Призма 28: Призма механизма состояний
Чтобы воспользоваться этой призмой, подумайте, какая информация изменяется по ходу вашей игры. Спросите себя:
• Какие объекты есть в моей игре?
• Какие у этих объектов свойства?
• Какие состояния могут быть у этих свойств?
• Что вызывает изменение состояния для каждого из свойств?
Играя, мы постоянно принимаем решения. Эти решения основываются на информации. Решая, какими в вашей игре будут различные свойства и как будут изменяться их состояния, вы определяете суть ваших игровых механик.
