Right. What she said.
As Radnen said, my idea of the libraries folder is to be able to ship it. My own game engine will ship with a single game in a complete package. I won't ship multiple games in an engine so I don't have such thing as common/. @Neo, when you said common/, I thought you meant the same thing as my libraries/, but with another name.
The use of SCM with a common/ folder is very troublesome, as it breaks everything.
To elaborate on my Load idea:
My load functions, actually any function dealing with resolving of paths, is using a resource path resolver. It always uses the same order of files. (This is not set in stone yet).
Example, loading a font, LoadFont('myFont') / new Font('myFont') (note the missing extension, because it is not needed for fonts).
- Look in the game/fonts/ folder
- Look in the libraries/*/fonts/ folder
- Look in the ./ folder (relative to the file)
- Look in the system/fonts folder
[li]
[/li][/list]
(I will have to figure out what the best order is: maybe like DLLs, local overwriting system, thus ./ as first...)
Now it is a bit more complex than that: when a library loads a file, it will first look in the own library folder, then in other libraries, and not using the game folder.
This can of course be implemented by any engine.
I had the idea of remapping ~/ and / too, because I want the file system of the game to be sandboxed. It is so easy to screw things up with the file api. I probably need to have a pointer to the User's library folder (on mac) to store game data like savegames, because an application can't just write in its own folder (IIRC). Mapping / to the game and ~/ to the User Application Data is usable i think (~/ is normally /home/USER, and / is the system. The idea fits.)
As a sidenote: in my resource path resolver, when prefixing with ~/ or /, the path is 'absolute'.
I hope this helps.
// Rahkiin