Какой правильный подход для написания многопутевых «сюжетных» потоков?

Question

Интересно, можете ли вы мне помочь?

Я пишу игру (2d), которая позволяет игрокам идти по нескольким маршрутам, некоторые из которых ветвятся / объединяются - возможно, даже зацикливаются.Каждый раздел игры будет решать, какой раздел будет загружен следующим.

Я называю каждый раздел IStoryElement - и мне интересно, как лучше связать эти элементы так, чтобы их было легко изменить / настроить ив то же время, graphable

У меня будет сборка двигатель / завод, которая будет загружать соответствующие StoryElement (s) на основе различных параметров конфигурации.

Я изначально планировал предоставить каждому StoryElement свойство NextElement() As IStoryElement и событие Completed().Когда вентиляционное отверстие срабатывает, движок считывает свойство NextElement, чтобы найти следующий StoryElement.

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

Я рассмотрел несколько других решений, но все они чувствуют себя немного неуклюже - например, мне нужен дополнительный уровень абстракции?т.е. StoryElementPlayers или аналогичные - каждый из них будет отвечать за связывание нескольких StoryElement, возможно, Series и ChoicePlayer, каждый из которых отвечает за построение своего собственного StoryElement - Но это просто переместит проблему на уровень.

* 1022Короче говоря, мне нужен какой-то способ эмуляции простого, но динамического рабочего процесса (но я бы на самом деле не использовал WWF).Есть ли образец для чего-то такого простого?Все, что мне удалось найти, относится к более продвинутому потоку управления (параллельная обработка и т. Д.)

Answer 1

Это может помочь представить объекты StoryElement как узлы в ориентированном графе.Края графа могут быть представлены StoryElementTransition объектами (или некоторым похожим именем).StoryElementTransition может содержать ссылки на состояние, из которого вы хотите перейти, состояние, в которое вы хотите перейти, и, возможно, событие, которое инициирует переход.

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

Answer 2

Я знаю, что на этот вопрос есть принятый ответ, и, вероятно, вы все равно решили, но я должен сказать, что в последнее время я об этом думал («как мы должны моделировать сюжетно-ориентированную игру?») И какие выводы я сделал »Мы пришли к следующему состоянию:

• Истории - это данные, их нельзя нигде определять в коде.

(То же относится и к элементам игрового процесса, напримеру вас не должно быть класса Goblin, вместо этого вы можете загрузить Enemy.Creep под названием "Гоблин" из некоторой базы данных врагов.)

• Большинство проектов, которые вы можете придумать, будут ограничены илитрудно расширить.

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

• В большинстве профессиональных игр используются скрипты и движок.

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

• Вам не нужно прикасаться к двигателю после точки и сосредотачиваться на истории.

Это означает, что вы будете редактировать файлы истории (базы данных? Разметки? Скрипты?) И смотреть, как они играют вместе, оставляя ваш компилятор в покое.