Як ви можете помістити всі зображення з гри в 1 файл?

Щойно я закінчив основну гру RPG, написану на C ++ SFML, я вклав багато зусиль у гру і хотів би поширити її, проте я зіткнувся з невеликою проблемою.

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

Ну, саме цього я намагаюся досягти: сподіваюся спакувати всі зображення в 1 файл (можливо, також .txt файли), а потім зможу прочитати з цього файлу або легко додати до нього.

Ігрові програмісти покладаються на один із двох основних методів зберігання даних:

• зберігати кожен файл даних як окремий файл
• зберігати кожен файл даних у власному форматі архіву

Недоліком першого рішення є проблема витраченого місця на диску, а також проблема повільніших установок.

Друге рішення передбачає власні підводні камені, по-перше, ви повинні написати все своє зображення / звук / тощо. завантаження процедур, які використовують користувацький API для доступу до архівованих даних. Наступним недоліком є ​​те, що вам потрібно написати власну архівну утиліту, щоб створити архіви в першу чергу.

Якщо ви завжди завантажуєте всі файли з архіву, TAR / GZ може бути не дуже хорошою ідеєю, оскільки ви не можете витягти конкретні файли у міру необхідності. З цієї причини багато ігор використовують архіви ZIP, які дозволяють витягувати окремі файли за потребою (хороший приклад - Quake 3, файли PK3 - це не що інше, як ZIP-файли з іншим розширенням).

• http://zpp-library.sourceforge.net/
• http://www.winimage.com/zLibDll/minizip.html

EDIT: "Сховати" структуру папки ігор та "Keep" лише виконувані файли

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

EDIT: Gamedev Tuts Plus мають хороший ресурс

• http://gamedev.tutsplus.com/tutorials/implementation/create-custom-binary-file-formats-for-your-games-data/

EDIT: лібрхів

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

• http://libarchive.github.com/

EDIT: Файли ZIP-формату з альтернативним розширенням

Тут мені подобається коментар @Joachim Sauer

Використання файлів ZIP-формату з альтернативними розширеннями також має велику традицію поза межами ігор: Java це робить , формат OpenDocument (він же формат OpenOffice / LibreOffice) , навіть Office Open XML (він же "новий" формат Microsoft Office) робить це .

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

Мені дуже подобається PhysFS за це. Це дозволяє отримувати доступ до папок або поштових архівів з тим самим кодом. Він добре працює на всіх етапах життя Ігор.

1. Під час розробки : отримуйте доступ до ресурсів безпосередньо з ієрархії папок. Таким чином, стислі архіви не заважають, і ви можете швидко повторити.
2. Початкове розгортання : збирайте свої ресурси для легкого розгортання / швидкої установки. Не потрібно змінювати код. Просто наведіть PhysFS на zip замість папки.
3. Оновлення / Модифікація : PhysFS може завантажувати кілька архівів zip, де ресурси переважають інші. Оновлення можуть бути такими ж простими, як і новий поштовий індекс, лише із зміненими файлами. Аналогічно для модінгу.

оновлення:

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

Я б запропонував використовувати файл ZIP. Це повсюдний формат, і ви знайдете готові бібліотеки, які дозволяють завантажувати файли з ZIP-файлу. Швидкий пошук Google навіть виявив завантажувач zip для sfml .

Ну, ви можете обдурити, як вони згадували :) Ви можете зробити спрайтовий аркуш із зображень, зараз немає потреби закопувати його, якщо це не заощадить багато тонни місця. Створивши спрайт-лист або кілька спрайтових аркушів із зображень, ви можете просто перейменувати їх розширення. Більшість геймерів не будуть намагатися перевірити, а чому б не залишити цю опцію артистам, які, можливо, захочуть модифікувати вашу гру в майбутньому? Таким чином вони також можуть створити спрайт-аркуш, перейменувати його розширення та почати прокат.

За допомогою текстових файлів я покірно пропоную вам перетворити ці дані у двійкову форму. Я впевнений, що ви знайдете простий спосіб зробити це. Наприклад, якщо ви використовуєте лише AZ, az та 0-9, ви можете використовувати 6 біт для представлення кожного символу, що дещо захистить ваш захищений авторським правом матеріал, це також не дозволить іншим редагувати карти. Ви завжди можете додати конвертер карт, якщо хочете. Хоча для блискавок текст цілком розумний.

Йдеться не лише про кількість ресурсів чи місця на диску.
З багатьма різними файлами текстур, як ви використовуєте SFML, який надає OpenGL, кожен раз, коли ви збираєтеся надати текстуру, OpenGL потрібно прив’язувати наступну текстуру до відеокарти (перевірте glBindTexture ()), і це дійсно дороге завдання.
Зважаючи на це, ви можете зрозуміти, чому ігри зазвичай містять кілька спрайтів у тій же текстурі, так званих спрайтах, відповідно до ваших меню / рівнів / карт гри.
Результат - величезний приріст продуктивності, оскільки ви надаєте багато спрайтів з однаковим викликом прив'язки текстури.

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

http://gamedev.tutsplus.com/tutorials/implementation/create-custom-binary-file-formats-for-your-games-data/

Спрайти - це зовсім інша тема, але вони є нормою для більшості ігор :)

Ще один метод, який ви можете використовувати:

Безкоштовна версія XnView надає функцію під назвою " Strip of Images" (SHIFT + A), яка дозволяє створюватиsprite-collections .

Це мінімізує доступ до файлів і особливо важливо для веб-додатків / ігор, щоб мінімізувати кількість HTTP-roundtrips .

Потім доступ до окремих зображень надається через координатні карти (наприклад, визначення css).

Спочатку ви повинні написати все своє зображення / звук / тощо. завантаження процедур, які використовують користувацький API для доступу до архівованих даних. Наступним недоліком є ​​те, що вам потрібно написати власну архівну утиліту, щоб створити архіви в першу чергу. Якщо ви завжди завантажуєте всі файли з архіву, TAR / GZ може бути не дуже хорошою ідеєю, оскільки ви не можете витягти конкретні файли у міру необхідності. З цієї причини багато ігор використовують архіви ZIP, які дозволяють витягувати окремі файли за потребою (хороший приклад - Quake 3, файли PK3 - це не що інше, як ZIP-файли з іншим розширенням). http://zpp-library.sourceforge.net/