PlayCanvas, the Web-first game engine | Hacker News Reader

PlayCanvas, the Web-first game engine

playcanvas.com

136 pointswiradikusuma45 comments

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.

I recommend checking out the newly released playcanvas-sync tools which let you map your PlayCanvas project's assets to your local machine's file system: https://github.com/playcanvas/playcanvas-sync Also, last month, the plans received a major upgrade: https://blog.playcanvas.com/plan-updates-more-storage-more-f...

It's certainly not super obvious to setup but there are ways to use PlayCanvas with local setup[1]. I have Redirector[2] 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.

[1] https://github.com/thisredone/coffeescript-playcanvas-templa... [2] https://chrome.google.com/webstore/detail/redirector/ocgpenf...

I think the engine is open source; but the real appeal is using the real time collab online tool, which is proprietary and had the drawbacks you mention.

The engine absolutely is open source, and there are no clauses pertaining to where the code must be hosted.

Their particular IDE may be closed-source, but the engine is not tied to it.

IIRC playcanvas was started by ex-mozilla people.

I played around with the engine a while ago and was quite impressed by the all-in-one-ness of it.

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/

Ahh, thank you for the correction.

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’m a game dev looking for something like PlayCanvas can you recommend alternatives? What did your studio end up going with?

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.

what did you guys end up using?

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 also went down that route and opted for three.js The downside is no decent game engine nor IDE, you end up writing your own engine and tooling.

Same cons that we came up with too. Which means it’s that’s much harder for anyone who isn’t a developer to make contributions to things like level design.

Interesting to see that PlayCanvas is now owned by Snap Inc recently: [0]

[0] https://techcrunch.com/2018/03/23/snap-reportedly-buys-its-o...

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...

Their lenses I think are all JavaScript, not sure if it’s WebGl rendering though, but it would make sense to do that to be cross platform

Check out on blog of released major features and releases on github for the engine. It is only growing.

An example of what could be done with it: http://venge.io

A competitive FPS shooter made in Playcanvas.

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.

The choice of hosting the game on a website seems like an orthagonal decision to whether or not to build it using web tech nowaday, as I mentioned.

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.

Thanks for the explanation, I simply get the idea now, so for a serious web based game, playcanvas would be the No.1 choice as of now?

What about Godot to wasm?

Compiling from most major non-web game engines to the web leads to incredibly bloated products. See: https://blog.playcanvas.com/playcanvas-versus-unity-webgl/

The blog is 4 years old but I think it's still relevant.

thank you so much for this reference, yeah really worth a reading, still very relevant today!

Interesting. I assume you can hook whatever javascript into it you want?

Yes. You can use it in conjunction with pretty much any other JS framework available.

I'll admit to being one of those anti-JS stick in the mud's, I really hate when people overload what should be a text doc with JS. However, this looks really cool.

I think partially it's that once you are doing something at this level, you are no longer just turning a document into an app, you are writing an app that can be deployed almost anywhere.

I think the future will trend in this direction to be honest.

edit: tend -> trend

It is a very nice engine, specially for those focused on Web only as target.

I wouldn't call it "web only", since the web runs everywhere. What PlayCanvas is king on, is having the same codebase and being able to play it on your desktop, laptop, mobile, and even smart tvs.

Well, surely web-only means that it didn't make concessions to work on other targets like UIKit.

Depends, many times, specially in what concerns games, it limps along.

Apple still blocks multitouch in fullscreen unfortunately.

Really? For webviews?

In Safari

I‘d love to be able to use their scene editor offline, uploading assets is a deal breaker

Is there support for networking/multiplayer games using this framework?

There's no networking built-in to the core engine but there's a tutorial to get started with Node.js: https://developer.playcanvas.com/en/tutorials/real-time-mult... PlayCanvas also works great with third party networking solutions like Nakama from Heroic Labs: https://heroiclabs.com/

Anyone know how compares to Godot webasm target?

Reply on news.ycombinator.com