spliting a server world over more than 1 PC
Author
Hi all,
I have been working on this for a bit and have been looking into using UDP to communicate data between the LAN of server computers. I was going to do something like this :
(Gate Keeper) - login/sends back correct IP/port of Server etc and possibly a login key. Broadcasts login key and user details to all computers on LAN
[Each game world]
(Chat Server) - deals with broadcasting chat to all in a chat room. Also keeps a copy of the game world, and player positions and if chat in game then sends to all who are close enough to hear the character. (also may as well work out and send if a character hears a specific sound mad by another player etc)
(World) - the "Fat Controller" of the world.. all requests goto this PC and it makes the decisions and forwards some requests to other parts eg. chat to chat server
(NPC controller) - decide what the NPCs are doing etc .. needs a copy of game map and player details. eg - searches to see if the NPC can see a player to attack.
The problem is how do i keep up to date records of the characters and world map stored on the (World) pc, on the other 2 parts of the [World] ???
I came up with one of 2 methods:
1) broadcast all updates from the (world) server to the other 2 using UDP for speed .. but it would need to have some method to garenty delivery.. and as i think about it need to be in order really to so old data doesnt over write new.. so I would really need TCP (which would make the whole thing slow right? too slow ?)
2) Store all character and Map data on a database which supports network connection where it can be updated and retrieved at will from all PCs.. but isnt this slow ?
wat i need to know is which is faster .. or a better way :-)
thanks
Tim
Hi Tim, (boy that''s wierd...)
You might want to rethink the arrangement of chat messaging. In some cases, you may desire to use proximity in determining which players will see a particular type of chat message. The proximity information should come from your main system that maintains "state" for world objects (players, NPCs, doors, elevators etc). Maintaining state on multiple server side systems isn''t a good idea for performance sake, not to mention the data integrity issues involved. You will want those CPU cycles for other things most likely.
I use a simple mechanism with a single Login/Chat server serving several "zone" servers. In chat mode, all of the clients messages are routed via the chat server. In game mode, chat messages are sent by the client to the appropriate server. I have a few types of "long range" chat options in my game, such as "global_tell" and "global_broadcast". Global chat messages are sent to the login/chat server and routed appropriately. Otherwise the chat message is a local "proximity" or "zone_only" message that gets sent to the zone server to deal with. The login/chat server doesn''t keep a copy of the "world". Doesn''t need to. It just keeps addresses of players, connection state, and authentication information. The zone servers maintain the state database for their specific part of the world.
My servers rarely send or recv packets between themselves. I use UDP for everything except for Updating the client program files and world data files. Once the player enters the game however, I use my own reliable UDP protocol. Also, all of my "server" programs can be run on a single hardware server if needed for testing. To do this I simply run in single zone mode instead of running all of the zones that make up the whole "world".
Oh, store persistent player data in a reliable database with backup capability. But at run time, keep the info in memory if possible. As far as the world state, you will likely want to write your own database, and not store state information in a disk-bound RDBMS at run-time. You might consider memory-mapped files for some types of information, although I''m not quite sure how well this works on windows.
Hope this information helps you in some way,
Tim
You might want to rethink the arrangement of chat messaging. In some cases, you may desire to use proximity in determining which players will see a particular type of chat message. The proximity information should come from your main system that maintains "state" for world objects (players, NPCs, doors, elevators etc). Maintaining state on multiple server side systems isn''t a good idea for performance sake, not to mention the data integrity issues involved. You will want those CPU cycles for other things most likely.
I use a simple mechanism with a single Login/Chat server serving several "zone" servers. In chat mode, all of the clients messages are routed via the chat server. In game mode, chat messages are sent by the client to the appropriate server. I have a few types of "long range" chat options in my game, such as "global_tell" and "global_broadcast". Global chat messages are sent to the login/chat server and routed appropriately. Otherwise the chat message is a local "proximity" or "zone_only" message that gets sent to the zone server to deal with. The login/chat server doesn''t keep a copy of the "world". Doesn''t need to. It just keeps addresses of players, connection state, and authentication information. The zone servers maintain the state database for their specific part of the world.
My servers rarely send or recv packets between themselves. I use UDP for everything except for Updating the client program files and world data files. Once the player enters the game however, I use my own reliable UDP protocol. Also, all of my "server" programs can be run on a single hardware server if needed for testing. To do this I simply run in single zone mode instead of running all of the zones that make up the whole "world".
Oh, store persistent player data in a reliable database with backup capability. But at run time, keep the info in memory if possible. As far as the world state, you will likely want to write your own database, and not store state information in a disk-bound RDBMS at run-time. You might consider memory-mapped files for some types of information, although I''m not quite sure how well this works on windows.
Hope this information helps you in some way,
Tim
Author
Ok thanks for the advice tim ;-) so..
do you think there should be zone computers .. all handling everything in their zone? like NPCs as well
thanks
... tim
do you think there should be zone computers .. all handling everything in their zone? like NPCs as well
thanks
... tim
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
