rres: a simple self-contained format for packaging game assets

One header, then resources one after another

rres is a simple and easy-to-use file-format to package resources, designed to package game assets, images, fonts, text, audio and models, into a simple self-contained comprehensive format that is easy to read and write and designed to load data in a fast and efficient way. The simplicity is stated as a design goal and the structure is spelled out: one file header and multiple resources one after the other. Every resource still carries a small resource info header of 32 bytes with multiple options available, which is the compromise the format makes, that the layout stays flat and predictable while a resource can still declare what it is and how it is stored. The design is inspired by four existing formats, XNB as used by XNA and MonoGame, RIFF, PNG and ZIP, and each of those contributes something recognizable. The specification names its own structures, with a file header called rresFileHeader, a resource chunk called rresResourceChunk, and within that a resource chunk info structure, a resource chunk data structure and a resource data type enumeration. There is also a central directory chunk, rresCentralDir, which is the index that lets a loader find a resource by its id without scanning the file.

Seven design goals, and the two that need reading twice

The design goals section lists the properties the format is trying to have, and two of them are worth more attention than the rest. The first is ease-of-use, described as an rres library to read .rres files that is small with only the minimum required functions to read resource data from its id, using only a small set of functions from the standard C library, plus an rrespacker tool with GUI and CLI to easily create and view .rres files. A format whose reader needs a handful of standard library calls is a format you can implement in a week, and that is the difference between an open specification and an aspirational one. The second is security, and the wording is careful. The format supports per-resource compression and encryption if required, but despite the support provided by the file format it is up to the user to implement it in the rrespacker tool and the engine mapping library, and rres does not force any specific compression or encryption algorithm by design. So the format gives you the extension points and refuses to pick your algorithm for you, which is a defensible position for a format and a trap for anyone who assumes that because a format mentions encryption, the files are encrypted. The other goals are flexibility, where any input file can be packed and unclassified data becomes raw file data, portability, since the format is not tied to a specific engine and the base library just reads the resource data as packed, and extensibility for new data types and custom data. The portability claim comes with an example, the auxiliary library rres-raylib.h that maps rres data to raylib structures.

The reasons to pack assets are operational, not aesthetic

The usage benefits section gives four reasons to put assets into a format like this, and all of them are about deployment rather than tidiness. Organization avoids thousands of files distributed in hundreds of directories in the final game build, with all the game data organized into a single or a few .rres files, which keeps the game directory clean and well structured. Performance is about file handles, which the README calls an OS resource, with the cost of opening a file not insignificant and a potential to cause delays in the game, and reducing the number of handles needed for a level also improves data access times inside the container. Security here means not exposing all the game assets directly to the user for easy copy or modification, with data packed into a .rres file being more difficult to extract and modify for most users, which the README frames as protecting copyrighted assets, plus the per-resource compression and encryption as an extra level when required. Downloading times is the fourth, since if data needs to be accessed from a server and downloaded, packing into one or a few files improves download times compared with fetching each file individually. The security argument deserves a note of caution, because obfuscation is not protection against anyone who will actually try, and the README's own wording, more difficult for most users, is honest about the limits.

Four redesigns, and the design documents in the tree

The design history is unusually candid and explains why the format looks the way it does. The project has been in development since 2014, started with the aim of creating a packaging file format similar to XNB for raylib, and in the last eight years it has suffered multiple redesigns and improvements along a file-format learning process, during which the author implemented loaders and writers for more than twenty different file formats and created more than twelve custom file formats for raylibtech custom tools. The format went through at least four big redesigns, and the first two are instructive. The first design was limited to packaging one resource after another, with a resource info header followed by a fixed set of four possible parameters, and along the file a generated .h header file mapped the rresId to a resource filename. It was simple and intuitive, but it did not consider complex pieces of data that could require multiple chunks, and there was no way to extract the original source files. The second design tried to fix that by letting every resource include multiple chunks of data in a tree structure, which made it similar to RIFF, where a chunk could contain further chunks, each with its own header and data. It added resource options but became quite complex to understand and manage, and the testing implementation was eventually discarded. The third design returned to simplicity while keeping some of the options, solving the multiple-resources-from-one-file problem with a simple offset field in the resource info header pointing to the next linked resource, and adding the optional central directory chunk to keep references for the input files. The repository tree reflects this documentation habit, with a design/ directory holding the format documents and an examples/ directory containing a worked .rres file, an .rrp file, a resources/ folder and a set of C examples.

Reading and writing the format, in C

The examples directory is where the format becomes concrete, and the file names show the two halves of any asset pipeline, creating and loading. On the writing side there is rres_create_file.c and rres_chunk_info.c, and on the reading side rres_data_loading.c and rres_load_image.c, which is the example of mapping a stored resource onto a raylib texture. There is also examples/resources.rres, a ready-made file to read, and examples/resources.rrp, which is the packer project file, plus an unpacked resources/ folder that presumably contains the same data in its original form so you can compare. The chunk info example is the one to read first, because the resource info header is the part of the format every reader has to understand, and understanding it means knowing which of the options are set and what the offset field points at. The load image example is the one to read second, because it is the smallest complete case of taking a resource id, finding it and mapping it onto an engine structure, which is exactly the portability claim made in the design goals. The projects/ directory at the top level presumably holds the packer tool and the mapping libraries, and the src/ directory holds the base library that the design goals describe as small and using only a small set of standard C library functions.

The packer tool and where to get the spec

There is no install command in the README, because rres is delivered as a specification, a base library and a tool rather than as a package you fetch from a registry. The README points you at the rrespacker tool with GUI and CLI to easily create and view .rres files, and the repository is where you get the pieces, with the design/ directory holding the format documents, the src/ directory the base library, and the projects/ directory the tool and the mapping libraries such as rres-raylib.h. The examples/ directory is the fastest way to see the format working, since it contains a ready-made resources.rres file, a resources.rrp packer project file and an unpacked resources/ folder, so you can compare the packed and unpacked forms of the same data side by side. The library itself is documented in the README as small, with only the minimum required functions to read resource data from its id, and using only a small set of functions from the standard C library, which means you can build a loader without pulling in a dependency tree. The licence is MIT, and the project is presented as both an open spec and a learning material, with the README noting the format description can be used by anyone willing to create its own data packaging file format.

Where rres is the wrong tool

The first limit is that rres competes with a ZIP file, and for a lot of projects ZIP is enough. If you need one archive with per-file compression and a directory, a standard archive with an index gets you there with no format design work, and every toolchain can read it. What rres adds over that is the typed resource info header, the id-based lookup, and the fact that the format is a specification you can implement rather than a library you must call, and those only pay off if you are writing a loader for a specific engine. The second limit is the maintenance gap, and it is worth being blunt about it. The recent releases are 1.2.0 from 2023-04-15 and 1.0.0 from 2022-08-07, so the last tagged version is more than three years old, while the last push to the repository was on 2026-08-12, so the code is still being worked on and the tags are not tracking it. If you adopt a format, you adopt the version you pinned, and pinning to a tag from 2023 while the working tree moves on is how formats drift. The third is that the security story is a set of extension points rather than an implementation, so if your requirement is that the assets are actually protected against a determined user, rres does not solve it for you and the packing is obfuscation. The fourth is the audience. The repository topics list raylib, and the mapping example is for raylib, so while the format claims to be engine independent, the tested implementation and the author's tooling ecosystem are around one engine.

Editorial conclusion

Adopt rres if you ship a game with thousands of loose asset files and want them in one or a few archives with a format you can read, extend or implement yourself. Skip it if a ZIP archive already does the job for your build, since the gain is the header structure and the id-based lookup rather than compression. Verify first which release you are pinning, since the tags stop at 1.2.0 from 2023 even though the repository is still being worked on, and read the central directory and chunk layout in the design documents before you write your own loader.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. raysan5/rres on GitHub
4. README
5. Releases