Unlike the edittime, the runtime runs in a browser. This means you have access to all browser technologies, ranging from WebSockets and AJAX to the Web Audio API. Exciting stuff!
Strict mode
Runtime scripts must conform to the ECMAScript 5 "strict" mode. This helps reduce bugs and allow javascript engines to run the script faster. To find out more about Strict mode, see this blog post by John Resig.
Object recycling
To reduce garbage collector overhead, Construct 2 recycles the javascript objects for instances when objects are created and destroyed at runtime. For more information, see onDestroy() in the next section.
jQuery
Construct 2's javascript runtime includes jQuery. All plugins and behaviors may assume the presence of jQuery 1.6.3 (or higher, if it is updated in future builds) when they are running on a browser-based platform. Note jQuery is not included with non-browser platforms, which include CocoonJS and directCanvas.
It is preferable to access jQuery via the full name (jQuery.foo()) rather than the short name ($.foo()) in order to maintain compatibility with other scripts that may be running in the page. For examples of using jQuery, the Mouse and Keyboard plugins use jQuery to detect input events.
You can find out more about jQuery at http://jquery.org/.
Debugging
Most browsers report javascript errors silently. If your plugin script contains an error, the browser will probably ignore the entire script. This will then prompt an assertion failure during preview similar to "Plugin 'FooBar' is not available". To see the error that caused this, most browsers provide a javascript console. You can find it in the browser menus, or one of the keyboard shortcuts Ctrl+Shift+J, Ctrl+Shift+K, or F12 may work. Most major browsers also implement full javascript debuggers (with breakpoints, watch, call stack etc.) via the same console.
Google Closure Compiler compatibility
When exporting, Construct 2 gives the user the option to 'Minify script'. This runs the common and runtime scripts through Google Closure Compiler's ADVANCED_OPTIMIZATIONS mode. This imposes some limitations on what scripts can do. You must obey these limitations when writing your plugins, otherwise your plugin will be broken on export. More details can be found on the Closure Compiler website.
The main thing is to always use dot syntax (Object.property) rather than bracket syntax (Object["property"]) in your own code. All properties using dot syntax are changed by Closure Compiler, but none of the properties in bracket syntax are changed. Therefore, if you use Object.property in one place and Object["property"] in another to access the same property, the plugin will be broken on export. You may still use bracket syntax (e.g. for a dictionary of user-inputted strings) - just be aware of how Closure Compiler will transform the code.
If you refer to external libraries, you must always use bracket syntax (i.e. Object["property"]). If you use dot syntax, Closure Compiler will rename the property and it will access the wrong property of the external library after export.
Remember the edittime scripts are not passed through Google Closure Compiler, so you can write them how you like.
The Document Object Model (DOM)
As with any javascript running in a browser, you can modify and update the DOM. However, this is not recommended in plugins and behaviors for three reasons:
- Construct 2's exported projects are intended to be totally self-contained. Ideally the canvas is the only page element affected by the script.
- Any DOM elements you change may not be present on some pages, or may be present but intended for a different purpose on other pages. Therefore modifying DOM elements can break compatibility with some pages.
- Non-browser platforms like CocoonJS do not have a DOM, so your plugin will most likely not work on these platforms.
With careful consideration to the above three points, you could still try experimenting with DOM features in plugins.