It's very nice to see that this "scales down", so-to-speak. It can be really disheartening to see small programs compile into hundreds-of-kB binary images. It's great to see that Rust+WASM can be so lean!
One big jump in binary size starts when you use the allocator, as then it needs to include the allocator's code.
Multithreading doesn't matter to wasm yet, incidentally; it's still single threaded.
The demo in that MDN page has the help text "Use the WASD (ZQSD on AZERTY) keys to move and steer" which doesn't inspire much confidence if it implies that you need to list controls for every possible keyboard layout and rely on the user knowing what they've got.
A good way to illustrate the controls could maybe be with an image? The keys on the image could say WASD for all I care, as long as I'm able to see the position of them, which is what matters.
There are similar issues for other things than games. Quite a few programs have `Ctrl + /` or similar as a keyboard shortcut, which is easy on an american keyboard, but on a Swedish one there's no dedicated key for slash (it's `Shift + 7`). The same goes for most symbols except A-Z (I use Swedish QWERTY), they are in other locations and with other modifiers.
Best, of course, is when you can get the character based on the physical key. One example of this is Visual Studio Code, where the shortcut for toggling the console is `Ctrl + Ö`, and presented as such. I assume they defined the shortcut by the physical key (the one to the right of `L` in this case) and presented it by its character.
You still see native apps getting this wrong, though. On a UK keyboard Sublime Text's view menu says that "Show Console" is Ctrl-` (backtick), but the key that actually shows the console is Ctrl-' (single quote). Took me a while to find that.
That's on Linux though, what are you on, Windows?
SublimeText Version 3.0, Build 3143
Maybe shooting needs a cost associated with it.
I spent the weekend playing around with Rust/WebAssembly too - calling between Rust and WebAssembly is a bit more fiddly than I expected, but I can understand why they did it.
I ended up trying to write a text adventure in Rust/WebAssembly for Ludum Dare (https://ldjam.com/events/ludum-dare/40). Due to other commitments, I ran out of time for the (48-hour) "competition", but am hoping to get something working in time for the (72-hour) "jam", which ends tonight.
(Brief blog on my initial experiences at https://maffydub.wordpress.com/2017/12/02/getting-started-wi... .)
A binary blob, that cannot be viewed except with an offline hexeditor.
WASM sucks. Please remove support and go back to ASM.js, at least it was readable and fast. Or transpile to JS in the first place. Thanks for destroying the open web.
If I go to https://www.hellorust.com/demos/add/index.html, bring up the "Sources tab under Chrome Developer Tools and click on "Run", then a "wasm" item appears - clicking on that shows me the disassembly.
Do you not see a "wasm" item?
 - https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
 - https://becominghuman.ai/passing-and-returning-webassembly-a...
Or to keep things even simpler, if every class of draw instructions is always performed in order (so not drawEnemy, drawText, then another drawEnemy) you could just have separate arrays of arguments for every draw type.
Anyway for your game specifically I doubt this is even close to an issue, but I'm curious just how performance scales when you jump in and out of JS a lot in WASM.
Yup! This is currently a very low-level target; we're actively working on stuff here. It'll get nicer over time!