Firstly, CThing?? Come one, surely you can think up a better name than that [smile]

This sort of setup will only be able to handle a *very* limited number of objects in your scene. By giving each individual CThing it's own (un)load distance you need to traverse every single CThing every single time your scene observer moves. A CThing should know nothing about when it should be (un)loaded, instead use a spatial partitioning scheme. The simplest approach here would be to split your scene into sectors, always ensuring that the sectors surrounding the current sector that the observer is in are loaded (assuming the observer cannot see further than a single sector).

A further benefit of this approach is that you don't have to know about all the CThings that are in each sector until the sector is loaded (an unloaded sector could contain 1 object or 1000, it wouldn't matter). With you're approach you need to know about every CThing in the scene, otherwise you'd never know when to load the object (since it stores it's own load distance).

Here's some pretty ASCII art:

/----------+----------+----------+----------+----------\ |          |          |          |          |          ||   0,0    |   0,1    |   0,2    |   0,3    |   0,4    || (unload) | (unload) | (unload) | (unload) | (unload) ||----------+----------+----------+----------+----------||          |          |          |          |          ||   1,0    |   1,1    |   1,2    |   1,3    |   1,4    || (unload) | (loaded) | (loaded) | (loaded) | (unload) ||----------+----------+----------+----------+----------||          |          |   HERE   |          |          ||   2,0    |   2,1    |   2,2    |   2,3    |   2,4    || (unload) | (loaded) | (loaded) | (loaded) | (unload) ||----------+----------+----------+----------+----------||          |          |          |          |          ||   3,0    |   3,1    |   3,2    |   3,3    |   3,4    || (unload) | (loaded) | (loaded) | (loaded) | (unload) ||----------+----------+----------+----------+----------||          |          |          |          |          ||   4,0    |   4,1    |   4,2    |   4,3    |   4,4    || (unload) | (unload) | (unload) | (unload) | (unload) |\----------+----------+----------+----------+----------/

If the observer is in sector (2,2), then sectors will be loaded an unloaded as above. If for example the observer was to move into sector (2,1) you would load sectors (1,0), (2,0) and (3,0) then unload (1,3), (2,3), (3,3). You can extend on this by delaying unloads (ie. don't unload sectors immediately in case the observer spins around and starts heading in the opposite direction just after crossing a sector boundary), only let each sector know about it's immediately surrounding sectors (which means you could have a virtually limitless number of sectors since even they don't all need to be known at runtime), and use non-regular sectors (eg. the artist could define the size/shape of sectors).

Better, it'll make a good starting point for you. I'll throw in a few things that you probably don't need to worry about at this stage (dive in too deep and you'll drown).

* You'll need to store some sort of state when unloading a sector (or scene as you've named it), which will then be restored when the sector is reloaded. If the observer returns to a sector everything should be where it was when it was unloaded (there are exceptions, for example it doesn't matter if that kicked over trash can mystically returns to where it was)

* Storing your objects in arrays may suffice for now, but you'll probably find further down the track that you need to maintain hierarchical relationships between objects (eg. an actor holding a torch) at which point start taking a look at scenegraphs.

* Using arrays will also become too prohibitive on performance (eg. collision detection would requiring testing against *everything*), you may choose to use your scenegraph for spatial partitioning within each sector , or use a different system (eg. octree) for maximum efficiency by keeping hierarchical relationships and locality in separate structures.