Server design
Hi, I recently start to develop a MMORPG. It's time to design the server. I wish that people give me their experience about it. My questions are : 1) Server have to manage player, but most generally the world too. I wonder if the best way to do, it is to have two servers : one for player management, and to distribute informations, and another to gouvern the world? 3) I wonder how NPCs are managed by the server, and more precisely collision management? Must I write same code engine as the client ( with OGRE for example), to be sure that the mesh collision are right? Or must I dedicated this job to the client, which informs the server if there is a default in the path way provided? 3) Lot of information must be provided to players, I don't know rythm to refresh information to player. Thanks for help
Quote:
1) I wonder if the best way to do, it is to have two servers?
I know of some MMORPG's, like The Saga of Ryzom, they have dedicated server binaries for all kinds of subtasks, like NPCs, weather, etc. That way, a crash of a server won't bring down your whole shard.
Have a look at the framework they use.
Quote:
2) Must I write same code engine as the client ( with OGRE for example), to be sure that the mesh collision are right?
Your client will be doing mesh collision calculations a lot more often than your server. Have the client do collision detection often (i.e. normally), then let the server check collisions only once in a while.
Ive linked this post to ogre forum...
There is answer here and there... interesting ....
http://www.ogre3d.org/phpBB2/viewtopic.php?t=13140&highlight=
There is answer here and there... interesting ....
http://www.ogre3d.org/phpBB2/viewtopic.php?t=13140&highlight=
It depends on what game you are creating. If you are wondering how collisions are done, then go take a look at WoW and/or Lineage2. Characters even don't get checked for collisions between themselves. May be I'm wrong, but as it seems to me, both of these games servers are based on a conception that "up is always up", that means, everything is going on a 2d map that can be represented by cells. Cells, in turn, can be walkable/unwalkable. Therefore, the server is not required to produce precise calculations. It will eliminate cheating by checking how players are walking from one cell to another.
In our game there are no distinctions between NPC and PC, you even can log in and play for NPC. The key, I think, is to separate game world from network i/o pipeline. This is the first step. After that, you will be free to design laws for your world. I would use task patterns linked in hierarchy chains and queues for anything that must (or wants) to be updated.
In our game there are no distinctions between NPC and PC, you even can log in and play for NPC. The key, I think, is to separate game world from network i/o pipeline. This is the first step. After that, you will be free to design laws for your world. I would use task patterns linked in hierarchy chains and queues for anything that must (or wants) to be updated.
Collision detection on the server should be as crude and fast as you can make it.
Don't use the same meshes on the server as the client. Server meshes can just be bounding boxes for most objects.
Don't render on the server, don't use VS or PS.
Use software for transformation, since if you're aiming at a rack server it's not going to have a HW TnL card in it.
Best to go back to basics and rope in a decent software 3d lib - use some of the ogre classes, they are a great starting point. ODE can be stripped to determine collision detection etc. The trouble with these libraries is they tend to be client-focussed, which can make them unwieldy when developing a server, both in terms of the size of the DLL / SO they produce and their demand for processor time.
The number of servers is not as important as how you handle traffic - by traffic I mean flow of information. There's no need to tell the whole world about something if it's happening in a locked room at the bottom of a dungeon.
In fact, to do so is a serious risk to your game- an exploiter WILL get at any unrequired information you send to them - your clients should be dumb, and stay dumb.
Detailed collision detection or physics can be done on the client (rag dolls) but any end state must be verified by the server (position of a body, not necessarily posture). Coarse (walls etc.) collision detection should be done on the server and forced on the client.
Frequency of updates to the client should be kept to a minimum (is here,starts walking in direction from point, stops walking, is here) rather than being updated of everything (is here, is here, is here, is here, is here).
Hope this gives you something to think about.
Don't use the same meshes on the server as the client. Server meshes can just be bounding boxes for most objects.
Don't render on the server, don't use VS or PS.
Use software for transformation, since if you're aiming at a rack server it's not going to have a HW TnL card in it.
Best to go back to basics and rope in a decent software 3d lib - use some of the ogre classes, they are a great starting point. ODE can be stripped to determine collision detection etc. The trouble with these libraries is they tend to be client-focussed, which can make them unwieldy when developing a server, both in terms of the size of the DLL / SO they produce and their demand for processor time.
The number of servers is not as important as how you handle traffic - by traffic I mean flow of information. There's no need to tell the whole world about something if it's happening in a locked room at the bottom of a dungeon.
In fact, to do so is a serious risk to your game- an exploiter WILL get at any unrequired information you send to them - your clients should be dumb, and stay dumb.
Detailed collision detection or physics can be done on the client (rag dolls) but any end state must be verified by the server (position of a body, not necessarily posture). Coarse (walls etc.) collision detection should be done on the server and forced on the client.
Frequency of updates to the client should be kept to a minimum (is here,starts walking in direction from point, stops walking, is here) rather than being updated of everything (is here, is here, is here, is here, is here).
Hope this gives you something to think about.
Winterdyne Solutions Ltd is recruiting - this thread for details!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement