"But what if –"
Oh come on, we can figure it out. There must be some way.
Also UDP. Yeah, we have WebRTC, but look up Beej's guide to network programming. That's the threshold of intelligence required. Currently to get WebRTC working with UDP for gamedev purposes, it's just... Not easy. Maybe not even possible. I don't know.
We need UDP and we need an install manager. And a few other things. Start thinking about how to extend the browser so we can deliver world-class experiences to gamers.
Let's not forget that the cloud is really someone else's computer and relying on said cloud means relying on someone else for your stuff.
And let's learn a little about all the thousands of Flash games that are in the process of being lost forever with the their hosting sites now shutting down.
Tons of them are archived but these are a tiny minority, at its hayday there were hundreds of Flash games released per day. A lot of that stuff are or will be lost forever.
> Second, how is the web worse than a compiled binary that you don’t have source code access?
The web is worse because for the application to run it needs to be loaded off that web site and the user has no control over that. I cannot for example preserve Google Docs or any other web application i like - i just have to hope that it'll remain online, will keep working with my computer without issues like slowing down and wont change its UI to something i dislike (people often use older versions just to be able to run or because they like the older UIs better).
> Games that are made for the web are easier to preserve and run in the future than native games by a long shot.
How can you preserve a game that you have not full access to its files? Only the developer has that power and developers for the most part have shown over and over that they do not care about the games and applications they make after a couple of years or so.
I have games from companies that closed doors more than a decade ago, if those games were web games, they'd be gone the moment the company shuts down. Or more likely, the moment the company decides they do not want to pay for the bandwidth of accessing the game anymore, like what happened to several MMOs (many of whom are perfectly fine playable solo) already.
> Would you rather run a browser that can play all of the games on the web in a backwards compatible way or rely on emulators for previous operating systems or game consoles?
I'd rather rely on native OS support (above all), compatibility layers like dgVoodoo2 (for 3DFX and older DirectX compatibility in Windows) and Wine (before dgVoodoo2 it was the best way to play old 3D games for Windows) and of course emulators. Remember the games i mentioned above about companies that do not exist anymore? Several of them are for DOS and running perfectly fine in DOSBox.
As i wrote in the message you replied to, it is all about who controls the files and personally i want to have full control of them because i do not trust the developers with that control - they have proven time and time again to not be trustworthy (not necessarily because of their fault, of course, but that is little importance when you lose an game or application you like).
You can’t run google docs offline because what would that even mean? One of the main features of google docs is the live collaborative editing. It’s a multiplayer game that requires a host server.
You can architect your game to be friendly to being archived or you can make it completely impossible by introducing a dependency on the network. This is true for native games and web games.
If a game is fully available on the client side - it doesn't just need to run on the client side, but have everything available on the client side, data files and all - then yes you can archive it. But this is a very limited case and so far only the most simplistic games can be distributed like that. And TBH considering the DRM craze that games have, if anything i'd expect companies to try and make such archival as difficult as possible.
> You can’t run google docs offline because what would that even mean?
Having a word processor, spreadsheet, etc available offline.
> One of the main features of google docs is the live collaborative editing. It’s a multiplayer game that requires a host server.
It is a feature but i'd say that the main feature is being able to edit documents. In terms of games, it is a game with multiplayer features that still requires a host server for its singleplayer part (which is generally something that is frowned upon).
> You can architect your game to be friendly to being archived or you can make it completely impossible by introducing a dependency on the network.
You are talking from the point of view of the developer, i am talking from the point of view of the user. It should be obvious from when i wrote "How can you preserve a game that you have not full access to its files? Only the developer has that power and developers for the most part have shown over and over that they do not care about the games and applications they make after a couple of years or so". It is the user that suffers from such choices, not the developer.
Please try read my posts with the eyes of a user, with the concerns of a user's and try to avoid any developer bias.
> This is true for native games and web games.
Technically yes, but things aren't black and white - there are "natural" tendencies in each approach with the web approach leaning heavily towards network reliant applications and the native approach avoiding it.
Uh, before Google Drive, I'm not sure people were looking for a substitute to Word or other word processors. The "Killer Feature" of Drive is that multiple users can collaborate on the same document, hosted online, in real time. If anything, Google Drive has less features than Word overall. It's having "one true source" instead of emailing around mutliple drafts that is the killer feature for most people. Or having access to that document across all their devices. You could build an offline text editor in the browser, but why would you? (Then again, I use VSCode every day which runs on electron and works totally fine offline).
Edit: I just realized, you CAN run google docs offline. https://support.google.com/docs/answer/6388102?co=GENIE.Plat...
> Technically yes, but things aren't black and white - there are "natural" tendencies in each approach with the web approach leaning heavily towards network reliant applications and the native approach avoiding it.
The native approach has it's own "natural tendencies" that are anti-user, but I'll agree that yes, there are a lot of games that are unarchivable. I don't disagree with that.
> I'd rather not see (offline) games in the browser, or any other online-based method, personally.
This is the statement that you made that motivated me to respond. This is why I tended to ignore what some businesses might do and focus on the developer perspective of "what is possible with these technologies." Because we're already talking about single player offline games.
I guess I'm focusing on the developer side because you seem to be focusing on all of the anti-user things that game devs might do, to which I say "aren't they already doing those on native apps?" I just don't see how the web can make the situation worse. Everyone isn't going to want to play every game in the browser. However, there is great potential for multiplayer games, there is great potential for single player games that compete with mobile (which is by far the most anti-user platform of all!). Yes, people will use for other things, but they're already doing that without the web's help anyway.
Another Edit: > If a game is fully available on the client side - it doesn't just need to run on the client side, but have everything available on the client side, data files and all - then yes you can archive it. But this is a very limited case and so far only the most simplistic games can be distributed like that.
This is increasingly possible with WASM and WebGL.
> Edit: I just realized, you CAN run google docs offline. https://support.google.com/docs/answer/6388102?co=GENIE.Plat....
Yes, but i'm not talking about being able to run something offline, i'm talking about being able to take Google Docs, put it on a CD, DVD, external hard disk or whatever and have it working in 10 years or whatever independently from Google's servers, pretty much how you can do today with -say- Microsoft Office 95 (or any other desktop application available in downloadable or physical format).
> I guess I'm focusing on the developer side because you seem to be focusing on all of the anti-user things that game devs might do, to which I say "aren't they already doing those on native apps?"
> [...]
> This is increasingly possible with WASM and WebGL.
It was possible ever since the days of Netscape when could encode data as arrays in JavaScript and you could make (simple) games with all assets in a single easy to copy around HTML file since Internet Explorer 8 was released.
WASM isn't any different from JS when it comes to how data is accessed. Native/offline games (and other applications) have their data stored locally, all the files are available there and to do anything else it needs the developers to go out of their way to achieve that - which is why practically nobody does such a thing. Web-based games would have their data stored remotely so even if you download the entire code of the game on the client side, you still cannot archive it because you'll practically never have access to all the necessary data files (imagine an open world game, for example, that downloads assets as you roam the world).
> possible with WASM and WebGL
And to try and make myself clear, i am not worried about the possibility of doing something, i am worried about the impossibility of doing something: ie. having full control over the software you are using.
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.
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.
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?
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.
I can set up a netcode.io server and cause it to list any IP addresses I want as "server addresses", then cause a netcode.io client accept that challenge token and permit traffic to that address. If netcode.io is widespread (i.e. in browsers) I can buy some advertising to knock out any client or server I want.
Unless you are in advertising, you might not be aware I can do that: I can purchase something like a million clients for something like $10. Knowing how certain formats work make it possible to purchase more traffic for even cheaper.
These attacks are well known to Google and the WebRTC designers and as such, is not possible with WebRTC: The browser does not permit traffic at volume until ICE/SDP negotiation is complete which means that signalling must have occurred.
By simply limiting the netcode.io clients size to the games that use it (i.e. games distributed with one of the non-browser implementations of netcode.io), this attack is mitigated substantially, but as soon as we try to use netcode.io as a "simpler webRTC" it falls flat on it's face.
Splat.
Perhaps we are lucky that the window.netcode browser extension isn't more popular, or that all those users have ad blockers.
Anyway. The workaround I suggested would probably be sufficient to stop this attack as stated, but it requires a netcode 1.1 or maybe a 2.0 since all clients and servers need to be upgraded. And there might also be other attacks.
> 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.
What Cisco calls Dynamic NAT doesn't work with this scheme. It is popular. Perhaps these people don't play games because game servers don't support their network configuration, or perhaps these people don't play games for another reason.
Non-game uses of UDP are very interested in talking to these networks however. It will be difficult to get buy-in from other parties interested in UDP unless you solve these problems.
> 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.
IP packets fragment once they go above a certain size. That size can only be discovered by experimentation, but will never be smaller than 576 bytes. Many networks block the standard discovery process (called Path-MTU discovery) for misguided reasons, but protocol developers still have to deal with it.
If your UDP packets are bigger than this size, and everything else is working, then losing either fragment will delay the receipt of the datagram and waste kernel memory. Developers who can do their own fragmentation smarter use setsockopt+IP_DONTFRAG and save everyone a potential denial of service opportunity.
If all you want to do is avoid head-of-line blocking on the player's network connection, then multiplexing several TCP connections (even websockets!) will provide the same latency and throughput guarantees that UDP will, getting correct NAT behaviour and resistance to D/DoS for free. Simply drop and reconnect any link on packet loss (trivial to detect on either side), and you only need enough connections to handle the maximum number of dropped packets you can tolerate within the time it takes to reconnect.
I've seen at least one game on HN use this trick in the last year, so I know it isn't unknown.
> 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.
That statement might have been over your head. Sorry about that.
1kb of code "on the hot path" is a shorthand way of describing the code that is executing in L1 and refers absolutely to binary size. My i7 only has 64kb of L1, and anything larger than that requires memory fetch and waits. Keeping the hot path within L1 is a good way to get 1000x speedups (and is a big part of why my code tends to be so fast).
Ulrich Drepper's "what every programmer should know about memory"[1] might be good introductory material for some of these concepts, and I highly recommend you read it.
[1]: futuretech.blinkenlights.nl/misc/cpumemory.pdf
> However I don't think you know enough about the domain to be able to sell it successfully.
Perhaps, and it is a small domain: The only people who think WebRTC is "too complicated" seem to be game developers.
No you can't since netcode.io authenticates packets with a public/private key pair and a sequence id. If either the sequence id has been seen recently or key sig fails it won't accept the connection.
Netcode.io was built by someone who dealt with millions of clients and shipped many high volume games so this isn't anything new.
> If all you want to do is avoid head-of-line blocking on the player's network connection, then multiplexing several TCP connections (even websockets!) will provide the same latency and throughput guarantees that UDP will, getting correct NAT behaviour and resistance to D/DoS for free. Simply drop and reconnect any link on packet loss (trivial to detect on either side), and you only need enough connections to handle the maximum number of dropped packets you can tolerate within the time it takes to reconnect.
> I've seen at least one game on HN use this trick in the last year, so I know it isn't unknown.
Nope, nope and nope.
For one, packet drops tend to happen in bursts so your multiplexed TCP/IP clients just means you're resilient to N+1 drops. Detecting a packet drop is not trivial and you need to go through a whole syn/syn-ack/ack if you recreate. Dropped TCP/IP sockets also don't clean up immediately so you can easily exhaust your available socket resources with this technique.
I played the game that you mentioned and if you seen in the comments the netcode was not ideal. It was pretty obvious that there was some head-of-line blocking even with multiple sockets. Compare that to something like Subspace that ran on a single 250-400ms 56K connection seamlessly back in '99.
Look, I'm sure you're an expert in WebRTC but you don't understand the technical requirements for a realtime netcode. Rather than trying to tell us how we're 'wrong' try listening instead. Games have a pretty unique set of requirements which is exactly why you haven't seen off the shelf solutions like WebRTC gain any traction.
How exactly do you think netcode.io knows that I own (or don't own) 151.101.193.67?
What exactly do you think prevents me from modifying my own netcode.io server at 151.196.182.212 from listing that IP address as one of the game servers?
It's a legitimate connection as far as the client is concerned, and that's what I have a few billion of.
Why do you think the public/private key or sequence ID has anything to do with this? Why do you think for a denial of service attack I care if the "server" 151.101.193.67 accepts the "connection" or not?
> Netcode.io was built by someone who dealt with millions of clients and shipped many high volume games so this isn't anything new.
If it helps you, I've built software with an install-base over a billion, in a place where high latency and bugs don't just mean a dissatisfied customer, but loss of real money.
However talking credentials at this point doesn't help me. It is probably best you respond specifically to what you think is wrong with my thinking instead of bringing up how smart you think your friends are.
> packet drops tend to happen in bursts so your multiplexed TCP/IP clients just means you're resilient to N+1 drops.
If you want to send datagrams at 20hz, and your RTT is 200ms, then 10 connections is equivalent in throughput and latency to UDP: Simply send datagrams down the channel. One side detect a stall? Tear down the channel and move to the next one. Even if you lose 10 packets in a row, the 50msec timer tick means you still recover at least one channel before the 200msec mark.
It's the same as UDP because it's the same number of packets. You can convince yourself of this with tcpdump, and subtract the TCP connect/teardown packets (which aren't blocking anything).
> Look, I'm sure you're an expert in WebRTC but you don't understand the technical requirements for a realtime netcode.
Accepted, at least for these discussions.
One of the principal authors of netcode[1] says that he doesn't understand WebRTC. He says it's too complex.
I have given several examples of things it does better than the published version of netcode if it were immediately adopted by browser vendors, and unless those specific things are addressed, you are going to have a hard time convincing Google and Mozilla to include netcode.io JavaScript bindings.
I appreciate you don't think network address translation is important, and I realise you don't understand the denial of service attack vector I'm describing yet. I think these things are important because I am experienced with their impact, and I know how WebRTC protects users from these things.
You can put your energy into understanding this attack vector, and what others might lay around also hidden from view, or your can put your energy into solving the problems that might make WebRTC a poor fit for game developers. In either case, you probably need to learn WebRTC.
[1]: https://gafferongames.com/post/why_cant_i_send_udp_packets_f...
I think gamedev in the browser is a reality, but it requires two things:
1. Familiarity with Web/OpenGL.
2. Familiarity with well-written Javascript.
Those two camps are typically not the same crowd...
There's a transition period that comes from writing dom-based UI controls into WebGL- and this scares off a lot of solid js developers.
Similarly, there's a transition period that comes from writing C# or C++ into clean JS on the level that games require (e.g. where messy code has a huge impact on development speed and sanity). For example, I think well-written javascript looks more functional than object-oriented. That point could start a flame-war of its own, but we can all agree that the JS in the wild is often messy as hell.
This assumes that JS is the language the game is written in at its core... tbh I don't see WebAssembly replacing this part anytime soon... I see C->WebASM more for like helper utilities. For example, it would be great for a tool to generate geometry for line drawing, rather than manage the logic of when and where to draw the line due to mouse events.
As more people start to glue these sides together, I think we'll see some really cool stuff on the web. Maybe even as cool as the full-flash Away3D type sites we had 10 years ago :P
You can now build html/js that uses webgl directly: https://docs.unity3d.com/Manual/webgl.html
The plugin has been deprecated for quite a while now. Unity compiles to WebGL/Javascript.
That is the same hitch the JVM had. For a non-technical user, that extra step feels risky and unintuitive. "Why doesn't it just work?" feels a bit unfair when you know what's going on, but to a normal user I think it's a fair question. We are the professionals after all, why can't we make it "just work"?