In PlayCanvas all logic is implemented by developer using scripting. Combined with components and attributes, developer has ability to customise UI in Editor on scripts and express logic of an app.
Current scripts are not an assets, although they “faked” to be there in scripts “folder” as assets. This is done for convenience. So they cannot be organised in folders as assets.
Current scripts cannot be defined in runtime, so no dynamic coding is available.
Current scripts can’t be concatenated, minified, obfuscated and there is no possibility to define multiple Script Objects per file.
There is no ETA on this, but it is very soon (weeks/months).
Some terms to agree on:
Script Object - is actual playcanvas script definition, currently is a function returned within
Script Instance - is what engine creates using script object, and attaches to entities under script component.
We’ve been looking at many limitations of current system, and are working right now on new system, that will address existing problems, as well as enable new features.
So we want to share some info on what we are working on and how we are seeing this. Any feedback and suggestions will be very useful, feel free to comment bellow.
Concatenation - ability to concatenate scripts on publish. This will reduce loading times, especially on connection with high latencies and projects with large number of scripts.
Multiple Script Objects per file - developer will be able to have one script asset with multiple script object definitions in it. This is especially useful for off-tools users.
Code Minification - it will be possible to automatically minify concatenated script file on publish, obfuscating and making your code more protected and harder to inspect by third party.
Collaborative Editing - those of you working in teams, already experienced collaborative editing of document type assets (html, css, shader, json, etc), but this was not possible with old scripts, as they are not assets. New system will allow collaborative editing and will protect against code overrides when multiple people are editing asset.
VanilaJS - we want to make it simpler and easier to understand, smaller boilerplate will be more newbie friendly and will have less learning requirements. As well as will enable some JS features, for example inheritance.
Script Registry - for those who are working on large projects, with complicated code base, will have ability to load script assets in async, and know when particular script objects are available. As well as ability to inspect and manage script registry from code.
Referencing by script name - in old system, scripts are referenced by their filename. This limited us a lot: no folders, no multi-script files, referencing non-playcanvas scripts, and other issues. We are moving away from this, and now components will be referencing Script Object Names, regardless of where they are defined. This enables more interesting workflows and ability to swap script objects easier during development, as well as developer don’t need to know where it is defined, simply type name of script object, and it will just works.
Loading Order - in old system, we allowed to non-playcanvas scripts to entities, for example jquery would be added to root. So developers end up having dozen of scripts attached to root. Then if order of loading has to be very precisely managed, old system have Script Priority list, which is well hidden and people simply don’t know about it. We are changing this too. So new system will be simple as this: if script asset is marked to be preloaded (by default true), it will be added to projects Script Order list, which is available from different places, including from script asset it self. This list will have all scripts that are going to be loaded, and developer can order them as required by simply dragging them within a list. No more entities with non-playcanvas scripts, and magical ordering of loading scripts based on depth-first search within hierarchy.
Code Hot Swap - my favourite. It allows to reload script instances without reloading the project. This will boost development process for advanced users dramatically. We want to make a system, where developer can optionally define
swapmethod on Script Object, which will be used for inheriting state information from old script instance and that is developers responsibility to implement. Then if script has been changed in Editor, it will reload script in launchers and update Script Object definitions within script registry, then use
swapmethod on script instances to perform swapping.
Script as Asset - in old system it is not an asset, that has many limitations. New system implements script as asset. Allowing us to simplify a lot, and allow developers to deal with scripts as with assets, organise them within folders as they want and interface with them as with assets.
Script Attributes - old system initially was small for script attributes, then got a bit improved with time multiple times. But some initial decisions lead to weird limitations. We are rethinking the way attributes will be defined, and work. In new system attributes are runtime friendly, this will add events when attribute is changed. Additionally we are changing some definition format, simplifying it and adding more variations and options to attributes. This will allow us to add more new attribute types.
Failure Tolerant - we do want to assist developers as much as possible. So new system will not only notify generic issues, such as missing script definition or script definition collisions in Editors UI. But as well we will be handling exceptions and errors in more efficient way, so to assist developer in debugging, and preventing applications from full-crash when only small thing is not working in one of the scripts.
Local Workflow - some of you use local workflow, with possibly version control systems. Initially new system will not have features to support this. But we will come up with even better solution later on.
Incompatibility with current system - this will not be applied to existing projects. Systems are conceptually and technically different, making automatic migration impossible. Although we will implement migration process and UI in Editor for people to upgrade their old projects to new system. New system will not limit or nerf existing system, and we will continue supporting current system as long as needed.