Войти
ПрограммированиеФорумОбщее

XML как формат хранения Game Contents - какая технология лучше (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
1:36, 21 июля 2009

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


#16
1:46, 21 июля 2009

Напиши редактор который будет хранить в какой-то многоюзерной базе или читать из простых файлов разложенных по папкам (по локациям и сценам) весь игровой контент и будет генерить ХМЛ сам.
А вся проверка ошибок всё равно сводится к try { } catch (ticpp::Exception) { }

#17
8:50, 21 июля 2009

Don Nikola
> А на хрена в таком случае вообще xml? Почему просто не хранить внутренние
> конфиги/скрипты в "откомпилированном" виде?
> Я все время думал, что читабельные скрипты и конфиги в конечном продукте
> оставляют лишь для того чтобы юзеры могли поправить что-нибудь. А если на юзера
> мы кладем, то зачем тратить время/ресурсы на парсинг всего этого добра в
> ран-тайме?
Как на хрена? Для разработки. Гораздо быстрее поправить файл, и сразу перезапустить программу, либо вообще перезапустить часть - уровень, какой-то модуль, etc, чем править исходники конфигов, потом их компилировать/паковать. Надо писать свой компилятор, отлаживать его, изобретать велосипед, а XML парсеров/генераторов уже много. Плюс если ты сделаешь бинарный (к примеру) формат, и будешь читать оттуда все данные одним куском в память - будет сложнее расширить формат, если что-то забыли.
Да и по по поводу human-readable xml тебя кто-то сильно обманул, мне кажется. Попробуй ручками поправь xml-ки тех же 5-х героев, или хотя бы тот же скелет огровского ниндзя. XML это вообще-то машиночитаемый формат, человек может читать только очень простые и небольшие по размеру файлики.
b]my.name[/b]
> 1. разные системы и локальные языки выявили кучу проблем, как с русскими
> файлами (запретили) на и с кодировками внутри файлов (приняли утф8)
Не понял, а что даст в этом случае валидация по схеме, поясни пожалуйста.
> 2. разные национальные варианты форматов дат флоатов и т.д. (при парсинге
> например флоатов, ставим флаг что не брать из этих настроек)
Не понял, а что даст в этом случае валидация по схеме, поясни пожалуйста.
> 3. от пользователей с половыми проблемами получаем логи падений, где не сразу и
> понятно, что послужило причиной падения например при загрузке меша
Это да, здесь конечно плюс, не спорю.

#18
8:53, 21 июля 2009

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

#19
10:29, 21 июля 2009

MATov

> по бустовски медленно :)

В голове у тебя по-бустовски медленно.

#20
14:18, 21 июля 2009

2kvakvs
>> try { } catch (ticpp::Exception) { }

например для рект, ошибкой может быть не невозможность пропарсивания, если обычно берем из потока  данные и парсим простым вариантов типа
parseValue<IntCoord>(string)
то если тоже самое делать подряд из потока несколько переменных, то уже не катит простой вариант, тот самый parceValue что я писал поставми выше, ибо данные могут иметь вид нармальный сначала, а после бгалополучного начала, любой мусор, и соответсвено если подряд парсить, то появляются ошибки, причем совсем в другом месте =) т.е. полностью парсинг одной еденицы выглядет сложнее, в простом случае проверку на пустоту после пропарсивания. так что никой тру кейт не поможет ни разу ...

#21
14:19, 21 июля 2009

2Iskander
я не про схему, а про вариант мышления - у нас не падает, а у пользователя падает, значит он дурак =) удобно, но не практично

#22
15:13, 21 июля 2009

а еще есть COLLADA

#23
15:26, 21 июля 2009

Iskander

>Как на хрена? Для разработки.

А не будет ли более верно использовать тот же xml лишь при разработке, а при создании релиза заменять на читалку из компилированного бинарника? Уж слишком жалко тратить время/ресурсы на никому не нужный парсинг при загрузке уровня или объекта. Но это конечно сильно религиозный вопрос.

#24
15:33, 21 июля 2009

2Don Nikola
это можно добавить в любой момент, не изменяя код клиента, при условии нормальной разработки ресурс системы, а имено

1. ресурс менеджер у готорого по некоторым ID запрашивается ресурс
2. ресурс это черный ящик для кода, нам только доступны его джетеры

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

#25
15:36, 21 июля 2009

Iskander
> destrator
> Я имел в виду для чего в данной задаче ты их используешь? Есть готовые xml
> файлы в поставке с игрой, их считаем априори синтаксически и логически
> правильными. Редактор карт производит нормальные файлы. А если юзер распаковал,
> ручками поменял и накосясил в xml-файлах - это его половые трудности, имхо.

Не знаю как у destrator, но проверка xml очень полезна при разработке. Представь, открывает левел дизайнер какой нить объект (описание которого представлено в xml), а там, ну например, поменялся формат, или кто-то накосячил ручками, или кто-то неправильно смерджил версии -  и фигак, редактор рухнул, при этом возможно что-то не сохранилось. а если таких файлов сотни, тысячи, то их придется править поочередно, N-ное кол-во времени.
Адекватная реакция на xml, который не прошел верификацию - запись в лог и загрузка объекта с дефолтными параметрами. тогда будет сразу ясно сколько и какие файлы повреждены и почему.

my.name
> это в строку любой тип
>
> template<typename T >
> inline std::string toString (T p)
> {
> std::ostringstream stream;
> stream << p;
> return stream.str();
> }
>
>
> это из строки любой тип
>
> template<typename T >
> inline T parseValue( const std::string& _value )
> {
> std::istringstream stream(_value);
> T result;
> stream >> result;
> if (stream.fail()) return T();
> return result;
> }

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

#26
15:40, 21 июля 2009

DEN
чем-то опровергнуть можешь мои слова или просто оскорблять необосновано умеешь?

#27
18:18, 21 июля 2009

DEN

Девушки не дают?

#28
20:27, 21 июля 2009

MATov

> чем-то опровергнуть можешь мои слова

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


memphys.sk

> Девушки не дают?

А ты что, свою жопу мне хочешь предложить?

#29
21:34, 21 июля 2009

DEN
Нет, но вь*бать тебе молотком по голове было бы очень кстати :)
Хотя не поможет всяко, даже на том свете ты останешься девственником-терпилой.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.