-
Notifications
You must be signed in to change notification settings - Fork 13
Scripting research
Being able to author scene functionality through scripts is a vital part of a virtual world toolkit. Tundra 2 uses Qt's QtScript engine to implement support of JavaScript for scripting. tundra-urho3d does not yet have a scripting engine embedded. This document describes some requirements and findings regarding scripting support, but does not commit to any decisions yet.
The following factors affect the choice of the scripting language and its engine:
- Familiarity and expressiveness of the language (basically, how easy/powerful will it be to use, and how intuitively it matches the C++ API)
- Platform support of the scripting engine
- Performance of the scripting engine. Both in terms of running the language itself, and the binding of Tundra's C++ objects (which includes marshalling data between script & C++)
- License of the scripting engine. Should be permissive such as MIT/BSD/Apache. LGPL will be problematic on mobile platforms, as the user can not be expected to be able to reasonably replace the engine library within a published app bundle.
QtScript's downsides are a big memory footprint (about 1MB per running script instance) and ineffective bindings. Due to tundra-urho3d not using Qt it is also out of the question.
The following platforms are considered here:
- Desktops (Windows, Linux, OSX)
- Mobiles (iOS, Android)
- Web (compiling tundra-urho3d through Emscripten, which is not supported yet, but feasible with some work)
Support for iOS and web platform rules out scripting engines which are only able to function through JIT compilation to machine code. For example Google V8 or LuaJIT would not run on iOS.
For familiarity with existing Tundra scripting, JavaScript would be an obvious choice. The API's can not be expected to stay 100% same compared to Tundra 2 though, as tundra-urho3d will not have Qt widgets in any case.
For expressiveness, performance and platform support AngelScript is a strong contender. It is less known than Lua and JavaScript, but implements OO paradigm in a clean manner that resembles C++ / C# / Java.
Urho3D itself supports AngelScript and Lua, but this does not have to affect the scripting language choice of tundra-urho3d, as it builds Urho3D without scripting support anyway, and will integrate scripting on its own. But as a language and bindings performance benchmark, it can be noted that AngelScript examples in Urho3D run about 1.5x faster than their Lua counterparts. This is when using Lua without JIT.
As a scripting engine, AngelScript is small and easily manageable, and supported on all listed platforms. The web platform will require use of generic bindings, as the native bindings (machine code) are not available.
On the web platform there will be a performance penalty of running the scripting engine (C/C++ compiled with Emscripten) inside the browser's JavaScript environment.
Using JavaScript as a scripting language, this might be possible to circumvent by not compiling a JavaScript VM such as SpiderMonkey through Emscripten, but evaluating scene script assets with the browser's JavaScript environment. This is similar to how eg. webrocket runs scripts. The tundra-urho3d C++ classes would be exposed as JavaScript-visible using embind. This requires additional research to determine the actual feasibility.
Regardless of the language and scripting engine chosen, an important part of the scripting work is to automate the generation of Tundra C++ class bindings. When new variables / functions are added to Tundra classes, generation of updated bindings should ideally be a "run this batch file" kind of operation, without manual tweaking needed afterward. This may require annotating the Tundra C++ headers.