Хранение огромной кучи текста

[Heliosis]

Значит, так. Вот есть игра, в которой есть диалоги, много, МНОГО диалогов Их все надо где-то хранить.
Если бы у меня было 2 персонажа,то я бы и вопрос не задавал, а как хранить диалоги для каждого персонажа, а их куча?
Ведь помимо персонажей в диалоговом окне будет появляться информация о предметах поднимаемых, выбрасываемых, использованных, получаемых, когда игрок взаимодействует с чем-то, то в этом же диалоговом окне также появляется какая-то информация.

Вот у меня и вопрос: как это все надо хранить? Все в одном большом .txt-файле? Или распихать для КАЖДОГО предмета/персонажа/объекта все их фразы в разные .txt-файлы? Или как-то еще иначе?

[A-Train]

В разных .json

[Heliosis]

В разных .json

То бишь для каждого объекта свой .json?

[Heliosis]

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

[A-Train]

Это уже зависит от самой системы диалогов. Смысл дробления в том, чтобы не грузить большой текстовый блок целиком, а брать нужные блоки текста в нужное время.

[A-Train]

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

[Heliosis]

Это уже зависит от самой системы диалогов. Смысл дробления в том, чтобы не грузить большой текстовый блок целиком, а брать нужные блоки текста в нужное время.

Вот чисто для примера.

Игрок подходит к какому-либо объекту, затем нажимает нужную клавишу, потом идет проверка, касается ли луч, выходящий из игрок какого-либо предмета, после чего он уточняет, что это именно, к примеру, палка, а не что-то другое, и затем он должен вывести в диалоговое окно какой-то текст.
Текст он получает, считывая .json-файл конкретно этого объекта.

Все понятно, но как он должен узнать, какую именно строчку ему нужно прочесть? Например, если текст должен зависеть от количества прикосновений к объекту, или от того, убил ли ты кого-то или нет и т.д.? Кучу if'ов писать?

[Heliosis]

А так же не менее важный вопрос: если вместе с диалогом должно выполняться какое-то действие, то нужно точно так же для каждого объекта создавать новый скрипт и записывать в него выполняемое действие?

[A-Train]

Должен быть еще конфиг, который связывает отдельные объекты из массы текстблоков, из массы событий игры и из массы объектов сцены.

[Heliosis]

Должен быть еще конфиг, который связывает отдельные объекты из массы текстблоков, из массы событий игры и из массы объектов сцены.

Ну это .ini, знаю, но что насчет важных вопросов сверху?

[A-Train]

Объекты (которые экземпляры класса) порождают события. Убил кого-то - событие, тронул что-то - событие. Их вот и связываешь в конфиге с чем-то еще. Никаких ифов не надо в коде. Все твои ифы - в конфиге.

[Cr0c]

А почему нельзя десереализовать в словарь? А потом по ключу (типа $npc_oleg_start_dialog), который на Text лежит, находить значение и подменять им ключ. В том же Start и заменять. Один файл локализации, формат любой, хоть xml, хоть json, хоть в txt. А в файле локализации можно добавить поле комментария с описанием строки. Так можно и весь интерфейс сохранить, не только диалоги. Локализация упростится, что тоже плюс.

[DbIMok]

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

[Heliosis]

А почему нельзя десереализовать в словарь? А потом по ключу (типа $npc_oleg_start_dialog), который на Text лежит, находить значение и подменять им ключ. В том же Start и заменять. Один файл локализации, формат любой, хоть xml, хоть json, хоть в txt. А в файле локализации можно добавить поле комментария с описанием строки. Так можно и весь интерфейс сохранить, не только диалоги. Локализация упростится, что тоже плюс.

Ок... Вроде бы понятно, кое-что, но не все. Не могли бы вы захотеть соизволить объяснить мне поподробнее, например в лс, если не затруднит? Или хотя бы ссылочку дать?

[Cr0c]

А почему нельзя десереализовать в словарь? А потом по ключу (типа $npc_oleg_start_dialog), который на Text лежит, находить значение и подменять им ключ. В том же Start и заменять. Один файл локализации, формат любой, хоть xml, хоть json, хоть в txt. А в файле локализации можно добавить поле комментария с описанием строки. Так можно и весь интерфейс сохранить, не только диалоги. Локализация упростится, что тоже плюс.

Ок... Вроде бы понятно, кое-что, но не все. Не могли бы вы захотеть соизволить объяснить мне поподробнее, например в лс, если не затруднит? Или хотя бы ссылочку дать?

А что тут объяснять? Есть список типа Dictionary, в котором ключ - это string и значение - сам текст. На компоненте Text лежит текст с ключом, по которому из словаря берется значение и заменяет ключ.
А в ресурсах хранить эти пары ключ-значение. Можно в ресурсе сделать три поля: ключ, значение, описание для разраба, чтобы понимать где оно используется.
Так, например, если сделать ключ $cancel_button и значение Отмена, то любая кнопка с таким ключом будет менять текст на это значение. Удобство локализации такой концепции объяснять не надо?
Замену можно производить при загрузке сцены, например. Файл ресурса можно внутри разбить по логическим блокам Интерфейс-Сцена1-Сцена2 и т.д.