Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: A WebAssembly game demo (funkykarts.rocks)
251 points by rossisred on May 24, 2017 | hide | past | web | favorite | 108 comments



Hello,

I have also been taking notes while building this here:

http://www.rossis.red/wasm.html

I'm happy to answer your questions about it.


Very nice write-up, thanks!

BTW, I also ran into issues with ScriptProcessorNode when generating audio, and ended up using `createBufferSource` with a scheduled playback time. I wrote a little about it here: https://binji.github.io/2017/02/28/binjgb-on-the-web-part-2....


Thanks for sharing! Your article is what I was looking for and didn't find when I was working on the audio :) That is an interesting approach which I will definitely try.


Really cool project. Just tried on my Moto E 2nd gen with Chrome and it was smooth as butter. Are you storing images as svg inside the wasm blob? Seems like you're not batching draw calls? Was the Dart app not fast enough?


The 2D elements (menu buttons, background trees, etc...) enter the game's editor as SVG, where they get converted to an intermediate vector format that is optimized to be loaded and rendered fast. That intermediate format is what's inside the wasm blob.

Regarding draw calls, I could definitely batch more than I do. But the game is rarely draw-call-bound so I haven't had a reason to optimize that part of the graphics pipeline.

Dart is still used in the game's editor, which has been stable for a couple of years now. For the production engine, C++ just makes too much sense. It is what made this WebAssembly demo possible :)


Is it a custom vector format? Are the vectors rendered on the gpu?


Yes, it is a custom format. The paths are "triangulated" on the CPU once and the resulting triangles are uploaded to the GPU for subsequent draw calls.


Thanks for sharing, I'll have to digest all of it. How has your experience on the app stores been? Have you seen the conversions you were expecting? How do you plan to continue the freemium model in its web form?


I plan to keep the web version as a demo for now. It contains the first 4 levels of the game, and after you beat the 4th level it will ask if you'd like to continue to the various stores (App Store if you're on iOS, Play if you're on Android, else Steam).

My experience on the stores has been good, people who play the game seem to enjoy it. The hard part has been discovery :)


Your game is amazing! I'm particularly intrigued by the 3D-ness of the sprites and how smooth all of the animation is. Can you suggest any resources for learning more about the process of making similar content (without giving away your secret sauce, of course)?


Thanks! The characters are regular 3D models. The 2D elements are where the game differs from a lot of other games. If you use vector graphics the size of your assets will decrease dramatically, and your game will be resolution independent.

Regarding animation, this is a good resource to get started: http://robertpenner.com/easing/


Its very crazy how well this runs compared to the Js games we tried... why is that?


That is a difficult question to answer as there are many factors involved, not just the choice of language. JavaScript can be really fast, but WebAssembly may provide more predictable performance and faster loading times. The project website is a good resource to learn about the differences: http://webassembly.org


Why doesn't it load in Safari or Chrome for Mac?


It should work in Chrome 57 or higher or in Firefox 52+. Support in Safari is not yet released as far as I am aware.


I have Chrome 58. Wasn't working yesterday, works today.

Also, your page now says "Sorry your browser does not support WebAssembly" in Safari, yesterday it didn't.


You're a king


Just a heads up, I find the font+background colour combination on that page very hard to read.


I second that claret / green combo is a no go, I thought page was broken.


Sorry, I got a bit carried away on the colors. I've made a few quick style tweaks that hopefully make it easier to read.


This represents simultaneously everything that makes me hopeful about WASM - a really clean, fun and nice game that performs super well - and everything that makes me dread it. I was curious so I opened up https://www.funkykarts.rocks/demo.wasm and there's nothing there that I can really read and learn from. I'm not saying it isn't worth making the trade, but it seems like a fundamental change to a part of the web I really loved - the ability to read and learn from things you experience that are cool - that doesn't seem to be considered very much and it makes me a little sad to see its inexorable end spelled out. I think I'll soon miss the days where we all had to show each other our code on the web.


Don't you still have that place, for example GitHub, where open source code lives in non-minified, non-obfuscated form, together with a README, an issue tracker, etc.?

Why do you need to rely on the production binary to be human readable? Should web developers be forced to open source all their work, whether they want to or not, because of technical limitations of the web implementation?

> I think I'll soon miss the days where we all had to show each other our code on the web.

All of my code is open source, you're welcome to look at it. That's not changing because WebAssembly is coming out.


"Should web developers be forced to open source all their work, whether they want to or not"

Yes. If they want it to run on the Web. That's the way it currently is and that's the thing I'm saying I'll miss.

You don't have to put any of your code on the Web, but when you do I can read it. I like that.


I appreciate the nostalgia and share the sentiment, but it's mostly gone from the web already thanks to JS minification and asset minification in general. without a repo to look at the original code, it won't be of much use, even using devtools. you can figure it out a lot more quickly than analyzing a binary, sure, but the web isn't a "hey what's this how does this work" platform anymore, unfortunately.


Yeah I feel like the OP missed the last 10 years or something, unreadable minified code is everywhere.


I read it well enough to see where the .wasm source was coming from. The demo.wasm is inscrutable to me where the JS around it is not. I realize not everyone is at a level where they can debug/read JS, but I can assure you it's possible to do as a person of only modest intellect. Source: I can do it, and I am a person of modest intellect. I can't really see a "path forward" doing the same thing with .wasm, even decompiled to s-expressions.


> makes me dread it

What you're experiencing here is a lot more equivalent to someone putting up an HTML page that contains links to .exe binaries to run a 3D game. Except with WebAssembly, you get to skip the downloading .exe and executing it in a safe sandbox steps.

The .exe binary wasn't open source before, and it isn't now.

So I don't see why WebAssembly is causing feelings of dread for you.


In my experience a lot of JavaScript code is already unreadable after having passed through minification & concatenation. Even more so with webpack bundles. Now granted, ASCII is still much easier to read than a binary, but I think we've already moved past the era of easily readable website source code.


"In my experience a lot of JavaScript code is already unreadable after having passed through minification"

I think that's the point. Obfuscation.

All minified code is easily de-minified if you want to know how it works (and can understand the language)


Absolutely true.

The point I was trying to make is that the days of yore OP was alluding to where when I "put any of [my] code on the Web, [...] I can read it" are long gone, thanks to the obfuscation of modern bundling technologies.

By the same logic, all compiled code (including WebAssembly) is easily reverse engineered if you want to know how it works.


> Should web developers be forced to open source all their work, whether they want to or not

Yes - that's how the web works (barring obfuscation/minificaction). And it's how wasm will work too: http://webassembly.org/docs/text-format/.


In some cases its due to how new WASM is and the fact that nothing beyond a bare bones debugger experience was considered needed for the MVP. I'm not sure WASM is worse than the general state of web source availability. At least strict typing gives more hints about the underlying code in a disassembly.

That said, WASM may make things better in the future at least when it comes true open source. It's a pretty clean output target, making things like verified builds a possible extension.

Once better debugging support lands, sites can opt in to providing fully mapped output->source code as part of the debug metadata allowing a functional view source.


Good information, thanks.

I was hoping that mapping data would be an inherit trait of WebAssembly, as I too prefer how open source frontend languages are.

I'm very excited for WebAssembly, but I would hate to lose the ability to easily dissect what's running on our machines. Even with minification this is still somewhat possible.

At the very least, I hope browser vendors improve dev tools for reading wasm files in the future.


Yes, a throw-back to the days of Flash in some ways.

"Can you update these files?"

"Sure, can you give me the source code?"

"I gave you the source code."

"No you didn't. I can't edit these."

"Well it's all I've got."


I NEED THE FLV FILE NOT THE SWF


You mean the .fla ;)


Downloading youtube videos has ruined me.


Ha.


Isn't readability already killed by minifiers? Not sure what's the status on the wide web, but I know at least at my employer we're using them, and it sounds they're something popular and well established?


You can translate it to something human readable(ish): https://github.com/WebAssembly/wabt


Really? Go to google or Facebook and tell me any of that source is readable. :)


The fact that so much of the web is closed source now is a great tragedy, and is the result of the fact that those companies primarily see themselves not as software vendors, but as service vendors. They see humans as a kind of zoo animal who isn't really capable of engaging deeply with their software products, and can only jab at buttons.

If Google and Facebook weren't run by supremacists, and instead considered the general public as intelligent beings who are capable of understanding software, we might see more software coming out of those walled gardens. But they don't. Facebook and Google "engineers" (and software "engineers" at large) think of software as fundamentally hard, fundamentally technical, fundamentally something for the precious few with brains big enough to engage with it deeply.

It's just like books used to be, when the educated considered reading too advanced for the unwashed masses.

And so these service companies toss apps over the wall for the plebs to play with, and they keep all the cool toys for themselves.

There are some exceptions. They open source some commodity tools, but only where there is open source competition forcing them to do so.

I find it quite sad. But they'll lose when the web comes roaring back, when some IDE learns to operate within the language of the plebs, and the plebs learn to code, the wizards at Facebook and Google will find out what happens when you treat your customers like they are too stupid to operate at your level. Silicon Valley runs on supremacism. Supremacism breeds resentment. Bumpy roads ahead.

Some people at Google seem to understand this. I see them fighting for an alternate worldview. Maybe when the change happens, that minority will gain control of the company.


This seems... maybe a little overblown.

I mean, considering I program in React every day, I find this characterization of Facebook's engineers maybe a little insulting. They seem to be perfectly aware their tools are usable by others, and probably went out of their way to make them as usable as possible by others.

Anyways, whatever, my two cents are a lot less passionate than yours, so carry on.


They are using React as a replacement for something like Jquery or Angular. If they kept it in house, they would slowly drift away from the rest of the development community. They only open sourced React in order to benefit from the work of other developers and prevent someone else from copying it and having those resources go into an incompatible de-facto fork.

They certainly didn't do it because they see a path from "Typical Facebook User" to "React User". They see typical Facebook users as consumers of services, incapable of understanding software in a deep way.

And they see them that way because they are supremacists. I don't think this assertion is overblown at all. I wish more programmers would just admit that they are supremacists, then we could get on with talking about whether that's a problem or not.


>They are using React as a replacement for something like Jquery or Angular

How about the fact that it is just flat-out superior? Do you really disregard the tool entirely simply because there are alternatives? React is amazing. I am guessing you don't think much of front-end development?

>They see typical Facebook users as consumers

Who is "they"? Every single person at Facebook? I think you are painting with a broad brush. People work at businesses; they don't follow the party line of said business.

>I wish more programmers would just admit they are supremacists

What is your point? That people who have written enough code that they are capable of developing software think they are more knowledgeable about software than people who haven't written enough code to be capable of developing software?

What about this makes a software engineer a supremacist vs. a mechanic, a scientist, a mechanical engineer, a ....


As an aside, jQuery isn't really comparable to React or Angular. They do entirely different things.


You've got the timeline precisely backwards here. The move towards making computing less and less like a motorcycle and more and more like a train was _not_ pioneered by companies like Google: they were the ones fighting it kicking and screaming for years. The market demanded that things get less and less hackable and more and more shiny, or at the very least rewarded those (like Apple) that felt that way too.


You guys don't need to come to the defense of Facebook and Google. This shouldn't be about blame. The point is that there's a problem. We need to fix it. Let's stop pointing fingers at each other and point them at ourselves.


I think that inaccuracy in and of itself is a problem when it comes to anything worth discussing. Not all of us see the world through such us-vs-them culture-warrior blinders all the time.

The point I was making that the market is demanding it (as opposed to companies pushing it on users) is entirely material to the discussion.


I think the desire for a closed web is driven much more by the need for a days wages than some overblown sense of superiority to others.

If you disagree, why not spend a day talking to one of those engineers? I'm one. My friends are others. We're mostly nice people, with hardly a sense of superiority at all!


So you are afraid someone could learn and be inspired by your code ? And that would not be an advantage to you ?


Yeah when I use webpack all you can see is all the code compressed into one line, about as helpful as reading binary, its really a matter of sharing the source code, most mobile users which are the majority can't even view source anymore. That aspect of the web is dying due to things like webpack and webassembly, but github offers a better alternative than "view source" these days.


You'll have the same problem with minified JS too. If your browser's dev tools don't clean it up for you then you need a better browser. Obviously everyone _should_ be using source maps, but you can't rely on that.


Did you ever try to decompile your iOS or Android app to learn from them. As a mobile developer, I never learn things this way.


That's the point. The web, at least until now, only ran a mostly human-readable scripting language. Even if grokking the entirety of a codebase isn't easy because of minification, you can still see basic loop structures, API calss, etc.


The text format (.wast/.wat) should be derivable from the source (though I've no idea how to do this). From [1]:

> The design goals for a WebAssembly text format derive from the following use cases:

> View Source on a WebAssembly module, thus fitting into the Web (where every source can be viewed) in a natural way.

[1] http://webassembly.org/docs/text-format/

EDIT: looks like this [2] can convert between binary and textual format.

[2] https://github.com/WebAssembly/spec/tree/master/interpreter/


This is amazing, and it runs soooo well.

At the same time it makes me miss Flash.

I know it's easy to hate on flash, it was kinda buggy/slow and it was also crazily insecure. But the web really got interesting with flash, people were creating games, animations, interactive websites.

All the websites are pretty static/flat nowadays. Even if from a design point of view they might look "nicer", I liked the Flash era.


You can build some pretty cool games with libraries like phaser.io.

Here's an example:

http://www.gunfight.io/


Definitely runs well. Silksmooth even on my older 2010 MacBook Pro with a recent Firefox on Os X.

Would he happy to hear more on how they compiled from their custom engine to this webasm target.


Seems to load and run faster than most webpages. Really cool and a promising example of WebAssembly


Wow, that is a really well polished, completed, and neat little game. Makes for a great WebAssembly demo given how quickly it loads and how much value you get out of it.

It runs and looks fantastic at 2560x1600 fullscreen too (on a laptop made in 2011).


In related news, it looks like Unreal Engine just today came out with an update for "HTML5 Support for WebAssembly and WebGL 2". This seems huge as there are a lot of games written with the Unreal Engine I'd love to see come to the web.

https://www.unrealengine.com/en-US/blog/unreal-engine-4-16-r...


This looks amazing and is buttery smooth. Loads and runs faster than most webpages even. Takes even less than 10% of my CPU (i5-5200U). Really excited about what WebAssembly brings to the table. But sadly the WASM is an opaque format and I couldn't learn anything about the demo.


What engine/tools was this made with?


The game has its own custom engine and tools. The engine is in C++ and is small which made WebAssembly a great fit.


The game looks good. But I'm a bit skeptical of web-assembly after the flash era, where games did all kind of nasty stuff. I know "it's just javascript" but I feel unease having a binary blob of code running on my machine, at least with "javascript" you can view the source code. I do have JavaScript disabled by default btw. I also know that png images are also binary blobs, yet I allowed them, even though there have been exploits, but I feel that png rendering is more hardened, and can do far less, then web-assembly.


Web Assembly is NOT javascript. It literally is assembly for the web. There are transpilers that converts higher level code (C#, Go, Python) to Web Assembly, but the end result is always byte code that is run by the browser.

You may be confused with ASM.Js, which IS javascript. It is a very optimized version that uses a similar idea of a CPU instruction set (get register, add, branch on flag, push on stack, etc), but it still is interpreted. ASM.Js is very fast and also has some transpilers, but it is very different from Web Assembly.

Web Assembly has the highest potential. High potential for speed, calculations, AND RISK. The threat model for Web Assembly has not been tested as well as Javascript.


Well, the WebAssembly bytecode is the same target that is used by JS, so it kind of is JS in a way, well, at least in the way that is important to the OP's concern, in that WebAssembly should have the same risk profile as JS. wasm and JS don't represent two different pipelines - they run on the same VM.


> at least with "javascript" you can view the source code

minified and/or optimized JavaScript is generally not human-readable. Try view source on some major websites.


They minify the JS because 1% reduction in file size will save them thousands of dollars in bandwidth costs. Most web sites doesn't, even HN doesn't minify. Then there's those who obfuscate their code because they don't want their visitors to know what the code does. With JavaScript though you can, within the browser (no extra tools needed, just right click and inspect), beautify the code and set breakpoints etc.


A good parallel to Web Assembly is just straight OS Assembly, as opposed to Flash. Any concerns you have around Web Assembly could be applied to regular Assembly as well (not saying that you don't already do this, but it's good to clarify).

That said, there are indeed security concerns with Web Assembly that are and will need to be addressed, as it runs way closer to the metal and has access to direct memory.


Apparently FF nightly already has support to show WebAssembly, but it will be no different than looking at straight Assembly.


Do you not think you're being overly paranoid? It's not practical to inspect all the code you run for security exploits.

I could understand if, say, Chrome had many actively exploited security holes like things were in the Internet Explorer days but I wouldn't say this is the case now.


> at least with "javascript" you can view the source code.

Functionally speaking, are you able to read minified JS?


Speaking of WebAssembly and games, has anyone tried building their Unity projects in WebGL and exporting in Web Assembly? I hear they have that feature in the latest 5.6 version


Yes. It works well, although I paid for a fancier demo and exported it, and it crashed occasionally.

They've done a pretty good job with compressing the assets too. Good weissman score.


It works nicely, your users have to download a ton of data, though. Long loading times. For nicer results, use something lightweight like CopperCube, or use a hand written lib like three.js.


That is so smooth and beautiful, physics are great too. Nice!


I just get "Sorry, but your browser does not yet support WebAssembly."

I'm on Firefox/Linux. Other WASM demos work, so I'm pretty sure that's a bug. :)


Works flawlessly on my Firefox 53 (and Chrome) on (Arch) Linux.


Thanks for the heads up, that is curious. I don't have access to a linux machine at the moment, but will investigate later. There should be some output from binaryen in the JavaScript console, does it report success?


I get the same error, in Chrome 56.0.2924.87 on Ubuntu 16.04.

Console: http://i.imgur.com/hVNCskv.png


WebAssembly support landed in Chrome 57 :)


d'oh, thanks


Seems to be something with multiprocess (aka e10s) Firefox. I can't get webassembly to work anywhere now... I swear it worked before.


FWIW, it works fine for me on Linux with Firefox 53.


very nice. I like the wall jump mechanic.


Looks great, and it's snappy! Is "Dartmobile" a reference to Dart the programming language? It's the same color scheme :p


Yes it is :) Fun fact: the first prototype of the engine was built in Dart and later re-written in C++ for production.


Can you share the prototype? I am excited for reading interesting Dart apps in the open.


Back when Dart first came out (I think 0.1), I built a gravity simulator in it. It was a shameless rip-off of http://www.nowykurier.com/toys/gravity/gravity.html, but it was just for me to get a little familiar with it.

It was pretty dang great writing that project, and I'm beyond surprised that Dart didn't have more success in replacing JS.

I unfortunately lost the source code at some point :( (this was before I got organized, got a GitHub, etc).


Definitely a well made game, but I don't think it would really fit with the Steam store. It looks like it's doing well on the play store however: https://play.google.com/store/apps/details?id=rocks.funkykar...


The game is popular on the Chrome Web Store, and ~30% of those users are on Windows. Chrome Apps will stop working on Windows later this year, and Steam seems like a good place for them to transition. A full blown web version is another possibility.


It doesn't seem to load right in my Nexus 6 Android Chrome 58.

Only the bottom left of the canvas is showing the game the rest is a lite blue box.

Edit: however it displays correctly in Firefox 53.0.2 (Android) on the same phone.


It works on my old Android 5 phone in Chrome 58. Amazing that it's supported so quickly at this stage of wasm development.


My mbp fans kicked into overdrive, reminding me that this is a browser game, but otherwise, I echo the sentiments that it loads fast and is really fun.


Interesting, wish it was also written in traditional JavaScript, so the performance could be crosschecked. Thanks for the game, most enjoyable!


Background music does not work for me (Fx/Win10). Devtools console says "Unsupported sample rate : 48000"


I wrote about this in my audio article [1]. Ideally, browsers will implement support for a configurable `sampleRate` in the `AudioContext` constructor.

There is a tracking issue [2] for Chrome but I wasn't able to find one for Firefox.

[1] : http://www.rossis.red/wasm.html#audio [2] : https://crbug.com/432248


I don't get it. I just see their home page with just a picture and links to app stores. Tried Chrome and Safari.


On my Linux Chrome with version 55 - it says, "Sorry, but your browser does not yet support WebAssembly."


Yes, I think you need Chrome 57+.


OT but how is the coin sound played without user input? Is it a WebAssembly thing enabling passive sound triggers?


If I remember correctly iOS is the only platform were that limitation ever existed.

https://stackoverflow.com/questions/12517000/no-sound-on-ios...


I get it on my web game on Android:

   Uncaught (in promise) DOMException: play() can only be initiated by a user gesture.
It's triggered in the game loop where the user event has been added to a queue so it's not in the same call stack. The coins are picked up in the air etc so I have a hard time believing they are within the same call stack since it's long after the jump.


Nice work! Looks really good.


Very nice. The levels are well-designed from a game design perspective, too.


Nice work, I enjoyed playing it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: