Подтвердить что ты не робот

Механизм/структура диалога RPG

Меня всегда интересовали структуры данных, участвующие в RPG (Ролевая игра). В частности, мне интересны действия, связанные с диалогом и событиями.

Например: если я подхожу к NPC в точке x в игре, с элементами y и квестами z, как бы я определил, что должен сказать NPC? Ветвительный диалог и ответ на вход проигрывателя кажутся тривиальными, поскольку имеют определенный script, а пользовательский ввод заставляет читателя script перейти к определенной строке в script, которая имеет соответствующий набор строк ответа (что очень похоже на выберите свое собственное приключение)

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

Я ищу идеи (не обязательно примеры языка программирования) о том, как подойти ко всему этому диалогу и логике, и отделить его, чтобы было очень легко добавить новый ветвящийся контент, не вникая в слишком много кода.

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

4b9b3361

Ответ 1

Например: если я подхожу к NPC на точки x в игре с элементами y и квесты z, как бы я определил, что NPC должен сказать? разветвление диалог и реагирование на игрока ввод кажется тривиальным, поскольку имеет определяется script, а причины ввода пользователя читателя script, чтобы перейти к конкретную строку в script, которая имеет соответствующий набор ответов линии (очень похоже на выбор приключение)

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

Совсем нет. Вы просто кодируете условные обозначения в данных.

Скажем, у вас есть список диалогов, пронумерованных от 1 до 400, или что-то вроде примеров "Выбор собственных приключений". Я предполагаю, что каждый диалог может состоять из текста, на котором говорит NPC, а затем список ответов, доступных игроку.

Итак, следующий шаг заключается в том, чтобы добавить в него условные условия, просто привязывая условия к каждому ответу. Самый простой способ - сделать это с помощью языка сценариев, поэтому у вас есть короткий и простой фрагмент кода, который возвращает True, если этот ответ доступен игроку, а False - нет.

например. (Формат XML, но может быть что угодно)

<dialogue id='1'>
  <text>
    Couldst thou venture forth and kill me 10 rats, perchance?
  </text>
  <response condition="True" nextDialogue='2'>
    Verily! Naught could be better than slaying thy verminous foes. Ten ratty
    carcasses shall I bring unto thee.
  </text>
  <response condition="rats_left_in_world() < 10" nextDialogue='3'>
    Nay, brother! Had thou but ten rats remaining, my sword would be thine,
    but tis not to be.
  </response>
</dialogue>

На вашем языке сценариев вам понадобится функция "rats_left_in_world", которую вы можете вызвать, чтобы получить значение, о котором идет речь.

Что делать, если у вас нет языка сценариев? Ну, у вас может быть код программиста индивидуального условия для каждой ситуации в вашем диалоге - немного утомительно, не так сложно, если ваш диалог написан заранее. Затем просто обратитесь к условию по имени в цепочке script.

Более продвинутая схема, все еще не требующая языка сценариев, может использовать тег для каждого условия, например:

<response>
  <condition type='min_level' value='50'/>
  Sadly squire, my time is too valuable for the likes of thee. Get thyself a
  farm hand or stable boy to do thy bidding!
</response>

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

Ответ 2

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

В разработке игр разработчики контента, которые мы программисты хотим предоставить. Они не будут (это очень важно) смотреть на код. Период. Снова и снова вы получаете технического художника или технического дизайнера, и они замечательные и не против; но большинство авторов контента технически не склонны.

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

Система, подобная этой (ветвящийся диалог), требует представления в инструменте, который относительно интуитивно понятен в использовании. Например, можно использовать систему визуальных скриптов Unreal Kismet.

По существу, структуры данных (скорее всего, ветвящееся дерево, так как оно легко представлять /debug/etc.), создавалось бы программистом, как и узлы, которые представляют объект в script. Затем будет создана система со своей способностью связываться с объектами мира (более вероятно, также представленная узлами в визуальных сценариях) и т.д., И весь кошелёк-кабалет соединяется в какой-то славный бит элегантного кода.

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

Просто подумал, что добавлю немного знаний и проницательности.

РЕДАКТИРОВАТЬ: Заметил пример XML. Я не уверен, что другие дизайнеры/художники и т.д. ощущайте это; но те, с которыми я работал, сталкиваются с идеей прикосновения к текстовому файлу.

Ответ 3

Я бы рискнул сказать, что большинство современных игр (будь то РПГ, экшн-игры, что-либо выше основных карточных/настольных игр) обычно состоят из нескольких компонентов: движок отображения, основные структуры данных и, как правило, вторичный скриптовый движок, Один из примеров, который был популярен какое-то время (и может быть, я даже не говорил с разработчиком игры в течение многих лет) был Lua.

Решения, о которых вы говорите (события, ветки разговора и т.д.), обычно обрабатываются вторичным механизмом сценариев, поскольку языки сценариев более гибкие и обычно проще использовать для разработчиков игр. Опять же, большая часть реальной логики, управляемой историей или игрой, на самом деле произойдет здесь, где ее можно поменять местами и изменить относительно легко. (По крайней мере, по сравнению с полной версией всего кода!)

Основной движок игры объединяет структуры данных, связанные с миром (геометрия и т.д.), структуры данных, связанные с игроком (ами) и другими действующими лицами, и скрипты для вождения встреч и используют все для отображения окончательной интегрированной среды.

Ответ 4

Вы можете использовать язык сценариев для ведения диалога. В принципе, script может выглядеть так:

ShowMessage("Hello " + hero.name + ", how can I help you?")
choices = { "Open the door for me", "Tell me about yourself", "Nevermind" }
chosen = ShowChoices(choices)
if chosen == 0
    if hero.inventory["gold key"] > 0
        ShowMessage("You have the key! I'll open the door for you!")
        isGateOpen = true
    else
        ShowMessage("I'm sorry, but you need the gold key")
    end if
else if chosen == 1
    if isGateOpen
        ShowMessage("I'm the gate keeper, and the gate is open")
    else
        ShowMessage("I'm the gate keeper and you need gold key to pass")
    end if
else
    ShowMessage("Okay, tell me if you need anything")
end if

Это нормально для большинства игр. Язык сценариев может быть простым, и вы можете писать более сложные логические ветки. У вашего движка будет некоторое представление о мире, который подвергается языку сценариев. В этом примере это означает имя героя и предметы в инвентаре, но вы можете разоблачить все, что вам нравится. Вы также определяете функции, которые могут быть вызваны скриптами, чтобы делать такие вещи, как показать сообщение или воспроизвести некоторый звуковой эффект. Вам нужно отслеживать некоторые глобальные данные, которые совместно используются сценариями, например, открыта ли дверь или выполняется квест (возможно, как часть классов карты и квеста).

В некоторых играх скриптинг может быть утомительным, особенно если диалог более динамичен и зависит от многих условий (например, характер и статистика персонажа, знание npc, погода, предметы и т.д.). Здесь вы можете хранить свои диалоговое дерево в некотором формате, что позволяет легко определить предварительные условия и результаты. Я не знаю, как это сделать, но я задал вопрос о хранении игровой логики в файлах XML. Я нашел этот подход эффективным для моей игры (в котором диалог сильно зависит от многих факторов). В частности, в будущем я мог бы легко создать простой редактор диалога, который не требует много сценариев и позволит вам просто определить диалог и ветки с графическим интерфейсом пользователя.

Ответ 5

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

https://github.com/scottbw/dialoguejs

Существует компромисс между сложностью сценариев и простотой редактирования для не-программистов.

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

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

Ответ 6

Это отличные вопросы. Я должен был решить это несколько раз для клиентов. Мы начали с структуры XML, очень похожей на вашу, и теперь мы используем JSON. Здесь вы можете увидеть пример: http://www.branchtrack.com/projects/on029pq6.json или https://dl.dropboxusercontent.com/u/11433463/branchtrack/on029pq6.json (префикс для чтения).

Полное раскрытие: ссылка выше генерируется в BranchTrack, онлайн-редакторе для ветвящихся диалогов, и я являюсь генеральным директором. Не стесняйтесь спрашивать что-нибудь.

Ответ 7

Недавно я столкнулся с такой проблемой, создав Chat Mapper. То, что я делаю, графически отображает диалоги в виде узлов в дереве, а затем каждый node имеет условие и script, связанные с ними. Когда вы проходите через дерево и нажимаете node, вы проверяете условие, чтобы проверить, действительно ли это node, и если это так, вы выполняете script, связанный с этим node. Это довольно простая идея, но, похоже, хорошо работает с нашим тестированием. Мы используем интерпретатор .NET Lua для скриптов.

Ответ 8

Для моего решения я разработал формат пользовательского текстового файла, состоящий из семи строк текста за node. Каждая строка может быть перечеркнутым списком или просто текстовой строкой. Каждый node имеет номер позиции. Последняя цифра числа - это тип, поэтому существует 10 различных типов узлов, таких как свежие вопросы, подтверждения, повторные действия на основе предыдущих результатов и т.д.

Каждое активирование диалога начинается с запроса выбора в хранилище данных, результаты которого можно сравнить с членами списка с чередованием, чтобы соответствовать соответствующему node. Это более жестоко, чем if/then, но это делает текстовый файл config меньше, поскольку вам не нужен синтаксис, кроме разделителя шагов. Я использую систему подстановочных знаков, чтобы разрешить выбор результатов запроса, чтобы они могли быть вставлены в речь NPC.

Наконец, есть API-интерфейсы, с помощью которых пользовательские скрипты могут взаимодействовать, если недостаточно простого файла конфигурации. Я планирую сделать веб-приложение gui в nodejs, чтобы позволить людям визуально script файлы конфигурации: D