Я бы не советовал использовать один плоский файл для теоретически бесконечных объемов данных.
Если у вас теоретически бесконечный объем данных, вам нужен произвольный доступ , что означает наличие нескольких файлов или базы данных - или индексированный формат плоских файлов, который включает повторное решение проблем индексирования, уже решаемых файловыми системами или базой данных.
Если вы распределяете свои чанки по нескольким файлам, получить чанк в (-110, 5000) - это просто сказать «% APPDATA% / game / map / -110 / 5000.dat» (или другое имя файла, если вы хотите начать сжимать их). Базы данных просто нужно запросить. Если в чанке нет данных, вы можете просто ничего не хранить. Один плоский файл не предлагает скорость и удобство произвольного доступа сразу.
В одном файле произвольного размера для быстрого произвольного доступа у вас должна быть гарантия местоположения любого куска данных, что означает использование индекса (поскольку необработанный двоичный поиск по вашим блокам данных снижает производительность, а создание сетки в вашем файл с "пустыми" пятнами дает вам проблему с Byte56 ). Как только вы разработаете систему индексирования, дадите ей эффективность и напишите себе API, вы воссоздали что-то вроде файловой системы или базы данных. Если вы на самом деле не получаете что-то от этого, это, вероятно, не стоит инвестиций. Например, Steam получает огромную выгоду от своих форматов файлов GCF / NCF.
Если вы хотите, чтобы ваши сбережения были защищены, это все же возможно сделать. Например, вы можете зашифровать каждый отдельный блок. Чтобы предотвратить их удаление, вы можете иметь центральный хеш на основе существующих сохраненных данных. Если сохраненные данные не совпадают с хешем (и ваша программа не вызвала изменения), чанк был удален.