
Half-Life and Team Fortress Networking - setra
https://www.gamasutra.com/view/feature/131577/halflife_and_team_fortress_.php?page=1
======
rjeli
Here’s a nice white paper from Valve with diagrams on lag compensation,
prediction, authoritative server, etc:

[https://developer.valvesoftware.com/wiki/Source_Multiplayer_...](https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking)

~~~
ggambetta
I've made an interactive demo that lets you tweak the different knobs and see
what happens: [http://www.gabrielgambetta.com/client-side-prediction-
live-d...](http://www.gabrielgambetta.com/client-side-prediction-live-
demo.html)

~~~
kernel_sanders
I made my own simple multiplayer 2d game to understand this stuff and just
want to let you know that your site was invaluable to understanding client
side prediction and server side reconciliation! Thanks so much for that!

------
katastic
PSA: Add print=1 to old gamasutra articles to get a single page.

[https://www.gamasutra.com/view/feature/131577/halflife_and_t...](https://www.gamasutra.com/view/feature/131577/halflife_and_team_fortress_.php?print=1)

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.

~~~
dmurray
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.

~~~
reificator
> 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.

~~~
taneq
> TCP is unusable for real-time gaming.

Only for the twitchiest of twitch games really needs lower latency than TCP
provides. So many amateur/indie game devs waste huge amounts of time messing
with UDP because "everyone knows TCP isn't realtime" when TCP would have been
perfectly suitable for their game.

~~~
reificator
Completely disagreed. If you're amateur/indie, use a premade engine that has
networking. If the engine's networking isn't good enough for what you need,
there are probably some options on the store that meet your needs.

------
gfodor
For those interested in game neworking I found this to be a good book on the
subject:

[https://www.amazon.com/Multiplayer-Game-Programming-
Architec...](https://www.amazon.com/Multiplayer-Game-Programming-Architecting-
Networked-
ebook/dp/B0189RXWJQ/ref=sr_1_2?ie=UTF8&qid=1511654324&sr=8-2&keywords=game+networking)

Also this is a good paper (10 years old) on DOOM 3's networking:

[http://mrelusive.com/publications/papers/The-DOOM-III-
Networ...](http://mrelusive.com/publications/papers/The-DOOM-III-Network-
Architecture.pdf)

------
matt_wulfeck
> _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 subkeys? Is it RSA?

~~~
neandrake
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...](https://stackoverflow.com/questions/3002067/how-are-software-
license-keys-generated/3050217#3050217)

~~~
Retric
Another approach is to add a key file as ~32MB gives 2 million 128 bit hashes
and you can go up / down on key length and file length. This still takes more
effort than a single Master, but doing 1-2 Million from a master is perfectly
reasonable.

------
Thaxll
This paper is what started a lot of things now still in used today, the tribe
model:

[http://www.pingz.com/wordpress/wp-
content/uploads/2009/11/tr...](http://www.pingz.com/wordpress/wp-
content/uploads/2009/11/tribes_networking_model.pdf)

------
roflchoppa
> "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.

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

~~~
alkonaut
I still play a short list of favorite servers in BF4. This is a game from just
a couple of years ago. Are you saying some newer games _only_ have random
matchmaking and no joining a favorite server?

~~~
juliangoldsmith
Most new games I've seen have only random matchmaking, unfortunately. Even
Quake Champions.

------
lakjsdlfkjasd
It's close to quake 3 protocol as well. It's not uncommon to see fake server
listings with fake players and server information, some of them even allow you
to connect to.

------
Hurtak
It is a 17-year-old article. Did the fundamentals stayed the same or has there
been any significant paradigm shifts in how game networking is done?

~~~
Thaxll
Still the same :)

~~~
skrebbel
Everybody keeps repeating that things are changing so fast in IT land that
it's hard to keep up. This is a nice example of how that's only superficially
true.

------
Zolomon
There are more resources like this on networking at
[http://gamedevs.org](http://gamedevs.org).

~~~
erikbye
Also: [https://gafferongames.com/](https://gafferongames.com/)

------
jblow
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.

~~~
comex
How so? More committed / better players aim more precisely, and thus benefit
the most from a system that judges their shots based on whether they hit the
target on their screen - as opposed to a space some distance in front of their
target, with the distance depending on their latency to the server (which of
course varies depending on the server's location). On the other hand, worse
players' aiming has a higher degree of luck/randomness, so it should be less
affected by the target being off.

edit: Maybe you mean that lag compensation makes it harder to avoid others'
shots. But does that really reward less skilled players? If anything it
rewards players with higher ping, but that's not necessarily the same as worse
or less committed. I suppose that _really_ uncommitted players are more likely
to try to game over some crappy Wi-Fi or even cellular connection, whereas for
committed players, latency is more likely to result from distance. But that's
a rather low threshold of commitment. In any case, having a really high ping
comes with serious disadvantages, including rubber-banding, a harder time
avoiding shots, a harder time aiming with anything that isn't lag compensated
(e.g. projectiles), etc...

Also,

> High-budget games these days locate servers around the world, so that is not
> an issue.

Even assuming there are enough players to fill the severs, it's only a non-
issue if you're matchmaking alone. If you want to play with specific people -
through either a party system or traditional named/player-operated servers -
and they happen to live far away, you can't avoid latency. Of course, there's
always going to be some ping value beyond which the game isn't worth playing,
even with lag compensation - but it's a higher value than without. And at
intermediate levels of latency - say, 100ms - lag compensation can be the
difference between a passable experience and an effectively perfect one.

~~~
leoc
High ping definitely makes hitscan aim easier in Valve FPS multiplayer.
(Projectiles, OTOH, aren’t lag-compensated.) There was that one time a top-
tier North American Team Fortress 2 team brought in a Brazilian Sniper as a
substitute in an official match, apparently in an attempt to game the system.
But that was an unusual event.

------
pushedx
I have had a suspicion for a while that "Flat Earthers" are trolling everyone
into giving them a free ride into space in order to prove them wrong.

~~~
artofcode
Wrong thread:
[https://news.ycombinator.com/item?id=15777831](https://news.ycombinator.com/item?id=15777831)

