Gaming need ideas on how to solve a multiplayer billiards problem

[Moach]

hi....

didn't know where else i could ask for help on this... i need some sharp brains to help me out....

the problem:

i'm building a multiplayer billiards flash game.... the game is simple enough, just point and shoot... anyways, i got all that sorted out and the game is running fine

but now, i'm delving into developing it for multiplayer....
i've created a little server in C++ using the Qt library - works and all, no problems there... it's just a big bumb relay, anyways...

the problem is trickier....

my first approach, which i'm currently using is this:

when a player shoots the cue ball, the X and Y vector components of his shot are wired over through the server onto the other player...
this works, to an extent... i can replicate shots on both sides without much fuss....

but look at this:

after a number of shots - de-sync occurs... even though there are absolutely NO random or non-deterministic factors of ANY kind, and numerical rounding errors being corrected with RK4 integration - there's still a large difference in the outcome of an identical shot in two different instances.....

i figured it was a matter of a small error that would accumulate over a series of shots, so i devised a correction system that would match the position of all balls according to the positions on the shooting player's side....

correction does work.... but only to an extent.... sometimes, the disparancy between the two is so severe, that i get balls falling into pockets on one side and not on the other... all this within the course of a single shot :facepalm:



i don't wanna have to run the entire shot in advance then relay the movements to the other side... this would force a player to wait for the other end to completely stop before he can see what the other guy did....
no, that's unacceptable....

so i need ideas....


how do i ensure synchrony on both sides without having to wait for a complete stop?

 

[Urwumpe]

I can't see the problem... Just do it like that:

Player A shots, computer at player A calculated secretly the motion of the balls, and then relays the motion data to the other players. All players then see the playback of the motion and the next turn happens.

 

[Moach]

pre-calculating has crossed my mind...

it's one of the possiblilities, indeed.... i don't wanna have the players wait out the shots in real-time tho... if the whole shot must run before broadcasting the results to the other side, then we'd have a huge wait between turns, more than double the natural time you'd spend "not playing" whie the other guy does so....

this because you'd have to wait for your shot to stop, then wait for the other guy to see it all over again, then wait for the guy to shoot, wait for his balls to stop, then wait untill you SEE their balls stop before you can play again....


so, in order to avoid this, all iterations would have to run before ANY player sees the actual shot... this could cause a small "hickup" if not done properly, as ActionScript 3 isn't all that fast, and we'd be feeding it hundreds of frames worth of calculations to do in a single pass

if i had threads to work with, this would be actually simpler.... but AS3 is single-threaded to the bone, so i'm a bit out of luck there....

it might be fitting to rig up a "max iterations per frame" construct.... allowing a break for the UI to catch up and all



it's viable... could work, i guess.... thanks for the idea
yet i was hoping someone might have a "genious solution", which didn't involve taking apart the whole game

 

[dgatsoulis]

I'm in NO WAY a programmer, not even close to one. (But i am one darn fine pool and billiards player! )
Just throwing out an idea here.

when a player shoots the cue ball, the X and Y vector components of his shot are wired over through the server onto the other player...
this works, to an extent... i can replicate shots on both sides without much fuss....but look at this: after a number of shots - de-sync occurs...

So... at the risk of sounding really stupid:
Is there a way for the other players to "see" not the X and Y components of the shot but instead, the "view" of the player that made the shot? (If that makes any sense.)

If that is possible, then the other players would "see" the "correct" shot in real time and after that you could send the components of the shot with the correction, so that they could continue the game.

Again, just throwing out an idea here... hope it helps.
Good luck with your project!
:tiphat:

 

[Moach]

thanks a milllion for the ideas, guys! but i think i got it :thumbup:

turns out, there was something wrong in the way the numbers were being wired over the net... now that i switched to double-precision format, it's dead-on accurate :yes:


we got ourselves multiplayer! - i just ran a trial-by-fire with the server on my WinXP-32 laptop, one player on a Win7-64 and the other on an IMac... solid play and fun all the way, no desync whatsoever


i think all there's left to do is ensure that there will be absolutely no more problems, then code up the GUI cues for server-related things and we're gold!

and yep - this IS my job

 

[dgatsoulis]

Nice!!!
Please post a link when it's done! I'd love to give it a shot!

P.S. Now... to restrain me from posting any other stupid ideas... is there any chance my previous post could have worked? (If the double precision format thingy hadn't worked for you?)
Probably not, i guess... but just wondering.

 

[Moach]

it would, but that would be a "blunt force" approach :hmm:
since as far as programming goes, broadcasting the "view" of something means relaying all positions on every frame....

although possible (and the way most games would do it) - it's quite a load on the server...

so, by relaying the XY vector instead, we reducve the load to a couple of bytes per shot... instead of having to rely on a live feed several megabits wide

 

[RisingFury]

I can't see the problem... Just do it like that:

Player A shots, computer at player A calculated secretly the motion of the balls, and then relays the motion data to the other players. All players then see the playback of the motion and the next turn happens.

Also know as ZeroPing for UT sniper rifle and InstaGib. Unfortunately the source of 90% of cheats in zp Sniper...