Doom 3 in WebAssembly
continuation-labs.com
continuation-labs.com
Also, download code is dumb for now, it is downloading one big full .pk4 file (400MB) for each visitor loading the app. I know, it should be better to only preload necessary assets for sure! Smart streaming of game data is one necessary step for apps on the web.
[1] https://kotaku.com/5866594/you-can-now-play-bastion-in-googl...
This loss of control over the software i use is my main annoyance by far as a user when it comes to the trend of pushing everything as a web app.
It does[0]. It's just a spec for a bytecode, and it's designed with the intent of being run in the browser and natively.
It’d be cool if browsers let you back up local copies of sites though.
But no one minds downloading a multi-megabyte or gigabyte game over Steam or console, because users are trained to expect that to take a while.
So what's needed, in my mind, is something with a user experience between the two - for games and applications to run in something more akin to a "package manager" mode than a basic browser window. Or maybe, on the web, have some alternative content to distract the user while the content downloads.
The size of the entire download could possibly be reduced by having browsers ship with some standard plugins and modules, maybe runtimes (imagine having most of the Unity framework already in the browser.)
Maybe, just maybe, they could not run in a browser window.
You could keep all the benefits of URLs and the web, but not have to actually tie the browser down with executing in a webpage.
Steam actually offers the option to start playing before the download is complete on a few titles (not everything supports it)
Then again, they're consolidating faster than the T-1000 in the foundry.
Steam is already a very good solution for distributing PC games and it has the added benefit of implementing a payment model, DLC features, social capabilities, updates, cloud-synchronized saved games, and, perhaps most importantly, a discovery service for finding new games. It even supports automatic WINE mode for windows-only games in linux (a feature that surprised me).
I welcome the day when more games run automatically in OSX or Linux, but I think the need for an app platform isn't going to go away. And as someone who plays games often offline (on a plane or sometimes the train) it's really nice to not require an internet connection to play something.
I'd be interested to see how landing on a webpage with a game ready-to-go turns non-gamers such as myself into infrequent or even frequent gamers.
I would also argue that the ubiquity of the web is what makes games like agar.io and slither.io so popular, especially for kids. I remember being at techshop in SF and seeing kids rushing straight to their computers after school and opening slither.io and playing instantly. No friction. I'm sure that lends to their success.
The web is great!
Or is it f2p? So you land on page, still need to make an account for persistence. Also will need to do credit card eventually for game developer to make money. Also now game developer is looking at cdn costs of over 500 a month at a minimum for any kind of real game that is even 0.5 gb in size.
I actually own a web assembly f2p game like this. It is really not a bright future for games that compete with real client games on steam that are not tiny and have the barest performance requirements.
With unity basically the entire game needs to fit in like ~512 mb of ram, and runs poorly.
Regarding the CDN costs, with some very aggressive caching (Service Workers and stuff), is it really that much worse than a downloaded game? You're the one who actually has a game, though, so I guess there really is a problem here.
Steam is kind of a nice walled garden. The problem is that it's not the only one and that there is loads of stuff outside their walls. There's the Apple store, the Google store, the Amazon store. And that's just mobile.
A few things these stores have in common: - pay to play: they all heavily promote games that pay to be promoted. This favors games with big budgets and is a monetization problem for smaller players; like indie games. - censorship and conflicts of interest between application/game developers are a problem regularly result in applications being blocked/removed for all sorts of reasons that boil down to arbitrary restrictions imposed by the store owner. - extortion rates on monetization, in app purchases, subscriptions, etc. make being there costly. - search is a problem. Even Google's search in the appstore is comparatively shit. I regularly resort to using their web search to find apps I know definitely exist in their app store. Apples store is a maze of misdirection. Their search is shit. - Getting into the store requires a non trivial amount of work and in some cases entrance fees.
PWAs fix the distribution problem and remove app stores as a necessity for that. Google, Duck Duck go, already take care of the discovery problem better than most app stores and in any case people discover things via social media, friend referrals, etc. Being featured in the top 20 of the IOS app store is not a feasible thing for most developers. Also, browsers already keep us safe so we don't need to rely on app store screening any more.
So, time to tear down those walls once more.
The history of walled gardens is that eventually somebody climbs over the wall and figures out there is a world beyond. Biblical stuff even, if you are into that ;-).
This might be an interesting POC, but seems very impractical in reality.
I recently found my Doom 3 CDs and tried installing it on Win10, but apparently doesn't work out of the box on 64-bit (crashes at start) without manually patching for using > 2 GB of RAM from the cursory googling I did.
If this does work later, will have to show it to my 11 year old step son. Was hoping to freak him out with Doom 3 when I found my disks (he loves shooters & scary movies, so thought he might get a kick out of it).
Sidenote: The Doom 3 BFG edition also gives you the original Doom games although they've been nerfed a little from the original. (e.g., the stimpacks no longer have the little crosses on them because of a lawsuit from the Red Cross)
Local HN submitter ruins everything :(
The browser is the solution to the presentation/distribution problem. I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else.
I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves.
no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.
> An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment.
The final dream is having a unified, Desktop, Consoles (Ps4 and Switch) and Browser runtime with a unified API (where sensible). One can dream.
With the browser, you're just adding another abstraction layer that has even more complexity. WebGL is far for a decent spec. And we're talking just graphics, as I mentioned before, audio and networking have tons of unstable and untested code.
Multimedia programming is already hard on native environments. I don't see the web being a friendly environment anytime soon. There's no silver bullet, "code once, run anywhere" for games and multimedia.
Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper.
>I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves.
This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that.
>no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.
Except the browser is the "launcher" and the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.
I agree, except for the magnitude difference in time required in most cases.
A web-app that takes more than 10 seconds to load is consitered broken to many. A desktop app that can go from "discovery" to "using" in less than a minute is consitered fantastic. Plus then there are update headaches.
I genuinely believe one of the major reasons why the web is taking over is because every other platform makes the process of "installing" code such a difficult slow process.
Not to mention the security issues with giving code access to desktop systems which traditionally are difficult for the average user to secure. And the fact that I don't ever think i've had a piece of installed software ever completely "uninstall" itself correctly. They always leave stuff behind. In a browser, a single "clear browsing data for this domain" gets rid of all of it, entirely.
>This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that.
But you do. Some platforms (like iOS) don't allow distribution over any methods other than their app store, or a browser. Still more heavily discourage distribution over HTTP (most linux distros). And most users will download the "installer" for a game via a browser in the extreme vast majority of cases, so why not cut out the middleman and just allow the game to be playable in a browser?
There are also other benefits of a web-platform game, like the ability to "deeplink" inside the app. I can not only share a link to the game, but can easily share a link to a specific screen in the game, or can share a link to allow you to connect to my game. And that whole process is crawl-able for search engines, and easy to implement. Sure, it's possible to do with desktop software, but it's much harder in most cases, especially when you throw cross-platform into the mix.
>...the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.
While of course a specific site can act as a gatekeeper, that's not what I was talking about. Time and time again we see stories about how Apple removed some app from the app store, or some company pulls their subscriptions from being allowed to sign-up on iOS devices, or how some game makes their own app-store to get around the limitations on android, or even how most "app stores" don't allow adult content.
That is the kind of stuff that the web-as-a-platform gets you away from. You aren't going to have Google removing your app because it's too adult, or Apple charging you a 30% fee for all subscriptions made on their platform.
I'm all for streamlining this process to allow users like yourself that want a "local install" to get it, but I don't think we should throw the baby out with the bathwater here. Browsers give us a shitload of benefits, and the discovery and "install" process (or the lack of) is second to none. I think we can work with those benefits, and give users and developers the options needed for other formats if they want.
For example, The microsoft store has started allowing PWAs to be listed, browsers could work with the OS and define some APIs that allow you to choose where to "install" a PWA or web game, possibly even allowing you to simply move it or uninstall it after the automatic "install" happens.
We are finally getting away from the days where it would take tens of minutes to download and install software on a computer, where it would require you to give a considerable amount of trust to that software once you run it, and making it really hard to share content within apps with others. I don't see why you would want to go back.
But now that I said all of that, I realized that I don't really know why someone would want to not have it. So I guess my question is why do you want a traditionally "installable" code? Is there something I'm missing here, or some assumption that one of us is making that is getting rolled in with this conversation?
>I think we can work with those benefits, and give users and developers the options needed for other formats if they want.
That's literally what I'm advocating. Not getting rid of webassembly applications in the browser, but also having native runtimes that are optimized for running the same webassembly applications.
Every benefit that the browser as application model provides could improve the way native applications work as well - there could literally just be a button or an option in the browser to "install as native" and the Webassembly binary in the browser could just be copied somewhere, maybe with some metadata, and an icon generated for the desktop. Native runtimes could sandbox them just as a browser might, and the uninstallation process need be not much more complex than dumping a cache or deleting a folder.
Your last paragraph basically describes a browser with a special "install" flow. Mobile Chrome already has a flow like that for PWAs where it will ask you "do you want to add this to the home screen?" and it will add the icon to your app drawer on android just like any other app, allow you to "uninstall" it just like any other app, and when you launch it it launches fullscreen just like any other app.
I'd love to see this expanded to cover desktop as well. And with some additional work (like giving the option to move storage data to different drives or manage apps based on their hostname more easily), it could become a very powerful system.
If you want to learn more, take a look at the google developers page for PWAs. It seems to be what you are looking for in some ways!
devdocs.io is one of them.
Like the parent commenter said, i'd welcome more control over the storage of that data, but it absolutely can and will cache large blobs like that.
The best would be that all browsers support the Chrome Filesystem API, but that's not for now
I'm assuming the time required to store and request a massive blob gets excessive at some point, but were there any other reasons?
It will be, as long as we can stay away from the paradigm of Electron as the de facto runtime for Webassembly. Despite its name, Webassembly doesn't need to run in a browser, we can have executable WASM run in thinner native clients.
Creating compiled applications that look halfway decent is REALLY hard with compiled UI toolkits, for the most part. And really easy for browser based toolkits. While I don't appreciate the additional bloat of Electron itself, it is a nice option. I would like to see something similar be available as a cross-platform baseline, auto-updated like chrome. Node + Carlo could be an option, which would at least use the platform installed Chrome.
In the end, something like Adobe's Air platform could be incredible, but run by a company that supported more modern JS, and rendering. My hope is that with MS changing Edge to use Blink's engine that something like this could evolve and be adopted by other platforms.
The only thing a browser offers is an HTML and Javascript context... which are necessary to run it in a webpage, but not really the entire purpose of webassembly as a concept.
... but yes, surprised how well it ran on my old laptop!
It's much harder for apps that are trying to render to the DOM (which is very slow). But WebGL apps should be perfectly fast in browsers...
The reason for the performance penalty with Firefox on Linux is that the framebuffer content is copied from GPU to host memory, compositing is done and then it's copied back to GPU.
For other platforms I'm not sure.
Further, SIMD support has been removed from Javascript and not been added back to WebAssembly yet, so that's another factor 4-8 for computation-heavy code. Experimental pthread support is only available in Chrome experimental for now due to the Spectre and Meltdown exploits. And general GPU compute apparently is really tricky to implement in a secure way, although DOOM does not use it.
Shouldn't happen with GPU compositing in Firefox (layers.acceleration.force-enabled), right?
Can you talk a bit about the biggest problems you faced?
Also, I'm a bit familiar with the doom 3 code, and the loading a 400mb pk4 file issue can easily be fixed by extracting it and loading/streaming the necessary stuff for each level and such.
Getting things working on platforms other than originally intended is really hard. Nice work!
https://groups.google.com/d/msg/emscripten-discuss/pKcWvKppj...
I was having a lot of audio cutouts too, and the framerate tanked when the actions started heating up. Imps jumping around could drop it to the low single digits. Still, pretty impressive for playing in a browser.
Not trying to be rude, but this phone doesn't exist,