Re: [Nel] Dynamic load balancing?

[Nahuel Greco]

On Tue, 20 Feb 2001 14:35:01 +0100
Vincent Archer <address@hidden> wrote:

> 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

I must switch to combat mode in the game?, i mean, when i combat, the scenary
and the gameplay changes, like in the PSX rpg games?

> - 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)
> 

If the bots service want to pathfind to some location, they must ask to the
pathfinding service?, and the pathfinding service must ask to the "state
tracking" ?, suposse that i have a bot script, running in the bot service, 
in some routine i must see if i can walk to some location, on the nort, on the
 south, etc, to decide later where i will walk.. then.. each bot script 
get_is_reachable() function will trigger a query to another service, and must 
wait the response of that service  to continue the code execution.

for thousands of scripts, that will be too slow, without thinking in the
"wait, is your query is in the queque" issue.


and btw, what scripting language do you plan to use for the code that will
execute in thousand of instances..?



> then some geographic-based services
> 
> - ecology managers

That will instantiate, for example.. more gold to keep the economy ok ?


> - 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!
> _______________________________________________
> Nel mailing list
> address@hidden
> http://www.nevrax.org/mailman/listinfo.cgi/nel
> 


----------------------------------------------------------
Nahuel Greco                 Web Development - Open Source
http://www.codelarvs.com.ar  Game Programming - Research
Freelance coding / sysadmin  Networking. The answer is 42.
----------------------------------------------------------