For what it’s worth, when I was working at a mobile game studio, we looked at this as an engine for a project. At the time we decided not to go with it since all your code needs to live on their server and there’s no easy local dev environment.
Not sure what the state of play for this product is now, but at the time we considered it too risky a proposition (what if they go out of business tomorrow?) and too limiting for the cost they were asking to use their platform.
It's certainly not super obvious to setup but there are ways to use PlayCanvas with local setup. I have Redirector rules in my browser and that basically handles it.
So with some tinkering you can have hot module replacement and front-end libraries integrated for a very smooth and web-dev-y modern workflow.
PlayCanvas was started by ex-EA/Activision/Sony devs. But Mozilla partnered with PlayCanvas to open source the engine and later launch Firefox's WebGL 2 support with the After the Flood demo: http://aftertheflood.playcanvas.com/
How long ago that decision were made? PlayCanvas is still here, doesn't look like it is going anywhere.
For many years it existed, many people resist, some don't. But business is still here. And community grows. Portfolio of commercial projects as well.
A bit over a year ago now, so at least that much time has passed. It looked like a very good product then, looks like a very good product now. When I spoke to their support I was actually helped out by their CTO so I always felt it was a pretty rooted place.
But, at that time it didn’t meet our requirements.
I think they ended up using Phaser. I left before they actually released a game with that new stack. As mentioned below the cons are that you will need to invest more in making your tooling and it’s way harder for anyone whose not a programmer to use it. The pros were that it was very easy to work with, HTML first, and had a long enough track record to have ironed out a lot of common developer problems.
I recall our unity engineer quite liked Defold, which had an integrated builder tool, but for some reason the lead dev didn’t want to go with it.
I don’t want to be throwing shade on Play Canvas though, it’s possible if we did the same assessment today we would have gone with that engine.
I left the company before that decision really formalized itself but I think the lead dev was leaning towards using Phaser. I believe they’re using that now at least.
We had been using Unity for a long time but when the company decided pivot to HTML, we kept running into performance issues for for web (which left the Unity developer we had hired in a pretty awkward position).
I wonder how this has affected the development of PlayCanvas. I don't see any statements about the acquisition or even just a roadmap or statement about the future.
It looks like Snap bought it + a game studio and then launched a few html5 games inside of Snapchat. But I dont see anything after that. Seems like maybe gaming inside of snapchat just fizzled out? That doesn't bode well for PlayCanvas development...
Could someone explain the USP of utilizing the browser platform for game dev? As far as I know, the usual suspects in the game engine world can compile to web as well as the other major platforms. Wouldn't relying on web runtimes and all the bloat associated be a detriment?
Is it the JS ecosystem and [insert framework] UI that's tempting? Or just the shared dev environment?
Traditional game engines work in ways that aren't suited for browser based gaming. There is quite a bit of work that needs to be done in optimizing asset streaming without the need for long wait times.
You don't see the USP of websites, apps, and games that run at a browser url instead of requiring app download? I encourage you to throw out your prejudices and try to answer that one yourself.
Runescape is a good example. It ran on the school and library computers when nothing else could (much less anything that needed installation). Runescape is finally beta-testing native mobile apps, and it's hard to imagine it rising to so much fame for such a long time without its decision to run in the browser.
> You don't see the USP of websites, apps, and games that run at a browser url instead of requiring app download?
Unity, Unreal, Godot ... they all support the web as publishing targets. Without downloading a plugin. supporting the web is not unique. but if you design for the web, the engine will run better than compiling to it.
> Runescape is finally beta-testing native mobile apps, and it's hard to imagine it rising to so much fame for such a long time without its decision to run in the browser.
They've had a mobile version of "Old School Runescape" for over a year now I think, and it certainly did get me to play again for a bit. Mostly out of a curiosity of how they managed to fit all that UI on a mobile screen (turns out, pretty well).
Unreal no longer supports the web as a publishing target. They've marked that feature as deprecated. Unity still does, however, from what I've heard it's not a great platform to use for the web. Godot's wasm compile target is very new, I'm looking forward to seeing what comes from it.
Many native engines "can" compile. But really it is only experimental and commercially non-viable option.
Unreal engine decided not to continue support webgl target.
Unity lifted off "experimental" from webgl target, but really nothing changed - it is still huge build, crashes mobile, and development process for web in unity, simply awful. So it can compile, but commercially it can't compete with webgl-first engines on similar projects.