[SGS] DarkShooter

[Jeff]

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

[hplus]

Okay that I believe   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).

[Jeff]

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.

Games published by our own members! Check 'em out!

[Jeff]

Okay that I believe   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.

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.

[dsellars]

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

[Jeff]

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.