2008-10-15 4 views
3

Как объединить несколько ресурсов для приложения (изображения, звуки, скрипты, xmls и т. Д.) В один/несколько двоичных файлов, чтобы они были защищены от рук пользователя? Каковы типичные шаги (организация, загрузка, шифрование и т. Д.)?Объединение ресурсов в один двоичный файл

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

ответ

0

Короткий ответ: да.

В Mac OS 6,7,8 был реализован значительный API, посвященный этой точной задаче. Если вам интересно, найдите «Менеджер ресурсов». Редактирование: также делает пакет анализа физики ROOT.

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


Edited добавить: Все из двух-или-трех инструментов такого рода, что я отсутствую доли аналогичный Struture:

  • Файл начинается с заголовка и индекса
  • Существует ряд блоков, некоторые из которых могут иметь собственные заголовки и указатели, некоторые из которых являются листами.
  • Каждый лист представляет собой простую сериализацию данных, которые необходимо сохранить.
  • Весь файл (или иногда отдельные блоки) может быть сжат.

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

2

делать как Java: упаковать все это в zip и использовать API-интерфейс, подобный файловой системе, для чтения непосредственно оттуда.

+0

Это небезопасно. Файл должен быть зашифрован – 2008-10-15 18:55:25

0

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

  1. Прежде всего, прочитайте о serializing objects. Когда вы загружаете ресурс из файла (графический, звуковой или любой другой), он сохраняется в экземпляре объекта в памяти. Игра обычно использует десятки графических и звуковых объектов. Вам нужно сделать инструмент, который загружает их все и сохраняет их в коллекциях в памяти. Затем сериализуйте эти коллекции в двоичный файл, и у вас есть каждый ресурс.

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

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

  4. В игре вы должны загрузить зашифрованный двоичный файл и распаковать его. Затем расшифруйте его. Затем десериализуйте коллекции объектов, и у вас есть все ресурсы в памяти.

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

+1

MD5 не является алгоритмом шифрования. Прочтите страницу википедии, с которой вы связались. Кроме того, вы должны всегда сжимать ПЕРЕД шифрованием, а не после. В общем, зашифрованные данные не сжимаются. – davr 2008-10-15 19:27:34

3

Существует много способов сделать это. m_pGladiator имеет несколько хороших идей, особенно с серализацией. Я хотел бы сделать несколько других комментариев.

Во-первых, если вы собираетесь упаковать кучу ресурсов в один файл (я называю эти файлы packfiles), то я думаю, что вы должны работать, чтобы не загружать весь файл, а затем изолировать его из памяти. Простая причина в том, что это больше памяти. Это действительно не проблема на ПК, я думаю, но это хорошая практика, и это важно при работе на консоли. Пока мы не сериализуем объекты (в настоящее время), как предположил m_pGladiator, мы движемся к этому.

Существует два типа пакетов, которые у вас могут быть. Один из них - это файл, в котором вы хотите получить произвольный доступ к содержимому файлов. Второй тип может представлять собой набор файлов, где вам нужно все этих файлов при загрузке уровня. Основным примером может быть:

  1. Пакет аудиофайлов может содержать все аудио для вашей игры. Вам может потребоваться только загрузить определенные типы аудио для меню или экранов интерфейса и различных наборов аудио для уровней. Это может упасть в первой категории выше.
  2. Тип, который относится ко второй категории, может быть все модели/текстуры/и т. Д. Для уровня. Вы в основном хотите загрузить все содержимое этого файла в игру во время загрузки, потому что вам (вероятно) понадобится все его содержимое, пока игрок играет на этом уровне или секции.

Многие упаковочные файлы, которые мы строим, относятся ко второй категории. Мы в основном упаковываем содержимое уровня, а затем сжимаем их чем-то вроде zlib. Когда мы загружаем один из них во время игры, мы читаем небольшую часть файла, распаковываем то, что мы читаем в буфер памяти, а затем повторяем, пока полный файл не будет считан в память. Буфер, который мы читаем, относительно невелик, а буфер конечного назначения достаточно велик, чтобы содержать самый большой набор несжатых данных, которые нам нужны. Этот метод сложный, но опять же, он экономит оперативную память, это интересное упражнение для работы, и вы чувствуете себя хорошо и тепло внутри, потому что вы являетесь хорошим распорядителем системных ресурсов. после того, как пакетный файл был полностью несжатым в его суффиксный буфер, мы запускаем последний проход в буфере, чтобы исправить места указателя и т. д. Этот метод работает только тогда, когда вы выписываете свой пакетный файл как структуры, которые игра знает. Другими словами, наши инструменты для написания папок совместно используют структуру (или классифицирует) код игры. Мы в основном пишем и сжимаем точные представления структур данных.

Если вы просто хотите сократить количество файлов, которые вы отправляете и устанавливаете на компьютере пользователя, вы можете сделать что-то вроде первого типа пакетного файла, который я описываю. Возможно, у вас есть 1000 текстур, и просто хотелось бы сократить огромное количество файлов, которые вам нужно застегнуть и упаковать. Вы можете написать небольшую утилиту, которая будет в основном читать файлы, которые вы хотите упаковать вместе, а затем записать заголовок, содержащий файлы и их смещения в файле packfile, а затем вы можете записать содержимое файла по одному за раз, после другого, в вашем большом двоичном файле. Во время игры вы можете просто загрузить заголовок этого пакетного файла и сохранить имена файлов и смещения в хэше. Когда вам нужно прочитать файл, вы можете хэшировать имя файла и посмотреть, существует ли он в вашем пакетном файле, и если это так, вы можете прочитать содержимое непосредственно из файла packfile, обратившись к смещению, а затем прочитав из этого места в файле packfile.Опять же, этот метод в основном способ собирать данные вместе без учета шифрования и т. Д. Это просто организационный метод.

Но опять же, я хочу подчеркнуть, что если вы идете по маршруту, как я или m_pGladiator, я бы усердно трудился, чтобы не вытащить весь файл в ОЗУ и затем десериализоваться в другое место в ОЗУ. Это пустая трата ресурсов (у вас, возможно, много). Я бы сказал, что вы можете сделать это, чтобы заставить его работать, а затем, когда он работает, вы можете работать над методом, который читает только часть файла за раз, а затем распаковывается в ваш целевой буфер. Вы должны использовать схему включения, которая будет работать так, как это. zlib и lzw оба делают (я верю). Я не уверен в алгоритме MD5.

Надеюсь, что это поможет.

Смежные вопросы