Angry Bots Demo | Hacker News Reader

Angry Bots Demo

webassembly.org

167 pointstilt65 comments

Kill flash, they said..

Flash version, [at least] 5 years ago: http://tsuyobi.heteml.jp/unity/flash/AngryBots/

It's great to see WASM coming at last, but I must admit I'm a little disappointed (for now, anyway). Huge download, and though it runs smoothly (firefox 50) I'm not really impressed given what was possible with the flash version.

WASM won't work on my browser, but the flash version does.

... and there goes Tuesdays work plan...

For me it's the opposite. And my browser shortcuts like closing tabs still work in the WASM version.

Haha - I've run into exactly this problem writing games in HTML5 and JavaScript. I was all smug thinking, "Hah - screw these Flash guys and their stupid loading progress bars because of all that dreadful Flash bloat. I'll show them!"

Except, of course, I didn't, did I?

Because most of that bloat is actually game assets (graphics, textures, sound effects, music, oh, and time spent churning out procedurally generated content), and not just the useless crap I thought it probably was(1), so it makes no difference what you're using as a platform, and you still end up with a progress bar (basically). The code on its own comes down in a flash, but that's only a part of the equation, and in terms of load/initialisation time, not a big part.

Still, what I never do is display a pop-up prompting the user to install Flash, or Unity, or Java, or whatever, which is a definite improvement.

(1) In fairness I do download all sfx and music in the background, so you don't have to wait for them all to load before you can start playing.

I think the issue was the separate flash runtime was a pain to maintain and make secure. I think battery life was also an issue.

I wonder when the first "no wasm" browser plugins will come.

The flash runtime still exists on iphones, now its called AIR. And you have to buy it thru the app store.

Old-timers as myself already saw this coming.

The main idea of killing Flash was because some websites completely ran on it, which is bad. But games never was an issue, and never will be.

Battery life, system resources, downloading assets, ..., it's all the same if you use either Flash or JavaScript.

Newsflash: Apple didn't block Flash because it is "bad", they blocked it because they wanted you to go through their app store

Newsflash: Games written for Flash (in ActionScript3) also run on Android and iOS. It even became "Best Mobile Application Development product" of 2014 and 2015.

They say Flash advertisement banners were annoying, so what do you think about those JavaScript popup banners that pop in the middle of the page you are reading, saying "Please subscribe to our mailing list"?

I you develop a game for Flash, it runs consistently in the Flash plugin. If you develop a game in JavaScript, you need to test it in all browsers you want to support. And yes, they are all different. And still gives troubles so many years later. Surprising? Not for old farts like myself.

But no worries. I looked at my google analytics for the past few years. Most visitors moved to Chrome. Flash plugin installed percentage: remained the same.

http://www.theverge.com/2016/5/15/11679394/chrome-to-block-f...

Nails in the coffin.

I still need to see how this turns out in practice. But if they completely get rid of it, this will mean more headaches for game developers, and more gamers crying that stuff doesn't work.

Non-game related, this might actually be a good thing. But coming from a game development background, this is a huge step back, both for game developers and gamers who want to play straight in the browser. But as said, we will see how inconvenient they make it.

Flash also has huge security flaws and memory leaks. Pretty much like Java applets.

At least with JS, if it leaks or has security breach, the browser's developer can fix it without waiting for a 3rd party, or I can use a different browser.

The more complex software is, the more potential security flaws and memory leaks. All software is subjected to this. Bringing HTML5 to browsers adds to this, and don't assume browsers are immune because they are not developed by Adobe.

Same arguments can be made for Flash: Plugin's developer can fix it without waiting for browser. Disable the plugin and use the same browser.

Conclusion: makes no difference conceptually.

That's all well and good but what would you have us do? Move all web app development over to the Flash Player and disable JavaScript (and JS APIs) in browsers? We have to reduce the attack surface somehow.

Oh, and guess what? We now have no browser competition because all the relevant parts are in the Flash Player and good luck motivating Adobe to fix issues with it now that it's basically a requirement to run a browser. Oh, and now they could charge everyone to access it if they want.

The difference is that Flash, being proprietary, Adobe is the only party allowed to fix a memory leak. HTML5, a standard, can have many proposals, discussions and implementations on how to fix issues.

Seriously? Have you ever seen something fixed faster by a committee then by a vendor who has a large financial incentive to protect?

I want to live in your world!

No difference conceptually. Huge difference in practice when looking at the track records of the two approaches.

> Same arguments can be made for Flash: Plugin's developer can fix it without waiting for browser. Disable the plugin and use the same browser.

Not exactly comparable. Flash, at its height, had pretty much the "multimedia in browser" market cornered with draconian vendor lock-in effects. They didn't need to hurry that much with fixing issues, because what are you gonna do if you are not satisfied with the Adobe Flash plugin? Run your favourite Flash game with Microsoft Silverlight? Use the open-source plug-in that could only run some Flash 1.0 animations?

At least with browsers you can easily switch vendors (the whole point of standardization and techs like WASM), or even fork your own.

Even if I don't like Apple or Steve Jobs that much, I must say they did one great thing killing off Flash by not allowing it on the original iPhone.

> At least with JS, if it leaks or has security breach, the browser's developer can fix it

In modern OSes, you could slap a sandbox or container-ish construction around Flash. If it had a bug, it would be contained.

In principle, a minimal browser that defers to isolated plugins would be the more secure design. In practice, the plugins were buggy and insecure of course, but this was accidental.

If Flash were open source, and/or had just as much effort put into it as current browsers, it would be at least as secure.

The only reason the monolithic kitchen sink that a modern browser is is secure (and fast) is that so many brilliant people have been putting so much hard work into it (and Google and Apple so much money).

No one ever demonstrated a performant Flash implementation on iOS. (or any other ARM system?) IIRC, Adobe whined and stomped and gave a demo that it could run on iOS, but it didn't run well at all. And as another commenter mentions, security flaws galore.

Do you know a game called "Angry Birds" that runs on mobile platforms? Seems to run pretty smooth in my eyes.

Edit: In case it is not clear, Angry Birds uses the Starling Platform, which uses Stage3D, which uses Adobe AIR, which uses the same technology as Flash, and is written in the same ActionScript3 environment.

I used to work with Stage3D when it came out. Its a crippled API with an even worse shaders API.

AS3 spawned way too many OOP practices in the Flash world for my liking, it was the most naive way to code games I've seen until people started doing the same in JS. Angry Birds is so simple a game it could waste 90% of the system's resources and still run smoothly.

The build pipeline for AIR is also terrible, with XML configuration and arcane documentation and plenty of non-documented behaviors. I once had to maintain a Flash extension, ExtensionBuilder is as bad as a toolchain can get.

I'm so glad Flash is dead :)

Do you have a source for the mobile version of Angry Birds using Flash? My understanding is that only the web\social version of Angry Birds uses Flash and the original iOS mobile version is a native app using a few third party libraries (Box2D and Lua).

Angry Birds was definitely C++/OpenGL. That's how it could run on WebOS with the PDK.

I used to surf the web with an Opera browser on Nintendo DS. The Opera devs felt like Adobe had no interest in supporting ARM platforms either due to organisational issues, or because they'd painted themselves into a corner technically in how they'd built on the assumption of having a high-powered desktop machine available.

It came as no suprise to me when Flash and the iPhone never happened.

> Newsflash: Apple didn't block Flash because it is "bad", they blocked it because they wanted you to go through their app store

No. They blocked it because it sucked. Horrible for battery, horrible for accessibility, performance wasn't great, and security issues galore. Don't forget, iPhone shipped without Flash before the app store even existed. When iPhone was first launched, Apple literally told developers to make web apps for it instead of providing native apps. It wasn't until iOS 2.0 that native apps were possible.

IMO flash didn't fit into the open web vision, if I wanted to make my own browser, it couldn't gain traction until adobe decided to release flash for my browser

Side note, the "open web" is probably one of the most misleading phrases of the last couple years. Because:

> if I wanted to make my own browser

muhahahaha (sorry). What I am trying to say, is that basically nobody can make a new browser from scratch today (not just a redecorated webkit). The only entities that can create or maintain browsers are megacorporations (Apple, MS, Google) or dedicated foundations (Mozilla).

Now, imagine a parallel universe where there is a standardized API for browser plugins which run in a sandbox (unlike NPAPI). Any startup can easily create bring new technologies to the web platform. You could put the plugins on the OS'es app store and vet them like regular apps if yuo like. Virtual reality, accessing a 3D printer, custom hardware, ... or just better network access and the ability to run a IMAP mail client, a terminal, or a bittorrent client in the browser (without a server).

I'd argue that the "open web" is actually one of the less open possible architectures, and limits what you can do. And the reason for this are business interests of Apple & co.: Why would you sell your app in the app store and give apple a 30% cut, if you could do everything a native app can in the browser? And I also bet some of the restrictions of the open web are benefitting the content industry - like restricting what formats you can use, the inability to use full networking (and to create a P2P "pirate itunes" without central server in the browser), the introduction of DRM in the browser (EME) and so on.

I agree captain, but this whole discussion is starting to resemble The_Donald thread on Reddit.

Also, it doesn't really show the potential of WASM, since most of the graphics is done in OpenGL anyway.

It reminds of Alien Swarm[0], a free game by Valve, it is well worth it if you can find 3 friends to play with.

[0] http://store.steampowered.com/app/630/

This feels like history repeating itself. The Flash version still runs better for me than the WebAssembly version, and the Flash version worked well on people's systems 5 years ago! It seems like half of the things I see on HackerNews is JavaScript poorly doing that other solutions did better a decade or more ago

That's why programming is "half a field," according to Alan Kay. If it were a real field, then there would be greater preservation of group knowledge/experience. Instead, it's like a pop culture, subject to cyclic fads, with less overall progress.

For awhile, OOPSLA was full of presentations of things that people did in Java, that had previously been done in Smalltalk. I'm sure many others have parallels.

Also, if Adobe had done a much better job, things would be different. (You could say the same thing for Smalltalk and OO.) But corporate incentive structures are somewhat broken and too short term. This is why Apple could produce a better UX free of bloatware and outcompete Wintel. This is also why Apple is now starting to fail some of its users.

I'm now looking at networking for browser based multiplayer games. WebRTC datachannel has a pretty big header. Websockets carry TCP sematics. I think Flash did this better too!

The best part is that we're just now achieving what we could do in Flash 5-10 years ago, which was capable of achieving what we could do with native code 5-10 years before that.

I never had a problem with Flash games and I haven't heard it many others. Flash games and Flash animation were casualties lost when it fell out of favor.

What I hated with a passion is seeing a progress bar and warning to updates Flash so I could look at the hours for a restaurant down the street. It would also hijack copy/paste and other shortcut keys to switch windows or close the window. I would also hear my CPU fan spin up and battery life drop because I left it open in another browser tab.

When CSS and Javascript started doing things Flash used to do I sighed because while I can use a Flash blocker, I can't do the same for CSS/Javascript.

webassembly is not javascript

My point is that all of these things are running slower than flash did on much older hardware. The technical sophistication of what the average user does with computers hasn't changed much in the past 10 years (for the most part), but these bloated web stacks have made real world performance actually go down as raw hardware performance has gone up.

Seems to work nicely in Firefox 50 release (no nightly required) once the config is set.

Really happy about the way this is progressing.

For me, the WASM version was noticeably slower, with an especially noticeable JIT warmup. It might have been because the asm.js version was running at a lower resolution, so it's not a very fair comparison.

If your browser natively supports WASM, there is no JIT and no warmup time.

Ah, I didn't realise there was no JIT. In that case, I'm not sure what caused it, but there was definitely a lower framerate at the start.

Same for me, asm.js version runs smooth and wasm had lags in few spots and strange glitches with bots getting stuck.

HTML5 is not progressing that fast for games, it's really really slow.

What is the total download size? For program? For data? How does this compare to the previous emscripten output?

I'd say it's around 50Mb.

From the network tab of Chrome developer tools:

  AngryBots11.wasm	GET	200	webassembly.org	xhr	UnityLoader.js:187	11.9 MB	54.38 s	GitHub.com	
  AngryBots.mem	GET	404	webassembly.org	xhr	UnityLoader.js:72	5.6 KB	172 ms	GitHub.com	
  AngryBots.memgz	GET	200	webassembly.org	xhr	UnityLoader.js:47	314 KB	1.30 s	GitHub.com	
  AngryBots.wasm.mappedGlobals	GET	200	webassembly.org	xhr	AngryBots.js:279	3.1 KB	250 ms	GitHub.com	
  AngryBots.datagz	GET	200	webassembly.org	xhr	UnityLoader.js:47	36.3 MB	2.9 min	GitHub.com	
  HWStats.cgi	POST	200	stats.unity3d.com	xhr	AngryBots.js:6595	149 B	3.80 s	Apache/2

Just shy of 50 MB all in all.

Keep in mind this is built in Unity. It's difficult to make even trivial native apps in Unity in less than 25 megs.

The Unity WebGL engine is about 5MB gzipped. You won't get a web export smaller than that, but you shouldn't need 20MB of assets on top of it for a small game either.

For a point of reference, Three.JS's source code hovers around 100KB gzipped, sometimes more, sometimes less. That is a factor of 50x difference.

three.js doesn't have 1/50th the features of unity. three.js is great and ive contributed to it but a game engine is a lot more than just a renderer.

Your stuff is broken

UnityLoader.js:72 GET http://webassembly.org/demo/AngryBots/Release/AngryBots.mem 404 (Not Found)

Now they need to add on-demand loading for parts of these applications and things could really get nice.

What I'd prefer to see in a demo is running compiled code of other languages (e.g. Haskell, C++, Python, Rust, Go) in WASM, and comparing performance.

Also interesting would be to run other virtual machines (JVM) inside WASM, and see what the performance is.

Also interesting: compiling Firefox into WASM, and running it on Chrome (or the other way around) :)

Further, I'd like to see a good test of multithreaded/shared memory performance.

You can transpile this demo to C++ with IL2CPP. It's built into Unity for iOS/Android platforms, never tried to do it on desktop, but I think it must be possible.

I forgot two:

Compiling Linux to WASM (yes I know it has been done for single-threaded Javascript, but it would be interesting to know how this would perform on WASM, with threads).

And compiling VirtualBox to WASM would also be cool. If only as a performance indicator.

Chrome (Version 57.0.2935.3 canary (64-bit)) on Windows 10 crashed the tab when I tried to reload the page to play again.

Works well on regular Chrome Version 54.0.2840.100 (64-bit) on Elemenetary OS Freya.

Would appreciate a bug report if you have a repo: https://bugs.chromium.org/p/v8/issues/entry?template=WASM%20...

The Web Assembly version seems to be faster (not just warmup), but it would be nice to get a 1:1 comparison there.

The Web Assembly version also looks to be using much lower texture resolutions as well. It's cheating to get better speed it seems.

I tried this with ASM.js - looked impressive to think this was all built with WebAssembly. Haven't seen the flash version, but still this looks awesome for 50mb.

I'm curious, why not use JVM bytecodes for web assembly... or actually any of the legitimate, mature, optimized, hardened runtimes out there? I feel like we're reinventing the wheel, again.

This has been answered 900 times already. See the design docs on GH.

The design docs have a rationale for why not llvm bitcode [1], but I can't find anything comparing wasm to other bytecodes or interpreters. Could you point me to the right place?

[1] https://github.com/WebAssembly/design/blob/master/FAQ.md#why...

I look forward to the day I'll be allowed to use ttk (tcl/tk) compiled to WASM instead of html/css to build interfaces.

Why Oh Why Oh Why would you use isometric WASD for this instead of Forward/Backward/Strafing?

Because the camera doesn't rotate, so when you are facing south, forward would move you backwards on the screen, and strafe-left would move you right on the screen.

Reply on news.ycombinator.com