Any plans for scripting support?

[amerkoleci]

Do you plan to add scripting language support, Lua or Mozilla Spidermonkey with Javascript support?

[floooh]

No plans yet, but from general experience:

• I would tend to a minimalistic Lua interpreter since it is small and self-contained (I don't want to bloat client code size too much)
• no 'deep' integration into the engine, it should be possible to write games/apps completely without, or with a different scripting language
• but I start to feel the need for some sort of REPL environment (built-in command shell, IMGUI integration, ...), but mainly for faster incremental development, not so much for runtime scripting
• engine features should be exposed to the scripting language in a way that isn't too 'intrusive' to the rest of the code, I'm thinking of some sort of class/method/property annotation macros which can be compiled to 'nothing' if no scripting or editor functionality is compiled into the engine (similar to Unreal Engine's UPROPERTY).

[marynate]

hi, floooh, since we're on scripting topic, I wonder what's your opinion on script hot reloading support? e.g. deploy to device once, and monitor/hot reload changed scripts (from local storage or via network) while prototyping game play

When prototyping games for mobile (especially iOS), the build->deployment cycle is simply too long for fast iteration.

[floooh]

Yes that sounds like a good idea, I'm personally a bit of a sceptic of gameplay scripting, but having a robust and extensible scripting layer is definitely a good thing, it would also make the engine useful for people who are not fluent in C++... Near term I'm more interested in a runtime inspection and editing system, but this and a scripting system have the same core I think... where modules can register reflection information which can be used to either attach a runtime inspection UI or a scripting language...

I'm currently not sure how much of this should be 'static' code generation during the build process, and how much should be done through a 'dynamic' reflection layer at runtime (priority should be first to keep the client small, and second performance overhead)

Usage scenarios could be:

• built-in Quake-style console with commands and variables
• built-in slim editor UI which allows to tweak variables (nice for small demos, may be based on imgui)
• add support for different scripting languages
• remote-control TCP port where full-blown editor tools can attach to (with 'proper' UIs, e.g. Qt), should also be able to attach to a remote app running on a mobile device

Most important to me is that the 'base' of exposing interfaces/classes/variables to the reflection module doesn't add much programming overhead or impose code design restrictions, and that all of this can be compiled out with compiling switches (so the engine design should always remain independent from scriptability).

[pjako]

I think wren (http://munificent.github.io/wren/) and duktape (http://duktape.org/) should be considered aswell.

[RobertoMalatesta]

+1 for Duktape,

since not only it runs Typescript transpiled Javascript but it now seems to be robust enough to run the tsc compiler as well.

IMHO, Typescript is the way to go in terms of scripting. I've been using it on rather large projects (>20k lines): it's really productive and enjoyable.

Just my 2c,

--R

[pixelpicosean]

Ducktape +1, using JavaScript also makes it possible to run the scripts without a VM while targeting emscripten or asm.js.

[JaredSartin]

I would greatly enjoy Lua... If scripting support is still considered. I may even try to bind to it myself with Sol.

[ghost]

Wren has some interesting performance tricks.