Game resource packaging is almost an essential function for online game clients. Web games and micro-terminals may not package resources or use small packets based on actual needs.
Resource packaging has the following advantages:
1. Speed up Client installation. Copying 3000 1 MB files takes much longer than copying 3G files.
2. The client is more clean and tidy. You can also "slightly" Avoid using game resources by others.
3. Avoid reading files that fail due to inconsistent file names on iOS and Android. Or the full platform is case-insensitive in the package.
4. Compress resources. If a large number of images such as PNG are not displayed, but if a large number of text and uncompress model resources exist, packaging can effectively reduce the number of clients.
Here we will introduce two open-source libraries, which can easily add the resource packaging function to the client.
1, stormlib (http://www.zezula.net/en/mpq/stormlib.html), this is Blizzard mpq packaging format open source implementation version. With this library, you can easily implement a packagemanager to load package resources.
2 zpack (http://multi-crash.com /? Page_id = 340) this is also an open source packaging format implementation. Compared with the above mpq, it is more streamlined, of course, the function is also weaker. However, some existing functions can fully meet my actual needs.
Main features:
- speed
- search by file name hash, Read efficiency is supreme
- When deleting files in a package, only the file index is deleted, no need to move data in the package
- during the two flush operations, you can add any number of files (for example, add the entire directory). In addition to the data written by the added files, no other redundant file I/O Operations
- size
- when adding a file, insert the file to the idle location left by the deleted file first, and use space as much as possible
- you can call countfragmentsize to check the number of idle space bytes in the current package, if necessary, you can call defrag to clear up the space.
- currently, data compression is not supported, however, you can easily add compression support
- Secure/robust
- Ensure the validity of the package file before the user calls flush. In this way, when a user adds or deletes a large number of files at a time, even if an accident occurs (such as a power failure or the process is forcibly terminated), the package file can maintain the logical structure after the last flush operation, no catastrophic consequences
- When the package file is opened in read-only mode, the original file name information is not loaded into the memory. That is to say, you can choose not to write the original directory structure and file name into the package, and the package file can still be read normally.
-
- Scalability/compatibility
- It is designed to ensure that the oldCodeCan still read New Data Structures
- When the data packet is different from the zpeditor version, zpeditor can still open the data packet in read-only mode.
- Tool
- although files in the package are organized in a flat manner (to ensure retrieval efficiency), zpack also provides the tool class zpexplorer, allows users to browse and edit package files in a tree directory
- provides command line tools, close to DoS usage habits
- provides an Editor similar to Windows Explorer
- Others
- The package file size is not limited to 4 GB.
- The core read module only relies on the C ++ standard library and can be easily transplanted to platforms other than windows, such as Linux, Mac, and iPhone.
- The code is small and concise, and no redundant interfaces are provided. Zpack CoreSource codeAround 20 K
A packaging module can be used as long as it can meet the following requirements:
1. Hash tile path to ensure sufficient search efficiency
2. Supports Compression
3. Safe and robust, and will not cause packet damage due to some operations
Finally, I felt that the open-source world is too rich. learning more about some open-source projects can save a lot of time to recreate.