   MMORPG Object Loading
  I'm working on a little MMORPG project, I'm writing the world loader right now. The world loading I'm talking about are Trees, Rocks, Rivers, Buildings, Plants, Chairs, Tables, etc... (Things that will not move and are stuck there for good). I'm also breaking up the world into zones, The World objects in each zone are going to be described in an XML file much like this<Zone Heightmap = "Zone1.cfg" ZoneX = "0" ZoneY = "0"><ObjectList><Obj Model = "Tree.Mesh" X = "" Y = "" Z=""><Obj Model = "Rock.Mesh" ......><.....So on and so forth...></ObjectList></Zone>(Zone1.cfg is for Ogre to Read)Hopefully that will give me an easy way to create a new "Zone" For PPl to play in...But to the question, Each Zone Might Have a Massive Object list with maybe 100 different objects (Estimation I dont really know). But Should I load all the Objects in the game at start up? By Load I mean Find the file, read it in, and store it away until it shows up and is rendered... I don't know how many total objects that would be if I loaded them all on startup but it could mound up...   
  If you really do mean 100 objects, then yes, load them all. That's a tiny memory hit and it's much easier if a whole zone is in memory all at once. If you get 10,000 objects then maybe it's time to start thinking about an 'in-view cache' or something, or splitting the zones up. But if there are really only 100 objects then that's nothing.BTW, I know your XML is just pseudocode, but I'd definitely have your objects have a behavioural type (<obj model="Rock.mesh" type="rock" ...>) as well as just a mesh and position. That way if you decide that the player ought to be able to pick up rocks, or trees should wave gently in the wind, your game logic has some way of determining what type these 'static' objects are.   ;  Ooo good Idea with the behavioural state, And thankyou for your andswer too, in that case I'll load them all in and if you come in range it will place one on the spot its supposed to be on =)The server side XML Zone file has descriptions of where NPC's and Enemies should go under the <NPCList></NPCList> Each NPC can be give a movement type, Static - (dont move)Patrol - (You define "nodes" along a path and they move around those in a circle...)Wander - (Give it a center Point and a radius and they will wander around in that area)Just thought I'd share that too   ;  For objects you can do 2 things: Load ALL of them during game load up, or load them up when entering a zone. For instance:You logon to the world, and the zone you're in contains 5 different trees, 3 different rocks and 1 boat. During loading of the zone, you'll parse the file, and check if each object is already in memory, using some form of cache. When the object isn't loaded you, you shove the object into your cache, and voila. Perhaps you'll add a ref. count to it for smartness, but that's a different matter.Now, say you define that there are max. 500 objects loaded in the cache, and your cache is full, you'll remove the objects that aren't referenced too. You also might want to keep track of how often they're used, so you can delete the ones that arne't used a lot.Say this is your first zone you're entering, you load the boat, 3 rocks and 5 trees. When you leave the zone, you'll keep the objects in cache(To preven loading times on clients) and parse the new zone. This zone contains 2 boats(Same, previously used model), 8 different trees(4 previously used) and 1 rock(previously used). This now means, you only need to load 4 trees, instead of 1 boat, 8 trees and 1 rock. That's quite a difference.Server side it's a complete other story: You need to laod all the objects for all the zones in memory. However, you'll have much less information per object, since they don't have a model attached to it.Toolmaker   ;  You should look into asset/resource manager techniques, as Toolmaker has mentioned.Having things in RAM speeds things up immeasurably, especially if you are using similar base meshes (instancing). Cycling out unused exemplars is basically a resource culling task. Make use of available RAM by using budgetted managers (perhaps with a priority setting for some assets).Your descriptor for your zone looks ok to me, but you should consider what's on it as a 'load request' rather than a definitive 'load this now'. If something's already loaded, it should stay loaded. If it isn't loaded it should be loaded. If the budget line is hit you can unload unused assets. It might be an idea to produce a 'compiled' version of the descriptor, with integer references to a known asset manifest - this allows your descriptor to be thrown around faster, with the asset table only changing as you introduce more assets, and then it's an iterative change so descriptors that reference old versions of the table should still work. This also separates asset versioning from the descriptor, meaning that if you want to replace an asset you only need to redistribute a new asset file and then a very small delta (patch information) to the asset manifest. Ogre has a fairly nice resource manager class in it I seem to remember. If you don't mind tying your engine level code to the renderer then this might be an idea. Depends on what dependencies you want in your project.Also, remember that you shouldn't be loading client (textured, complex) rendering meshes on the server - all you need are collision hulls. These are MUCH smaller, which is good, because on the server you're loading everything that is visible for all active players in zones handled by that server.Your server side descriptor should be compressed and sent to the client so it loads required assets, but do NOT send positional information for critical objects (mostly mobs or other players) before such objects are visible to the player - this helps cut the usefulness of 'radar' helper apps, unless your spawn points are static.Hope this helps   