Hi, I am trying to do a java real time networked game. Right know the client is only sending data to the server when it moves (change of position) and the server sends data to clients when any client has moved. My question is the following: Is it better this approach or maybe its better to constantly send the info every certain time. Thanks and any suggestions to improve real time are welcome.
Elioncho
In a real-time game it is better to send at intervals. Otherwise, how do you deal with “when it moves”? When the positional value changes you send a message? If you are constantly moving you could be sending thousands of messages a second depending on the frequency of updates in your game or however you are dealing with this. Intervals are really the only way you can keep traffic to a consistent level as well as giving your network a consistent flow that keeps the game from getting jerky when lots of stuff is going on and really smooth when nothing is going on. If programmed well you’ll have a consistent flow throughout.
I would recommend taking a look at the synchronization system in JGN that provides exactly this:
http://svn.javagn.org/core/trunk/src/com/captiveimagination/jgn/synchronization/
For an example in jME that uses a synchronization implementation and allows multiple connected clients see here:
http://svn.javagn.org/synchronization/jme-networking/trunk/src/com/captiveimagination/jmenet/
The “flagrush” is an example based on the FlagRush tutorial in jME. As you can see from the JMEGraphicalController it is trivial to create implementations for other systems to allow JGN to work with them.
For more information on JGN see:
Thanks for the info,
By the way, can anyone help me by giving me which are the best time rates to send info (every ? milliseconds)
If you know the the origin and destination of the movement, you can simply only send a pair of points and timestamps, you don’t have to send any more bytes until the units reaches its destination and moves on to some other place.
There is no golden rule of intervals at X milliseconds. The less data, the higher the interval, the better.
I would agree with that statement for something like a multi-player top-down style game where you command units and tell them where to go. But if we’re talking about a first-person style game you have no idea what the destination is and polled synchronization is the only real solution I believe. Please correct me if there is another option I haven’t considered.
I will often start out with updates every 100ms and then gauge which direction to move based on how smooth it is in-game. In JGN you also have a proximity adjustment that can modify updates sent to a specific client for a specific object based on proximity. So if you set updates for every 100ms for something but a specific client is a long distance away an adjustment may be applied for proximity to reduce the frequency of updates since there is no need to be updating at the same frequency for objects that are at a greater distance from the player.
[quote]But if we’re talking about a first-person style game you have no idea what the destination is and polled synchronization is the only real solution I believe. Please correct me if there is another option I haven’t considered.
[/quote]
you can still use a timestamp for an fps, collision must be performed serverside timebased, and client act a little like delayed “video player”, no real collision on client side or only the currentplayer.
client1 send move x,y,z,t to x2,y2,z2,t2
client2 send move x,y,z,t to x2,y2,z2,t2
client3 send move x,y,z,t to x2,y2,z2,t2
server time know is min(t2/t) of the three clients, perform collision for all clients to min(t2/t)
server send to client all other clients position
clients display all other clients/players using server info, interpolating if currenttime < min(t2), or extrapolating if min(t2) is in the past.
as t2 sent by client will be close to currenttime or be in the futur, the “delay” introduced will not be a lot noticable for a displacement.
exemple:
player 1 press up arrow to go forward than it must immediatly send to the server :
px,py,pz,currenttime
px+vx100ms,py+vy100ms,pz+vz*100ms,currentime+100ms
in case of a network lag, a client may need to know a player pos before server has sent it, so as cllient act as “video player” you need to extrapolate last know coordinates for an unknow player pos, and update it when server info are available.
I have notice something in the game battledfield when you loos server connection you can see other player continuing there movment throught building without any collision and you get stuck until connection come back (you can still rotate view, rotate view must be performed clientside as it request fastest response, I have experimented that and a delay on player camera rotation is very noticable).
Though a true statement I would disagree that it’s the best approach. Dumb clients were common things in games of old, but I don’t see any reason why correction support shouldn’t be done in-game on the client as well. A good example of “the problem” is TrackMania Nations. I remember playing that a couple years ago and they essentially go for the exact same approach you specify, but since it’s so fast-paced it was extremely noticeable when one of the cars would jump and then land back on the track because often their wheels would often end up in the track for a few milliseconds until corrected. This creates a very unrealistic and annoying experience in games. How hard would it be to simply follow the rules of the game on the client and simply receive corrections from the server?
I’ve seen exactly what you’re talking about in Battlefield 2 as well. You’d see tanks sliding through buildings, terrain, etc. but this wouldn’t be an issue if some simple collision validations were enforced on the client as well to keep the game realistic until the server can give a proper update of positional information. Both of these games use dead-reckoning but do not enforce any collision correction on the client. If you couple dead-reckoning with client-side physics you can drastically improve the game-play during lag and in many cases not even see the effects of lag unless drastic or while very quickly trying to change directions.
[quote]it was extremely noticeable when one of the cars would jump and then land back on the track because often their wheels would often end up in the track for a few milliseconds until corrected
[/quote]
yup, I was talking about FPS, dont really think about drive game.
[quote] If you couple dead-reckoning with client-side physics you can drastically improve the game-play during lag and in many cases not even see the effects of lag unless drastic or while very quickly trying to change directions
[/quote]
yup bis, right, enforcing client side will improve game reality, and a good thing is that it can be done in a second step, but maybe in few case it can make things more complexes for a little gain.
Well, the way I do game development it actually simplifies the process because I utilize the same scenegraph on both client and server and simply have different controllers that interact with it based on whether it’s client or server. This allows me all the advantages of having the same code-base regardless of client or server as well as all the advantages of client-side validations and collisions. The best of both worlds and less code to write…I love Java. 