In our system we use something called a NPC client. This is a seperate application from the main server that logs in and is assigned a group of NPC's to control. This can be things like path wandering, and combat behaviours.

This way we can scale up the number of NPCs and their complexity by simply adding more npcclients. For example, a big mob may have one client by itself while 200 rats in a sewer can be all be handled by another one. The server and npcclient communicate over the network and the npcclient is notified of information it needs like who is attacking it, where items are, etc.

Quote:Original post by x_gamer_x
Interesting acraig, I hadn't thought of that.

Is your system being used in practice?
I'm curious on the ratio of NPCClients to NPCs you have. I would think a physical server given decent specs could handle a good amount of AI entity behaviors, unless very complex.

Yes, is being used in our PlaneShift project to control the NPCs. Right now we are only using the one npcclient to control all the npcs. There is around 150-200 NPCs ( this includes creatures like rats and the like ). It handles character wandering around and their combat 'brains'. At the moment CPU usage is very low.

Quote:
Also, how does this NPCClient interact with the main server?
I'm guessing it grinds out all the AI details and sends the results to the main server (ie given a current and target location, the main server recieves the "updated position" of the npc after the pathfinding routine is run).

Pretty much yes. The behaviours are scripted XML files that the npc client loads ( things like Wanderer script etc ). The NPCclients then figure out which of it's behaviours have priority for which mob and does the calculations and sends the results back to the server. The server makes sure the npcclient has updated data by sending it 'perceptions'. For example if a player attacks a rat the server will send an 'attack' perception to the npcclient responsible for that NPC. The npcclient will then deal with that perception, most likely will push the attack behaviour to the top of it's behaviour queue.

Quote:
Are there any major pros/cons to this system you've found?

The major pro is that we can offload some of the required CPU power off of the main server. Since we use donated hardware it makes it easier to make use of them. The con is that it will take up some of the bandwidth, so many npcclients make steal a lot of the network.

You can see our npcclient source code here

Quote:Original post by x_gamer_x
I would be curious if anyone has any information on the subject

Look in Game Programming Gems 4 (thousands of clients per server) if you can find a copy of the book.

Quote:
(both centralized and alternative topologies) they would be willing to share. I'm also looking for information on how it is possible to have multiple servers handle different elements of the game (IE having a seperate login server, chat server, etc.), though I suppose that wouldn't be too complicated to develop

Easy to develop, crap performance. Don't go there if you want thousands of players. Fine if you only have a small game (<3,000 players)

Quote:Original post by graveyard filla
just curious, but why is it crap performance to split up duties into individual servers?

Because if you split up the duties to a bunch of individual servers you introduce mass latency issues and you are killing your performance for basically no reason.