4 ms·

It's been proposed a few times[1], the WebRTC crowd just shows up and says that WebRTC is "good enough" and the cycle continues. Never mind that the dependency

It's been proposed a few times[1], the WebRTC crowd just shows up and says that WebRTC is "good enough" and the cycle continues. Never mind that the dependency graph for WebRTC is way too large and that WebRTC is just too complicated for GameDev needs. [1] https://github.com/networkprotocol/netcode.io https://github.com/networkprotocol/netcode.io

geocar 9y ago
I’ve done webrtc “servers” (in C, not some nodejs bindings for the chromium implementation) and webrtc P2P. It really is “good enough” for a lot of things. But not game developers, who are used to dealing with a very forgiving environment that will let them do stupid things quickly. I have watched game developers in earnest busy wait a network thread “for speed reasons” but also derive approximate linear solutions to nonlinear problems using overflow, wraparound, and so on. Some of the dumbest guys I’ve ever met doing some of the cleverest things, or the smartest guys showing off just how dumb sleep deprivation makes you. I’ve never been quite sure. Games are beautiful. Game developers are beautiful. Game code almost never is.[1] Joining a new game dev team you think this is going to be it, finally some clean code the way the masters do it, but then it isn’t. That is to say: Games aren’t how to do software development, but proof of how far you can get by doing software development wrong. I have thought about packaging my webrtc “server” as a library and selling it to game dev shops, but I don’t think the professional browser market is there yet. [1]: I’m aware of a small number of examples to the contrary, but there are many more counter examples.
- vvanders 9y ago
  Congrats, you've just gone ahead and proved my point. Zero technical reasons other than an ad hoc attack on game development practices. Unless you have a client library that can be paired to that server which takes up less than 200kb of mem you won't see adoption. You're going to want to use one network stack across your products and a lot of the handheld and smaller platforms are really memory constrained.
  - geocar 9y ago
    > Zero technical reasons other than an ad hoc attack on game development practices. These have been brought up ad nauseam so I didn't think it was useful to go over them. The biggest reason UDPSocket doesn't just show up in browsers is that: • Browser vendors don't want to accidentally make it easy to trivially D/DoS servers • Browser vendors don't want to accidentally make it easy to trivially D/DoS clients • It's not clear how to handle NAT traversal except when (interactively) trying to traverse NAT But let's say we don't need anything more complicated than basic hole punching, P2P or cross-origin UDPSocket, and we can solve the trivial D/DoS issue with some kind of Allow-UDPSocket-From HTTP header, or OPTIONS or whatever. And maybe we have some kind of weird HTTP/2.0 transaction that does TURN/STUN automatically. Maybe. Then we can have UDPSocket and you can implement netcode in JavaScript if you want! However, WebRTC has already solved all those problems. Including the NAT one (that SDP/STUN/ICE stuff is there for a reason!). And obviously P2P, but also including some you probably haven't thought of, like issues around IP fragmentation (1200 byte packets!? DTLS fragments things itself for a reason!), and whether rolling custom crypto was a good idea. > Unless you have a client library that can be paired to that server which takes up less than 200kb of mem you won't see adoption. 200k should be plenty: The dumb client can speak a slightly trimmed down WebRTC (e.g. limited to only a single codec) to keep the size down. My webserver which is just about as fast as they get, is only about 1kb of code on the hotpath. But this doesn't answer my questions about a market: I don't sell to game developers, and I genuinely don't know if building a tiny+performant WebRTC client and server business is worth my time. Is it? How much will a game development studio pay to have this problem solved for them?
    - vvanders 9y ago
      DDos is already handled cleanly by something like netcode.io using access tokens. Anything more than the most trivial NAT traversal isn't needed since any online game worth their salt uses dedicated servers in order to prevent cheating and gamestate manipulation. The fact that you're bringing up a 1200 byte packet limit shows that you have no understanding of the domain space. Most networking stacks keep the packet size well under 200 bytes since they don't want to saturate the connection and dead-reckoning deals with state reconciliation. Binary size also matters, so the fact that you want to bring in a whole codec when it may not be wanted isn't a great selling point either. I'm sure there's a market out there given how RAD Tools and other middleware companies do just fine. However I don't think you know enough about the domain to be able to sell it successfully.

geocar 9y ago

I’ve done webrtc “servers” (in C, not some nodejs bindings for the chromium implementation) and webrtc P2P. It really is “good enough” for a lot of things. But not game developers, who are used to dealing with a very forgiving environment that will let them do stupid things quickly. I have watched game developers in earnest busy wait a network thread “for speed reasons” but also derive approximate linear solutions to nonlinear problems using overflow, wraparound, and so on. Some of the dumbest guys I’ve ever met doing some of the cleverest things, or the smartest guys showing off just how dumb sleep deprivation makes you. I’ve never been quite sure. Games are beautiful. Game developers are beautiful. Game code almost never is.[1] Joining a new game dev team you think this is going to be it, finally some clean code the way the masters do it, but then it isn’t. That is to say: Games aren’t how to do software development, but proof of how far you can get by doing software development wrong. I have thought about packaging my webrtc “server” as a library and selling it to game dev shops, but I don’t think the professional browser market is there yet. [1]: I’m aware of a small number of examples to the contrary, but there are many more counter examples.

vvanders 9y ago
Congrats, you've just gone ahead and proved my point. Zero technical reasons other than an ad hoc attack on game development practices. Unless you have a client library that can be paired to that server which takes up less than 200kb of mem you won't see adoption. You're going to want to use one network stack across your products and a lot of the handheld and smaller platforms are really memory constrained.
- geocar 9y ago
  > Zero technical reasons other than an ad hoc attack on game development practices. These have been brought up ad nauseam so I didn't think it was useful to go over them. The biggest reason UDPSocket doesn't just show up in browsers is that: • Browser vendors don't want to accidentally make it easy to trivially D/DoS servers • Browser vendors don't want to accidentally make it easy to trivially D/DoS clients • It's not clear how to handle NAT traversal except when (interactively) trying to traverse NAT But let's say we don't need anything more complicated than basic hole punching, P2P or cross-origin UDPSocket, and we can solve the trivial D/DoS issue with some kind of Allow-UDPSocket-From HTTP header, or OPTIONS or whatever. And maybe we have some kind of weird HTTP/2.0 transaction that does TURN/STUN automatically. Maybe. Then we can have UDPSocket and you can implement netcode in JavaScript if you want! However, WebRTC has already solved all those problems. Including the NAT one (that SDP/STUN/ICE stuff is there for a reason!). And obviously P2P, but also including some you probably haven't thought of, like issues around IP fragmentation (1200 byte packets!? DTLS fragments things itself for a reason!), and whether rolling custom crypto was a good idea. > Unless you have a client library that can be paired to that server which takes up less than 200kb of mem you won't see adoption. 200k should be plenty: The dumb client can speak a slightly trimmed down WebRTC (e.g. limited to only a single codec) to keep the size down. My webserver which is just about as fast as they get, is only about 1kb of code on the hotpath. But this doesn't answer my questions about a market: I don't sell to game developers, and I genuinely don't know if building a tiny+performant WebRTC client and server business is worth my time. Is it? How much will a game development studio pay to have this problem solved for them?
  - vvanders 9y ago
    DDos is already handled cleanly by something like netcode.io using access tokens. Anything more than the most trivial NAT traversal isn't needed since any online game worth their salt uses dedicated servers in order to prevent cheating and gamestate manipulation. The fact that you're bringing up a 1200 byte packet limit shows that you have no understanding of the domain space. Most networking stacks keep the packet size well under 200 bytes since they don't want to saturate the connection and dead-reckoning deals with state reconciliation. Binary size also matters, so the fact that you want to bring in a whole codec when it may not be wanted isn't a great selling point either. I'm sure there's a market out there given how RAD Tools and other middleware companies do just fine. However I don't think you know enough about the domain to be able to sell it successfully.