Hi, I'm planning to make a 2D game with SDL2 and I'm trying to keep some data like Collisions, Textures, etc. outside of the main executable so it can be easier to manage, make updates and make mods, I need some advice for the following topics, so I can make my game's loading faster and reading its content easier.

> Data which contains numbers and strings, such as Collisions, Animations, Constant Properties, etc
Currently I'm using txt format (pros: simple to use, no need for additional libraries, cons: is hard to understand, can be inefficient)
> Data which contains sprites and sounds and per-rendered cut scenes
Currently I'm using popular formats such as png, mp4, ogg (pros: easy to use, popular, supports everything I need, cons: there might be faster and better formats that I don't know about)
> A way to keep these files organized
Currently I'm keeping the files in the executable directory in a folder called “resources” (pros: easy to understand and handle, cons: there might be faster and better ways that I don't know about)

I'd be glad if you could suggest me replacement for the things that I mentioned above so it would be easier to manage, make updates for, mod and make the loading process faster

I use a combination of these tools, they are very helpful:

• Texture Packer Pro: https://www.codeandweb.com/texturepacker
• PhysicsEditor: https://www.codeandweb.com/physicseditor
• Tiled Map Editor: https://www.mapeditor.org/​

Texture Packer Pro can export to JSON and XML formats.

For my 2D platformer which uses SDL2, I am using the .png format for textures, WAV for sound effects, .mp3 for music (though this is still tentative), and XML files for data. I choose .png because it uses lossless compression (unlike .jpg) so your textures don't suffer in quality. WAV is also lossless but file size can be quite large.

Look into the XML format for storing data for your game. It may be what you're looking for. I personally use TinyXML2 to handle loading and saving of XML files.

The answer is to use whatever data format you like best, that fulfills your needs. Everything has their pros and cons. The question is if you want it to be human read-/editable or if you have some kind of editor and prefer more compact and faster loading.

The former can be achieved using text based formats like JSON or ini. Both have a long tradition in game development, especially when it comes to configuration. I'd avoid XML because its an old and complex data format which gets even worse when you start using schemas. We're using JSON or the even more simple ini format for just everything.

There are of course other data formats for texture and audio data but they're complex and may be difficult for you to use. PVRTC for example can be direcly decompressed on the hardware and there are of course very efficient formats for audio as well. But do you need them or is your game ok with taking a second longer to load everything?

Binary data formats can be more efficient but at the same time need an editor or converter tool so the question is if you want to spend time to write such a pipeline for encoding/decoding.

The best way to organize those files in production is to either use an archive file format or have a database along your game. Archives like BSA (used by Bethesda games) are pretty standard from the beginning while database based assembly organization is a thing which Unity introduced. We prefer the archive file format because you don't have the overhead of a database, so we created our own very plain format.

It is stored in chunks of 64k to fill an entire disk cache in order to block the OS from cross-loading files. The first chunk(s) are reserved for the header information, it is a virtual file system which can contain files and folders, has flags that specify the type of file and it's address in the archive. The address is compressed, providing the chunk ID and byte offset. Data is then appended to the header by an algorithm that tries to find the best order from our assets in which no asset is breaking between chunk borders, except it is too large to fill just only one chunk. This way we optimize OS page loading, because we're accessing the archive from within our game engine by memory mapped I/O.

Memory mapped I/O is a technique provided by all major operation systems and their derivates. The file isn't loading into the application memory but the OS is providing access in memory pages of 4k per page. When accessing an area not loaded yet, the OS is fetching it from disk and loads it into virtual memory, potentially unloading pages it doesn't need anymore. You get a convenient plain data pointer and don't have to do anything other than telling the OS what parts of the file you want to load