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:
<body>
<h1><div id="loadstate" style="text-align:center;"> </div></h1>
<canvas id="application-canvas" class="GAME"></canvas>
<div class="HUD" id="HUD">
</div>
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);
overflow-y:hidden;
overflow-x:hidden;
}
.GAME {
display:block;
margin:-1px;
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:
Playcanvas:
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:
- Having a system that can export meshes (and materials)
- Having a system that can export levels to (probably) your own custom format
- 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.
