If you don’t care about hiding assets and making them harder to steal or modify, it doesn’t matter how you deliver them. I delivered some of my games in exactly this format: texture atlases and sounds were loose PNG and WAV files that could be previewed and modified. I didn’t want to hide them, and this made it easier to develop the game and mod it later.
However, you should care about loading assets into memory quickly, which is why creating large binary files containing asset collections is a very good idea—one commonly used in game development. You can also compress and encrypt assets to make data mining and asset theft difficult. But this is largely a futile effort, because if your game is valuable, sooner or later someone will break the security measures and create tools to extract and modify the assets.
If you have only a few assets, it doesn’t really matter how you store them, because they’ll load quickly anyway. However, if you have hundreds of megabytes or even a few gigabytes of assets, I advise against manipulating text files (JSON, XML, and the like), especially frequently at runtime, because parsing them is a waste of CPU time. Use the built-in tools or create your own to generate compact binary asset files, with O(1) access to specific assets via an offset dictionary (also stored in such a file). Also, try to limit the number of installation files so as not to overwhelm the file system—using thousands of tiny files isn't a good idea.
Recent
