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?
Sep 15 2003, 9:05 am