Re: [Nel] Dynamic load balancing?

[Vincent Archer]

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: address@hidden

Nevrax France.                              Off on the yellow brick road we go!