9 ms·

Yes. Please, someone, make gamedev in the browser a reality. There are a thousand hitches: Why can't I install a 9GB game on the browser? We need all that space

Yes. Please, someone, make gamedev in the browser a reality. There are a thousand hitches: Why can't I install a 9GB game on the browser? We need all that space for textures. "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.

vvanders 9y ago
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?
      - 9y ago
lxtx 9y ago
I've written a library for that purpose [1]. It's not ideal, but I guess it's as close as you can get to UDP in a browser without using extensions. [1] https://github.com/seemk/WebUDP https://github.com/seemk/WebUDP
dakom 9y ago
> Yes. Please, someone, make gamedev in the browser a reality. 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
badsectoracula 9y ago
I'd rather not see (offline) games in the browser, or any other online-based method, personally. I want to have control over the games' data files so i can copy them to my external hard disk, be able to run them in 10 years without hoping some server is still online and their owner gives a damn about stuff they made 10 years ago (most stop giving said damn within a couple of years, let alone 10), etc. 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.
- chickenfries 9y ago
  I don’t understand why you object to browser games but use flash as an example of what could happen? First of all, tons of flash games are archived. Second, how is the web worse than a compiled binary that you don’t have source code access? Games that are made for the web are easier to preserve and run in the future than native games by a long shot. 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?
  - badsectoracula 9y ago
    > First of all, tons of flash games are archived. 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).

vvanders 9y ago

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?
    - 9y ago

lxtx 9y ago

I've written a library for that purpose [1]. It's not ideal, but I guess it's as close as you can get to UDP in a browser without using extensions. [1] https://github.com/seemk/WebUDP https://github.com/seemk/WebUDP

dakom 9y ago

> Yes. Please, someone, make gamedev in the browser a reality. 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

badsectoracula 9y ago

I'd rather not see (offline) games in the browser, or any other online-based method, personally. I want to have control over the games' data files so i can copy them to my external hard disk, be able to run them in 10 years without hoping some server is still online and their owner gives a damn about stuff they made 10 years ago (most stop giving said damn within a couple of years, let alone 10), etc. 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.

chickenfries 9y ago
I don’t understand why you object to browser games but use flash as an example of what could happen? First of all, tons of flash games are archived. Second, how is the web worse than a compiled binary that you don’t have source code access? Games that are made for the web are easier to preserve and run in the future than native games by a long shot. 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?
- badsectoracula 9y ago
  > First of all, tons of flash games are archived. 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).