[Nel] Dynamic load balancing?

Tue, 20 Feb 2001 14:35:01 +0100

According to Nahuel Greco:
+> You will use standard CORBA?, wich orb?
+
+Not CORBA. As I said, 'a kind of ORB approach'. Not a straight lift
+from existing solutions, who are nice from a development point of view,
+but whose features are too generic and too heavy for optimisation.
+
+> What are the "functional" parts that you will be planning? 
+
+I don't have the exact split, which is deeply tied into game design,
+but you'll have chiefly:
+- access services (who translate between client protocol and service
+  requests)
+- PC manager services
+- combat services
+- item services
+- databaser service (only one)
+- pathfinding services
+- bots service (AI)
+- magic services (maybe, I'm not 100% sure if these aren't managed by the
+  other services as exceptions to their rules)
+
+then some geographic-based services
+
+- ecology managers
+- state tracking (the true geography service. That one knows where mobs,
+  ground items, and PC are relative to each other... but that's about
+  all it does)
+
+and a few others, I think, who are related to higher-level game dynamics.
+
+I might be off, there's still questions on which service handle which
+agent for some cases.
+
+> How do you plan to send the map to the user, i mean, if you divide the game
+> in areas, you can say the client to download the map for an area before
+> enter, but if you dont use the area-divided approach, then, you must send
+> the sorrounding terraing at each step that the client do?
+
+We use a 'mainly static terrain' approach. I.E. the client already has the
+various maps parts on-line. We only send gross modifications (i.e. replace
+this map part with that pre-patched one, so the rope bridge across the chasm
+is no longer there) and local items information (some trees have grown
+while you were away).
+
+Sending the map on the fly requires substantial sacrifices in term of map
+complexity (see Asheron's Call for a good example for this).
+
+> There is no risks of overloading the internal network / get out of sync?
+
+The functional approach is made by looking at the communication between
+agents, and putting all agents that discuss with each other the most in
+the same services, to avoid network load. Note that agents do *not*
+migrate across the network, ever (i.e. a PC full state is always managed
+by a specific PC service, regardless of what the PC does or where he
+moves).
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+