It does have benefits, but also downsides. If this is just for fun, then awesome, that's one of the great reasons to hack about with something. If they're looking to sell it or get people to actually use this in production, then I can't see a good reason to. You'll lose the performance, features and tooling available with other modern game engines. Maybe useful if you want to do a little product demo.
I think you haven't considered technology development/innovation cycles. Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work. There are several factors that will enable web-technologies to outpace native solutions. These factors are not inevitable technologic. One thing that will drive technology adoption is market potential/volume: imagine developing a product once and being able to ship it to any device e.g. customer that has a browser. Well, thats a massive market compared to just one smartphone OS for example. Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run? Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side. The entry barrier into web-based products comparatively vanishes: no downloads, no install, no plugins...
...not yet talking about new business models that might be/are possible in a web-ecosystem...
"Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work"
Well yes, but that's what I mean when I say I wouldn't want to take it to production. Maybe in the future, but it's not ready yet. I think it has some way to go before it's viable, and a long way to go before it competes with the likes of Source, Unreal and Unity.
" imagine developing a product once and being able to ship it to any device"
Always a worrying promise, as you need to write one product that works on multiple, slightly different setups. Browser Y supports the CSS selectors you're using, but there's a rendering issue on Browser Z 2.9.0.1 - 2.9.1.3. Browser X renders it correctly but doesn't yet support hardware acceleration so it doesn't run so well.
It's also not the only cross platform option there is, and I'm not sure trying to target vastly different devices with the exact same code is a great idea. Why would we expect to be able to write a game for a phone with a touchscreen that also works on a desktop with a keyboard and mouse? Why is it better to have one product with internal switches "if mobile..." rather than two with shared code? You've now got a lot of regression testing to make sure you're not affecting the desktop experience when you update something that 'should only change the mobile bits'.
"Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run?"
It depends on the quality of what each side can offer, and the difficulty in adding to it. A cross-platform game engine can add support for a new feature of graphics cards and be ready quickly rather than having to draft an addition to a spec which you hope the browser manufacturers implement similarly, then watching until the market penetration of the version of the browsers you want reaches the right level.
"The entry barrier into web-based products comparatively vanishes: no downloads"
No downloads? So why did it take so long for me to load the demo? I'd like to know how I can get your product over the internet without downloading it.
"Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side"
Imagine having to load large parts of a game online every time you want to play it, rather than just opening a program. Also, realtime updates? Sounds awful. Fix one JS file and watch the fun as some people load an older cached version, others a new one, others loading in that file on level three after loading the older assets on level two. Something that was loaded 5 minutes ago is now trying to call a function on an object that's been renamed in the latest push. Not being able to load level 4 because the server is under strain...
Comments
That's true, but the Web platform has its perks, and the demos are trending closer to native. It's about the promise, not the readiness.
It does have benefits, but also downsides. If this is just for fun, then awesome, that's one of the great reasons to hack about with something. If they're looking to sell it or get people to actually use this in production, then I can't see a good reason to. You'll lose the performance, features and tooling available with other modern game engines. Maybe useful if you want to do a little product demo.
I think you haven't considered technology development/innovation cycles. Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work. There are several factors that will enable web-technologies to outpace native solutions. These factors are not inevitable technologic. One thing that will drive technology adoption is market potential/volume: imagine developing a product once and being able to ship it to any device e.g. customer that has a browser. Well, thats a massive market compared to just one smartphone OS for example. Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run? Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side. The entry barrier into web-based products comparatively vanishes: no downloads, no install, no plugins...
...not yet talking about new business models that might be/are possible in a web-ecosystem...
"Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work"
Well yes, but that's what I mean when I say I wouldn't want to take it to production. Maybe in the future, but it's not ready yet. I think it has some way to go before it's viable, and a long way to go before it competes with the likes of Source, Unreal and Unity.
" imagine developing a product once and being able to ship it to any device"
Always a worrying promise, as you need to write one product that works on multiple, slightly different setups. Browser Y supports the CSS selectors you're using, but there's a rendering issue on Browser Z 2.9.0.1 - 2.9.1.3. Browser X renders it correctly but doesn't yet support hardware acceleration so it doesn't run so well.
It's also not the only cross platform option there is, and I'm not sure trying to target vastly different devices with the exact same code is a great idea. Why would we expect to be able to write a game for a phone with a touchscreen that also works on a desktop with a keyboard and mouse? Why is it better to have one product with internal switches "if mobile..." rather than two with shared code? You've now got a lot of regression testing to make sure you're not affecting the desktop experience when you update something that 'should only change the mobile bits'.
"Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run?"
It depends on the quality of what each side can offer, and the difficulty in adding to it. A cross-platform game engine can add support for a new feature of graphics cards and be ready quickly rather than having to draft an addition to a spec which you hope the browser manufacturers implement similarly, then watching until the market penetration of the version of the browsers you want reaches the right level.
"The entry barrier into web-based products comparatively vanishes: no downloads"
No downloads? So why did it take so long for me to load the demo? I'd like to know how I can get your product over the internet without downloading it.
"Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side"
Imagine having to load large parts of a game online every time you want to play it, rather than just opening a program. Also, realtime updates? Sounds awful. Fix one JS file and watch the fun as some people load an older cached version, others a new one, others loading in that file on level three after loading the older assets on level two. Something that was loaded 5 minutes ago is now trying to call a function on an object that's been renamed in the latest push. Not being able to load level 4 because the server is under strain...
As I say, it's got positives and negatives.