Live data from Hacker News

Half-Life and Team Fortress Networking

gamasutra.com

21–30 of 57 posts

Re: Half-Life and Team Fortress Networking

#21

> "The days of needing to do such things as manually type in IP addresses to connect to remote servers are coming rapidly to a close. Therefore, it is important for you to provide a seamless user experience for your gamers as they go on-line." >> I miss the days of playing CS-1.5 and having to use gametiger.com to find servers to play in. Lots of pool_day and de_dats.

Yup. I hate how online matchmaking these days has made away with the community feel that picking your own server provided.

That feel still exists in certain communities, such as Insurgency and Arma III, which are both great on Linux.

Re: Half-Life and Team Fortress Networking

#22
post #14
post #3

PSA: Add print=1 to old gamasutra articles to get a single page. https://www.gamasutra.com/view/feature/131577/halflife_and_t... Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.

On the other hand, to misquote Philip Greenspun, any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP.

Experience doesn't agree with this however. Pretty much every game engine in existence has a well-tested UDP-based networking stack, without which low-latency game play simply wouldn't be possible. The other thing this statement ignores is that TCP currently has serious issues which I would call performance bugs, so it isn't even setting the bar particularly high.

Re: Half-Life and Team Fortress Networking

#23

> The CD keys we used were algorithmically generated so as to be very difficult to guess randomly. Because authenticating takes several seconds, and the odds of guessing a valid CD key are low, there is a large barrier to repetitive key guessing. I would love to learn more about this. How did the authentication system work? How difficult was it to brute force? Does it simply involve a master key creating individual s…

It's possible this might be more documented on old warez/cracking/serial # generation tutorials if they're still around anywhere. This is only speculation but I imagine the process would be something like breaking a CD-key into multiple parts (a unit#, salt, hash of the unit#+salt)

1. Using unit# + some known/random salt, compute a hash

2. Mix-in the unit# + salt to the resulting hash in some deterministic fashion (prefix, suffix, or maybe inserting/replacing into a known/random location)

3. Convert the hash result into a CD-key format

Generate one for each unit produced, print on a label and attach to the distributed product. When installing, the process to verify the key would be

1. Extract the unit# from the entered CD-key (or if randomly inserted/replaced just do this for each possibly bytes assuming its the unit# + salt)

2. Using the unit# follow the same 3 steps above to get a CD-key

3. Compare the generated CD-key to the one entered for validity

Using hash is fast, produces an output with a very large output range (not easily guessed) and unlikely to have collisions, while also limiting the possibly valid keys to (roughly) however many bits necessary for a unit#. This method also allows for offline validation since the key to the hash is being shipped as part of the CD-key, and this was back in the days when a constant-connection to internet wasn't available or necessary for licensing.

The downside, which was the bane of most producers, is that a reverse-engineer who acquires a copy of the software can use a debugger or disassembler to extract out the first 3 steps above to create a keygen. Once the keygen was out though basically anyone could generate their own valid keys. In order to combat this software makers started requiring an additional step that after validating the key it contacts a central server to see if anyone else has used it or not...

> How did the authentication system work? How difficult was it to brute force? Does it simply involve a master key creating individual subkeys? Is it RSA?

Producing individual builds/images to burn onto CD's was unlikely as it would make the CD production process impractical -- a single build/image for burning CD's was likely used until they ran out of stock and/or wanted to ship updated versions of the software. Using RSA would otherwise be a great solution as the software producer could generate private keys for each sold license. Many newer software licensing schemes have this approach.

Edit: Related answer on StackOverflow: https://stackoverflow.com/questions/3002067/how-are-software...

Re: Half-Life and Team Fortress Networking

#24
post #14
post #3

PSA: Add print=1 to old gamasutra articles to get a single page. https://www.gamasutra.com/view/feature/131577/halflife_and_t... Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.

On the other hand, to misquote Philip Greenspun, any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP.

TCP has different goals than UDP gaming. You can (and 99% of games do) implement a real-time version of abstract TCP. But the similarities fall away when you stop looking at the "abstract" version of TCP.

This is an extremely optimized, important aspect of game programming. I would be very careful to suggest everyone is spending thousands of hours re-inventing the wheel for no reason--especially in the ultra-time-constrained game industry.

https://gafferongames.com/post/udp_vs_tcp/

>Unfortunately, [...] TCP still has serious problems for multiplayer games and it all stems from how TCP handles lost and out of order packets to present you with the “illusion” of a reliable, ordered stream of data. [goes on to explain issues]

When you implement your own error and ordering stack, you are in control of how and when to drop a packet or consider the packet too out-of-date. These "best settings" are very much related to the entire architecture of your physical simulation, game mechanics/rules, and distribution of players. Some games use TCP for control signals and UDP for faster, but less critically important data.

Lastly, as for re-inventing the wheel, there are actually plenty of vetted libraries that implement error checking, quality of service, etc for UDP while still retaining the configurability and real-time/games focus that TCP doesn't allow.

The majority of the industry runs on UDP. That's not an accident--especially when the majority of college students / outsiders don't know anything about UDP and focus on TCP in their studies. Different application, different tool for the job. When you're sending banking information you need to know it got there or didn't. When you're updating someone's head direction in a FPS game, you can tolerate huge amounts of inconsistency between players when the connection starts degrading.

Re: Half-Life and Team Fortress Networking

#25

> The CD keys we used were algorithmically generated so as to be very difficult to guess randomly. Because authenticating takes several seconds, and the odds of guessing a valid CD key are low, there is a large barrier to repetitive key guessing. I would love to learn more about this. How did the authentication system work? How difficult was it to brute force? Does it simply involve a master key creating individual s…

Somewhat related: Some cdkey generators printed out valid keys for Steam back in the early days, around 2004.

Re: Half-Life and Team Fortress Networking

#26

Earlier quoted context omitted.

Yup. I hate how online matchmaking these days has made away with the community feel that picking your own server provided.

That feel still exists in certain communities, such as Insurgency and Arma III, which are both great on Linux.

there are also still retro games being played, like Descent, with small and tight-knit communities.

Re: Half-Life and Team Fortress Networking

#27
post #14
post #3

PSA: Add print=1 to old gamasutra articles to get a single page. https://www.gamasutra.com/view/feature/131577/halflife_and_t... Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.

On the other hand, to misquote Philip Greenspun, any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP.

> any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP

Assuming that's true, that doesn't change the fact that TCP is unusable for real-time gaming.

So the solution sounds like a formally specified, bug tested, and fast implementation of half of TCP, as long as it's not the half that breaks soft real-time gaming.

Re: Half-Life and Team Fortress Networking

#29
post #28

I don’t recommend lag compensation. It’s a bad idea because it degrades the experiences of more-committed / better players in order to cater to the less-committed / worse players.

how are they less committed? it's their fault that they live in a country which doesn't exist on the server installation roadmap of stupid greedy corporation? that suggestion was really American for the lack of better word.

let them run their own servers? tough luck, most games in 2017 don't allow dedicated server setup

Post reply on HN