the file structure is the object

i'm very muching liking this concept of the objects in the game 'living' in the filesystem. for instance..

Code:

---------------------------------------------
file://robote/stupidcrap/lame.superlame

sillybox=object cli://gamebasis/code/Box()
{
};

sillycow=object cli://gamebasis/code/Cow()
{
MadEnabled=true;
};

so the fullpath of each object is..

file://robote/stupidcrap/lame.superlame/sillybox
and
file://robote/stupidcrap/lame.superlame/sillycow

gbscript was always doing it (to an extent), but i never took it to the next logical progression of making it a first class concept.

the filesystem is considered some magic object persistance land (as it really is). the object is always 'living', just not in memory for it to be useful. so JIT (haha) when you access any object 'living' in the path it will put the object into memory. it's a one way type of thing. you would not put the potentially modified object back into the filesystem (for a game at least). you need to do something else to store your state diff and especially to do it in a super fast fps style.. walk 2 steps, save, walk 2 steps, save, walk 2 step, crap then reload.. type of way.

anyway.. this is useful for tons and tons of things. i was surprised when i started specially putting the word 'object' on things that were meant to be an 'object'. in a duh type of way.. almost all content IS AN OBJECT. duh. duh. duh. instancing is a rarity. you typically don't need to construct 'new' things, you just want the things as they were. of course this is c++ brainwashing. the crazy smalltalk peoples already know this of course. i do think that you probably should have both concepts (i'm not sure cloning is always the answer), but i'm (stupidly) surprised that you probably have 'objects' 50 to 1 over an instance.