LauriM
commented
9 years ago Providing some personal research, this is how I did the filesystem abstraction in my own engine.
Reference https://github.com/LauriM/PhantomEngine/tree/master/src/engine/file (Also look into the engine/resource directory)
Lowlevel abstraction
Functionality to open files and write to them should be abstracted on low level, this is fairly simple.
Listing files in a directory is something thats not in the C++/C standard, so that has to be wrapped.
Low level abstraction in itself is fairly simple.
Filesystem abstraction
Filesystem should be abstracted by default. Many devices used can have multiple different media sources, so its important that you can mount different kind of filesystems, not just "one per platform".
Examples of Filesystems. (I call them Archives in my own engine)
- DirectoryArchive (Give a directory during construction, files are loaded from there)
- ZipArchive (Read files from a zip archive, writing is usually not permitted)
- AndroidAssetArchive (Use the Androids build in asset manager to read files from there)( Android doesn't have a filesystem you can directly use!)
And so on.
This way when the FileManager gets a request to open file, it goes trough all the archives it has and asks if they have a file. If the file is found, its returned to the user.
With this kind of abstraction, you get the ease of adding new archives, all the different systems will support them automatically. It also makes it possible to add a simple support for "patch"/"mod" files. User/developer can create a patchfile, thats loaded as an archive, that then overrides some assets from the original game files.
This kinda of system allows the engine to run even without a real filesystem! (Virtual filesystem)
Permissions
Write is rarely needed and on platforms like Android its not really even possible. (You need to use SD card and write to there)
For permissions its better just to handle them as an error. If the user doesn't have permissions on the asset files/something, its better just to stop running the engine instead of trying to handle the problem. No read permission == cannot read file.
So, catch the permission problem and log it/notify the user about it, no need to do anything special about it.
siquel
Subject requires researching before documenting the module can continue.