Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  What to do to improve real time?  (Read 3153 times)
0 Members and 1 Guest are viewing this topic.
Offline elioncho

Senior Newbie





« Posted 2008-04-01 18:34:40 »

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
Offline sunsett

Senior Devvie




ribbit!


« Reply #1 - Posted 2008-04-01 19:58:50 »

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:

http://www.javagn.org
Offline elioncho

Senior Newbie





« Reply #2 - Posted 2008-04-02 05:32:48 »

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:

http://www.javagn.org

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)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 833
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2008-04-02 05:44:25 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline sunsett

Senior Devvie




ribbit!


« Reply #4 - Posted 2008-04-02 13:42:19 »

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.

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.
Offline DzzD
« Reply #5 - Posted 2008-04-02 19:09:47 »

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.

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+vx*100ms,py+vy*100ms,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).

Offline sunsett

Senior Devvie




ribbit!


« Reply #6 - Posted 2008-04-02 19:25:32 »

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.
Offline DzzD
« Reply #7 - Posted 2008-04-02 20:09:24 »

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
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
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.

Offline sunsett

Senior Devvie




ribbit!


« Reply #8 - Posted 2008-04-02 22:22:39 »

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. Smiley
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (57 views)
2014-11-26 15:22:04

toopeicgaming1999 (50 views)
2014-11-26 15:20:36

toopeicgaming1999 (10 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (27 views)
2014-11-25 11:26:43

Gibbo3771 (24 views)
2014-11-24 19:59:16

trollwarrior1 (37 views)
2014-11-22 12:13:56

xFryIx (75 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!