|
I was a bit bored, and thought would make a very simple replay syncer and in the process learn about windows system programming.
This is the result:
![[image loading]](http://dl.dropbox.com/u/134488/SC2ReplaySync.jpg)
Very simplistic, there is no NAT traversal or anything, you punch in the port you want to make the server on, and you punch in the IP and port if you want to connect. If your computer is not directly accessible from the internet, you will have to set up port-forwarding or configure your firewall correctly.
It uses UDP as its protocol.
How does it do its thing?
You set up the server, clients connect and every 200 miliseconds we send everyone a message with a timestamp, who then send it back. We now know our ping towards that connection.
When receiving the start command, a 5 second delay will start after which the application sends the Starcraft II window the "p" button press. The delay takes the ping into account to achieve as exact of a synchronization as possible.
No install, just a single executable.
What do you need to run the code?
.Net framework version 4 (that limits it to XP sp2 and up I think)
There must be countless bugs in the code I'm sure, and I'm new to this, so be gentle with your criticism. The code is open source and available at https://github.com/sztanpet/SC2ReplaySync I plan to license it as GPLv2 but was too lazy to add the necessary things as of yet.
The binary can be downloaded from here.
Customization features will be the most requested feature I'm guessing, but I do not have much time to work on this, but it's in the works. Also the way we detect the SC2 window is english specific so I'm guessing it wont work on non-english clients.
Hope someone finds it usefull
|
Currently known things about the code include: because UDP is a "stateless" protocol we don't actually check if the other end of the connection is still there or not, so even after a client disconnects, the server sends pings. Not a biggie I think.
|
Wow this is a pretty amazing tool
Thanks for making it
Slight desyncs in replays are pretty frustrating
|
On May 14 2011 09:17 frogmelter wrote:
Wow this is a pretty amazing tool
Thanks for making it
Slight desyncs in replays are pretty frustrating
Agreed. I get really annoyed when casters' replays aren't synched. Hopefully they start using this tool to save us and themselves from further frustration.
|
Northern Ireland2557 Posts
wow, nice tool, certainly very helpful for casting. hope more people use this so we don't get instances like clash of the titans (T_T)
|
So what's going on, you both connect to the server which syncs the two systems and then tries to unpause the replay at the same time? And since you are using UDP, what do you do if the unpause packet doesn't reach one or more sides? Though I assume you probably manually doing something at the application level that tries to do packet acknowledgement? Or is this working completely differently from what I think D:
Hehe curious for more details ^^
|
Very cool, nice work. I don't want to take away from it at all, but I don't think this is the main issue with trying to do replays at the same time. The main issue is that SC2 actually plays back the game slightly faster or slower based on your computer. So even if you start at exactly the same time, you can get seconds apart over the course of a longer game (which we've seen recently in TSL for example). =\
|
really surprised that this hasn't been created yet.
Very well done sir you should Have named it after youself I think its fitting for it.
|
On May 14 2011 12:39 EtherealDeath wrote:
So what's going on, you both connect to the server which syncs the two systems and then tries to unpause the replay at the same time? And since you are using UDP, what do you do if the unpause packet doesn't reach one or more sides? Though I assume you probably manually doing something at the application level that tries to do packet acknowledgement? Or is this working completely differently from what I think D:
Hehe curious for more details ^^
nope, no ack or anything, that might be a good idea now that you mention it tho
|
The problem with this is starting the replay at the same time is not the issue when it comes to casting. Computers actually process the replays at different speeds and desync over time is the bigger issue.
|
Oh wow this is great. gj on making this, maybe blizzard will integrate it :D
|
On May 14 2011 17:10 iCCup.Raelcun wrote:
The problem with this is starting the replay at the same time is not the issue when it comes to casting. Computers actually process the replays at different speeds and desync over time is the bigger issue.
Yea that's what I thought.
What I had thought this might/should be doing (and this would be dependent on how quickly it is possible to pause/unpause at the application level - one can imagine that if pause/unpause actually has negligible native latency of action, then one could play the replay at speeds such as 0.8x faster through throttling of pause/unpause, though from the user interface level it seems that there is nontrivial pause/unpause latency). But, assuming you could pause/unpause very quickly in order to create a smooth and throttle-able replay, then at the initial synchronization, you would use NTP to synchronize the clocks of the computers involved. Thereafter, each sync packet would contain both the current gametime and the current clocktime, and you would make some algorithm which works above the network layer of the application in order to determine how much you need to throttle the replay speed. This may involve saving state information, i.e. what the local gametime/clocktime data has been over the last minute or something. I'm not sure how often you would want to throttle in order to preserve a relatively stable replay speed with not much "slowdown" - maybe constant throttling? Might have to test empirically.
Maybe you would save state information every 250ms or so, so 4 states per second. It is kind of unfortunate that game seconds and real seconds don't match up - maybe instead you would use a frame time that corresponds to something like 1/4 a game second. Various variables to test out!
But, none of this would work very well if you can't pause/unpause smoothly at the application level.
I suppose, if you can't pause/unpause smoothly, then we could let there be some allowable desync - say, within 1.5 game seconds or something (but even that is probably too large, so maybe in practice it must be within 1 game second or even less). This would be done using the same gametime/clocktime pairs mentioned above. If one party gets ahead, then the party which is ahead serves as the client which initiates a 3-way handshake agreeing to pause the game at some gametime in the near future. The party which is behind then initiaties the unpause handshake (to unpause at some specified clocktime) once the pause has been done. Of course, in case of various reverse desyncing, in order to agree to unpause the party which previous was ahead must check that it actually has paused the game before handshaking. Once the handshake is complete, then we resume.
I'm not sure how annoying it would be to watch if the two computers kept desyncing like mad, since you might pause a lot, but in that case I suppose you'd be screwed for casting anyways. The smoothness I suppose would be a function of the desync window you allow, but then again, the length of the pause will be somewhat related to this as well - I don't think the combined delay inherent in handshaking would combine to be more than a second, so the desync window may be equal or even a couple times greater in temporal length. edit - On second thought you would probably have to set the unpause time a few seconds into the future in order to allow for possible network burps so you don't screw yourself over in terms of how many times you interpret a possible packet loss or something.
Whew that was a long post lol.
|
yea, thought about that, not even trying to implement some of the ideas in there, desync is a non-issue for me and "its good enough"
patches welcome though
|
i have a question about the relative replay speed on different machines, to those who might understand the issue better:
if having relative replay speeds on different machines with identical replays and settings is what is preventing blizzard from implementing group replay watching, how is the game itself somehow magically synchronized between two players but this concept somehow does not forward into replays as well? very confusing double standard to someone who doesnt have it all figured out such as myself.
|
On May 15 2011 23:07 kyarisan wrote:
i have a question about the relative replay speed on different machines, to those who might understand the issue better:
if having relative replay speeds on different machines with identical replays and settings is what is preventing blizzard from implementing group replay watching, how is the game itself somehow magically synchronized between two players but this concept somehow does not forward into replays as well? very confusing double standard to someone who doesnt have it all figured out such as myself.
It slows down gameplay if sync packets are not yet received - like, it literally pauses the game. Try throttling your available SC bandwidth in game, you'll see, once you make the packets queue up a lot.
|
|
|
|
|
|
EPT
