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.

Quote:Original post by I_Smell_Tuna
Where is the client getting the list of visible cells from?

Cells have a fixed size ( let's say 50 x 50 meters ), the client has the list of cells of all the world, servers too. Client just checks based on his view frustum the list of cells and pass it to the server, the server has the same list, server checks if it controls that cell, if not, it has to send the request to the server that controls it.
I have read the post you mentioned, i think the system i'm talking about could handle the crowded situations quite well. If a zone is crowded then the neighbour zone(zone=server) will start to control cells from the crowded zone until the network is balanced.

Quote:Original post by I_Smell_Tuna
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.

Yes it has to do some calculations, but it only has to check a few cells not check what cells are visible from the entire world. Don't you see it?
If the client does the visibility check and the server just sends the information requested it will be faster, of course, but it will allow cheating as said previously.

I have made three little drawings to understand it better.


In this drawing we see a world partitioned into cells, the black small squares are the cells, this world is 8x6 cells, in a real online world you will have thousands of cells.
The colored parts are zones, the cells in a zone are controlled by one single server, then each zone equals to one server. In the drawing are three zones/servers.
www.3dusers.com/basic.JPG

When a zone is crowded or lagged it sends a help request to the neighbour zones, and the crowded zone passes a few cells to the neighbours
www.3dusers.com/crowded.JPG


Now we see a client and his viewing frustrum.
He checks all the cells in the world and determines that cell 1,2,3 and red are visibles, then it sends "gimme all the stuff that is in cell 1,2,3,red" to the red server/zone because it is the one he currently is.
Red server checks that cell 1,2,3,red are really visible to the client, then it sends the red cell "stuff" to the client because it is the one it owns. For cells 1,2,3 the server sends a "send information in cell X to player X" to the apropiate server.
www.3dusers.com/player.JPG

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!

mmm well the client has to get the information of the currently visible cells, and draw the stuff that is going on. To determine the visible cells a frustum culling is done. Am i missing something ?

For the cheating problem i have come with the solution of determine the visibility of the cells in the client and then validate these cells in the server, so the server only needs to check a few cells against the client frustum.

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.

Yes, another problem is that i have not the budget of sony online entertainment and if i can tweak a few lines of code and make the server support a few more players without sacrifying scalability then better.
Sure SOE can put thousands of servers online.
If someday i put a world online I don't think i could get more than 2 servers online...

And well, that is what I am questioning from the first post, do you think it could be ( besides of implementation quality )scalable, efficient, etc...? Why/why not ?

On a side note I have readed that the reason why the big folks (soe and such) don't get more people in the clusters is for contents production problems.
If bigger quantities of players are in a cluster then worlds need to be bigger and bigger worlds mean more content so they just repeat the world with different clusters.
This is something I have readed but don't know if it's true.
Also, I dont want this thread goes off topic!

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.