Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  [SGS] DarkShooter  (Read 7277 times)
0 Members and 2 Guests are viewing this topic.
Offline Jeff

JGO Coder




Got any cats?


« Reply #30 - Posted 2006-03-30 22:06:47 »

Short answer is it sounds like your particualr application is outside of our problem domain, sorry.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline hplus

Senior Newbie





« Reply #31 - Posted 2006-03-30 22:16:06 »

Okay that I believe Cool  I suspect if you aked them yould find they are ALSo runing loosely coupeld physics on the client.  The only other way they could get the kind of motion theya re getting (ex a smooth arc in a jump) and not do that was if they were actually sending back paramteric curves to the client and I kind of doubt that.

I specifically asked them, and they run the same physics on the server and on the client, to avoid position cheating. Because they run physics at 30 frames per second, it means that they can smooth enough arcs when you jump -- linear interpolation between successive 33ms bites wouldn't be noticeably different from an actual parametric arc.

Thanks for clarifying the general model for the SGS back-end, too; it helps.

Last, @dsellars: I believe Jeff is suggesting that the server checks the moves the client's made using rays or swepth spheres, covering the movement area, rather than just move the object and test for intersection. Thus, the server would be running different code than the client (or at least, the same code with vastly different parameters). This is a model you can use if your game is only loosely physical, or only physical on the client (like an MMORPG).
Offline Jeff

JGO Coder




Got any cats?


« Reply #32 - Posted 2006-03-30 22:26:32 »


I guess the use case I am thinking of is: Client reports a hit, sends to server for clarification (or doesn't report damage til the server sends hit but does show fancy *hit* effect), server sim hasn't seen it (cos it's steps are too far apart), says no hit. 

now I'm thinking this still isn't the way I want to be looking at it, but I'm not sure what is.

Okay.  Due to the realities of interent latencies, at leastin the US, youa re talking latencies that are usualy in the 100ms-200ms range and jitter pretty badly, all the way up to near a second in worst cases.  To make it mworse, analog modems can go into retrian mode and put as muchas  6 seconds of latency ona line.

All of this leads to an inevitable  reality-- you cannot expect a tight synchronization over the net.  Set two clients up next to each other for any online game and I gaurantee you that what you will see is a pretty loose synch.  Thats just reality.

So sicne you cannot closely synch, you don't try.  You design your game as open loop and loosely synchronized. As long as the simulation on each persons terminal is reasonable and fair, they dont have to be identical.  Now there are a few times when POV becomes critical, mostly these are interractions like shooting someone or hitting them.  The schemes for that vary. 

Most first person games take advantage of the fact that the only person who has any great amoutn of information on aiming is the shooter.  based on that, you can let him decide if its a hit.  The one problem with this as a complete solution is it leaves the cleitn open for cheating.  One way to sovle this is to move shooting to the server.  This works though you risk having shots thata re dead on on the lcients side miss in the server's view.  Another solution is to let the client decide but have the sevre checkign for "reasonableness".  If the serve decides there is no way a hit could have happened thatis being reported, it decides the client is cheating.

Now buried in this whole discussion is really the question of position.  Im going to pull it to the front because it helsp illustrate a difference you cna take advantage of between client and server.  The client has to be correct ona  frame by frame basis.  Thsi means that it indeedneeds to si,ulate ona frame by frame basis.  The Server though just needs to detect the client cheating and resolve such questions as "where was object X at time Y".  With any object that moves in straight lines (or actually in a mathematically predictable curve, straight is just the degenrate case) if you know some information at two end points, you know every postion the object was  in between these end points.

I dont actually need to process the entire shot when its fired if I can ask the question later "at this time could this object have hit that object with a shot."  Cheat detection doesnt have to be immediate as long a its reasonably soon after the fact.  All you cna do with a cehater anyway is (a) reset the game to befoe the cheat and/or (b) kick him or her out.

BattleTrollS/JNWN takes advantage of this, as we demoed at the show.  We send a message to the server whenevr our movement state changes-- this means start, stop, or chnage angle.  The server does a line segment test vs the walk mesh to check all the points in between. If it intersects a wall or other unwalkable, we tport the player abck to the start position of that ssegment.

(We actually limit the angle change messages to a min-change to avoid flooding the server.  We also send an update periodically even if we are just walking straight so lag doesnt get too extreme.)

I hoep this helps get the ideas flowing anyway.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #33 - Posted 2006-03-30 22:28:39 »

Okay that I believe Cool  I suspect if you aked them yould find they are ALSo runing loosely coupeld physics on the client.  The only other way they could get the kind of motion theya re getting (ex a smooth arc in a jump) and not do that was if they were actually sending back paramteric curves to the client and I kind of doubt that.

I specifically asked them, and they run the same physics on the server and on the client, to avoid position cheating. Because they run physics at 30 frames per second, it means that they can smooth enough arcs when you jump -- linear interpolation between successive 33ms bites wouldn't be noticeably different from an actual parametric arc.

But as you say they are simultaneously running the physcis  on the client.  Thats why its smooth, ist being locally controlled for the client. I assume they do some correcting periodically to keep it in lien with the servers idea of the world.  Thsi is what I mean when I say a "loosely coupled simulation" on the client.

There woudl be no way to get it smooth otherwise, internet spikes and latencies woudl screw it all up.


Quote
Last, @dsellars: I believe Jeff is suggesting that the server checks the moves the client's made using rays or swepth spheres, covering the movement area, rather than just move the object and test for intersection. Thus, the server would be running different code than the client (or at least, the same code with vastly different parameters). This is a model you can use if your game is only loosely physical, or only physical on the client (like an MMORPG).

Yes precisely. i laid out one approach above, i hope that helps, too.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline dsellars

Junior Member




Need to write more games


« Reply #34 - Posted 2006-03-30 22:49:33 »

Thank you both for your time and input.

The problems you laid out are what I was worried about with this type game, part of the reason I decided to have a think bout this is precisly cos I don't see how you can keep everything excactly in sync Sad but then I have never tried to do it so.... 

I think I need to have a play and  think about all of this now.  I see what you are saying and it's similar to what I've started to think about.

I suspect I was getting too caught up in the wrong train of thought.

Cheers,
Dan.

Offline Jeff

JGO Coder




Got any cats?


« Reply #35 - Posted 2006-03-30 22:57:35 »

Btw... I am pretty surprised that CoH is doing any server side physics.

Their combat is all dice-roll from what I can see.  There is no twitch targeting and such.  (Which is true of just about all MMOs, again because of the latency issues.)  The Havok style physics that came  in with CoV all seem to be visual fluff and have no impact on play.  Even "knockback" was a late addition and doesnt really do much in the way of physics being a single object projected backards ona straight line.

The powers that "throw things" dont knock boxes over nor can you pick up real map objects-- the "thrown object' comes from nowehre and is just part of the animation.

About the only game-play physics I see in game is wall collision and floor detection.  It seems to me like there would be far cheaper and more scalable ways to handle that.


 

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: 1 [2]
  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.

TehJavaDev (17 views)
2014-08-28 18:26:30

CopyableCougar4 (26 views)
2014-08-22 19:31:30

atombrot (39 views)
2014-08-19 09:29:53

Tekkerue (36 views)
2014-08-16 06:45:27

Tekkerue (33 views)
2014-08-16 06:22:17

Tekkerue (22 views)
2014-08-16 06:20:21

Tekkerue (33 views)
2014-08-16 06:12:11

Rayexar (67 views)
2014-08-11 02:49:23

BurntPizza (45 views)
2014-08-09 21:09:32

BurntPizza (36 views)
2014-08-08 02:01:56
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!