networking libraries

Networking & Multiplayer
#21

Then I’d say I get a last rebut against your statements. :o The packet size of TCP is much larger than that of a UDP message. Further, your premise of “HQ won’t send messages that could be dropped” in so much as TCP messages can be dropped as well, it’s just the protocol handles the resending. In UDP JGN handles that instead of the protocol. It’s probably not as efficient or as fast, but it works.

In JGN I can reliably send more than 2,000 messages per second, so 10/second per player isn’t bad for me. :slight_smile: If you’re talking about a first-person shooter you just have to update that frequently or you are no in sync with the server reliably. Look at games like Quake, Unreal, Battlefield 2, etc. and I believe you’ll find updates at least that frequently. One of the features on its way is prioritized update messages that send updates to clients less frequently depending on distance from the object. That is a feature explicitly part of the PhysicsNetworking.

Something I haven’t yet added is clock sync, but it shouldn’t be too difficult to add. I would be interested in how you went about implementing this?

-Matt Hicks

#22

He probably meant that HQ cannot afford to lose any of the messages that he send in order to work.

My message to all of you, network lib authors :
Make Loveibs, not war.

#23

:slight_smile:

I think we are pretty kind for we are talking about religion :slight_smile:

Honestly, TCPvsUDP is a war longing for years meanwhile, w/o any result. Both works, depending on specific sitiuations. The arguments are quite obvious and always the same.

This thread (I think) was meant to collect network libraries available. I just wanted to add HQ to the list.

#24

No grudge held on my part. :slight_smile: My API will stand or fall based on its merit. :slight_smile: I would say you’d be hard-pressed to find many first-person shooter games that use TCP for their primary communication though. :-p

I can always appreciate some good competition, but my goal in creating this API was to get collaboration so there isn’t 50 mediocre networking libraries but just one really awesome one.

From all the research I’ve done UDP is the undisputed champion for game development. Hey, I’d be interested in a stress-test challenge. :slight_smile: Would that forever resolve the UDP dispute? :-p

Herkules, I think your API has some really good ideas in it. I would say the biggest drawback to using it though is the learning curve it takes to understand all of those aspects. It seems pretty flexible though, which is great, it’s just creating a custom message seems to take a lot of code to make happen. If you could resolve that I would see a lot more usefulness to your API.

-Matt Hicks

#25

Can be complicated, but in HQ its done very simple (hence not exact). It measures the time a message needs to go to the timeserver and back and the answer contains the timestamp from the server when it sent the answer. When the client receives the answer from the server, it assumes current time now is servertimestamp + roundtrip/2 and adjust the clients clock accordingly.

The key in fact is not that protocol but having an adjustable clock :frowning: (package de.hardcode.time)

#26

I was planning on implementing a similar concept but have a time sync and then create a conversion value for when messages are sent to that remote machine. So it would say, “the time is +500 ms on the remote machine, so take my current timestamp and add 500 milliseconds to it before sending”.

-Matt Hicks