Item — HN Reader

Valve recently announced partner access to their network backbone which addresses a lot of the problems mentioned here:

    * Access to our network, giving your players protection from attack, 100% reliable NAT traversal, and improved connectivity.
    * Tools for instantly estimating the ping between two arbitrary hosts without sending any packets.
    * A high quality end-to-end encrypted reliable-over-UDP protocol.

>> Second, clients can select a route that gets off of the public Internet and onto our dedicated links as early as possible. On our backbone we can ensure that the routing is optimal, since we have peered with over 2,500 ISPs. We also prioritize the latency-sensitive game traffic over HTTP content downloads, which we can afford to do because game traffic makes up a relatively small percentage of our overall bandwidth utilization. And on our backbone, a sudden surge of traffic unrelated to gaming won’t degrade the experience.

https://steamcommunity.com/groups/steamworks#announcements/d...

They started using it in some of their games a couple of years ago (Counterstrike Global Offensive and Dota2 if I recall correctly).

1 comments

Which is great if Steam is your only platform and you want to be tied to Valve forever, but as soon as you want your game on mobile, console or even another PC store like Epic or GOG you need another solution.

Microsoft and Apple are far worse IMO by pushing their proprietary graphics APIs. I see Valve more as their competitor than as a threatening monopoly. In the future, things can change though, nothing is fixed.

More "graphics API is the worst lock in possible"... With an online game it's way easier to escape graphics "lock in", especially considering almost everyone is using a game engine (Unreal or Unity) that hides most implementation details from you. There are challenges with porting graphics apis are different shader languages but with glslang and dxc supporting different languages it's basically a solved problem. The main issue with service lock-in, and why it's worse than proprietary graphics APIs is that it blocks cross play. So even if you wrap the API for different platforms Steam users cannot play with Xbox users, etc. The idea that graphics API is the biggest bottleneck to game portability (especially across systems that also have proprietary windowing systems, threads, audio, input, programming languages, network libraries, etc) because John Carmack said we should use OpenGL 20 years ago needs to die.

Try using Valve's game controller outside of Steam. Huge PITA.

That's not really a lock-on. The "tube" level of multiplayer stack can usually be abstracted away even easier than graphics API (and almost no modern game engine supports less than at least two of those). Just compose a packet of a reasonable amount of bytes, configure a connection overall profile (reliable/unreliable, which usually, but not necessary, maps to TCP/UDP), and you're done.

I'd be much more afraid of vendor lock-in that actually runs throughought your code base and shapes it.

i hate these underhanded "use this cool feature that we made to lock you in to our platform" tactics

???

Isn't the entire point of the original article to lock you into the Network Next platform by forcing you to implement their SDK?

I think every network provider is going to work to lock you into their platform.

Well, in defense of Network Next, their system seems to fall back to public routes if there's no benefit. That doesn't seem too much like lock in, since you have to have public servers working anyway.

Nope, still lock-in.

You have to use THEIR APIs. It won't work if you use regular networking code. Gotcha!

Our APIs are just simple replacements for UDP sendto/recvfrom and they’re open source. While they won’t work unless you work with our marketplace, if they don’t work, they just fall back to regular UDP packets. How is this lock in again?