Как лучше хранить карты для игр
 

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

Читал, что блиц умеет загружать файлы .бсп.

Вообще как лучше хранить данные о карте, чтобы было блицем удобно юзать их?

Ответ: Как лучше хранить карты для игр
 

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

Ответ: Как лучше хранить карты для игр
 

а откуда возьмется хотя бы мегабайт текста, если в нем не хранить сами бинарные ресурсы? ну и да SAX парсер вместо DOM тоже помогает.

Ответ: Как лучше хранить карты для игр
 

Да естественно напишу редактор. Сейчас стоит проблема выбора типа записи карты.

Интересно как сделать оптимально

Ответ: Как лучше хранить карты для игр
 

хотя бы геометрия уровня. думаю что если в самом уровне (не в кадре) будет хотя-бы миллион трисов (это итак не очень много для современных игр) то уже в текстовом виде это будет несколько мегабайт. а если еще считать сюда оформление структуры? <> и т.д.

естественно

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

то есть по сути карта это всеголиш описаловка положения обьектов

Ответ: Как лучше хранить карты для игр
 

Мы кажется про блиц тут беседуем.

Ответ: Как лучше хранить карты для игр
 

т.е. mesh'и хранить в XML? мда, не надо доводить мысли до абсурда.
формат должен представлять собой _логическое представление_ т.е. например так:
<model name="player">
<mesh>meshes\\player.b3d</mesh>
<texture>textures\\player.dds</texture>
</model>
<bonus type="health">
<position x:0.0, y:1.0 z:125.0>
</bonus>
а парсер читает из файла и вызывает функции соотвествующие типам узлов (SAX).
в принципе можно даже на Блице самому написать 3-4 функции типа
XMLnode, XMLattribute, XMLvalue и функцию levelFromXML(filename$) и не искать никаких парсеров

Ответ: Как лучше хранить карты для игр
 

ты внимательно читал что я написал? модели и текстуры лежат не в хмл, а в одельной папке, хмл - только описание свойств

Ответ: Как лучше хранить карты для игр
 

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

ну дык из этого миллиона врятли хотя-бы 10к будет в кадре сразу. никто же не говорит что в игре будет виден сразу ВЕСЬ уровень.

Ответ: Как лучше хранить карты для игр
 

ну вообщем вопрос был про оптимальное хранение файла карты )))

Ответ: Как лучше хранить карты для игр
 

К чему искать/учить спецификацию чужого формата (XML) когда можно написать свой? Тем более XML - текстовый формат, он предназначен для хранения ранхы там отчётов и т.д., но не для загрузки игры, так что скорости от него не жди. А в своём формате можно описать всё в том порядке, в каком оно будет загружаться и т.п. ну и другие фичи.
У меня уже вон давно свой формат для описания загрузки моделей, предметов и т.д. - ни разу не пожалел ;)

Ответ: Как лучше хранить карты для игр
 

а можно чуть подробнее про твой формат в качестве наглядног о примера, просто я прогер в области веб, знаю много языков отлично +)) решил вот геймдевом занятся! даже вспомнил си++ ради этого

написал уже часть движка блиц+си++ ОПП ))) дошел до редактора и загрузки уровней из файла

если не тему, то хз тут вроди таких веток нет

Ответ: Как лучше хранить карты для игр
 

оказывается бывают сетки врагов, деревьев и корованов?
ты прекрасно понял что я имел в виду геометрию (сетку вершин и треугольников).
так вот ее надо хранить в отдельном файле (ИМХО)
если триггер задан какой-то хитрой геометрией (нерегулярной) - указать путь и имя файла в XML и при парсинге уровня загрузить из файла модель (3ds, b3d).
Но Блиц ничего подобного не умеет, есть только элипсоид и бокс, у которых 2 (радиусы) и 3 (высота, ширина, глубина) параметра соответственно.

Ответ: Как лучше хранить карты для игр
 

Я не занимаюсь созданием игр, но видел в одной игре практически всё на xml =) Называлась она вроде Fallen Lords. Так в ней даже местоположение "монстров" в xml хранилось. Ух я помню ради прикола вписал в одной карте-миссии куууучу монстров и запустил. Смотрели Властелина Колец, когда призраки оркам люлей давали и гигантских слонов валили? Мне практически удалось воссоздать этот момент. :-D :-D :-D Комп жёстко притормаживал при отрисовке миллионной армии монстров, которые кучей напоминали именно призраков (по цвету) и они набрасывались на гигантского монстра (не слон, но похож на него и тоже с наездником). Реально выглядело похоже. :-D Ах да, о чём это я. Я это к тому, что вполне в xml можно хранить местоположение. =)

Ответ: Как лучше хранить карты для игр
 

сть пяток парсеров хмл для блитца, ищи на оффоруме

ИМХО очень неудобный способ записи - не вижу никаких преимуществ перед обычной записью из редактора в свой формат.

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

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

Ответ: Как лучше хранить карты для игр
 

Ответ: Как лучше хранить карты для игр
 

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

линк в студию, если не сложно

Ответ: Как лучше хранить карты для игр
 

А чего тут думать? Бинарная запись самая практичная. Составляешь структуру, затем записываешь побайтого и радуешься результату. Ну вот такая структура например :
1)Тип объекта
2)Название
3)Свойства
4)Дополнительные параметры

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

Ответ: Как лучше хранить карты для игр
 

Ответ: Как лучше хранить карты для игр
 

человек задал вменяемый вопрос. то, что написано impersonalis'ом в "факе" хм... тянет на детский сад, ну может первый класс начальной школы:)
Aceton же не писал "памажите делать ММО суть такова". А вопросы интересные есть: сериализация, линки, кросслинки, предварительные объявления - сложностей полно. Вот это и хотелось бы пообсуждать, а не ответы "каг песадь байты в файл и вапще ты нуб".

Ответ: Как лучше хранить карты для игр
 

Если по теме то самые практичные файлы бинарные но для них нужен редактор.
XML рулит только тем что редактировать можно любым текстовым редактором (правда сомнительное преимущество, т.к. гемор это ещё тот).

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

Плюсы XML:
+есть множество парсеров, выдающих в ответ на запрос данные.
+ненужен редактор, подойдёт даже "блокнот".
+легко читаем человеком

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

Плюсы:
+компактный размер
+защита данных от правки (нужен опр. скилл для правки)
+быстрая загрузка
+возможно хранение любой информации вплоть до ресурсных файлов


Я продпочитаю гибридный формат, по сути это бинарный файл с оглавлением и делением на секции.

Т.е. вначале файла идёт заголовок со списком идущих ниже секций и их смещений от начала и размерами.

Секция представляет собой блок бинарных данных с именем.

Чтение такого формата происходит примерно так:
*загружаем заголовок со списком секций.
*перебирая список секций загружаем их в соответствии с именем/типом секции, если алгоритму секция неизвесна он её просто пропускает.

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

например b3d формат примерно так и устроен.

Ответ: Как лучше хранить карты для игр
 

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

А блокноте удобно править только уровни примитивных 2д игр.
И то дело вкуса.
Мне проще за час написать свой редактор, чем в этих тегах ковырятся

Ответ: Как лучше хранить карты для игр
 

SBJoker хорошо написал. Но остается вопрос про линки(ссылки) из одних узлов/чанков/тегов на другие. Где применяется, ну например в вейпоинтах (ссылки на следующий, предыдущий). Да, можно конечно выкрутится и сделать каждому номер и ссылатся на номер, но интересно решение именно со ссылками. Кто-нибудь вобще такое делал? И как обходится с чанками, которые ссылаются на те, которые впереди в файле (еще не прочитаны/загружены)?

Ответ: Как лучше хранить карты для игр
 

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

Ответ: Как лучше хранить карты для игр
 

есть один знакомый, он делал редактор файлов check.bin в Мафии. этот файлик как раз все вейпоинты содержал. я думаю у него можно структуру формата узнать, если нужно.

Ответ: Как лучше хранить карты для игр
 

т.е. все равно номерами, только глобальными. ну ладно, вполне себе решение.

Ответ: Как лучше хранить карты для игр
 

Номерами и только ими..просто связывание осуществлять после загрузки всех объектов, и все дела ;) .

Ответ: Как лучше хранить карты для игр
 

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