Страница 1 из 2

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

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

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

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

СообщениеДобавлено: 23 дек 2016, 13:49
A-Train
В разных .json

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

СообщениеДобавлено: 23 дек 2016, 13:53
Heliosis
A-Train писал(а):В разных .json


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

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

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

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

СообщениеДобавлено: 23 дек 2016, 14:01
A-Train
Это уже зависит от самой системы диалогов. Смысл дробления в том, чтобы не грузить большой текстовый блок целиком, а брать нужные блоки текста в нужное время.

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

СообщениеДобавлено: 23 дек 2016, 14:05
A-Train
Как их заполнять - отдельный вопрос, нужно чтобы они правильно десериализовались в приложении. Для заполнения блоков текста и конфига связывания потом можно отдельную геймдизайнерскую тулзу сделать.

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

СообщениеДобавлено: 23 дек 2016, 14:05
Heliosis
A-Train писал(а):Это уже зависит от самой системы диалогов. Смысл дробления в том, чтобы не грузить большой текстовый блок целиком, а брать нужные блоки текста в нужное время.


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

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

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

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

СообщениеДобавлено: 23 дек 2016, 14:08
Heliosis
А так же не менее важный вопрос: если вместе с диалогом должно выполняться какое-то действие, то нужно точно так же для каждого объекта создавать новый скрипт и записывать в него выполняемое действие?

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

СообщениеДобавлено: 23 дек 2016, 14:12
A-Train
Должен быть еще конфиг, который связывает отдельные объекты из массы текстблоков, из массы событий игры и из массы объектов сцены.

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

СообщениеДобавлено: 23 дек 2016, 14:13
Heliosis
A-Train писал(а):Должен быть еще конфиг, который связывает отдельные объекты из массы текстблоков, из массы событий игры и из массы объектов сцены.


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

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

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

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

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

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

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

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

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


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

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

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


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

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