Using PlayCanvas without provided index.html file

Hello Community,

I am building a PlayCanvas application and want to integrate it into my website to place a UI over the top of it. However, the .zip file that comes at the end of the download process contains an index.html file that seems to be the way I launch my PlayCanvas app. The standard self-hosting approach seems to be via an iframe pointed at this index.html file.

That said, I don’t want to use an iframe. In fact, I don’t want to use the provided index.html file at all. I want to update all of the paths\to\file in the provided .js and .json files, and then drop all of the dependencies (start_.js, loading_.js, playcanvas.min, etc.) into my own html file. I would probably also change a few things inside of start.js and loading.js to support this approach.

  • Do you recommend a workflow like this?
    – If not, what alternatives exist that don’t involve PlayCanvas hosting or an iframe?
  • Does anyone know how often the JSON file schema is subject to change?
  • Would PlayCanvas still provide me technical support if I went this
    route, or would I be on my own since I am tinkering with aspects of
    their application that they don’t intend to be modified?

Any advice (or links to help me help myself) would be appreciated. I want to make sure I get the foundation of this project off on the right foot.

It is totally fine approach, then only thing is to make sure all mouse events will be tracked properly and there will be no weird keyboard overrides and conflicts between page and app.

So far I don’t even remember when last time we’ve changed that bit. What can change is we add few more fields there and there, but usually it is backwards compatible and takes in account scenario when it is missing.

We do support all users who create awesome content and keen to push WebGL forward with us. We give higher priority to our paid users and clients of course, because we still need to be able to pay our bills to provide all public with free tools and constant updates.

Are you still planning to use Editor, or you going to use engine off-tools?


You can find out all the ways you can publish your PlayCanvas application here: .

We have seen various workflows used by different users when they are self hosting depending on their situation. The problem with changing the downloaded files to a new structure is what do you do when you need to re-publish again and again. You’d probably need to automate that custom workflow with custom scripts so that you can easily re-deploy your application. Other than that we don’t really mind if you change the downloaded files. They’re yours to change.

Are you talking about JSON model files? This doesn’t change very often (at least it hasn’t changed in a long time so far).

We always provide support if we can, but if there is a totally custom architecture you’d need to share a lot more details for us to be able to understand what’s wrong. So you won’t be on your own but it might be harder depending on the issue.

My suggestion would be to first spend your time building the best PlayCanvas application that you can using the built-in workflow and worry about architecture on your end later if of course that doesn’t break your system.

Thank you both for such fast and thorough responses!

Probably a hybrid approach. The editor seems ideal for real-time feedback and a few other tasks, but other aspects will likely require an off-tool approach.

I recently started using HTML to draw over a playcanvas window. In my case, it’s for a HUD (heads up display).

The HTML file looks like this:

<h1><div id="loadstate" style="text-align:center;"> </div></h1>

<canvas id="application-canvas" class="GAME"></canvas>
<div class="HUD" id="HUD">

And the styles are:

.HUD {
    -webkit-touch-callout: none;
    -webkit-user-select: none;
    -khtml-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    user-select: none;
    margin: 0px;
    padding: 0px;

    position: absolute;
    left: 0;
    top: 0;
    width: 100vw;
    height: 100vh;
    background-color: rgba(255,255,0,0);

    left: 0;
    top: 0;
    width: 100vw;
    height: 100vh;

I am completely engine-only, using a custom loading script, custom just about everything. I don’t even use the playcanvas website to convert model formats as I wrote a blender exporter. The project using the HTML/css above is visible on gitlab.

The matrial JSON format changed about 8 months ago, but other than that there haven’t been any changes in the year or so I’ve been using playcanvas, and it was still backwards compatible.

I am happy to answer any messages you flick my way about workflow. In fact, I wrote this all up a couple days back as I got asked by another forum user. So I’ll copy-paste some snippets here:

As to their not being [an offline UI] for playcanvas yet, you shouldn’t need one. Every engine I write games for ends up looking exactly the same on my system:

Blender Game Engine:

Writing reports in Latex:

And several other non-game development things like web development, coding for embedded systems etc.

So for having a UI? I don’t want one. I just want a toolchain to allow me to use my own models without using their servers. I thought there was one when I started using playcanvas, discovered their wasn’t and so wrote my own
(I’ll give you a guess what my screen looked like while I was developing…). But I don’t like programs that use GUI’s very much except for art. In a game I’d rather manually load assets and place them from in-code.

From the other participant:

What do I mean? It’s not always possible (and is kind of slow) to place them in scenes like you do in, let’s say, Blender. Also, let’s say that you’re importing something, and in the end it is scaled / rotated incorrectly. And since there is inter-step (model should be imported via PlayCanvas) it’s not the fastest process to fix this simple problem. Tweaking materials? Same story. Without any editor it’s kind of time consuming to do this manually.

The thing to realize is that there is a difference between the game and the content.

The images I showed you above are all relating to making the game, not making the content. Making the content is done through several external programs: textures in gimp, sounds in audacity, music in LMMS, 3D model
assets in blender.For levels I also use blender. You link in assets, position them, and then export them to a format your game can read. In the case of my current playcanvas game it’s a json file. It contains a list of models to load, a list of spawn point location and orientations, light information etc.

So for an overal game development workflow this is what I tend to visualize it as:

in theory you could separate out level making into it’s own stream parallel to asset production, but I generally work in small teams and have only a single person on the art side.Time spent developing the gameplay (in that feedback loop near the end) is about double the time spent developing the assets. It doesn’t matter how big the game is, that tends to be a rule of thumb - at least in the projects I’ve completed.

Where is simplesix, my playcanvs project? It’s just about to finish the workflow development and core gameplay development. For simple six I did them in the other order - developing the core gameplay before the development
workflow. Things would have been better had I done it in the order depicted here. All of the lines from art into the game depend on that workflow/pipeline. Note this also includes defining what is the forward axis and scale. (Scale, axis, player size and son on should be written down, documeted and stuck on a post-it-note on your monitor)

So you can see that developing the models and art is quite distinct from developing the actual game. You find this in big game companies. You have a game engine development team (in this case playcanvas), you have a gameplay development team (in the case of simple six, me) and you have an art team (in the case of simplesix a friend and myself). So when I’m developing an asset my screen looks like this:

Notice that the selected object has the custom property “Type” currently set to “PrimaryWeapon.” This is noticed by the exporter and exported with the model. So if I want to tweak the player ship’s weapon spawn points, I can go to the asset, move the spawn-point and re-export.

Similarly with levels:

If I could be bothered, I could make the spawn-point icon be that of a player ship as opposed to just a set of arrows, but I haven’t yet. For lights it just looks through lights in the scene and exports those with their parameters already set. So it looks pretty similar in-game to in-editor.

So this is the part I am currently developing in my game: finishing off this workflow pipeline. The exporter doesn’t support multiple UV-map materials (so everything has to be baked to a single texture). The format for transferring non-model-data isn’t quite complete, and the exporter has some stability issues. I guess it will be another month or
two before I get it done to my satisfaction. (I’ll push it to github when I’m done)

But when it’s done it’ll be literally “file->export->playcanvas (.json)” to get a model or level into the game. The edit-test cycle as a result can be very fast for the artist developing the level/asset, and that is one of the critical parts about a good workflow. (another critical part is maintainability).

Now, simplesix is simple. You have levels, and only and handful of assets like the ship, lasers, missiles and explosions. The total number of model assets is only 8. What happens if we go higher? Say we have assets we use to build up levels. (currently simple six assumes a single model-file per level)
Well, we need to expand our workflow. So let’s use blender’s linking toolset and link assets into our level. Then expand the exporter to export “there is this object (url) at this position (vector) and orientation (quartenion).” Awesome. Adding a new asset? Model it, export it, link it into a level, export the level and hit play. Done. Maybe 2 minutes to get it in-game. Want to change the asset? re-export it, done. Want to change it’s location in the level? re-export the level.

It’s all about planning how you store and load levels. If you do good design work at the start of your game, it will keep things simple as you progress.

Notice how this workflow depends on something:

  1. Having a system that can export meshes (and materials)
  2. Having a system that can export levels to (probably) your own custom format
  3. Having a load system that can load your levels

Also notice that it doesn’t depend on the game engine having a nice user interface. Heck, you just ignore it entirely.

Using the playcanvas website to do your asset conversion is a pain. It takes too long to export to dae, upload, re-assign materials, download, extract. That takes like 15 minutes. That’s way to long to tweak things effectively. So you have to have an off-line asset converter that acts fast. The playcanvas loading system? Can’t load in lights let alone references to custom objects. Great, write your own. You’ll never find a pre-built game engine that does everything you want and this is one of the key issues for indie developers. They think the game framework/workflow is the same as the content. They never design/develop the workflow and as a result, trying to tune things like spawn-points, trying to manage assets, and trying to complete the game becomes hard.

So: spend some time thinking about the workflow.

But hey, I’m another weird developer with strong opinions about how programs should be. I am very against modern user experience trends. I think they make things a lot more complex than they need to be. There is nothing simpler than point-click-type, and that is what the way I work offers.

And that is the end of probably the longest post I’ve ever made. I hope it was useful, or if not, at least interesting.