Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla and Unity Bring Unity Game Engine to WebGL

blog.mozilla.org

Post reply on HN
Print view View original

41–50 of 122 posts

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#41

Post by valarauca1 »

TazeTSchnitzel wrote: post #29
valarauca1 wrote: post #26

Earlier quoted context omitted.

You can read/write local files from within a webpage. So I guess its possible. It would require looking into how WebGL loads assets and overriding this with diskIO operations not difficult. The next problem would be asset management, but this isn't an important issue. A lot of game data is already stored locally with little to no protection. I'd have to look at how javascript handles file I/O it might not be 'that' d…

There's localStorage and there's IndexedDB. The former is blocking and not ideal, but I think you can store blobs in IndexedDB and it's async.

It depends. I was talking about storing files in user-land not browser-land, like c:\program files (x86)\company\our cool game\art\texture.png

That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff.

I'm not a web developer at all. I'm just researching this as I type it.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#42

Post by NinjaWarrior »

papa_bear wrote: post #18

Is there an straightforward way to solve the issue with crazy load times on big WebGL games? If I remember correctly, I played one a while ago and it had to download assets for ten minutes before I could play it and it was a huge downer. If this becomes the norm I'm sure it wouldn't be too hard to get used to, but I was coming at this game from the mindset of playing instant gratification flash games. It would be coo…

I think Unity can distribute their runtime library via CDN (just like three.min.js or something). It will able to cut down the initial some megabytes.

Progressive downloading technique (like AssetBundle) is a must for both loading time and server costs. Every developer should use it because if many games have massive long loading time (like Epic Citadel or BananaBread or Monster Madness. Whatever Mozilla says, these demos are not commercial ready), end-users will hesitate to click game links. I feel many gamers already stopped considering the web as a game platform these days. Kids know how to download games from App Store, but they don't know how to use Mobile Safari. All App Store, Google Play and Steam are growing. Many users will continue to prefer download apps for a long time.

Ultimately, time may solve the problem. The internet bandwidth is growing 50% per year. Many PC browser games will start instantly 5 or 10 years later, Mobile will have more trouble.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#43

Post by TazeTSchnitzel »

valarauca1 wrote: post #41
TazeTSchnitzel wrote: post #29

Earlier quoted context omitted.

There's localStorage and there's IndexedDB. The former is blocking and not ideal, but I think you can store blobs in IndexedDB and it's async.

It depends. I was talking about storing files in user-land not browser-land, like c:\program files (x86)\company\our cool game\art\texture.png That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff. I'm not a web dev…

Oh, for local apps? Sure, you can do that. file:// doesn't work well though (you can't load textures from it, for example), but you could use a local server.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#44

Post by beefydude »

Is it just me, or it is a bit hypocritical for Mozilla to be talking about the wonders of the Open Web and then embracing two very proprietary developer platforms to promote Asm.js

If they cared about the open web, and they cared about open source, they would be helping open source game engines like Ogre3D and Torque3D.

Instead, for the sake of expedience, we see them promoting proprietary components.

It was not too long ago that they were lecturing the world on the evils of proprietary video and audio.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#45

Post by TillE »

wildpeaks wrote: post #40

I'm curious if they'll also add features such as In-app Purchases given that's a recurring issue in threads about HTML5 games.

Amazon is one good option for IAPs with web games:

https://developer.amazon.com/public/solutions/platforms/weba...

edit - Forgot to mention, they even have a Unity plugin:

https://developer.amazon.com/public/solutions/platforms/cros...

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#46

Post by valarauca1 »

TazeTSchnitzel wrote: post #43
valarauca1 wrote: post #41

Earlier quoted context omitted.

It depends. I was talking about storing files in user-land not browser-land, like c:\program files (x86)\company\our cool game\art\texture.png That can handled currently in HTML5. Even written too if you give it permission on load. This would side step warnings of IndexDB going over 50MB would be easier with large textures/models. Also side steps that webworkers can't really do asynch indexDB stuff. I'm not a web dev…

Oh, for local apps? Sure, you can do that. file:// doesn't work well though (you can't load textures from it, for example), but you could use a local server.

The problem is that most people don't have a local server. Even if you have local (geographical nodes) your still limited to the clients bandwidth.

Also how can you load say models but not textures? All files are just binary data.

I guess your only option is to play around with indexDB. Also it that per file 50MB, or overall 50MB. I guess with more aggressive compression could could achieve decently small disk usage.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#47

Post by zenbowman »

This is awesome. I worked in educational technology building virtual humans (http://alelo.com/), and have experience with a variety of game engines. Unity is far and away the most pleasant developer experience, despite being 1/100th the cost of some of the other commercial engines.

Pre-Unity, game engines were truly stuck in the dark ages.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#48

Post by TazeTSchnitzel »

valarauca1 wrote: post #46
TazeTSchnitzel wrote: post #43

Earlier quoted context omitted.

Oh, for local apps? Sure, you can do that. file:// doesn't work well though (you can't load textures from it, for example), but you could use a local server.

The problem is that most people don't have a local server. Even if you have local (geographical nodes) your still limited to the clients bandwidth. Also how can you load say models but not textures? All files are just binary data. I guess your only option is to play around with indexDB. Also it that per file 50MB, or overall 50MB. I guess with more aggressive compression could could achieve decently small disk usage.

>Also how can you load say models but not textures? All files are just binary data.

CORS and the Same Origin Policy.

Re: Mozilla and Unity Bring Unity Game Engine to WebGL

#50

Post by azakai »

coldcode wrote: post #49

What is the performance like for asm.js and WebGL compared to a native app for PC or Mac? What do you lose?

WebGL is basically at native speed. The only issue might be if a GL extension you need is not in WebGL yet, but that is moving along quickly.

asm.js can run close to native speed, depends on the JS engine of course, but it's not far off. See for example

https://github.com/joelgwebber/bench2d

Post reply on HN