Hacker News Reader

Comment by daenz | Hacker News Reader

I feel like an old fart for not buying into the push for the browser to be an OS or game system.

In my mind, no matter how optimized the browser becomes, it will always be slower than natively-compiled code. And in the 3d gaming world, where the faster code always has the greatest potential for the best game engines, the browser will always lose.

My instinct tells me that there will be a huge push for webgl games, some initial adoption and frameworks, etc. The result will be that web developers will realize how fucking complex graphics engines are (I'm writing one now...nothing in webdev compares to it) and will give up. And I can't see graphics developers in the game industry incentivized enough to fully make the jump to the browser (why would they want to write game code that is distributed to everyone in raw source form?)

View on HN

It does not need to be the absolute fastest possible for it to be fun. If the framerate is acceptable and joining a game with my friends is as simple as visiting a URL, this can be a huge competitive advantage over traditional games.

I understand what you are saying. The tipping point for me in terms of "Oh, that will never happen because of X" was MineCraft. An incredible game written in Java. Sure, it's not pushing extreme graphics, but that doesn't matter. It's the game that matters.

So I look at games on the web the same way. Heck, I've been playing games on the web for years. No, they aren't in the same realm as AAA games coming from Blizzard, Valve, or EA. But, I had fun, native wouldn't have gained them anything, and I spent more time playing them (and more money) then some of those AAA games.

Also, remember the original Serious Sam. Had a generation behind graphics but was successful because it was fun. I can see a Quake Live type game without plugin being relatively successful.

Quake live without plugin would be awesome.

Quake live in it's current form, and same with Battlefield Heroes, is just silly. OMG a game that runs in your browser!!1 You just have to install this activex-plugin first... Totally misses the point of having browser games. I might as well install a full game.

In the case of quake live installing the plugin was actually MORE hassle than installing a normal program, i counted the steps and with a normal game i usually just select install dir and press next two times, done. For quake live i had to go through tons of hoops, the installer had several steps and in the end i also had to restart my browser twice. Sooo convenient that it runs in the browser....

> why would they want to write game code that is distributed to everyone in raw source form?

It's not. Asm.js is pretty much just assembly.

> It's not. Asm.js is pretty much just assembly.

No, it's not. Have you even read http://asmjs.org/spec/latest/ ?

It's a rather high-level bytecode, expressed by constraining JavaScript to a specific subset of the language, interpreted according to rules that are considerably more specific than those specified in the JavaScript spec.

It essentially exposes a load-store architecture, exactly as the assembly language of RISC processors does. There are some minor differences, such as the control structures and an infinite register file, but those aren't really relevant to reverse engineering. (IDA has been able to figure out control structures and local variables for a long time now.)

Would you call Java's or Dalvik's bytecode assembly?

Yes. But note that, even so, there is a large distinction between Java or Dalvik bytecode and asm.js: the memory model of Java and Dalvik bytecode is defined in terms of high-level class types, object instances, and properties, while the memory model of asm.js is a large array, 8 bits wide by X MB long. Naturally, the latter is much lower-level and more difficult to decompile…

In that case, I think we just have some differing definitions.

Given who he is, I imagine pcwalton is far more familiar with it than you are. Either way, you're wrong. Bytecode is not human readable which, as even your definition states, asm.js clearly is.

>In my mind, no matter how optimized the browser becomes, it will always be slower than natively-compiled code.

So what? Phones will always be slower than consoles, and desktops. Consoles will always be slower than Desktops. The performance level that is showcased in the mozilla videos is good enough to create very deep and engaging games.

>The result will be that web developers will realize how fucking complex graphics engines are

I agree, which is why nobody will code in raw asm.js and raw webGL. You'll code in a framework (e.g. Unity) which will compile down to asm.js/webGL.

>why would they want to write game code that is distributed to everyone in raw source form?

Flash games could always be decompiled and that didn't stop anyone from using Flash to write games. There's a world of difference between decompiled code (or minified code as the case will be for JS) and properly organized source code. Client code also doesn't matter for a class of games that have a heavy server component.

> (why would they want to write game code that is distributed to everyone in raw source form?)

You would distribute the asm.js code, which is your object code.

I don't buy the performance argument (covered by other replies), but I too am getting sick of the "reinvent the OS inside the browser" mentality.

If the issue is one of security, the underlying OS should implement some kind of jail, which the browser can then call with whatever crazy native code the website serves. This will also end javascript's reign as the ONLY allowed language on the web (for purely arbitrary reasons).

But who am I kidding - this is never going to happen as long as Windows holds the majority OS share. And people are far too ingrained into the current ways. Long live JS as the new machine code, I guess.

I expect most serious developers will stick with engines like Unity, which let you run games in a browser with a plugin, but also compile and distribute them in standard ways on every popular desktop and mobile platform.

Unity Web Player is easy to install, and it's an increasingly common requirement for a lot of games. It's a barrier, but only a small one.

>I expect most serious developers will stick with engines like Unity

They should stick with engines and frameworks like Unity. Coding raw JS and WebGL is ugly. But there's no reason why Unity cannot compile down to something like asm.js and webGL. In fact, I believe Unity already lets you compile to a swf, which gives you great performance and doesn't require any extra plugins (besides Flash).

>Unity Web Player is easy to install, and it's an increasingly common requirement for a lot of games. It's a barrier, but only a small one.

It's an insurmountable barrier.

"...It's an insurmountable barrier..."

Why do you say so? Why is it a small barrier or an insurmountable barrier?

Genuinely interested in the answers there.

Just seems to me that there are a lot of Flash games, Unity games and Java games. I mean, if Minecraft or BSG Online is any indication... technology doesn't really stop your average gamer. But maybe I'm wrong???

I have developed a couple of unity based browsergames and i can Tell from experience that you loose a sibstantial amount of users at the plugin installation, especially for games that target a more casual market. Unity compiling to asm.js would be huge!

Unfortunately it is a MASSIVE BARRIER in many institutions, we developed software for the military and anything we made had to run on the browser, no additional plugins.

I'm sure we'll see exporting to WebGL from Unity once more browsers start to support it. It already has Flash exporting which makes the Unity plugin dead-on-arrival (well a few years after arrival anyway).

Reply on news.ycombinator.com