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

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

но для примера сейчас сделаю тхт с данными, которые собираюсь сливать в файл.

вот, вроде всё, что будет сохраняться слил в тхт...

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

Однозначно бинарник. Минимум мусора, максимум остального.

Это идея хорошая. Только забудь про дроби. Версия не бывает дробной. Оно выражается целым числом от 0 до бесконечности. Это ты уже потом можешь его поделить как нужно. Для версий хватит 2 байт, это будет выше крыши (ты ж не будешь делать Win8? Ну вот! 65000 тыс. версий тебе хватит).
[][]

И вот тут уже у тебя ступор пошёл. Компу пофиг other это или 0, store это или 1, multiplayer или 2, ... Ну ты понял идею? Сюда можно зафигачить битовую карту. Это будет удобно и тоже влезет в 2 байта.
[][]

Здесь можно строкой, но с применением индексирования для названий папок. Дальше кол-во файлов и после сами файлы. Кол-во символов в названий (столько байт) и кол-во свойств (1 байт). Читаем название. После идут тип свойства (байт) и значение свойства (размер можно читать либо с типа, либо 4 байта на любое свойство, этого должно хватить). Потом опять название объекта и его свойства и т.д.

Здесь у нас сначала хранится размер карты. В зависимости от размера. Если 0-255, то по байту, если до 65535 то 2 байта, более 4 байта.

Далее линейный массив индексов тайлов (по байту на индекс). Линейный массив в двумерный же умеешь преобразовывать?

А вот что такое индекс расскажу сразу. Помнишь паллитру в GIF файлах? Допустим файл хранит паллитру из 4 цветов (4 индекса). Каждому индексу соответствует опр. цвет. Если цвет будет 32бита и картинка будет большой то экономия будет огромной. Так же делают в 3д графике, так же и в файлах.

У тебя же не рандомные название директорий? Вот. Значит каждой директорий можно применить индекс. Допустим папка tiles будет иметь индекс 0. Теперь мы когда читаем папки, видим ноль, ага! Значит тут tiles. Если файлы будут мизерными это будет излишеством. Но чем похожих элементов (папок) больше, тем актуальнее этот приём.

По поводу битовой карты. Хранить свойства в строках дикое расточительство. Каждому свойству можно приставить свой бит. 1 байт = 8 бит, т.е. 8 не взаимоисключающих свойств. Идут биты слева направо. Получится допустим так (каждый кубик бит):
[reserve][reserve][reserve][reserve][reserve][other][store][multiplayer]

Представь что это простой массив. Массив битов. Какие у них индексы? multiplayer - 0, store - 1, other - 2 и т.д. отличие только, как ты наверное заметил, читаем слева направо. multiplayer взаимоисключающее свойство? т.е. может быть multiplayer и singleplayer в одном? Если да, то экономи на 1 свойство. Смотрим результат:
[0][0][0][0][0][1][0][1] или двоичное представление 00000101 или десятиричное 5. Это всё вместится в 1 байт. По биту на свойство (+взаимоисключающие).

Значения у свойств степени двойки. Т.е. первое свойство 1 (0000 0001), второе 2 (0000 0010), третье 4 (0000 0100), четвёртое 8 (0000 1000) и т.д. Заметил магию? Цифра 1 просто меняет позицию. Теперь мы из числа 00000101 (это 5 в десятиричной системе, если помнишь) можем выдернуть свойства.

Экономия везде. И теперь сравниваем. По прикидкам бинарник будет весить (с теми данными что у тебя в txt) не более пару сотен байт против 2к в txt без сжатия данных (да, да, комментарий ). Причём при больших объёмах это будет чувствоваться гораздо сильнее.

P.S.: Я те могу картиночку нарисовать твоей структуры, чтобы ты понял её. Нужно? Или так понял?

она не моя, а из твоей статьи

Здесь я просто показал идею, но спасибо, разжевал.

если бы до сих пор не научился - сгорел бы со стыда

Спасибо, применю.

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

вполне.

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

И не моя! А пионеров программирования.

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

А вот здесь надо подумать. Потому как хранить число в строке тож не очень. 32битное число занимает 4 байта в 16ричном варианте и 10 в строковом. 2.5 раза разница.

Уже вроде всем всё понятно про запись в бинарник? Да там и не сложно. Щас дел накопилось, и всем я должен что-то сделать... Только мне никто ничё не должен.

Не мной это всё придумано, я только перерабатываю в более удобоваримый вариант, более понятный.

Примерно так выглядит:

Надеюсь будет понятно без объяснений (полукруглый кубик - байт).

Маленький размер и удобство чтения* - бинарники, а большой размер и удобство изменения вручную - текст.
Бинарники: карты, модели, картинки... В общем, где мно-ого объектов.
Текст: различные настройки, свойства отдельно взятых объектов, скрипты...
Для каждой ситуации нужно выбирать своё.
Ну, а как организовывать файл - это дело личное. :D
P.S.: Если что, тему сильно не читал.
*в смысле, программная реализация оного

Не следишь за новыми веяниями! Сейчас моден не текст, а XML за лёгкость поиска и изменения настроек (а может ещё какие плюсы есть? Сетевики отзовитесь. Какие ещё плюсы у XML?).

Конечно, личное. Но. У каждого дела есть набор правил и давно изученных особенностей, которое облегчает и серьёзно продвигает в развитии проекта. Например версия файла. Меня постоянно раздражало что при загрузке нового типа формата старый получался не совместим (и все предыдущие "сейвы" были бесполезны). Теперь же это ограничение можно обойти. И наверняка есть ещё множество интересных нюансов.

XML - это тот же текст... также, как и HTML, MHT, XSL, INI, CSV да и многие другие.
> Например версия файла. Меня постоянно раздражало что при загрузке нового типа формата старый получался не совместим (и все предыдущие "сейвы" были бесполезны). Теперь же это ограничение можно обойти. И наверняка есть ещё множество интересных нюансов.
Это советы.

Ang3l, ты в чем рисуешь такие схемы, скажи, пожалуйста!

кстати, схема хорошая, но вот только к чем папки объектов?
и я под кол-во объектов выделил бы 2 байта на твоем месте, если честно - запас нам никогда не помешает.

Добавлено (03.04.2010, 22:34)
---------------------------------------------

Как делать нефиг добраться до информации) В особенности если работать со специальной длл для чтения их. Например, практически во всех подобных длл есть функция, аналогичная document.getElementsByTagName('') в яваскрипте. Плюс к тому же, можно легко построить эффективную иерархию!

Использую ConceptDraw Office PRO. На данный момент, она мне понравилась больше всего. Есть почти копия - EDraw Max. Visio 2007 какой-то убогий и тормознутый, а вот эти ничего. Кстати, схемы можно делать в Word'е (особенно в последнем красиво получаются), вставляем Вставка > Фигуры > Новое полотно, а дальше с зажатым Alt'ом (для привязки к сетке) размещаем фигуры. Все эффекты в комплекте, но это относится к 2007, к ранним я хз.

Обозначение вложения. т.е. не просто байт кол-во чего-то, а кол-во объектов определённых внутри "папки". Мысленное вложение. Как в принципе и папки для файлов, т.е. для удобства (для компа всё равно куча файлов, а нам понятнее). Это схема моя, так что, может ты придумаешь что-то более удобное и наглядное - вперёд!

Дело вкуса. Насколько это нужно. Но в данном случае, логично, мало ли что. Да и лишний байт не утянет.

Ang3l, спасибо!
Кстати, еще можно при желании сделать поддержку дельта-файлов.