Hi I have some technical issues and ideas which I try to discover. It is about the server side programming in games which are a kind of mmo.
For the beginning the word-state is held by a central server-system. Lets say I have a large terrain which is divided into 4 areas. Each area is running on a separate server. So the player is transferred to the right area when he crosses a virtual boarder in an area. So in some situations (player is near a boarder) the player object exists in two or more areas at the same time, but only one of them is sending data to the client. The object of the are in which the player actually stay is active all the others will be updated but they are sleeping, so a fast switch on crossing the boarder is possible. After crossing the boarder and after a defined distance to it, the objects of the other areas will be removed. I created a figure to explain the above:
So my question is now, where should the terrain be stored? If the terrain is static I could store it in the client. so the client can stream the terrain for rendering locally. So the terrain could be divided locally into quads for more performance, but the informations will still come and actions will be checked by the associated area server. Which means less network traffic caused by terrain data and the traffic is focused on transferring dynamical objects and game relevant informations. Which includes other players, animals and checking date like next player movement, collision detection for a hit (e.g. shooting) or interactions. So when the server has the job to check if the next step or action of the player is possible (legal) or illegal I have to render on each area server the whole area to check that actions? Or how is it realized on the server to check actions, especially movement and collision actions of different players at each situation? So each player is represented by a thread and interacts with the client. So each action could be handled individually for each player object. The transferred to a other area-servers shouldn’t be the problem.
maybe someone can help me and give me some hints
Hi, has no one any idea?
Different options:
Hide portals, like a ship that brings you over a river that is te border transfer while playing a nice sailing animation. (Or jumpgates, or magical portals, or lifts) This is the simple solution, then you don#t need checks at the borders at all.
Other option would be to have each physic model larger than the actual zone is, so a few meters are overlapping., and do the chek for the enxt are athat way.
It really depends, you could also do the physic clientside and just check from time to time if the players are in a valid position(in a background thread looping through all players, checking one at a time).
I’d say your green areas should overlap (e.g. they are computed on both servers) so that you can account for other objects from both servers. So your ship moves from the center of one quadrant to the green border where its transferred to the other server incl. movement etc. Then it shortly is being computed on both servers so that collisions from both grey areas can work on the ship.
Hm that is a good hint with the overlapping areas. By overlapping boarders the switch between the area-server and the client is more smoothly.
So my other question was: I have to render the world on each area server to check the collision with the environment (other players, objects and terrain), the only difference will be, that there is no visual output?
WEll you dont really need to rener it, you could even have the server not using jme at all. (Makes live easyer tho if you use it serverside)
The thing with overlapping is that, as you’ll get to a corner, instead of having 2 servers following a client, you might end up with 4. So you’ll have to make sure the “right” one gets to be the second server. Maybe using the character’s direction as a “most likely where the client will end up” hint.
@EmpirePhoenix
If you don’t do it on server-side you have to do it on client side. So you have to trust the client, but trusting a client is hmm …
But you are right life would be easier with this solution. But if I would do all the checks on server-side, I have to render the area on server-side right? The Server knows the position of each player, but it is impossible to say if there is any barrier between two players (so it is impossible to say yes you two can interact with each other).
Another way for a position-check would be: Each time the client is ending the position to the server, the server takes the old position an calculates with the max speed of the player a radius for a next possible position. If the player is in it it’s ok, if not a correction will be done.
@madjack
Yes something like a direction forecast would be better. But theoretically you have prepared the player on both areas for waking them up. So you have to sync two areas player-object / player-thread with the current active areas player. So you need in the overlapping area maybe a another boarder for checking which area would be the best.
Servers do not render anything. Imagine having 20 clients connected to a server… It can’t render 20 screens. That’s unthinkable. But, although servers don’t render, they have an internal representation of the world. They know where everything is and should be aware of barriers or whatnot. Servers send information to the clients like world geometry, entities, locations, etc, so they are aware of the world’s state.
risor said:
@madjack
But theoretically you have prepared the player on both areas for waking them up.
What do you mean by that? The state of the servers should be invisible to the players (maybe you meant the "player's representation inside the server?). As such,
So you have to sync two areas player-object / player-thread with the current active areas player. So you need in the overlapping area maybe a another border for checking which area would be the best.
Prediction is just that. Prediction. You could have a "watcher" thread that would survey players placement in the world and notify relevant threads in other servers.
I really hope your game won't have that many "sectors" because that would mean a lot of servers, and game servers don't come cheap. Why not go with instances?
madjack said:
Servers do not render anything. Imagine having 20 clients connected to a server... It can't render 20 screens. That's unthinkable. But, although servers don't render, they have an internal representation of the world.
I meant the representation of the world. I thought the server renders / builds (from the perspective of an observer) the area one time and will check in it all player actions. That was my first thought, because I couldn't imagine how to represent the world on the server-side for easy checking.
madjack said:
What do you mean by that? The state of the servers should be invisible to the players (maybe you meant the "player's representation inside the server?). As such,
Yes I meant the representation of the player on the server.
madjack said:
I really hope your game won't have that many "sectors" because that would mean a lot of servers, and game servers don't come cheap. Why not go with instances?
For now I planed to get the background knowledge first. I will check if my thoughts to realise something like that are hitting in the right direction.
Last I checked, servers are pretty much the same thing as a client except that it doesn’t output anything to the screen.
Servers will:
Check for valid move and/or actions.
Send world information to clients.
Synchronize client’s state with it’s own internal representation of that player.
Synchronize players with other players (speed, location, actions, etc)
And many more things.
So you can actually look at servers the same way you look at a local client except the server takes care of several clients instead of one. Plus additional work.
Of course it’s more complicated than that. But it’s essentially how it works. At least to my knowledge. Feel free to improve on that though. 
Well my server has only few vectors and quaternions that represent the object positions, also it does physic ticks to calculate the physic, but nothing more than that are done serverside.
EmpirePhoenix said:
Well my server has only few vectors and quaternions that represent the object positions, also it does physic ticks to calculate the physic, but nothing more than that are done serverside.
That's your choice of implementation and that's fine, but I would consider that a risk. If you have several people playing on the same server, that opens the door to hacks and cheating if the server doesn't do proper checking.
As I say, that's your choice.
madjack said:
So you can actually look at servers the same way you look at a local client except the server takes care of several clients instead of one. Plus additional work.
Of course it's more complicated than that. But it's essentially how it works. At least to my knowledge. Feel free to improve on that though. ;)
(simplified) My idea was to run for each client a thread on the server. This thread is holding the data of the player and checks and realises interactions with the environment and other players. So a client will send a request to the server (the assigned thread), the server checks and realises the action and sends the updated data to the player. So some sort of cheating and hacking is prevented. But to check this requests I thought building the world without visual output would be the easiest way. So As you wrote the client and server is much the same, with some extra jobs.
Oh threads. Yeah. Much better then. 
One thread per client? Not good, as that produces quite some overhead with more players only for threadmanaging.
Depends on the game. If it’s for 6 players max, not much of a problem on a real server. Let’s understand here that a server is not some average machine in the office of some guy at work…
With all things being equal, it might work or not. A thread is much better than one physical server per player. lol
Yeah, but the cost for threadhandelign gros exponentiall, while better hardware only gives a linear boost. I thought tho this was more for a mmo or similar, than 300+ players are not that much. Also to modify the world with different thread massive snychronizing needs to be done, taht can lead to huge slowdowns.
If you use thread-pooling you are able to reduce overhead. So maybe a better way is not to keep for every player a thread alive, but a bunch of threads for all players which will be prepared for the player if the client is sending a request. So only the fast switching content of the threads could be a problem.
A Single server wouldn’t be able to handle that much requests in time (when the game is a mmo). So the whole world is split in to the areas, which could be represented by one server if necessary. That means more server and higher costs, but that shouldn’t be the problem for now .
In general, if the world is so active that 1000 threads causes synchronization issues then 1000 connections handled by the same thread will cause scaling issues. And while you could start splitting your selectors into groups then you are right back to your original problem of multi-threaded data access. SpiderMonkey uses a single thread for managing its connections but having implemented plenty of two-thread-per-client servers, I’m not sure it makes much difference for most of the use-cases SpiderMonkey intends to handle. Modern OS threading just don’t add much overhead for threads that wait on I/O most of the time. And it’s certainly a LOT trickier to get right.
And I’m not sure I understand why the cost goes up exponentially.
Also, if a developer is doing multi-threading and sprinkling his/her code with “synchronized” everywhere then they should probably stop because they don’t know what they are doing. The java.util.concurrent classes are very good at avoiding hard-synchronization.
At any rate, an MMO scale game would certainly be distributed across multiple servers… the inter-machine synchronization necessary to make that happen probably dwarfs any small gains and losses between different threading models. How one zone sees the activity of another is also a small issue compared to making sure that all game state is consistent in this case. Though an “entity system” can help in this case there are performance trade-offs based on need. …but then I rapidly digress into discussions of CAP Theorem and eventual consistency.
Really, I think in an MMO, the spatial partitioning of zones per server (where continuous travel between zones is possible) is a performance optimization on top of a system that could handle remapping the zones at any time, to include serving multiple zones from the same server. So when player A is connected to server 1 and is at the edge they might be seeing parts of zone 2 but it would still be server by server 1.
…then again, I’m probably biased. There are a dozen different ways to tackle this particular problem and my point of view is tainted by “entity systems” architectures since they have a lot of “win”.