Hi all, I have been looking for information about programming a client/server architecture for a mmog, but i have only found bits of information and nothing really concrete. After all this reading i have figured out a possible solution but I'm not really experienced about network programming and possible issues this implementation could suffer. So I ask about your opinion and constructive crits about this implementation, and a little explanation about why it wouldn't work is welcomed, not just 'it wont work sorry!' Here it is: The world is partitioned into squares that will be called 'cells'( original, isn't it? ), they won't be very big so i will need thousands to fill the world. An array of cells will be called 'Zone'( :) ). Each zone is controlled by a server. Cells can be passed to another server if it's needed to balance the network. In the client side we check wich cells are visible and a request of the information available in the visible cells is sent ( players, npcs, etc. ). Information from various servers at the same time will be required if the player is viewing cells from various servers. The client side will have the cell 'topology' so it can check the cell visibility itself but it won't know wich server owns this cell so i think a master server with information about what server owns each cell will be needed. I would really like to skip this master server but i cant figure how the client will know which server owns a specific cell, because cells can be passed from server to server, with some restrictions. Well it's long enough, I hope it's not the dumbest post in the forum story, as I said before I have never tried such a thing. I'm awaiting your comments, Thanks!

The client should not decide which cells are visible. The server should. This stops someone hacking your client and requesting info on the whole game world.

Other than that, you've got a pretty standard spatial partitioning zone model there.

I cover a lot of this in some of the threads I've posted on this forum. Your servers need to be aware of each other. Since they are usually colocated on a fast lan, intra server traffic is not too scary, providing not too much goes on at server boundaries. If you're not too experienced with the network programming, I'd advise working on a single zone principle at the moment, and use your framework for batching events. Later on, add the inter-server traffic.

IMO, its all about the scalablity of your architecture. You want to make it such that adding more servers to the world cluster will improve the performance... I dont think you can have a "massive" mog on a single-server.

You say that 'zones' are made up of several cells, then go on to say that cells can be passed to different servers. It would probably be best to pass the whole zone instead. I also second the scalability comment, you should design your back-end programming so that you can load your software on the computer, connect it to the network, and have it communicate with the other servers and not have to do anything more than that.

Well if your server is going to check to see if the cell is visible anyway why not just have the client send a request for visible cells then have the server reply with a list of visible cells.

Here is a thread with MMO cluster architecture ideas. http://www.gamedev.net/community/forums/topic.asp?topic_id=348831

Where is the client getting the list of visible cells from?

Quote:

Original post by Anonymous Poster The client has to determine what cells are visible between the thousands that exist in the game world( as i said it's optimized, not checking each single cell against the frustum ), then send the ID of the visible cells to the server, and the server only verifies the visibility of requested cells, no more. I think it's faster and doesn't allow cheating.

The verification part still requires the server to do the calculation. Also, that calculation is only a tini bit of CPU work, comared to everything else that happens.

While reading your thread I couldn't help to notice that you are talking about network traffic in combination with view frustum. It's important to note that none of the network traffic should rely on the view frustum. The client will need to know everything that is going on within the cell, not only what's on the screen. I agree with _winterdyne_, the server should handle all that, otherwise it would be way to easy to cheat and overload the server. Checking the player position server-side isn't a performance problem anyway.
Anyhow, good luck with your project!

Quote:

Original post by Anonymous Poster Quote: Original post by Steadtler IMO, its all about the scalablity of your architecture. You want to make it such that adding more servers to the world cluster will improve the performance... I dont think you can have a "massive" mog on a single-server. I agree that you can't have a massive game on a single server, but if one single server can handle 500 players instead of 300 then the network needed is much smaller and a big improvement.

Depends what is your primary concern. Lets say that, for a fixed users-servers performance, your main concern is the maximum number of players that can connect to the cluster without the connection dropping below that performance. Then, scalability becomes the main concern, almost the only concern. Even if each server can only support 30 players, if you have perfect scalability, you can support 10'000's of players by adding enough servers. I dont think its the cost of additionnal servers that prevent WoW or EQ2 clusters from supporting more than a few thbousand players. Its the scalability of their architecture.

Sorry I didnt want to go offtopic, but just to remind you to keep scalability in mind. Some views:

Quote:

Original post by adicted The world is partitioned into squares that will be called 'cells'( original, isn't it? ), they won't be very big so i will need thousands to fill the world.

What happens if a lot of your players decides to go in the same cell at the same time? If you cells are not very small, that will happen sooner than later. If your cells *are* very small, then it wont be performant because you will have too many cells. Its a classic problem I think. I see two solutions: Having cells of varying sizes (hard to manage!) or having copies of cells on multiple servers (RAID-like, less efficient).

Quote:

Original post by adicted so i think a master server with information about what server owns each cell will be needed. I would really like to skip this master server but i cant figure how the client will know which server owns a specific cell, because cells can be passed from server to server, with some restrictions.

Since this information is small, of fixed change and does not change a lot quickly, you can keep a copy of this information on every server.

Hope I am of help.