Система диалогов

Начал делать для своего проекта (в первую очередь) систему диалогов. Возможно в дальнейшем из неё можно сделать отдельный Asset для AssetStore Unity.

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

Сам же визуальный стиль для системы диалогов я навязывать не буду, и когда и если это станет отдельным asset`ом, то пользователь сможет его настроить сам. Я посмотрел в Юнити есть уже разработки по диалоговой системе (https://www.assetstore.unity3d.com/en/#!/content/11672), но там все сильно перегружено. Я предлагаю более простую для юзеров систему:

1. Геймдизайнер (сценарист) создает граф диалогов в простом графовом редакторе, и экспортирует в простом стандартном формате

2. Разработчик настраивает условия в редакторе Юнити

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

В первом приближении, все квесты сводятся к тому, когда npc начинает диалог - можно задать ряд условий. Все условия делятся на 3 вида - к NPC кто-то подошел, к нему что-то принесли, или от него что-то унесли. Дистанция показывает соответственно на сколько близко подошли, как близко принесли, как далеко от него унесли. Дальше вопрос что/кто принес/подошел. Можно указать как набор геймобъектов, а так же задать им альтернативы (т.е. условия на and/or). Так же можно указать, для начала диалога, какие фразы должен был увидеть игрок в процессе диалога раньше.

По мне так все. Просто и элегантно.

Вопрос следующий - какие типы квестов я упускаю? Если кто-то уже разрабатывал систему диалогов для себя, буду рад если поделитесь опытом.

upd.
По мере разработки буду здесь отмечать ход разработки как в блоке. Многое из осужденного можно пропустить и посмотреть

1. тут пояснение и ролик чуть ниже http://www.gamedev.ru/projects/forum/?id=221059&page=5#m71
2. актуальные дискуссия начинается от сюда http://www.gamedev.ru/projects/forum/?id=221059&page=7#m97

1. Локализация
2. Проверка на существование вещи в инвентаре, на то, что какой-то флаг по квестам поднят.
3. Установка состояния / флага по сложному условию (различные проверки на непротиворечивость и тп).
4. Из п.2-3 следует, что нужно какое-то хранилище флагов / состояний квестов, которое будет выгружаться в save-данные игрока.
Самое простое решение для условий - это прикрутить какой-то скрипт-язык или нарисовать свой парсер кода условий для нод.

Leopotam
> Локализация

Решается просто, геймдизайнер создает граф диалогов - на разных языках, поэтому вопрос лишь в том какой файл подгрузить во время рантайм

Leopotam
> Проверка на существование вещи в инвентаре

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

Leopotam
> нужно какое-то хранилище флагов / состояний квестов

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

Leopotam
> становка состояния / флага по сложному условию

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

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

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

Добавь спискам читабельности.
http://va.lent.in/unity-make-your-lists-functional-with-reorderablelist/

tac
> я имею введу типовые квесты, которые ожидается, что можно полностью
> формализовать

1 сходи—принеси .
2 патруль по точкам А Б С
3 destruction - уничтожить . разбить сломать и тд. ( поди и побей NPC по имени М (типовой пример -забить босса уровня)) это destruction.  cломать генератор на электростанции -тоже destruction
4 to make - сотворить —- это обратно для destruct —— полечи вон того мужика.  почини вон тот генератор . крафт система —- приготовь снадобье тролля против орка (смешай травки) —- тоже to make

всякие логические игры типа —- вскрой сейф в комнате —-

это 2(патруль)+3(взорвать замок)
или 2(патруль)+4(подобрать шифр взлома это to make)
потом 1 —— принеси .

пример .

эй мужик иди там через три коридора (2патруль) , возьми из сейфа(3 если сломать замок или 4 если подобрать шифр) бриллиант, принеси (1) сюда -—получишь 100500 а если не сделаешь (провальное условие fail) то тебя поедят тролли.

Большая ошибка по 2 причинам:
1. увеличивается стоимость саппорта такого решения - при увеличении сложности графа дизайнер, скорее всего, пошлет на 3 буквы такое решение и будет требовать интеграции более вменяемого, ибо даже при небольшом изменении структуры квестов он должен будет сделать идентичные изменения в N-версиях графов. Вероятность ошибки при этом очень быстро начинает стремиться к 1 - дизайнер обычно гуманитарий и не способен к подобной точной работе.
2. Локализация всегда должна быть отделена от остальных данных, а связка должна выполнятся только по фиксированным токенам. Желательно, чтобы это были электронные таблицы (google docs, excel) с транспортным форматом в виде CSV. Это даст возможность быстро редактировать локализацию внешними людьми (в google docs можно дать права доступа на 1 столбик языка, чтобы случайно / намеренно не потерли остальные данные + есть хистори изменений), либо загружать на сервисы локализации. Пускать локализаторов, а тем более требовать от них работы в юнити, нельзя. Если потребуется поддержка RTL текстов - юнити вообще не вариант (в принципе не поддерживает), тут только сторонние сервисы.

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

Лучше абстрагироваться от конкретного геймплея и обязать хост-систему реализовывать N-методов через интерфейс, которые уже использовать в условных нодах (минимально 2 метода: bool GetFlag(string name); void SetFlag(string name, bool state);).

Т.е. система диалогов ничего не знает как и что хранится в хост-системе, но может запрашивать состояние и менять его через разрешенное апи.

Не очень хорошая мысль - диалоги делает дизайнер, не программист. Позднее я отказался от идеи нодов диалога и реализовал все в виде скрипт-языка с реакцией на эвенты (показ квеста, выбор варианта и тп).

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

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

Leopotam
Почему слил идею с графом? Я наоборот отказался от скриптоязыков в пользу визуального редактора графа.
Более того я на нем сделал всю модель поведения (аи) для данного вида нпс. В принцыпе сам доволен.
Как сделано:
Блоки есть 2 типов - диалоговые и функциональные.
Переходы между блоками могут иметь условия или набор условий - в них можно проверить проверить параметр свой или контактирующего на условие. Например hppercent<30, itemcount("bullet")!=0, переменная iamRelax >0
Если условия не соблюдены , переход считается не активным и в меню диалога не будет этого пункта меню

Для функциональных можно проверять только результат на успех или неуспех.
Функциональные это например - одеть оружие, идти к указанной цели, уничтожить цель, сменить режим бега, установить переменную iamRelax= 1

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

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

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

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

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

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

А что то я не вижу разницы между вашим предложением с флагами, и ругулярными выражениями от Мира /аналог чего есть в юните при описанни коенчного автомата при анимации/

Leopotam
для этого достаточно простого парсера выражений.
Учитывая что я юзаю делфи, там имеется мощная поддержка rtl.
Можно программно получать доступ к свойствам и виртуальным методам объектов по имени. Вычисляем результат через сравнение вариантов и сравниваем с желаемым.
Это не очень быстро, но нектороые фокусы позволяют это ускорить. Ну и аи и диалоги это не рендер.
Для функциональных блоков нужны апи, это да. Но скажем для квестов как в казуалках там нужно то минимум - создать предмет и ещё ченеть.
С большим числом ты прав. Я ещё не решил как сделать хорошо, и у меня редактор топорный :)

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

meekobold
> Не вижу на картинке циклов :(
Привидите реальный пример где нужен цикл

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

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

У топикстартера юнити. Я просто последние 2 года занимался разработкой для саудитов, а у них как раз rtl - никому не пожелаешь такого треша. Например, текст пишется справа налево, а цифры - слева направо. Любые подкрашивалки текста (в виде html-тегов, например) работают тоже только слева направо. Те нужно смешивать одновременно RTL + LTR - большинство редакторов просто сходит с ума, включая msoffice и libre office, гуглодоки вели себя адекватнее всех. Но все равно, когда нужна разбивка в несколько строк с включениями данных через string.format + подкраска всего это разноцветными блоками - это просто жесть, проще никогда не делать поддержку RTL языков.

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