Friday, July 31, 2009
at
3:47 AM
|
I got this link from my sensei classifying our company business model as the Ramen Profitable. Rather funny name. So now we're noodle shop guys. lol
http://paulgraham.com/ramenprofitable.html
On the side note, I've just managed to get two PC linked together and entering the game. No game syncing yet. That's to be done after this. :)
While getting this done, I implemented a system I called delayed sync messaging. This system basically utilizes the time sync method I mentioned here. The concept behind this system is so that one can accurately synchronize a particular event that needs accurate triggering. For example, the beginning of the race, count down should be as synchronized as possible so client don't get a laggy start.
When dealing with this type of events, the only caveat is that the server side also have to synchronize with the client side. This means that the event has to be delayed as much as possible as such that all clients will get the request before it is triggered.
In a LAN environment, this usually isn't much of a problem because the ping rate is rather high; less than 1ms to 10ms. However, in the Internet scale, latency can go as high as 500ms to 1500ms or more. In that situation, time syncing becomes a necessity to accurately identify the server time.
I haven't really tested the time syncing algo I've implemented in the Internet environment yet. However, in theory, it shouldn't go wrong.. I hope... :-P
Sneak Peak:
Don't mind the UI. It's just programmer art to keep me going. ;-)
http://paulgraham.com/ramenprofitable.html
On the side note, I've just managed to get two PC linked together and entering the game. No game syncing yet. That's to be done after this. :)
While getting this done, I implemented a system I called delayed sync messaging. This system basically utilizes the time sync method I mentioned here. The concept behind this system is so that one can accurately synchronize a particular event that needs accurate triggering. For example, the beginning of the race, count down should be as synchronized as possible so client don't get a laggy start.
When dealing with this type of events, the only caveat is that the server side also have to synchronize with the client side. This means that the event has to be delayed as much as possible as such that all clients will get the request before it is triggered.
In a LAN environment, this usually isn't much of a problem because the ping rate is rather high; less than 1ms to 10ms. However, in the Internet scale, latency can go as high as 500ms to 1500ms or more. In that situation, time syncing becomes a necessity to accurately identify the server time.
I haven't really tested the time syncing algo I've implemented in the Internet environment yet. However, in theory, it shouldn't go wrong.. I hope... :-P
Sneak Peak:
Don't mind the UI. It's just programmer art to keep me going. ;-)
Posted by
Lf3T-Hn4D
Posts
6 comments:
Cool stuff man! 1 Bowl of ramen noodles to go !
Hello! I really enjoy this devlog, it's very interesting, and I am very excited about this game!
There is an interesting tool to simulate bad network conditions that I found on another devlog;
http://mm.soldat.pl/?p=231
He is also using a network idea developed by John Carmack that supposedly works very well.
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
Whoops, my bad. Just went back and saw that you're already citing that work in your netcode. Anyway, hope the QoS tool works well for you.
Prometheus: Yeah! :D hehe.
Elliot: Thanks :) That QoS tool looks handy. I'll give it a try. Thanks for the link. :)
good job!
good networking is not simple thing, i did it 3 years ago and broke my brain. as I understand now, debugging tools, embedded in the engine, is very important thing.
Post a Comment