Який хороший плоский формат файлів для зберігання 2D-карти плитки, яка може нескінченно рости в будь-якому напрямку?

Я створюю простий двигун карт, який автоматично розширюватиметься в будь-якому напрямку із процедурно-створеним вмістом за потребою.

Який хороший спосіб зберігання даних карт, які закріплені на походженнях 0,0, щоб прямокутний підмножина даних карт можна було швидко та ефективно завантажувати з будь-якої точки карти?

У мене є ідея, що, можливо, я повинен об'єднати карту на окремі сектори, а потім використовувати якийсь формат заголовка, щоб визначити, де у файлі зберігається певний сектор. Це хороша техніка чи є кращі, ефективніші методи, на які я можу подивитися?

Я б радив не використовувати єдиний плоский файл для теоретично нескінченної кількості даних.

Якщо у вас є теоретично нескінченна кількість даних, то вам потрібен випадковий доступ , що означає декілька файлів або бази даних - або індексований формат плоских файлів, який передбачає повторне вирішення проблем індексації, вже вирішених файловими системами або базою даних.

Якщо ви поширюєте шматки по декількох файлах, отримання фрагмента (-110, 5000) - це лише питання сказати "% APPDATA% / game / map / -110 / 5000.dat" (або якесь інше ім'я файлу, якщо ви хочете починайте їх стискати). Базам даних просто потрібен запит. Якщо шматок не має жодних даних, ви можете просто нічого не зберігати. Єдиний плоский файл не пропонує швидкість та зручність випадкового доступу безпосередньо біля кажана.

Для швидкого випадкового доступу в одному файлі довільного розміру ви повинні мати гарантію на позицію будь-якого фрагмента даних, що означає використання індексу (оскільки необроблений двійковий пошук через ваші фрагменти даних погіршує продуктивність і створює сітку у вашому файл із "порожніми" плямами дає вам проблему Byte56 ). Після розробки системи індексації, надання їй ефективності та написання API, ви відтворили щось на зразок файлової системи чи бази даних. Якщо ви насправді щось не отримаєте, це, мабуть, не вартує інвестицій. Наприклад, Steam отримує значну користь від своїх форматів файлів GCF / NCF.

Якщо ви хочете отримати певну безпеку, ви все одно можете це зробити. Наприклад, ви можете зашифрувати кожен окремий фрагмент. Щоб запобігти їх видаленню, ви можете створити центральний хеш на основі наявних збережених даних. Якщо збережені дані не відповідають хешу (і ваша програма не спричинила зміни), фрагмент видалено.

Здається, що найчастіше рішення розбивається на безліч файлів, однак ваше запитання передбачає лише один файл. Єдиний розумний варіант для цього (на мою думку) - це емуляція дуже простої файлової системи всередині цього одного файлу. Це насправді не дуже важко зробити, але ви дійсно повинні розглянути можливість використання декількох файлів, якщо можете.

Якщо вам доведеться дотримуватися одного файлу, ви можете знайти натхнення для своєї реалізації з ext2 fs. http://en.wikipedia.org/wiki/Ext2 Я знаю, що це допомогло мені прийняти кілька хороших рішень, коли мені довелося впровадити простий FS для гри.

Але насправді, для будь-якої зростаючої карти, як правило, краще просто використовувати файл для кожного "доступного" фрагмента.

Я застосував систему мовлення для своєї гри, коли я спіткнувся з нескінченними світами (не впевнений, збережу я їх чи ні). Для використання з одним файлом спочатку я використав світову позицію, щоб обчислити зміщення байтів у файл. Це передбачає статичний розмір шматка, або принаймні статичний максимум. Однак, якщо користувач на деякий час відправиться в одну сторону, цей файл став би досить рідким за розміром, оскільки там ще не було сформовано великих земельних ділянок, тому у файлі були порожні пробіли.

Я також спробував дві файлові системи. Один файл містить карту "парного місця" до "зсуву файлів зсуву" пар. Другий тримає всі шматки. Коли генерується новий фрагмент, він просто переходить на кінець файлу, і його зміщення зберігається у файлі позиції> зміщення. Це було проблемою, коли у вас було багато фрагментів, і знаходження зміщення у файлі позиції> зміщення зайняло небагато часу. Якщо ви вважаєте це можливим, ви можете завантажити дані позиції-> зміщення на хеш-карту під час завантаження, щоб отримати швидкий доступ.

Наразі я використовую другий варіант, але я можу перейти на щось інше, якщо я виявлю, що продуктивність недостатня. Можливо, за допомогою цієї інформації ви зможете створити щось, що працює для вас. Удачі!