Permissive Client/Server structure

#1 Well, a response would be nice :P

#2 Less than 12 hours after posting your question, you're annoyed that no one has responded ?

Your analysis of how the Torque networking works is incorrect. To learn more, go here:

Tribes Engine Networking paper

#3 If you think that is better than change it and show us. It sounds interesting.

#4 There is a problem with letting clients determine the begining of a firing sequence as opposed to the server. The server and the client can have different versions of what actions are currently happening, and trying to reverse them can cause anomalys in the actions occuring on screen.

To implement what you want, you would have a client signal to the server I am firing this weapon, at this time, along this vector. The client machine may see that as a hit where as the server has not recognized that action as having taken place. Now if the command finally reaches the server and the server has to back track because the client said this action happened at this time, it could cause the server to reverse itself.

Also there is the problem of multiple clients sending in commands with there own time stamped commands. The server would have to constantly revise history to make it jive with all the clients.

The server should be the originator of all actions. All the client does it feed commands to the server and display what the server says has happened. This way there is now conflict between what the server says has happened and what the client says has happened.

#5 Jason what you describe is exactly what Half-Life does with its crappy "lag compensation" code, it lets the clients do whatever they want, shows people getting hit and taking damage on the client and they are either dead or not there anymore, and then goes back and changes everything to reconcile against the server image.

It is an awful way to do things unless you are a dialup user on a 700ms connection, because the higher the difference in players latency the MORE OF AN ADVANTAGE the slower player has over the higher player.

I quit playing HL mods for a couple of reasons, mainly the cheating, that combined with my FAST connection it was almost impossible to play against anyone with more than a 300ms difference in latency.

I am usually sub-50, anyone that is more than 250 ( which is 90% of everyone playing it seems ) has a distinct advantage over the sub-50 players just because of the issues you state.

For modem users they love the backwards time calculations in HL now, for the rest of us, it is almost unplayable.

#6 Mikkel,

The Torque network code is as good as any in the industry. That is why Tim and Mark were asked to give the speech at CGDC about networking and why there is a document describing how to do it. Since they published that paper, countless engines have referred to that document and have improved their networking code because of it.

I'm sure if you asked them, Tim, Rick, and Mark are open to new suggestions and feel that our networking could even be improved. However, I think there might be a better way of asking. My suggestion would be that if you think you have a better method, then use the scientific way of posting your theory and letting the community give it a peer review and pick it apart. Our way of doing things has survived this test.

In the meantime, we are happy with the way our networking is architected, but will continually be looking for ways to improve.

Jeff Tunnell GG

Edit: Grammar.

#7 Could we get a link to that paper to take a look at it. It could be helpful in some way, or at least an interesting read. Or maybe a way to help me go to sleep. Thanks.

Jason

#8 Tribes Engine Networking paper"



There's the link - it's also in my reply above.

#9 Just to chime in a bit, try playing Descent against someone who is using a modem when you aren't. You basically cannot hit the other person.

I don't know a lot about the Torque networking but it seems to have been designed with different connection speeds in mind.

#10 Bear in mind that it's essentially an insoluble problem to provide a totally flat playing field to people with wildly variant amounts of lag.

Torque and many other modern MP-focused engines do excellent jobs, but the problem of compensating for lag while keeping the game fair isn't going to go away no matter what the game designers do (short of buying everyone low-latency net connections).

If you come up with a better architecture or paradigm, I think everyone here would love to hear about it... But there's only so much that can be done, and only so much that's worth the effort to do.

My suggestion: play on servers where everyone runs <150 ping. I don't know what game you're playing, but generally I can find a CS server where this is the case (I play on cs1 through cs3.gamers.com; I'm in Portland, OR, and it's nice and fast.)

#11 Is there a pdf version of the above link? Would like to read it offline.

--Dave W.