I’m wondering whether they really had to implement everything in order to learn those lessons. The “lessons” are pretty much the widely-known basic definitions of the well defined terms contained within them. It’s not like we’re talking about a chaotic emergent phenomenon that arises due to the complex interactions of the pieces in a complex system.
The content is originally from 1999.
I’m with enobayram – as a hobbyist game programmer in 1999 it was painfully obvious even then that TCP really wouldn’t cut it for any kind of twitch gaming over the internet.
Basic texts on networking also taught TCP was used for reliability with UDP for speed. Troubleshooting or warning guides talked about how TCP performance could drop off due to congestion control algorithms. So, I was writing reliable protocols on top of UDP. Until I discovered UDT. :)
Just sounds like the author never discovered this the easy way when learning about network programming. Then, had to discover it the hard way.
To be fair I think part of the issue was also expectations of LAN vs WAN. A “how bad could it be” when the answer turned out to be horrific.
For the record the author has learned his lesson in many ways and is doing fine (I work with him).
[Comment removed by author]
I imagine you would have a layer ontop of UDP that ensured the delivery of a few different classes of packets and let the ones where if you lose a few packets it wouldn’t matter as much. Also, you’d probably want a synchronization packet to synchronize the world state every now and again to avoid the client getting too far away from the server world view. so the light switch object would be guaranteed to be synchronized fully after n-intermediate packets.