Hi,
First of all, sorry for my english, i’m a french java user.
We are developping a graphical 2D MMORPG in Java (1.5). But at the moment, we’re only analyzing the project. As we are only experienced in web-based games and applications with PHP and JavaScript, we don’t know lots of things about creating multiplayer games in stand-alone application languages as Java, C++…
We have thought to a technical diagram :
Client side :
-action listener for keyboard or mouse event
->action and actual position analize for query creation
->socket sending (which contains de query)
Server side :
-One thread per player
->socket listener for socket recuperation
->socket analize and verification
->execution of the command contained in the socket
->calls of World class’s methods. The objet instanced of the World class is the representation on the server of the world game with map, players and non-players creatures positions, objects positions…
The class has some methods to acces to the data quoted before and to modify them too.
->The methods of the World class return the data necessary for the 2D engine.
->socket creating and sending with data returned by the methods
Client side (one more time) :
-socket's recuperation
->analyze of it
->graphical 2D engine creats the image in a buffer with the socket's datas.
->showing of the image
That’s an iteration. First question, what do you think about that ?
Then, to have a correct FPS, we must have that iteration or that loop about 80 times per secondes, don’t we ?
So, a period must last about 12ms with the sleep() time of the loop’s thread.
All that technical schema can be executed in a period of a maximum of 10ms ?
But the server answering time is the value of the ping, isn’t it ?
For exemple, for me, it will be about 80/100ms.
So, how can keep a correct FPS, for a non lagging and shifted game ?
How work the other multiplayer game to be so fastly updated with the position of the other players…?
Oh boy. Clearly this is your first brush with the internet.
What you have described is what is known as a “lock-step” game. Lock-step works great ona LAN but is crappy over the internet. The problem with a lock-step game is that if you wait for each packet of input in order to render, the best possible framerate you can get is youtr internet-latency times 2. There are other reasons as welkl why lock-step is bad. For instance, everyone’s eprformance will be only that of whoever the slowest player is.
Having said that there are ways to improve lock-step performance somewhat. There si a technique kn0own as “latency hbuffering” where you build a FIFO buffer for the inputs that is worst-case-expected-laytency (in seconds)/ requried FPS. Thsi keeps you running at a rate of FPS, but means that ALL packets will have the worst case latency. In practice however this worst-case-but-smooth ptrformance is actually preferrable to jerkiness you would get from a “raw” lock-step game.
The best thing to do however is to completely decouple your frame generation from your data input. This would insure that animation and such woudl keep running at ful lframe rtate. This really takes you over the line to an “open-loop asynchronous” game. In this case you are going to have to EITHER enforce a strict turn-based game OR do prediction and correction to handling.
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.
Thank you Jeff pour the answer.
So my initial technical diagram isn’t usable in a game played over the internet.
If I’ve a latency of 100ms, i can only i’ve 10 sockets per second, don’t I ? Or if i send the sockets one per one, even if they aren’t arrived on the client, i can have a lots of socket but with a light shift, that’s possible ?
I can get 10 times the exact position of the other players.
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 ? : 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.
Is this system correct ? Is the difference between what’s is showing on and the “reality” realy disturbing ? Is there a better system ?
[quote]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.
[/quote]
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 ? And NIO permits to have lots of clients connected and which are requesting data in the same data, no ?
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…
As I understand your initial design there are some real issues, yes.
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.
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.
Yup, thats the idea exactly!
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.
[quote]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.
[/quote]
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.
