Thanks!! very kind of you to say so 
It took 24 github repos to make all of this in the end lol. But I’ll be able to use it myself on lots of things so - no biggy.
1 Like
This is heavenly sent!
Thanks a lot Mike for the ongoing contributions.
Taking Playcanvas to a whole different level of production.
I’m quite new to the web development pipelines. Am I right in saying that there’s a script/process in this tool that uploads the project source (ie PlayCanvas Components) to the project on the PlayCanvas servers?
There is a WebPack plugin that does that yes. https://github.com/whydoidoit/playcanvas-webpack-plugin
1 Like
Just wanted to add the following to my reasons for doing this project…
I want anyone to be able to come along and add a shader I wrote by typing npm install --save playcanvas-ssao-shader or to add my multithreaded nav mesh generator and follower using npm install --save playcanvas-a-star (those aren’t there yet but they will be soon). Why do I want that? Because in a few months time I want to type npm install --save that-thing-mike-didnt-do and benefit from a community building this stuff
One thing I’d like to mention here is that the assets REST API is not yet meant to be used by third parties so it might change or stop working without notice.
We are looking into making it available but don’t have an ETA yet!
1 Like
Yeah understood. It’s just working off what the editor does at the moment. If it did stop working then:
- Either: You can drag and drop the build file
- Or: Someone can fix the plugin
1 Like
I always wonder why PlayCanvas is not so much popular, like other solutions.
Because it is great, I really love it.
And I hope you just answered my question - people were need to use it with new web standards and technologies.
Thanks for this great work!
Agreed it is by far my favourite tool and for ages I’ve crammed it into my workflow while cursing the fact I keep having to browserify bits of my other code or write them again and I feel like I’m in a time warp writing ES5 async code
I mean, with the advent of these instant games in Messenger and the ubiquity of the web, I think it is a real choice against Unity for proper game development especially for mobile devices.
Where it’s lacking of course is:
- Mecanim (ok I’m trying to fix that over time with Blend!)
- Physics - an emscriptem port of anything is a bit of a nightmare until you can tell emscriptem that garbage collection is a total no-no - (ok so my Collision thing fixes this for me, but limits what I can write - one day I’ll have time to build that ground up physics engine).
- Navmeshes and path following
- A customisable editor or an open source editor, having one that is neither has been a real issue, we have dozens of Unity editor extensions - so I finally bit the bullet and built a proper extension, before PCE+ I had bits of code I’d drop in but no framework or way to easily distribute it to the team.
But for me the biggest single thing is that Scripts 2.0 had some lovely features but felt like it was making the whole system more of a “toy” with no source control. Collaborative coding or pair coding is great in certain circumstances but hardly a respected coding practice across large projects. Where is the TDD? The code review? The pull requests? I mean make the PlayCanvas Engine project be editable at any time by anybody you at sometime approved and it would sink into a bug ridden disaster.
I did have a sudden “Eureka!” moment when I realised I could use scripts 2.0 to manage the output of a proper build process and sudden get all of the features I wanted. Suddenly this is a tool that I can convince my team isn’t a thing we should use “when we have to”. We avoided 7 different developments on PC over the last 18 months in favour of poorer Pixi or HTML alternatives. We build 2 in PC. We could just have used the Engine, but like I say, that’s shooting yourself in the foot (and surely can’t help PC’s business model). No way I’m convincing people to give up Unity’s cycle speeds or building our own level editors.
I guess that my use case isn’t the “standard PlayCanvas user use case” but I’d argue that if more people had our needs for PC then it would significantly boost the usage and change the popularity immensely.
I’ve met a bunch of the PlayCanvas team a year or so back, they are super smart people, I certainly don’t want to second guess them. I’m hoping that this thread will lurk around the place and mean that developers or teams that come across PC but silently reject it because of the restrictive development architecture will read it and come on board. My second hope is that people really use this and we do get a growing community of npm packages for PC. It would totally revolutionise how people made choices for mini game development and probably how they chose for major projects too.
I guess the thing is that this forum is a community, but it’s a village, probably a hamlet. It needs to grow and push real discussion and revolution. People choose Unity because of the hugely supportive community. I know I did and thoroughly enjoyed being an active part of that community. But the Unity product is totally unfit for the purpose I have - mobile devices running HTML5/WebGl/Javascript.
[Rant ends]
7 Likes
+1 for the lack of version control. This is really important. When writing code with others, you can not do “code review”, especially when the project become large, the code base will become mess without version control.
Another thing I want to say is that the web based code editor is too poor, and without plugins I used in other editor(vim / sublime text). Can you guys provide plugin mechanism for the code editor ? Or provide api to let users upload scripts, that means we can use our favourite editor and use git/svn by ourselves.
1 Like
Well this template lets you do that…
Yes, I know. 
Although the implementation is based on something internal. I mean playcanvas team should consider exposing api for developers.
1 Like
Yeah it’s been on the cards for a while I think… I just looked at the editor code and saw how they did it.
I finally got this working but seems like when i try to update some code, the launch window shows an old version of the script. The server seems to have the correct one though.
Webpack compiles successfully if i make any changes, yet playcanvas shows an old version. Only way I can get this to work is by re-running npm run start which is much slower…
You’ve got the localhost thing running with the loading screen or startup script so it’s reading locally?
Check the network tab to see if it is getting it from there
Might want to have dev tools invalidate the cache
Can see your url (passing local=)? It;s not loading from local, it’s loading from pc
Oh your url has two ? in it
You need the second to be an &
i may not be attaching the loading screen 2_0 script correctly.
Not sure if its even running, its currently just sitting in the project folder, and not in the scene. I had attached my test.js script to an entity so this explains why it was being loaded via pc.
Should putting its loading order before build.main.js be enough to load the changes?