Wow, what an impressive game for the web browser, and in such a small size!
I'm particularly impressed by the variable lighting of the bullets down hallways, that's really quite masterful work.
Kudos!
Edit: I am impressed because I'm impressed. I spent a few weekends recently messing around with pygame, and I had a really hard time organizing my code and my thoughts. I do primarily numerical, technical work, and I see that there is something challenging about writing a game that I haven't come across much in 25+ years.
Feel free to shit on my comment, but I still think it's a very cool project, and seeing it run so smooth in a web browser, in a vm, on a beat up box with a Celeron was surreal to me.
Ok, I'm not trying to take anything away from the developer here but calling this "masterful" makes me think you must have incredibly low expectations for webtech games and/or developers.
Or incredibly low expectations for programmers in general, which is fair. If you pick 100 random run-of-the-mill programmers from any corporation, and ask them to repeat this exercise, 95 of them would not even get out of the starting blocks. I liked it.
(It was a js13kgames submission in 2018; I’m guessing that this being submitted here now is in some way linked to how Q1K3 is currently on the homepage, also a js13kgames submission, though for 2021. Pure speculation.)
• There’s an & that should be either & or &, depending on whether it’s setting HTML or text.
• The opening garbage text is mojibaked, so that it looks like… different, not as æsthetically pleasing garbage.
• The text that’s supposed to be like “7 SYSTEM(S) STILL OFFLINE” is getting mangled badly, missing much of the string and getting a bunch of U+0000s in it—unchecked and incorrect string indexing, by the looks of it. Hmm… “1␀␀␀␀␀␀␀␀␀␀STIL1␀␀␀␀␀␀␀” actually looks like something’s clobbering the string literal stillOffline. Ouch; that actually worries me, though I hope it’s largely just a side-effect of some shortcuts taken to keep the code tiny and not something that would normally be an issue?
• terminal_text_outro has some double quotes that should be single quotes (apostrophes).
For what it's worth, the original 13kb JS only version[1] does not have these problems.
I was confused for a second why this game made its way to HN again (there's a making of for the game itself from 2018[2]). This seems to be a port of the game to D[3] as a demo for a WASM runtime, Spasm, which is also written in D[4].
Pretty impressive performance. It seems web assembly is pretty good tech for writing a performant web app. Is there any benchmark comparing web assembly vs javascript? I mean the same logic executed by javascript code vs the web assembly.
Also curious to know if there are any serious web apps developed using web assembly.
Figma uses webassembly. We also use it for our web engine at https://castle.xyz, I gave at talk about that you can watch here: https://youtu.be/0FjCaoc1uzs where I go into some details and also do some live wasm game development (not sure how "serious" since we're still working on our app though).
Much, much better performance than JS is possible because (among many other things) you can perform a lot of optimizations during AOT compilation due to eg. LLVM, avoid GC and arrange memory to help cache efficiency.
Re: JS call overhead, ultimately using instanced drawing so you have a constant number of draw calls even for a growing number of objects is what helps.
I compared it casually with the original JavaScript implementation: in both Firefox and Chrome, both JS and WASM hit max FPS easily (165, in my case, incidentally). According to Firefox’s profiler, the JS version experiences noticeably more frequent jank; Chrome’s profiler doesn’t obviously show any jank for either. In Firefox, both are around 50% idle and there’s no obvious difference in their performance, though they definitely have different hot spots. In Chromium, indications suggest the WASM is being a few percent more efficient, spending 68–70% idle versus JS’s 65–66%; it spends much less time in scripting (~17% vs. ~22–23%), but more in rendering, painting and “system” (whatever that is) which make up the balance of that 100%.
These results are utterly unscientific. You also can’t compare Firefox and Chrome’s profiling numbers to one another.
I don't think you say much about the performance here except that it isn't noticeably terrible. Any modern computer should be expected to run this kind of thing with a smooth framerate using paltry resources. I would expect this even if this had been written directly in javascript.
My understanding is WASM is pretty performant except in the case when it needs to interact with browser apis / js where is preforms quite a bit worse than JS.
I recently discovered https://lekh.app which uses web assembly. I had a conversation with the developer and he told me that he is using web assembly for the core diagramming and shape recognition logic. The app is for diagramming and whiteboarding.
The whole diagramming and AI (to recognize shapes) is compiled into ~1M of web assembly.
I am the developer of https://lekh.app When I first experimented with the web assembly, it was kind of magic for me. I had a diagramming app called Lekh Diagram (https://lekh.app/diagram.html). The core logic was written in C++ and is being used in Android and iOS apps. I wanted to make a collaborative web version of the app. Initially I thought I would have to rewrite everything in Javascript. But when I first tried to compile all the c++ code into web assembly, it was around 4M of web assembly. And the performance was awesome. I was pretty satisfied with 4M. Then I started developing the Lekh Board (web version of the diagramming app). Later in the development phase, I realized there is a flag which I can pass to reduce the size further. Then I got the web assembly size ~1M.
Readit News
I'm particularly impressed by the variable lighting of the bullets down hallways, that's really quite masterful work.
Kudos!
Edit: I am impressed because I'm impressed. I spent a few weekends recently messing around with pygame, and I had a really hard time organizing my code and my thoughts. I do primarily numerical, technical work, and I see that there is something challenging about writing a game that I haven't come across much in 25+ years.
Feel free to shit on my comment, but I still think it's a very cool project, and seeing it run so smooth in a web browser, in a vm, on a beat up box with a Celeron was surreal to me.
Many of us could code something like this technically but it would play horribly and look worse - and would be more than 14kb of WASM
It is the little things, the lighting, the little sound effects, even the unlimited ammo
Deleted Comment
"Unreal Engine 3 Support for Adobe Flash Player - Epic Citadel"
https://www.youtube.com/watch?v=xzyCTt5KLKU
(It was a js13kgames submission in 2018; I’m guessing that this being submitted here now is in some way linked to how Q1K3 is currently on the homepage, also a js13kgames submission, though for 2021. Pure speculation.)
Source code: https://github.com/phoboslab/underrun
The original js13k game implemented a small sonant-x player for the audio, both sound fx and music.
https://github.com/skoppe/spasm
-- [0] - https://github.com/skoppe/spasm/tree/master/docs/examples/un...
• There’s an & that should be either & or &, depending on whether it’s setting HTML or text.
• The opening garbage text is mojibaked, so that it looks like… different, not as æsthetically pleasing garbage.
• The text that’s supposed to be like “7 SYSTEM(S) STILL OFFLINE” is getting mangled badly, missing much of the string and getting a bunch of U+0000s in it—unchecked and incorrect string indexing, by the looks of it. Hmm… “1␀␀␀␀␀␀␀␀␀␀STIL1␀␀␀␀␀␀␀” actually looks like something’s clobbering the string literal stillOffline. Ouch; that actually worries me, though I hope it’s largely just a side-effect of some shortcuts taken to keep the code tiny and not something that would normally be an issue?
• terminal_text_outro has some double quotes that should be single quotes (apostrophes).
Other than that, seems to be working well.
I was confused for a second why this game made its way to HN again (there's a making of for the game itself from 2018[2]). This seems to be a port of the game to D[3] as a demo for a WASM runtime, Spasm, which is also written in D[4].
[1] https://phoboslab.org/underrun/
[2] https://news.ycombinator.com/item?id=18031024
[3] https://github.com/skoppe/spasm/tree/master/examples/underru...
[4] https://github.com/skoppe/spasm
Else folks get stuck at "Initializing..." with an exception in the console. Not everybody checks the console.
(TypeError: can't access property "createBuffer")
Edit: stuck at "Initiating..."
Also curious to know if there are any serious web apps developed using web assembly.
Much, much better performance than JS is possible because (among many other things) you can perform a lot of optimizations during AOT compilation due to eg. LLVM, avoid GC and arrange memory to help cache efficiency.
Re: JS call overhead, ultimately using instanced drawing so you have a constant number of draw calls even for a growing number of objects is what helps.
These results are utterly unscientific. You also can’t compare Firefox and Chrome’s profiling numbers to one another.
Deleted Comment