The relationship between modules is not necessarily based on file structure, more so an object-oriented one.
http://docs.python.org/3.3/tutorial/modules.html
For example, given a ‘sound’ module with this structure:
sound/ Top-level package
__init__.py Initialize the sound package
formats/ Subpackage for file format conversions
__init__.py
wavread.py
wavwrite.py
aiffread.py
aiffwrite.py
auread.py
auwrite.py
...
effects/ Subpackage for sound effects
__init__.py
echo.py
surround.py
reverse.py
...
filters/ Subpackage for filters
__init__.py
equalizer.py
vocoder.py
karaoke.py
...
First off, folders containing init.py are considered modules by Python. This allows it to distinguish which folders are modules.
When you do ‘import sound’, this executes init.py in the sound directory. Generally, init.py will import more modules in the current directory or sys.path (see later), and thus execute the init.py in each of the respective directories (formats, effects, filters). These modules are imported into the name space of whomever called it, in this case ‘sound’. They are then accessed with the dot operator. So notice the relationship.
Now init.py could be setup so that after importing sound, you’d access submodules like ‘sound.filters.equalizer.*’.
However, init.py could also could import everything from the filters folder into the namespace of ‘sound’, and you’d access it like ‘sound.equalizer.*’. And of course, this does not correlate with the file structure.
The init.py in filters could import stuff from the effects subfolder, and so on.
About sys.path:
When you import scripts, Python looks for the existence of that module in any of the directories specified in sys.path. By default, the directory of the initial blend file that the BGE is started with is added to sys.path. This directory you can get by using bge.logic.expandPath(’//’).