PlayCanvas REST API


Today we’re launching the first version of the PlayCanvas REST API.

The REST API is available to all Organization account holders and allows developers to automate processes to help them with their development. For example, you can use the API to create a daily build of your application and download it via a build server. In the future we’ll be expanding the API with additional features like access to assets and more.

You can read more details about the API in the documentation.

We’d love to hear your thoughts on how you are using the API and what you’d like to see in the future. Let us know on our forum.

PlayCanvas versus Unreal WebGL

Our previous article comparing PlayCanvas with Unity’s WebGL exporter certainly got folks talking. One of the questions that came up in the aftermath was “OK, but what about Unreal’s WebGL exporter?”. Unreal, like Unity, relies on Emscripten to port the native codebase to JavaScript. So it would be reasonable to expect Unreal to suffer from the same issues as Unity: large download sizes, long load times and poor runtime performance.

We could do the same experiments as before with the textured cube, but let’s try to make a more real-world comparison. Flappy Bird clones have been made in both Unreal and PlayCanvas. Let’s take the Epic-authored Tappy Chicken and see how it fares against the PlayCanvas-powered Flappy Bird. Here’s the  (playable) PlayCanvas game:

Unfortunately, I can’t embed Tappy Chicken because Epic have restricted it to desktop browsers. So here’s a link to it, along with an animated GIF:


So before we begin, there’s an important point to make. They are not the same game and they do exhibit certain differences. Tappy Chicken uses different textures, has parallax, uses particles and so on. But in essence, they are remarkably similar and worthy of a comparison, despite not being pixel perfect clones of each other. It’s up to you, dear reader, to decide if the differences in the games account for the results of the analysis presented below.

As before, we will look at three key metrics: download size, load time and runtime performance.

Download Size

To check the download size of each app, we disabled the cache in Chrome Dev Tools and recorded the total transfer:

Tappy Chicken (Unreal) Flappy Bird (PlayCanvas)
10.0MB 0.22MB

Epic’s game is over 47 times larger than the PlayCanvas game. Again, we see an Emscripten dependent engine struggle with download size. Just the JavaScript of Tappy Chicken accounts for 7.3MB of the entire 10MB payload, and that is the GZIPped size. Uncompressed, it is over 36MB of JavaScript. PlayCanvas’ hand-written, ‘JavaScript-first’ approach wins out here, with a tiny 147KB footprint (615KB uncompressed) for the entire engine.

Load Time

Unfortunately, Epic prevents Tappy Chicken from running on mobile so we’ll just test load times on desktop. For the test, we’ll use a Core i7-powered Win10 machine on a 50Mb/s connection to the net. The browser cache has been disabled.

Browser Tappy Chicken (Unreal) Flappy Bird (PlayCanvas)
Chrome 52 15.8s 0.9s
Firefox 48 11.0s 1.4s
Edge 14 23.6s 1.1s

The PlayCanvas game was also run on a number of mobile devices and always runs at 60Hz and loaded in under 2 seconds.

Things to notice:

  • Chrome loads the PlayCanvas game 17.6 times faster than the Unreal game. Other browsers show impressive multiples too.
  • Firefox loads the asm.js-based Unreal runtime the fastest. Since Emscripten is a Mozilla technology and Firefox is heavily optimized for asm.js code, this is not a great surprise.
  • Load times appear to depend on more than just loading the game files. Preprocessing 36MB of JavaScript also contributes to the slow Unreal load times.

Runtime Performance

To analyse runtime performance, let’s compare captures of the two games using the Timeline panel in Chrome Dev Tools. Here’s a capture for the PlayCanvas-powered Flappy Bird showing a frame executed in 0.57ms:


And here’s a capture for the Unreal-powered Tappy Chicken with a frame executed in 5.0ms:


In each capture, a typical frame has been selected. Not the fastest, not the slowest. Just an ‘average’ frame. Note that both captures are showing a frame at the same timeline scale.

Things to notice:

  • CPU load in the Unreal game is typically around 8x greater than for the PlayCanvas game. Taking the ‘Composite Layers’ step of the browser into account (green bar in the Timeline captures), the multiple is closer to 6x. So although both games generally lock to 60Hz on the test hardware, the PlayCanvas game can process a frame well within a millisecond whereas the Unreal game is clearly stressing the CPU. On lower end hardware, the Unreal game would become CPU bound.
  • CPU load is much more variable in the Unreal game and spikes regularly. Without understanding the internals of the Unreal engine, it is hard to explain this. But the result is sporadic frame drops.


To summarise:

  • Epic’s game is over 47 times larger than the PlayCanvas game.
  • Chrome loads the PlayCanvas game 17.6 times faster than the Unreal game.
  • CPU load in the Unreal game is typically around 8x greater than for the PlayCanvas game.

To be fair, Epic say the following in their documentation:

The HTML5 pipeline is currently experimental. Some projects may not run properly when built for the HTML5 platform. Expect some rough edges.

But we clearly see here that Unreal suffers similar problems to Unity’s WebGL exporter. Export sizes are huge, load times are long and runtime performance is poor when compared to a ‘WebGL-first’ engine like PlayCanvas.

To learn how PlayCanvas built an engine so optimized for the browser, head over to GitHub to explore the open sourced runtime. And if you want to start building with PlayCanvas today, sign up for free on To check out the Flappy Bird project, click here.

PlayCanvas versus Unity WebGL

A question we get asked a lot is “How does PlayCanvas compare to Unity’s WebGL export?”. So let’s examine this in a blog post.

But first, let me quickly introduce Unity and PlayCanvas to the uninitiated. Unity is a game engine provided as a native, desktop application for Windows, Mac and Linux. PlayCanvas is an HTML5/WebGL game engine that is provided as a web application that runs in any browser on any operating system.

For the purpose of this article, we’re keeping things simple. We’ve created the ‘Hello World’ of apps in both Unity 5.3.2 and PlayCanvas: a spinning, textured cube:

The application above is the PlayCanvas app. I’m not embedding the Unity app since it can crash the page (if you’re feeling brave, click here to run it in a new tab).

We decided to look at 3 key metrics: download size, load time and frame rate.

Download Size

To check the download size of each app, we disabled the cache in Chrome Dev Tools and recorded the total transfer:

Unity PlayCanvas
4.72MB 0.22MB

The Unity app is over 21 times larger than the PlayCanvas app. How is this possible? The PlayCanvas engine is a miniscule 147KB when GZIPped meaning the code and assets for the app account for the remaining 73KB. The engine is so small because it is hand-crafted in JavaScript, relying on as much functionality as possible from the browser itself.

Unity, on the other hand, relies on Emscripten to export to WebGL. This tool auto-converts C# code to C++, which in turn is compiled to LLVM before finally being turned into JavaScript. A side effect of this process is the generation of huge amounts of code, which bloats the exported application, overwhelms modern JavaScript engines and often causes the browser to run out of memory.

Load Time

We ran both apps on 12 different devices, from low end to high end. These were the recorded load times on a 50Mb/s connection to the net:

Device Browser Unity (s) PlayCanvas (s)
iPhone 4S Safari Crash 2
iPhone 5S Safari 18 1
iPhone 6 Safari 17 1
iPad Mini 2 Safari 21 1
Samsung Galaxy Tab S2 Chrome 51 19 1
Samsung Galaxy Note 10.1 2014 Chrome 51 28 1
Samsung Galaxy S6 Edge Chrome 51 28 1
Samsung Galaxy Note 4 Chrome 51 28 1
LG Nexus 4 Chrome 51 44 2
Leapfrog Epic Chrome 51 43 1
Blackberry Z10 Default Browser Crash 1
PC (Core i7 + GeForce GTX 880M) Chrome 51 13 1

Key things to notice:

  • The PlayCanvas app’s load times are up to 43 times faster than the Unity app.
  • The Unity app fails to even load on lower end devices. The sheer amount of JavaScript causes the browser on those devices to run out of memory loading the page.
  • Load times for Unity are up to twice as slow in Chrome as Safari. This could be down to Chrome spending more time preparing the app’s huge JavaScript codebase for execution.

Frame Rate

Here are the frame rates recorded for the same set of devices:

Device Browser Unity (fps) PlayCanvas (fps)
iPhone 4S Safari Crash 58
iPhone 5S Safari 21 60
iPhone 6 Safari 28 60
iPad Mini 2 Safari 16 60
Samsung Galaxy Tab S2 Chrome 51 17-55 60
Samsung Galaxy Note 10.1 2014 Chrome 51 15-50 60
Samsung Galaxy S6 Edge Chrome 51 15-50 60
Samsung Galaxy Note 4 Chrome 51 15-57 60
LG Nexus 4 Chrome 51 15-50 60
Leapfrog Epic Chrome 51 16-55 60
Blackberry Z10 Default Browser Crash 60
PC (Core i7 + GeForce GTX 880M) Chrome 51 57-60 60

Key things to notice:

  • PlayCanvas frame rates are up to 4 times greater than Unity. In particular, Unity seems to perform poorly in Safari on iOS.
  • Unity exhibits very unstable performance in Chrome for Android. Initially, the app’s frame rate is in the mid to high teens for approximately 20 seconds before it starts to rise to a number in the 50s. At that point it, it regularly drops frames and never reaches a solid 60FPS.
  • PlayCanvas easily locks to 60FPS across all devices except iPhone 4S where an occasional frame is dropped. Ideally, a much heavier stress test would be required to start taxing PlayCanvas.


To summarise:

  • Unity WebGL apps are up to 21 times larger.
  • PlayCanvas apps load up to 43 times faster.
  • PlayCanvas app frame rates are up to 4 times higher.

Even for the most basic of 3D apps, Unity struggles to achieve anything close to acceptable download size, load time and frame rate. It’s important not to somehow blame browser vendors or HTML5/WebGL for these results. As PlayCanvas proves, you can achieve incredible performance using these web technologies today as long as a sensible approach is taken when architecting an engine.

To learn how PlayCanvas built an engine so optimized for the browser, head over to GitHub to explore the open sourced runtime. And if you want to start building with PlayCanvas today, sign up on

If you want to look at the original projects that built the two apps used in the article, here is the Unity project, and here is the PlayCanvas project. After publishing this article, we noticed that the Unity project disables hardware anti-aliasing and uses bilinear filtering on the textures, whereas PlayCanvas enables AA and trilinear on the textures. So PlayCanvas is actually doing more work here.

Organizations & new plans

Today we’re pleased to launch Organizations for PlayCanvas users along with an updated and simplified set of plans including unlimited projects and more storage.


An organization offers you a convenient way to manage users and projects for businesses or for larger projects. With an organization you can specify multiple administrators who can add and remove users with project based permissions. Additionally, organization plans come with a convenient single invoice for your business.


New Plans

Our new plans offer big bonuses over our previous plans including unlimited projects and increased storage.

Previously we offered 7 different plans with an array of options which has led to confusion in the past. Today, we’re simplifying our plans down to just 3 and you’ll be pleased to hear they include a big increase in the number of projects you can make and storage. Here’s what the new plans look like:


We now offer two paid plans and the biggest change you’ll see is that they both have Unlimited Private Projects and a big boost in storage space. The second change is that they both follow a simple per-seat model so you only pay for the number of people in your team.

The Free plan is great for getting started, learning about PlayCanvas or making your first few applications. With a free plan you can make an unlimited number of public projects and there are no limits on how many other users you can add to your public projects.

If it’s just you but you want to work with private projects, the Personal plan is ideal. This plan is great for individual developers or for small teams. It is just $15 per user/month, you can make unlimited private projects and you get 1 GB storage for your assets. The Personal plan is also required if you want to download the HTML of your project and host it on your own server.

If you’re using PlayCanvas for your business, the Organization plan is for you. With this plan you can manage your team members, remove the PlayCanvas loading screen and more features like offline archiving for your projects. The Organization plan costs $50 per user/month and you get 10 GB storage for your assets.


Realtime Chat Lands in the PlayCanvas Editor

Hot on the heels of the new scripting system, we’re happy to announce the arrival of realtime chat in the PlayCanvas Editor!


PlayCanvas has always been designed with collaboration in mind. Developers should be able to seamlessly work together to build scenes. But until now, you’ve had to use Skype, Slack or some other chat app alongside the PlayCanvas Editor. But no longer! Added to the bottom left of the Editor’s 3D view, there is now an expandable chat control. Team members in the current scene can now easily communicate and coordinate actions!

There are lots of cool features in the chat control. For example, hyperlinks are automatically detected. And desktop notifications are sent if you happen to have switched to another tab:


Try it out and give us your suggestions on how we can make it even better. And if you’re a WebGL developer that’s never tried PlayCanvas before, you’re seriously missing out! Sign up today at!

PlayCanvas Scripts 2.0

We’ve just launched “Scripts 2.0”, a complete re-design and re-implementation of the scripting system for PlayCanvas applications. Our goals were to fix an array of small irritations that had built up over using the PlayCanvas scripting for the last few years and take the opportunity to clean up the interface and simplify the creation and usage of scripts.

Here’s a list of the improvements you can enjoy with the new script system:

  • rapid iteration by hot-swapping code at run-time
  • real-time collaborative code editing
  • script concatenation and minification for publishing
  • better error handling and fault tolerance
  • full folder support for script assets
  • multiple script definitions in a single file
  • simpler interface and boilerplate

Live hot-swapping

If you choose to, you can now allow your scripts to update all running instances of your application. We dynamically reload scripts after they change. By implementing a single swap() function, you can transfer state into your new script instance and carry on as if nothing had happen. Except you’ve got all your new code!

Real-time collaborative code editing

Now that scripts are first-class assets, we now support real-time collaboration in the Code Editor. This means you’re no longer in danger overwriting other people’s code. In fact, you can see it appear as they type.

To help support this, we’ve also improved the error handling and fault tolerance of scripts while they’re running. This means bad scripts won’t bring your game screeching to a halt, preventing everyone from working.

Script Concatenation

With the new script format we now support multiple script definitions in a single JavaScript file. We’ve added the option to concatenate and minify all your scripts into one file when you publish. This will save you many HTTP requests and reduces the size of your application, making for a much quicker start up time.

How do you find these new scripts?

Scripts 2.0 is live right now and any new projects you create will have the new script system enabled. However, if you’re not quite ready to move to the new system or you need some of the features that are currently only available with the old system, you can still create projects using the “Legacy Script System”. Look for the option in the new project dialog.

If you haven’t tried PlayCanvas before:


Getting started with WebVR


Did you hear? VR is BIG! But what is bigger than VR? The web, that’s what. What happens when you mix the web and VR?

WebVR is an emerging standard that lets you create 3D virtual experiences on the web and control them using your mobile phone or VR headset. But creating virtual reality is a complex process involving knowledge of WebGL rendering, new input APIs and (at the moment) a constantly changing spec.

That’s why we’ve introduced the VR Starter Kit in PlayCanvas.


Variance Shadow Maps for WebGL and More!

May is drawing to a close and it’s starting to feel like summer here in London. Let’s celebrate with a PlayCanvas Dev Update! We’ve been busy bees, so here’s a rundown of the main changes.

Variance Shadow Maps

The light component now allows you to select a shadow type. In addition to the current PCF Shadow Maps, there are new options for 8-bit, 16-bit and 32-bit Variance Shadow Maps. 8-bit VSM uses a small amount of GPU memory and is guaranteed to work on any device but is lower quality. 32-bit VSM uses a lot of GPU memory and relies on a device’s ability to render to floating point textures but the quality is very good. 32-bit VSM will gracefully fall back to 16-bit and then to 8-bit should the device not provide the required capabilities.

Let’s compare PCF with VSM. First, here’s PCF:


And here is VSM:


The big advantage of VSM is the ability to apply large blur kernels, which would be prohibitively slow with PCF. As you can see, the results are most pleasing!

VSM is still work in progress so expect more updates to land in the engine in the coming weeks.

Reworked Editor Camera Controls

We’ve completely rewritten the controls for the Editor camera in the 3D view. It should be far more intuitive now and also enable you to be more productive. For example, we have changed the behavior of dollying the camera to be based on what the mouse cursor is pointing at. This makes it feel much more similar to Google Maps:


Easy Asset Inspection in Dev Tools

We’ve made it so your assets are displayed in your browser’s Dev Tools as they are in Editor’s Asset Panel. This makes it much easier to locate, inspect and debug when running your game launched from the Editor.


Engine Optimizations

We’ve performed a thorough round of engine optimizations, aimed at speeding up your games, but also to reduce memory allocations to avoid garbage collection stalls. Specifically, we have:

  • Created a special profile build of the engine which is now only used when you run the PlayCanvas Profiler from the Editor. The regular non-profile build has the code that collects all of the timing and statistical information stripped out.
  • Optimized many commonly used functions. Here is a good example.
  • Removed many allocations that used to happen at runtime. Here is a good example.

Other Changes

  • Editor tooltips have been refactored with any missing ones added.
  • Improved reporting of an asset’s references when right clicking it in the Asset Panel.

New Tutorials: Multiplayer with Node.js and WebGL & Facebook SDK

We’ve added two new tutorials to our developer site this week.

How to create a real time multiplayer game with Node.js and PlayCanvas – READ MORE

Real ti

How to use the Facebook SDK in your WebGL application – READ MORE


You can find loads more tutorials on our developer site.

Runtime Lightmap Generation for WebGL

For many years, lightmapping has been the mainstay of achieving low cost yet realistic lighting. However, it’s rarely seen in WebGL applications because generating lightmaps requires third-party modelling applications with complex workflows in order to bake out textures.

All that changes today as we introduce Runtime Lightmap Generation into the PlayCanvas Engine.