Hmm. Okay il ltry toanswer. We may have some communication issues here but Il ldo what I can. If im not getting what your saying myabe someone else can chime in...
Thank you Jeff pour the answer.
So my initial technical diagram isn't usable in a game played over the internet.
As I understand your initial design there are some real issues, yes.
If I've a latency of 100ms, i can only i've 10 sockets per second, don't I ?
Not sure Im following you here. Internet latencies vary. In the US we typically see anywhere from 50ms to spikes of 300ms or so from the interent itself. Analog mdoems introduce their own latency spoikes and can make the amtter much worse (up to about 6 seconds) if nto handled very caefully.
The latency is the measure of tiem it takes a packet to get from the sender to the reciever. It is really orthogonal to the question of bandiwdth, which is how big the apcket can be or how many packets you can send per second.
Latencies are a reality in internet games, the whole question is hwo yo udeal with them. There are bsically only two ways I know of:
(1) Delay the entire resposne of the game scuh that there is an even and player-predictable "lag" .between input and response (the latency bufferign technique)
or
(2) Make guesses as to what is happeniogn based on the last information you had and then correct those guesses as new information comes in.
Thr former is more obviosu to the player, the latter is trickier to do but done right can make msot reasonable latencies unnoticable. Teh former indsures that verery player sees the same thing, while the latter emans every player's individual view is only an approximation of the "true" world state.
But the others players are moving all the time, and my player too. The only player that i can have the exact position all the time is the client's player.
For the other can i proceed like that, or is there a better possibility ?
Thsi gets into the prediction I talked abotu above. You know where the other players were and what they were doing at some past poitn in time, that data has just come to you in the current packet. Based on that you make a guess as to where the player shoudl be now and what they are doing. When the next packet coems in you need to correct any error in that last guess and make a new one.
Hard corretions cause "warping", so what is typically done is a lot like a color dither. You carry an "error term" over subsequent frames and rduce it eahc frame to get you back on track. ofcourse meanwhile you are potentially making new errors in your current prediction so that erro term will likely never be 0, or nto unti lthe player stops moving at any rate. Thus you dont have an exact idea of wher the other player is, but you CAN have a good enough idea to "fake it." Unless two players are sitting right next to each other, they'll never know they are playing slightly different games.
: The client side is always update to get a nice FPS (about 80FPS), with the map, the client's player exact position, the objects and so on. Then for the other players, i can get their exact position and movement direction every 100ms, and during these 100ms, i can guess their position by calculating their position, their speed and their direction. And when a socket comes, i correct their position.
Yup, thats the idea exactly!
Is this system correct ? Is the difference between what's is showing on and the "reality" realy disturbing ? Is there a better system ?
Generally what you have to worry abotu are key moments of interraction. There are two ways to handle this:
(1) If you can afford teh security risk, you can make key decisiosn on the client that is most likely to see an error f its wrong. Take an FSP as an example. When i am shooting at you, i have you in my reticle, I can til with great detail if its a hgit or a miss, but YOU only see me generally pointing my giun at you. Its a lot harder for you tot ell. Therfore, I, the oen firing, shoudl decide whether its a hit or a miss.
The only problem with thsi is that clietns are inherently insecure so allowing a client to make a key game decision and fore it on the other players runs some security risk of cheating.
(1) the OTHER solution is to have a server which has the one "true" state and decides all of thes ehit/misses for the player. Its possible due to latency that A shot I think aught to hit the serve wil ldecide is a miss, but if you dont go for real tight toelrances on weapons or too fast moving players then all the player shoudl be at abotu the same disadvantage regardless of their individual latencies.
Ona last note, yo uwill NEVEr get to "massively multiplyer" on one thread poer user unless your data rate is very very very low. Your going to have to learn NIO and do your server that way.
So i mustn't use threads on the server ? I must use NIO, but with it, is there any problem of conflicts when to client would acces to the same data ?
NIO allows you to handle many socekts on the same thread. You hadle them in-turn on that single thread so there is no conflict. Its a bit tricky to get working right but its the right way to use sockets ina server that has to handle a great many users. Having a thread per user just does not scale.
