ID:153574
 
What tips or techniques does anyone have for constructing an architecture for maintaining an absolutely enormous wilderness of text-based rooms to be initialized and de-initialized as needed? I'm leaning towards a straight geometric grid for the map as a whole, with few predetermined areas or zones. Should I just chop up the map into grid sectors and initalize these as needed, causing an occasional heavy performance hit when a player crosses sector lines, or would it be more efficient to simply load up a player's immediate surroundings as they travel across the wilderness (they would not actually be traveling at any great speed, mind you)?

What would be an efficient method of keeping track of when the game is running out of resources and needs to deallocate some rooms? Should I just have rooms examine themselves and deallocate themselves when they've fallen out of current use, or would it be more effective to keep track of how many instances are in existence and then deallocate when that numbers gets too high? (On a related subject, what are the rules regarding the 65535 object limit? I keep forgetting them.) I imagine that in a game of this scope, an event loop would be an absolute necessity, so it would probably be prudent to have rooms that aren't be interacted with go into "sleep mode" to conserve resources, but there's also going to be enough stuff to make hitting the object limit a very real possibility if the server runs for too long, so at some point I am probably going to have to write the unused rooms to the save directory and delete them from memory. This creates a problem, however: I don't want inactive rooms or their contents running continuous procs from the event loop, but at the same time, I want the rooms to be able to examine themselves and tell when it's time to go poof. Should I code a portion of this functionality directly into the event loop, or would this potentially small bit of processing add up to too much?

For that matter, we're talking about a potentially very large number of objects. Given that BYOND's list handling is not perfectly effecient, would an event loop work at all or would it bog down too much? I'm already planning on having most or all objects have two versions of whatever lifecycle procs they have (or, to be more accurate, two paths of procedure calls), one for their regular lifecycle (controlled by the event loop) and another for playing "catch-up" when an item is re-initialized after a long period of "down time"; for example, if you leave a chunk of raw meat in the middle of nowhere and then wander off, and no one comes by that part of the woods for a couple days, when a player re-enters the area it will load the meat and then process a couple weeks' worth of lifecycle stuff (it won't actually loop through it as many times as lifecycle ticks there are in 48 hours; it would simply fast-forward to any major events, which in this case would be the meat spoiling). Should I keep only the most recently active and dynamic objects as part of the event loop, and have everything else play catch-up when needed and stay out of the event loop entirely?
I'm going to take a guess and say that occasional I/O is better than lots of I/O. Disk access is relatively slow. Accessing the disk more times could possibly mean more chances for errors as well. (Read: I'm repeating Comp. Sci. philosophy based on older equipment.) If you know that you are not going to have an incredibly large number of players spread across an incredibly large number of sectors, it may be best to load by sector.

For room deallocation, I'd keep track of candidates (longest dead, will be dead in the future, etc.) constantly and then grab the "best" however many whenever I wanted. At roughly 8:00AM with no sleep, I admit I don't have an exact method to share, but I imagine it can be done with small, constant inserts. I'd rather be able to deallocate at any time than wait for an emergency.

I like the idea of separating things so they are not updated every time through the event loop. However, it may be easier to create a loop object which only updates every umpteen event loops, shove it into the main event loop, and then use it to store objects which are not updated as much. That way, those objects don't take up time every event loop and you don't have to keep track of simultaneous actions. You can also increase/decrease the number of updates required for the loop object rather than each separate room.

As for the 65535 limit, I think every object (including text) obeys except for turfs loaded from the map. If some of your rooms are not dynamic enough to require resaving, it might be easier to avoid the limit by using those turfs... I'm not sure how text fields on turfs loaded from the map deal with the limit though.

...I'm not sure how much I answered. Me sleepy. Bye. *clunk*
In response to ACWraith
ACWraith wrote:
I like the idea of separating things so they are not updated every time through the event loop. However, it may be easier to create a loop object which only updates every umpteen event loops, shove it into the main event loop, and then use it to store objects which are not updated as much. That way, those objects don't take up time every event loop and you don't have to keep track of simultaneous actions. You can also increase/decrease the number of updates required for the loop object rather than each separate room.

Hmm. That's certainly a thought, but for less dynamic objects (such as, say, trees) I was thinking more along the lines of "once every 24 hours realtime".

As for the 65535 limit, I think every object (including text) obeys except for turfs loaded from the map. If some of your rooms are not dynamic enough to require resaving, it might be easier to avoid the limit by using those turfs... I'm not sure how text fields on turfs loaded from the map deal with the limit though.

That helps some, but the main thing that I can never remember is whether the 65535 limit is for all non-turfs, if it's for broader categories (atom/movables get 65535, datums get 65535), or whether each base type gets its own limit.

(EDIT: I did some forum searching and Shadowdarke sez mobs and objs get 65535 each. So if it doesn't work I'll blame him).