Jump to content
  • Advertisement
Sign in to follow this  
x_gamer_x

Client-Server (Centralized) Topology for an MMO

This topic is 4935 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently researching the viability of a centralized server networking model for an MMO, and looking into possible alternatives. I've found one article on GDNet: Distributed Gaming I would be curious if anyone has any information on the subject (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 by simply sending specific messages to different servers who all have access to the same database. Anyway, if you've got any links or info you think would be helpful to my research, I'd greatly apreciate it. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

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

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

Thanks for the reply.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Thanks again for the quick response, and wow, I wasn't expecting to see source code :). Rating++.

I don't have time to go over it right now, but I definetly plan to in the future.

If anyone else has information on the suject, I'm still looking ;).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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)

Share this post


Link to post
Share on other sites
just curious, but why is it crap performance to split up duties into individual servers? i had always assumed this is how commercial games did it.. if not, how can it scale to handle many players?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
so, how does it work then? some sort of system where all machines share the same set of jobs? then scaling is just a matter of adding more machines? even then, the commucation between the servers is nessasary i would think...

Share this post


Link to post
Share on other sites
Quote:
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


If you do a poor job of factoring your servers, that's certainly true.

If you carefully design and implement a split-server system, you can build a system that scales linearly by just adding hardware, basically until you hit some unforeseen n-squared communications bottleneck (guild chat, anyone?) or run out of network backplane bandwidth (unlikely with current big iron hardware available).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!