программирование событий игровой истории

28

Я разработал игровой движок на c / c ++ и DirectX.

У меня есть движок плиток для карт, анимированные спрайты игрока / NPC, общение с NPC, меню и изменение уровня, но игры нет, просто кажется пустым.

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

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

Это немного амбициозно, но я стремлюсь получить такую ​​игру, как старые игры Pokemon / Final Fantasy.

Кто-нибудь знает, как эти игры работают или теория используется?

Я долго искал и был бы очень признателен за любые отзывы людей.

Skeith
источник

Ответы:

19

История вашей игры, вероятно, должна быть в форме конечного автомата (или какого-то расширенного FSA). Когда происходят определенные события, вы должны перейти в новое состояние. Таким образом, вам нужно только сохранить текущее состояние и любую необходимую информацию, чтобы знать, куда двигаться дальше в FSA (наряду с такими сведениями об игроке, как позиция, здоровье и т. Д.).

Например, если мы абсолютно упрощаем игры про покемонов, значки в спортзале образуют главную ветвь FSA. Вы начинаете в состоянии 0, где у вас нет бейджей, и, побеждая лидеров гимнастики, вы перемещаетесь по штатам, в состояние 1, в состояние 2 и т. Д. Чтобы ваши игровые сущности обновились до текущего состояния, вам нужно только получить их посмотреть на текущее состояние. Например, NPC за пределами 3-го спортзала проверит, в каком состоянии вы находитесь, увидите, что вы находитесь в состоянии, соответствующем наличию 3 значков, и соответственно отреагирует (возможно, «Молодец!»).

Вам не нужно хранить состояние всего в мире; просто состояние истории. Сами сущности знают, как реагировать в зависимости от текущего состояния.

Джозеф Мэнсфилд
источник
интересный подход, и мне нравится, что он должен будет попробовать его, но как вы будете отслеживать побочные квесты, которые не зависят от развития сюжета?
Это действительно зависит от сложности вашей истории. Может быть проще всего иметь несколько FSA (по одному для каждой подкатегории) или вам может потребоваться несколько сложных ветвлений. Вы должны сесть и нарисовать свою историю в качестве дорожной карты. Когда вы поймете, как все переплетается, подумайте о том, как вы можете сохранить текущее состояние (или указать, может ли оно быть более чем в одном сразу). Некоторые вещи нужно будет хранить отдельно, например, позиции NPC (если вы хотите, чтобы они были сохранены) и здоровье определенных персонажей, потому что они не зависят от истории.
это FSA, о котором вы говорите, где бы я мог найти объяснение этому, желательно упрощенное и без переплетения других теорий.
Скиф
Вы можете узнать все о конечных автоматах повсюду, но в 99,9% случаев речь не идет об играх. Вводная книга по вычислениям научит вас о них, но вам действительно не нужно так много подробностей. Вам просто нужно понять концепцию пребывания в состояниях и перемещения между ними, когда происходят определенные события. Ответ @ pwny на самом деле просто говорит то же самое по-другому. Чтение о FSA будет отличным способом изучения концепций конечных автоматов. Просто Google для введения в конечные автоматы!
Джозеф Мэнсфилд
7

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

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

С этими двумя простыми дополнениями к вашей игре, вы можете сделать ее более «живой».

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

Также попробуйте Gamedev

pwny
источник
это возможно, но я уверен, что у профессионалов лучше было то, что вам нужно, сотни тысяч логических значений и целых чисел (я пробовал). я просто не вижу реалистичного подхода к крупномасштабной игре. спасибо за ссылку
Не обязательно, представьте себе 5 независимых наложенных состояний. Вы получаете 32 возможных ветки для 5 логических значений. Я думаю, что это разумно. Кроме того, системы триггеров используются во многих профессиональных играх, особенно потому, что вы можете затем писать сценарии поведения, используя серию триггеров.
pwny
2

Как уже упоминалось, это идеальное приложение для конечного автомата.

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

Хороший, очень свободный аналог - книга « Выбери свое приключение» . Каждая страница содержит некоторый текст, описывающий часть истории, и решения, которые игрок может принять. Каждое решение ведет на другую страницу. Некоторые страницы могут ссылаться на ранее посещенные страницы и т. Д.

В старых текстовых приключенческих играх, таких как Zork и Leather Goddesses of Phobos , и в печально известных играх Sierra * Quest ( SpaceQuest с Рэйгером Вилко в роли космического уборщика - один из моих любимых ) использовалась очень простая версия этого типа системы. Каждая комната на карте была состоянием, с выходами, связанными с другими состояниями или комнатами. При получении элемента установите флаг в объекте глобального состояния. Каждая комната будет проверять эти флаги, чтобы определить, какие персонажи или предметы были доступны в каждой комнате.

Таким образом, ваши состояния могут быть реализованы в виде класса или структуры, каждое со свойствами для:

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

Условия входа - достижения, которые уже должны быть достигнуты, чтобы перейти на уровень

Выходы - ссылки на каждый возможный «следующий» выход. Север, Юг, Восток и Запад - некоторые примеры этого, но вы также можете включить Дверь1, Телепорт и т. Д. При попытке выйти из комнаты или при определении выхода / двери «открыто» ваша игра может проверить следующее состояние чтобы увидеть, были ли выполнены его условия входа, и изменить способ отображения выхода на экране, или просто не позволить игроку двигаться в этом направлении.

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

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

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

Надеюсь это поможет.

3Dave
источник
для этого примера вообразите город. У меня есть файл, который содержит макет плитки, а также графику и размер, списки NPC и тому подобное. добавив файл, можно добавить в игру новую городскую камеру, позволяющую другим вносить свой вклад, или так было в планах, но файл становится несколько полным и сложным. если я вас понимаю, я бы поместил в этот файл события, которые могут происходить в указанном городе, с флагами для отслеживания прогресса?
Скиф
@ Да, это звучит как разумный подход.
3Dave
0

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

Каждая карта имеет множество слоев. Графических слоев, которых может быть несколько. Слой обструкции. И затем есть слой зоны. Здесь важен слой зоны. *

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

Когда зона активируется, она вызывает функцию из скрипта. Так что вам нужно встроить какой-нибудь язык сценариев. VERGE имеет свой собственный язык, называемый VergeC, и также позволяет использовать lua. Я сам предпочитаю использовать Python.

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

* Существует также слой Entity. Сущности действуют как мобильные соседние активированные зоны.

Бенджамин Линдли
источник
это похоже на систему, которая используется в серии игр для RPG. но что, если у этой плитки есть 5 различных событий в зависимости от того, как далеко вы пройдете эту историю?
Скиф
@ Скейт Не может. С каждой плиткой связана только одна зона. И каждая зона имеет только одну функцию сценария, которую она вызывает. Это не проблема, хотя. Помните, у вас здесь есть полноценный язык программирования. Информация о том, как далеко вы пройдете историю, будет храниться в переменной (или нескольких). Поэтому решить, что делать, - это просто проверить эту переменную в скрипте и предпринять соответствующие действия в зависимости от ее значения.
Бенджамин Линдли
@Skeith: Хотя вы можете добавить опцию изменения, к какой зоне принадлежит плитка.
Бенджамин Линдли